TL;DR
SPF (Sender Policy Framework) is a public DNS TXT record that lists which mail services are allowed to send email as your domain. Receiving servers check it on delivery. If the sender is not on that list — or the record is invalid — the message may be treated as unauthenticated.
- A domain may have only one TXT record that starts with
v=spf1. - If you already have SPF, merge new senders into that line. Do not add a second record.
- MAIL FROM / bounce subdomains are a different DNS name and need their own SPF — do not copy the apex record onto them.
- No extra quotes, no CDN proxy on mail DNS, and stay at or below ten DNS lookups.
What is SPF?
Email displays a From address such as [email protected]. The portion after @ is your domain — the same name people type to reach your website. Anyone on the internet can attempt to send a message that claims to be from your domain; SPF is how you publish which mail systems are genuinely allowed to do so.
SPF is a short text entry in your domain’s public DNS. It is not software you install and not a setting inside an inbox. When mail arrives, the receiving server reads that entry and checks whether the sending service is listed.
Key terms in plain language
- Domain — the name after
@in an email address; also used for websites. - DNS — the public directory that stores records (including SPF) for a domain.
- TXT record — a type of DNS entry that stores text; SPF policies live here.
- Apex / root — the main domain (
yourdomain.com), not a subdomain such asmail.yourdomain.com. include:— an SPF mechanism that says “also allow the senders authorized by this other domain.”~all/-all— the closing rule: soft-fail or hard-fail everyone not explicitly allowed.- MAIL FROM / return-path — the technical sender address used during delivery; it can differ from the address users see in the From field.
SPF in the email ecosystem
When a message is delivered, the receiving server evaluates several signals to decide whether to accept it, quarantine it, or reject it. SPF (Sender Policy Framework) is one of those signals. It answers a narrow question: was this message sent from an IP address or relay that my domain owner has authorized?
SPF does not validate message content, headers visible to the user, or cryptographic signatures on its own. It is typically used alongside DKIM (which signs message content) and DMARC (which tells receivers what to do when SPF or DKIM do not align). Together they form the modern baseline for domain-level email authentication.
The policy is published as a DNS TXT record on the domain that appears in the envelope sender — often the same domain as the visible From address, though not always. Receivers query that record during SMTP and compare the connecting host against the mechanisms listed in the record.
One SPF record per domain
The SPF specification allows exactly one TXT record beginning with v=spf1 on a given domain name. Publishing two or three separate records — each with its own v=spf1 prefix — produces an invalid configuration.
In practice, resolvers may return multiple TXT strings and receivers may evaluate whichever record they encounter first. That leads to inconsistent results: the same domain can pass SPF in one check and fail in the next, even when nothing intentional changed in DNS. The fix is always consolidation — one record that lists every authorized sender.
Other TXT records on the domain (site verification tokens, DKIM public keys, DMARC policies) are unrelated and do not count toward the one-SPF limit. Only lines that start with v=spf1 create the conflict.
Inspect existing TXT records
Before adding or editing anything, enumerate the TXT records already published on the apex — the root of the domain, commonly entered as @ in a DNS panel.
- macOS or Linux terminal:
dig TXT yourdomain.com +short - Windows Command Prompt:
nslookup -type=TXT yourdomain.com - Windows PowerShell:
Resolve-DnsName yourdomain.com -Type TXT - From a DNS management UI: open the TXT list for the apex host and read each value in full.
Count how many distinct values begin with v=spf1. Zero means you can create a new record. One means you must edit that record in place. More than one means you must merge into a single line and delete the extras.
Create or merge a record
No existing SPF
Publish one TXT record on the apex. A minimal record lists authorized senders with include: mechanisms and ends with a qualifier such as ~all (soft fail) or -all (hard fail):
v=spf1 include:_spf.google.com ~all
Each include: delegates to another domain’s SPF policy and consumes part of the ten-DNS-lookup budget defined in the standard. Add one include per mail platform you actively use.
Merge with an existing record
Open the existing v=spf1 line and append new include: entries before the terminal ~all or -all. Remove any duplicate includes. Do not create a second TXT record.
| Situation | What to publish |
|---|---|
| Invalid: two TXT records | v=spf1 include:_spf.google.com ~allv=spf1 include:mail.example.net ~all |
| Valid: one merged TXT | v=spf1 include:_spf.google.com include:mail.example.net ~all |
After merging, delete the superseded records. Leaving retired providers as separate v=spf1 lines keeps the domain in an invalid state and continues to produce unpredictable SPF outcomes at major receivers.
Apex SPF vs MAIL FROM subdomain
Many sending setups use a dedicated subdomain for the SMTP envelope address (MAIL FROM / return-path), separate from the domain shown in the From header. That subdomain may need its own SPF TXT record — shorter than the apex record and scoped only to bounce traffic on that hostname.
Example: mail for [email protected] might use a return-path of bounces.mail.yourdomain.com. The apex record at yourdomain.com authorizes senders for the organizational domain; the record on bounces.mail.yourdomain.com authorizes the bounce-handling path. These are different DNS names and must not be treated as interchangeable copies.
An MX record on the MAIL FROM subdomain is a separate requirement for some providers. SPF and MX answer different questions and are published independently.
DNS formatting pitfalls
- Apex host is usually
@or blank. If the panel requires a fully qualified name, useyourdomain.com— not a doubled suffix such asyourdomain.com.yourdomain.com. - Some registrars add quotation marks around TXT values automatically. Paste the SPF string without wrapping it in extra
"characters; doubled quoting breaks lookups on some resolvers. - Do not proxy SPF-related TXT or MX records through a CDN edge. In Cloudflare, for example, the record should be DNS only (grey cloud).
- Stay within the ten-lookup limit. Each
include:counts, including nested includes inside delegated policies. If a merge exceeds the cap, remove providers you no longer send through before adding new ones.
Propagation and rechecking
DNS changes propagate according to TTL values and resolver caching. A newly published TXT record may appear in dig, nslookup, or Resolve-DnsName within minutes or take longer depending on the prior TTL and the resolver queried.
Re-run the same lookup from more than one network or resolver before concluding a change failed. Automated verification tools re-query live DNS each time they run; a result that changes after an edit usually reflects what is currently published, not intermittent randomness. If a check fails, confirm the merged record is the only v=spf1 line visible on the apex, wait for propagation, and test again.
Quick checklist
- Exactly one apex TXT value starts with
v=spf1. - Every mail platform you still use appears as an
include:in that single line. - Retired providers are removed from the record, not left as extra TXT entries.
- Any MAIL FROM subdomain has its own SPF (and MX, if required) — not a duplicate of the apex string pasted onto the wrong name.
- No extra quotes, no CDN proxy on mail DNS, and total DNS lookups stay at or below ten.