Question 1

What is SPF and where do I publish it?

Accepted Answer

SPF (Sender Policy Framework) is a DNS TXT record at the apex of your domain that lists the servers authorised to send email for that domain. Receiving mail servers look up the record, compare it to the connecting server, and decide whether the message should pass, soft-fail, or hard-fail. SPF is defined by RFC 7208 and is one of the three records that make up modern email authentication alongside DKIM and DMARC.

Question 2

What does the all mechanism mean at the end of an SPF record?

Accepted Answer

The all mechanism is the catch-all that decides what happens to mail from any server not already matched. -all is hard fail: receivers should reject mail from unlisted senders. ~all is soft fail: receivers should accept the mail but mark it. ?all is neutral: no opinion. +all explicitly authorises every sender on the internet and defeats the point of SPF, so it is treated as a finding by every modern scanner. The recommended end state is -all.

Question 3

Why does SPF have a 10 DNS lookup limit?

Accepted Answer

RFC 7208 caps the number of DNS lookups during SPF evaluation at 10. Mechanisms that trigger a lookup include include, a, mx, ptr, exists, and the redirect modifier. If evaluation goes past 10 lookups the result is permerror and the record fails for every receiver. Large include chains across many SaaS senders are the most common cause of permerror in the wild. The fix is to flatten includes, remove unused senders, or split sending across subdomains.

Question 4

What is the difference between SPF, DKIM, and DMARC?

Accepted Answer

SPF authorises sending servers by IP. DKIM signs messages cryptographically so receivers can verify the message was not tampered with. DMARC sits on top of both and tells receivers what to do when neither passes with alignment, plus where to send aggregate reports. SPF on its own is not enough because forwarded mail often loses the original return-path; DKIM survives forwarding, and DMARC ties them together. Publish all three.

Question 5

Should I use -all or ~all?

Accepted Answer

Start at ~all (soft fail) once the record lists every legitimate sender, then move to -all (hard fail) once DMARC aggregate reports show that all legitimate mail aligns. Going straight to -all without monitoring through DMARC risks blocking a forgotten sender. Once -all is in place and DMARC is at p=reject, the domain is hardened against direct spoofing.

Question 6

How do I add a new email sender like a marketing platform?

Accepted Answer

Most large senders publish an include mechanism (for example include:_spf.google.com or include:spf.protection.outlook.com). Add it to the SPF record between the v=spf1 prefix and the trailing all mechanism. Re-evaluate the lookup count after the addition; including a vendor that itself contains many includes can push the record past the 10 lookup limit.

Question 7

Does an SPF record affect mail I send to my own domain?

Accepted Answer

It can. Forwarded mail and aliases that rewrite the return-path may not survive an SPF check at the forwarding mailbox even when the original sender is authorised. SRS (Sender Rewriting Scheme) and similar mechanisms exist to rewrite the return-path so SPF still passes after a forward. Most SaaS forwarding services handle this automatically, but on-premise mail servers need to be configured.

Question 8

What happens when SPF returns permerror?

Accepted Answer

permerror means the receiver could not evaluate the record cleanly, usually because of a syntax issue, a missing referenced record, or going past the 10 DNS lookup limit. Most receivers treat permerror as not authorised and either soft-fail or reject depending on local policy. permerror also breaks DMARC because DMARC needs a clean SPF or DKIM result aligned with the From: header. Auditing the record with a generator and a verifier catches this before deployment.

Question 9

How do I publish an SPF record for a domain that does not send email?

Accepted Answer

Publish v=spf1 -all at the apex. This tells receivers that no server is authorised to send email claiming to be from the domain. Pair it with a DMARC record at p=reject and an empty MX record (or one that points nowhere). Parked domains and brand domains that do not send mail are the most common phishing targets, so locking them down with SPF + DMARC is high value for low effort.

Mechanism	Meaning
v=spf1	Protocol version. Must be the first token. Required.
ip4:	Authorise an IPv4 address or CIDR range. No DNS lookup.
ip6:	Authorise an IPv6 address or CIDR range. No DNS lookup.
a	Authorise servers whose A or AAAA record matches the named domain. One DNS lookup.
mx	Authorise servers listed in the MX records for the named domain. One DNS lookup.
include:	Recursively evaluate another SPF policy. One DNS lookup, plus whatever the included record uses.
exists:	Authorise if the named A record resolves. Macro-based; rare in everyday records.
redirect=	Delegate the entire SPF policy to another domain. Replaces the all mechanism. One DNS lookup.
-all	Hard fail. Receivers should reject mail from unlisted senders. The recommended production setting.
~all	Soft fail. Receivers accept the message but mark it. Useful while monitoring with DMARC.
?all	Neutral. No opinion. Provides no protection.
+all	Authorise every server on the internet. Equivalent to having no SPF record at all.

Mechanism	Meaning
v=spf1	Protocol version. Must be the first token. Required.
ip4:	Authorise an IPv4 address or CIDR range. No DNS lookup.
ip6:	Authorise an IPv6 address or CIDR range. No DNS lookup.
a	Authorise servers whose A or AAAA record matches the named domain. One DNS lookup.
mx	Authorise servers listed in the MX records for the named domain. One DNS lookup.
include:	Recursively evaluate another SPF policy. One DNS lookup, plus whatever the included record uses.
exists:	Authorise if the named A record resolves. Macro-based; rare in everyday records.
redirect=	Delegate the entire SPF policy to another domain. Replaces the all mechanism. One DNS lookup.
-all	Hard fail. Receivers should reject mail from unlisted senders. The recommended production setting.
~all	Soft fail. Receivers accept the message but mark it. Useful while monitoring with DMARC.
?all	Neutral. No opinion. Provides no protection.
+all	Authorise every server on the internet. Equivalent to having no SPF record at all.

SPF Record Generatorbuild a valid SPF TXT record

Generated SPF record

How to publish an SPF record

SPF mechanism reference

Common SPF record examples

Google Workspace only

Microsoft 365 only

Mailbox plus a transactional sender

Domain that does not send mail

Monitoring before tightening

SPF, DKIM, and DMARC together

Related security resources

Frequently asked questions

Where is the SPF record published?

Can a domain have more than one SPF record?

What is the 10 DNS lookup limit?

What is SPF flattening?

Should I use ptr in SPF?

How does this generator differ from a DNS analyzer?

Related features

Vulnerability scanning tools that map your attack surface

Cyber security assessments

Want to verify the record after you publish it?