How to set up SPF

An SPF record is a single line of text you publish in your domain's DNS that lists the mail servers allowed to send email using your domain. When a receiving server gets a message claiming to be from you, it checks the sending server against that list. If the server is on the list, SPF passes. If it is not, SPF fails. SPF is one of the three building blocks of email authentication, alongside DKIM and DMARC, and it is usually the first record people set up because it is the simplest to understand. This guide gives you the exact record to publish, where to add it at every major DNS provider, and the handful of mistakes that quietly break SPF for thousands of domains.

What SPF is and why you need it

SPF stands for Sender Policy Framework, defined in RFC 7208. It is a TXT record published at your domain's apex, which is the bare domain itself, such as yourcompany.com rather than a subdomain. The record names the servers and services permitted to send mail on your behalf and ends with an instruction telling receivers what to do with everything else.

On its own, SPF is a useful signal but a weak defence. It validates the hidden envelope sender, the Return-Path, not the From address your recipients actually see, so an attacker can pass SPF for their own domain while still forging your name in the visible From line. SPF only becomes a real anti-spoofing control once DMARC ties it to that From address through alignment. So publish SPF, keep it correct, but treat it as one leg of the stool, not the whole chair. The end goal is DMARC at enforcement, with SPF and DKIM feeding into it.

The record to publish

A minimal SPF record for a domain that sends only through Google Workspace looks like this. Copy it, then swap the include for whichever provider actually sends your mail.

v=spf1 include:_spf.google.com ~all

Read left to right, this says: this is an SPF version 1 record (v=spf1); authorise every server that Google's _spf.google.com record authorises (include:_spf.google.com); and for anything not listed, apply a soft fail (~all). If you send through more than one service, list each as its own mechanism, separated by single spaces, before the final all:

v=spf1 include:_spf.google.com include:sendgrid.net include:spf.protection.outlook.com ~all

The DNS fields to enter are the same whichever provider you use. Only the value changes.

• Type: TXT
• Host / Name: @ (the apex; some panels want this left blank, see the gotchas below)
• Value: your full v=spf1 … ~all string, including the quotes only if the panel asks for them
• TTL: 3600 (one hour) is fine; lower it to 300 while you are actively editing so changes propagate faster, then raise it again

If you are not sure which includes you need, our SPF record generator builds the line for you from the services you tick, and the SPF checker validates an existing record and counts its lookups. Both are free.

Where to add it, by DNS provider

The record is identical everywhere. What differs is the panel, the wording, and, crucially, how each provider treats the host field. Several providers automatically append your domain to whatever you type in the host box, which trips people up constantly. Where that applies, we say so.

Cloudflare

Sign in and select your domain, then open DNS > Records. Click Add record. Set Type to TXT. In the Name field enter @ for the apex; Cloudflare will display it as the bare domain. Paste your SPF string into the Content field without surrounding quotes. Leave TTL on Auto or set 3600. Save. Cloudflare does not proxy TXT records, so there is no orange-cloud toggle to worry about.

GoDaddy

From your account open My Products, find the domain and choose DNS or Manage DNS. Under Records click Add. Choose Type TXT. In Name enter @ for the apex. Paste the SPF value into Value. Set TTL to one hour or custom 3600. Save. GoDaddy appends your domain behind the scenes, so never type the domain into the Name box; @ means the apex.

Namecheap

From the dashboard pick the domain and click Manage, then open the Advanced DNS tab. Under Host Records click Add New Record and select TXT Record. In the Host field enter @ for the apex. Paste your record into Value. Leave TTL on Automatic. Save with the green tick. Namecheap appends the domain automatically, so a host of @ resolves to the bare domain; do not write the domain out in full.

Amazon Route 53

In the AWS console open Route 53 > Hosted zones and select your domain's zone. Click Create record. Leave the Record name field empty to target the apex. Set Record type to TXT. In Value enter your SPF string wrapped in double quotes, like "v=spf1 include:_spf.google.com ~all"; Route 53 requires the quotes. Set TTL to 3600. Choose Simple routing and click Create records. If an apex TXT record already exists, edit that record and add your SPF string as a new line inside it rather than creating a second record.

Google Domains / Squarespace

Google Domains has migrated to Squarespace Domains, so the panel may carry either name. Open Domains, select your domain, and go to DNS (under DNS settings or Manage DNS records). Add a custom record. Set Type to TXT. In the Host or Name field enter @ for the apex, or leave it blank if the form treats blank as the root. Paste the SPF value into the Data or Value field. Set TTL to one hour. Save.

Microsoft 365 / Outlook DNS

If your domain's nameservers point at Microsoft, manage DNS in the Microsoft 365 admin centre under Settings > Domains, select the domain, and open DNS records. More often your nameservers live with your registrar, in which case you add the record there, not in Microsoft. The SPF value Microsoft expects for Exchange Online is:

v=spf1 include:spf.protection.outlook.com ~all

Enter it as a TXT record on the apex (host @ or blank). If you also send through other services, merge their includes into this one record rather than adding a second SPF record. Microsoft's setup wizard sometimes offers to create the record for you; let it, then check there is still only one SPF record afterwards.

One SPF record per domain, no exceptions

RFC 7208 permits exactly one SPF record per domain. If a receiver finds two TXT records that both begin v=spf1, the result is a permerror, and SPF fails for everyone, not just the second record. This is the single most common SPF failure, and it usually happens innocently: you added Microsoft 365, the wizard published an SPF record, and later you added a marketing tool whose own wizard published a second one. Now you have two, and both are dead.

The fix is always to merge, never to duplicate. Take the includes from each record and combine them into one line with a single all at the end:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net ~all

Then delete the other SPF record so only one remains. Our SPF checker flags duplicate records immediately, which is the fastest way to catch this.

The ten-lookup limit, and how includes blow it

This is the rule that catches almost everyone eventually. RFC 7208 caps the number of DNS lookups an SPF record may trigger during evaluation at ten. The mechanisms that count toward this limit are include, a, mx, ptr, exists, and the redirect modifier. Exceed ten and the receiver returns a permerror; SPF fails exactly as if the record were broken, even though every entry in it is legitimate.

The trap is that the count is recursive. A single include in your record can itself contain several more includes, each of which counts. Google's _spf.google.com expands to multiple lookups. Microsoft, SendGrid, Mailchimp and the rest each cost one or more. Stack four or five providers and you can sail past ten without ever writing ten lines yourself. The reader sees a short, tidy record and has no idea it is over budget. The only way to know is to count the expanded total, which the SPF checker does for you.

When you are over the limit, you have three honest options. Remove includes for services you no longer use, which is more common than people expect. Replace broad include mechanisms with the specific ip4 and ip6 addresses a service publishes, since literal IP mechanisms cost zero lookups. Or flatten the record, described below.

Soft fail versus hard fail: ~all and -all

The mechanism at the end of your record tells receivers what to do with mail from servers not on your list. There are two sensible choices:

• ~all is a soft fail. It says "this probably is not authorised, but accept it and mark it suspect." Mail from an unlisted server is usually still delivered, often to spam.
• -all is a hard fail. It says "this is not authorised, reject it." Receivers are entitled to refuse mail from any unlisted server outright.

Avoid +all, which authorises every server on the internet and defeats the purpose, and you rarely need the neutral ?all. The honest guidance is to start at ~all while you confirm you have catalogued every sending source, exactly as you would stage a DMARC rollout, then tighten to -all once you are certain the list is complete. Under DMARC, the difference between ~all and -all matters less than people think, because DMARC makes its own pass or fail decision based on alignment regardless of which one you chose. But a clean record finishing in -all is the correct destination once your senders are known.

The ptr mechanism is deprecated, do not use it

You may see old records containing a ptr mechanism. Do not add it, and remove it if you find it. RFC 7208 explicitly deprecates ptr because it is slow, places an unreasonable load on DNS, and is unreliable in practice. Some receivers ignore it entirely, others penalise records that use it. It also consumes one of your ten precious lookups for no good reason. There is no situation in a modern SPF record where ptr is the right answer.

Flattening, and when it is worth it

Flattening means replacing the include mechanisms in your record with the actual ip4 and ip6 addresses they currently resolve to. Because literal IP mechanisms do not trigger DNS lookups, a fully flattened record can list dozens of servers while staying comfortably under the ten-lookup ceiling. For domains that genuinely must send through many providers, flattening is sometimes the only way to keep SPF valid.

It carries a real cost, and you should know it before reaching for it. When you flatten, you freeze a copy of each provider's IP addresses into your own record. The moment that provider adds, removes or rotates a sending IP, which they do without telling you, your frozen list is wrong, and mail from the changed server starts failing SPF. A flattened record therefore needs active monitoring and automatic refreshing, or it silently rots. This is exactly the kind of ongoing maintenance our done-for-you service handles: we host and continuously update a flattened, lookup-safe SPF record so it stays correct as your providers change their infrastructure, rather than leaving you to chase IP changes by hand. If you flatten yourself, automate the refresh; never flatten once and forget it.

Common mistakes and gotchas

Most broken SPF records fail for one of a small set of avoidable reasons. Run through this list before you consider the job done.

• Two SPF records. Covered above, and worth repeating because it is the most frequent fault. One v=spf1 record per domain, always. Merge, never duplicate.
• The domain typed into the host field. On GoDaddy, Namecheap and several others, the panel appends your domain automatically, so entering yourcompany.com in the host box produces a record at yourcompany.com.yourcompany.com, which does nothing. Use @, or leave the field blank where the panel treats blank as the apex.
• Over ten lookups. The record looks fine but fails with permerror. Count the expanded total, not the visible lines, and reduce includes or flatten.
• SPF on a subdomain expecting it to cover the parent. SPF is not inherited downward the way DMARC's policy can be. A record at mail.yourcompany.com protects only that subdomain. The apex needs its own.
• Missing the all mechanism. A record with no terminating all is treated as neutral for unlisted servers, which weakens it. Always finish with ~all or -all.
• Adding a new sender without updating SPF. Sign up for a new email service and its mail will fail SPF until you add its include. Every new sending platform means an edit to the one record.
• Leftover ptr mechanisms. Deprecated, lookup-wasting, and sometimes penalised. Strip them out.
• Forgetting that SPF alone does not stop spoofing. SPF checks the envelope sender, not the visible From. Without DMARC tying the two together through alignment, a correct SPF record still leaves your domain spoofable.

Once your record is published and clean, the next steps are DKIM for cryptographic signing and DMARC to bind both to your visible domain and move you to enforcement. SPF is the foundation; it is not the finished building. You can explore the rest of the authentication stack and our full set of free checkers and generators on the tools page.