If your organization sends mail from Microsoft 365, a marketing platform, a ticketing system, and a website form, you need a create SPF record plan before mail starts bouncing or landing in spam. SPF is the basic DNS policy that tells receiving servers which systems are allowed to send email for your domain.
Quick Answer
To create an SPF record, inventory every legitimate sender, write one DNS TXT policy that starts with v=spf1, add only the authorized IPs or provider includes, publish it on the sending domain, then validate it with test mail and header checks. SPF helps stop spoofing, but it works best with DKIM and DMARC.
Quick Procedure
- Inventory every system that sends mail for the domain.
- Collect each provider’s SPF instructions and authorized IPs.
- Write one TXT record starting with v=spf1.
- Add ip4, ip6, and include mechanisms only where needed.
- Choose a final all qualifier, usually ~all for testing or -all for enforcement.
- Publish the TXT record in DNS for the correct domain or subdomain.
- Send a test message, inspect headers, and fix any failures before broad rollout.
| Primary Topic | Create SPF record for email authentication |
|---|---|
| Record Type | DNS TXT record |
| Core Syntax | v=spf1 plus authorized mechanisms |
| Common Qualifiers | +, –, ~, ? |
| Best Practice | Keep the policy lean and within SPF lookup limits as of July 2026 |
| Related Controls | DKIM and DMARC for layered email security |
| Validation Method | Test mail, header review, and DNS lookup checks as of July 2026 |
What an SPF Record Is and Why It Matters
SPF is the Sender Policy Framework, a DNS-based email authentication method that publishes which servers are allowed to send mail for a domain. The receiving mail server checks the connecting IP address against the domain’s SPF policy during SMTP delivery. If the source is authorized, the message is more likely to be accepted and trusted.
SPF matters because email spoofing is still one of the easiest ways for attackers to impersonate a company. A valid SPF record reduces the odds that a malicious server can send mail pretending to be your domain. It also supports deliverability, because mailbox providers use authentication signals when deciding whether a message belongs in the inbox, spam folder, or quarantine.
SPF is not a content check. It tells a receiver whether the sending infrastructure is authorized, not whether the message body is honest. That is why SPF alone does not stop every phishing attempt.
The business value is straightforward. Fewer spoofed messages means less brand damage, fewer help desk tickets, and a cleaner signal for mailbox providers. For the practical side of email security, the U.S. Cybersecurity and Infrastructure Security Agency recommends layered authentication and anti-spoofing controls; see CISA Email Authentication guidance and the framework guidance in NIST Cybersecurity Framework.
Visible From Address vs. Envelope Sender
The address users see in their inbox is the From address. SPF usually checks the envelope sender, also called the return-path, and sometimes the SMTP identity presented in the HELO/EHLO exchange. That difference is where a lot of SPF confusion starts.
If your marketing platform sends a campaign using your brand’s visible From address but the envelope sender belongs to the vendor, SPF will evaluate the vendor’s sending infrastructure, not the pretty display name in the inbox. That is why a correct SPF record must match the actual mail flow, not just the domain users recognize.
For a deeper background on spoofing and message-origin checks, the spoofing and authentication glossary entries are useful context.
How Does SPF Validation Work During Email Delivery?
SPF validation is the process a receiving server uses to compare the sender’s IP address with the policy published in DNS. When a message arrives, the recipient server queries the domain’s SPF TXT record, checks the connecting IP, and decides whether that source is allowed to send mail for the domain. If the IP matches an authorized mechanism, the SPF result is typically a pass.
The server does not simply look at the visible From field and make a judgment. It evaluates the envelope sender domain, the return-path, and sometimes the HELO/EHLO identity depending on the receiving implementation. This matters when troubleshooting because the “wrong” domain may be checked if your mail system rewrites the return-path or sends through a relay.
Note
SPF can pass while a message is still suspicious, and SPF can fail for legitimate mail that was forwarded through another system. That is normal behavior, not proof that the email is good or bad.
Typical receiver actions vary by policy and mailbox provider. A pass can improve trust and deliverability. A fail, soft fail, or neutral result may trigger spam filtering, quarantine, or outright rejection if the organization has strict mail hygiene rules.
For standards-based implementation guidance, Microsoft documents SPF, DKIM, and DMARC behavior for Microsoft 365 mail flow in Microsoft Learn, and Google provides operational guidance for domain authentication in Google Workspace Admin Help.
Before You Create an SPF Record, What Do You Need to Inventory?
Before you create an SPF record, build a complete list of every system that sends mail for the domain. Missing even one source can break delivery for password resets, invoices, alerts, or campaign mail. In practice, that inventory usually includes Microsoft 365, Google Workspace, help desk platforms, CRM systems, website forms, HR tools, and transactional email providers.
Break each sender into one of three categories: direct mail from your own IPs, a third-party service that publishes an include mechanism, or a platform that sends from dedicated IP ranges you must authorize explicitly. This distinction determines whether you will add ip4, ip6, or include terms to the policy.
Inventory Checklist
- Primary mail platform: Microsoft 365, Google Workspace, or another core service.
- Website forms: WordPress forms, app notifications, or contact-page mail.
- Support systems: Ticketing tools and customer service platforms.
- Marketing services: Newsletter and campaign tools such as Mailchimp.
- Transactional systems: Billing, receipts, password resets, and alerts.
- Infrastructure mail: Servers, appliances, or scripts sending directly.
Gather the exact SPF guidance from each vendor before you write the record. Many providers publish their authorized mechanisms, subdomains, or IP ranges, and those instructions change over time. If you skip this step, you are guessing, and guessed SPF records are the ones that fail in production.
If your organization is expanding its mail stack, the same discipline applies to other identity controls. Teams asking how to implement oauth 2.0 or how to implement rbac are doing the same thing at a different layer: mapping real systems before setting policy.
What Is SPF Record Syntax and How Do the Mechanisms Work?
A valid SPF record begins with v=spf1 and then lists one or more mechanisms that describe who may send mail. Mechanisms are evaluated from left to right until one matches. If nothing matches, the final all qualifier determines whether the message should pass, fail, or be treated as neutral or soft fail.
The most common mechanisms are ip4, ip6, include, mx, a, ptr, and all. In practical terms, ip4 and ip6 authorize specific source addresses, include imports another domain’s SPF policy, and mx or a authorize whatever systems the domain’s DNS says should receive mail or resolve to the domain. The ptr mechanism exists in the standard but is widely discouraged because it is slow and unreliable in modern deployments.
Qualifiers control the outcome when a mechanism matches. A plus sign means pass, a minus sign means fail, a tilde means soft fail, and a question mark means neutral. The record often starts with an implied plus, but security teams usually prefer explicit policy choices so the intent is clear.
| Mechanism | What It Does |
|---|---|
| ip4 | Authorizes a specific IPv4 address or CIDR range |
| ip6 | Authorizes a specific IPv6 address or CIDR range |
| include | Delegates authorization to another SPF policy |
| mx | Authorizes servers listed in the domain’s MX records |
| a | Authorizes the IP address returned by the domain’s A or AAAA record |
| all | Matches everything not already covered, usually at the end |
The official technical reference for SPF is RFC 7208 from the IETF, available at RFC 7208. For practical validation rules and syntax notes, Valimail’s SPF syntax guide at Valimail SPF syntax guide is a helpful companion.
What Are Common SPF Record Examples for Real-World Setups?
Real-world SPF records are usually short. The best records authorize only the mail systems you truly use and nothing more. A clean record is easier to audit, easier to troubleshoot, and less likely to hit SPF lookup limits.
Single Provider Example
If Microsoft 365 is your only sender, your record may be as simple as the provider’s published include plus a restrictive all qualifier. If you also send from one static IP on a firewall or Linux relay, add that IP explicitly with ip4 rather than layering extra includes you do not need.
A pattern might look like this:
v=spf1 include:spf.protection.outlook.com ip4:203.0.113.10 -all
Mixed Environment Example
Mixed environments are common. A company might use Google Workspace for employee mail, Mailchimp for newsletters, and a support platform for ticket replies. In that case, the SPF record needs to authorize the Google Workspace include, the marketing vendor include, and any fixed IPs used by internal systems.
That might look conceptually like this:
v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:198.51.100.25 -all
The exact include strings and IPs must come from each vendor’s current documentation. Do not copy examples blindly from a blog post or forum thread because provider SPF ranges change, and stale examples are a common cause of failure.
Website and Application Mail
Website servers often send contact forms, order confirmations, or password resets. If those messages originate from your own app server, authorize the server’s public IP directly. If the app routes through a vendor service, authorize the vendor’s SPF include instead.
This distinction is important because blindly adding broad authorization weakens your policy. A targeted SPF record gives you control without opening the domain to every sender under the sun.
For provider-specific guidance, consult the official docs for Google Workspace, Microsoft Learn, and Mailchimp’s help documentation if that is your sending platform. Use the vendor’s current SPF instructions, not guesses from old configuration snippets.
How Do You Create an SPF Record Step by Step?
To create an SPF record safely, start with your real sending inventory and build the policy from that list. Do not begin with a giant template. The fastest way to break email is to assume every vendor, relay, and app belongs in the same record without verifying how mail actually leaves your environment.
-
List every sender. Write down each service, app, server, or platform that sends mail for the domain. Include internal systems and third-party tools, even the ones that only send occasional alerts.
-
Map each sender to a mechanism. Use ip4 or ip6 for static infrastructure, and use include when the vendor publishes its own SPF policy. If a system is only reachable through DNS-based infrastructure, check whether mx or a fits the use case.
-
Write a single TXT record. Start with v=spf1, add mechanisms in a readable order, and finish with an all rule. A clean order is usually primary mail provider first, then trusted business services, then explicit IP ranges, then the final qualifier.
-
Choose the enforcement level. Use ~all if you are still testing and want a soft fail, or -all when you are confident the record covers all legitimate senders. If you are migrating providers, many teams begin with soft fail and move to hard fail after validation.
-
Test in a staging mindset. Before you touch production DNS, compare the draft record against each vendor’s documentation and send controlled test messages. A clean SPF record is one that matches reality, not one that looks clever.
One practical rule: keep the record as short as possible. SPF has a limit of 10 DNS lookups during evaluation, and nested includes can consume that budget quickly. The IANA SPF registry and the SPF RFC are good references when you need to confirm how mechanisms are interpreted.
Warning
Do not publish multiple SPF TXT records on the same hostname. More than one SPF policy can cause evaluation failures and make legitimate mail look unauthenticated.
Where and How Do You Publish SPF in DNS?
Publishing SPF means creating a DNS TXT record on the domain or subdomain that matches your outbound mail identity. Most administrators do this in the domain’s DNS console, either at the registrar, cloud DNS service, or hosted DNS provider. The exact screen varies, but the record type and the target name matter more than the interface.
If your mail is sent from example.com, publish the record on that domain unless your provider says to use a subdomain. If a marketing system sends from a branded subdomain like mail.example.com, that subdomain may need its own SPF policy. Matching the authenticated domain to the real sender is what keeps the policy accurate.
DNS propagation is not instant everywhere. Some resolvers refresh quickly, while others cache old values longer. That is why a successful DNS save does not always mean every mailbox provider will immediately see the new policy.
When you enter the value, use only one TXT record for SPF at that hostname. If you already have a TXT record for domain verification or other purposes, that is normal. The problem is multiple TXT records that each begin with v=spf1 on the same name.
For organizations managing mail at scale, CISA’s email security guidance and the anti-spoofing practices in NIST documents reinforce the same operational principle: publish accurate identity controls, then maintain them as the environment changes.
How Do You Validate an SPF Record Before and After Deployment?
SPF validation is the process of confirming that the record is syntactically correct, published in the right place, and actually authorizes the systems that send your mail. The safest method is to validate before production rollout, then recheck after every mail platform or infrastructure change. A record that worked last quarter can fail today if a vendor changes IP ranges or you add a new service.
Start with a DNS lookup to confirm the record appears exactly where you expect. Then use a controlled test message from each legitimate sender and inspect the message headers on the receiving side. You are looking for SPF result lines that show pass for authorized sources and a sensible result for sources that are intentionally blocked.
What to Check During Validation
- Syntax: The record starts with v=spf1 and contains no typos.
- Hostname: The record is published on the correct domain or subdomain.
- Sender coverage: Every legitimate service is authorized.
- Lookup count: The policy does not exceed SPF’s DNS lookup limit.
- Header result: The test message shows the expected SPF outcome.
Many message headers include lines such as Received-SPF or authentication results added by the recipient. A pass result typically means the source IP matched the published policy. A fail result means the receiver did not find a valid authorization match. If the result is neutral or soft fail, check whether your policy was intentionally permissive or whether the sender was omitted.
For structured verification, MXToolbox’s SPF check tools at MXToolbox are commonly used for quick validation, while the authoritative standard remains RFC 7208. For administrators in Microsoft environments, compare the results with the mail authentication guidance in Microsoft Learn.
What Are the Most Common SPF Errors and Limitations?
SPF failures usually come from a short list of mistakes. The most common ones are duplicate SPF records, missing sender entries, syntax errors, and overly complex policies that exceed lookup limits. If legitimate mail starts getting rejected, those are the first places to look.
Forwarding is another classic problem. SPF checks the sending IP, so when a message is forwarded through another system, the forwarding server’s IP may not match the original sender’s SPF policy. That is why forwarded mail can fail SPF even when the message originated from a legitimate source.
Common Troubleshooting Checks
- Confirm the published record. Retrieve the TXT record from DNS and compare it to your intended policy.
- Check for duplicate SPF entries. Merge them into one record on the same hostname.
- Review all vendor includes. Make sure each include still exists and has not changed.
- Count DNS lookups. Too many includes, mx checks, or nested references can break evaluation.
- Inspect the mail path. Verify whether the message was relayed, rewritten, or forwarded.
SPF also has functional limits. It does not validate the body of a message, it does not stop lookalike domains, and it does not prove the sender controls the visible From address. That is why the modern email stack uses DKIM and DMARC alongside SPF. The DMARC.org reference materials explain how alignment and policy enforcement fill the gap SPF leaves behind.
If you want a broader security context, the phishing glossary definition and the FTC’s consumer fraud resources at FTC show why authentication alone is never the whole defense.
How Do You Maintain an SPF Record Over Time?
SPF maintenance is ongoing DNS hygiene, not a one-time setup job. Every new vendor, sender, relay, or outbound app can change the policy. If you treat the record like a static checkbox, it will drift away from reality and start breaking legitimate email.
Keep a change log that lists each authorized sender, why it exists, who owns it, and when it was added. That makes it easier to review the policy during audits, migrations, and vendor offboarding. It also helps when someone asks why a random IP range appears in production DNS six months later.
Maintenance Rules That Prevent Pain Later
- Review quarterly: Remove sender entries you no longer use.
- Track vendor changes: Recheck SPF whenever a provider updates infrastructure.
- Watch deliverability: Monitor spam placement and authentication failures.
- Limit complexity: Avoid unnecessary includes and broad authorizations.
- Document ownership: Assign someone to own email DNS changes.
This maintenance mindset matches broader IT operations practice. Whether you are tightening email controls or rolling out RBAC in a cloud platform, the same rule applies: policy only works when it matches the live environment. For workforce and governance context, the CISA and NICE Workforce Framework resources both emphasize repeatable operational controls, not one-time configuration work.
How Does SPF Fit Into a Stronger Email Security Strategy?
SPF is one layer in a broader email security stack. It helps prove that the sending infrastructure is allowed to send mail for the domain, but it does not prove message integrity or enforce policy on its own. That is why mature mail environments pair SPF with DKIM to sign messages cryptographically and DMARC to tell receivers how to handle failures.
In a common flow, SPF may authorize the sending IP, DKIM may sign the message body and headers, and DMARC may require alignment between the visible From domain and the authenticated domains. That combination gives mailbox providers a much stronger signal than SPF alone. It also gives defenders better telemetry when a phishing campaign tries to mimic the brand.
SPF reduces spoofing risk; DKIM and DMARC turn that reduction into enforceable policy. If you only publish SPF, you are checking one box. If you use all three correctly, you create a much harder target for impersonation.
Security teams can also use authentication results in incident response. A sudden pattern of SPF failures from a known vendor can indicate misconfiguration, DNS drift, or a compromised sending path. On the flip side, unauthorized sends that fail SPF can provide a useful signal that someone is trying to spoof the domain.
For formal guidance, see the CISA email authentication page, the DMARC.org resources, and the mail authentication documentation in Google Workspace Admin Help and Microsoft Learn.
Key Takeaway
Build SPF from a real sender inventory, not from a template.
Use one TXT record per hostname and keep the policy lean.
Validate with test mail and header checks before broad rollout.
Maintain SPF whenever vendors, IPs, or mail paths change.
Use SPF with DKIM and DMARC for stronger email security and deliverability.
Conclusion
To create and implement an SPF record correctly, start with a complete inventory of every legitimate sender, turn that inventory into a single DNS TXT policy, publish it on the right domain or subdomain, and verify the result with controlled test mail. That is the core workflow whether you are using Microsoft 365, Google Workspace, a marketing platform, or a mix of all three.
The details matter. Accurate syntax, a lean record, and sensible use of include, ip4, and ip6 keep the policy reliable and easier to maintain. The best SPF record is the one that matches your real mail flow today and stays current when that flow changes tomorrow.
If you want a stronger email security posture, do not stop at SPF. Pair it with DKIM and DMARC, keep reviewing sender inventory, and validate after every mail or DNS change. For teams that need this done right the first time, ITU Online IT Training recommends using the official vendor documentation as the source of truth and treating email authentication as an ongoing operational control, not a one-time task.
CompTIA®, Microsoft®, AWS®, ISC2®, ISACA®, PMI®, and EC-Council® are trademarks of their respective owners.
