SPF Record Syntax Explained: Mechanisms, Qualifiers, Modifiers

If you are staring at a line that starts with 'v=spf1' and trying to work out what each piece does, this is the reference for you. SPF record syntax is built from three kinds of terms — mechanisms, qualifiers and modifiers — and once you can read them in order, an SPF record stops looking like a wall of colons and slashes.

This guide walks through every mechanism (ip4, ip6, a, mx, include, exists, ptr and all), all four qualifiers, and the redirect and exp modifiers, exactly as RFC 7208 defines them. The goal is that you can read any record you are handed, and edit one without breaking your mail.

The anatomy of an SPF record#

An SPF record is a single DNS TXT record published on a domain. It always begins with the version tag 'v=spf1', which RFC 7208 requires to be exactly that — a record that starts with anything else is not treated as SPF at all.

After the version comes a list of terms. Each term is either a mechanism (a test against the IP that delivered the message), a modifier (which changes how the record is evaluated), or a mechanism with an optional qualifier in front of it.

A receiving server reads the terms left to right and stops at the first mechanism that matches. That first match, together with its qualifier, decides the result — pass, fail, softfail or neutral. This 'first match wins' rule is why order matters, and why the catch-all 'all' always belongs at the very end.

The mechanisms, term by term#

A mechanism is a test against the sending IP address. RFC 7208 defines eight of them. Some check the IP directly and cost nothing; others ask DNS a question, which is why they count toward the lookup limit covered further down. When 'a' or 'mx' is written without a domain, the record's own domain is used.

The four qualifiers: +, -, ~, ?#

Every mechanism can carry a qualifier — one character in front of it that says what a match means. RFC 7208 section 4.6.2 defines four, and the qualifier is optional: if you leave it off, it defaults to '+'.

Because the default is '+', 'include:_spf.google.com' and '+include:_spf.google.com' mean exactly the same thing. The qualifier you almost always write out is the one on the final 'all', because it sets the policy for every sender you did not list. '-all' hard-fails them; '~all' softens it to a warning; '?all' says nothing at all.

Modifiers: redirect and exp#

Modifiers are not mechanisms. RFC 7208 section 6 is blunt about it: 'Modifiers are not mechanisms. They do not return match or not-match.' They change how the record is evaluated rather than test an IP, and each may appear at most once, after the mechanisms.

'redirect=<domain>' hands the whole evaluation to another domain's SPF record. It only takes effect if none of the mechanisms above it matched — so you never combine 'redirect' with an 'all' mechanism, because 'all' matches everything first and 'redirect' would never fire. Use it to share one policy across several domains.

'exp=<domain>' points to a TXT record holding a human-readable explanation string, which a receiver may return when a message hard-fails. It changes the error text a sender sees, not the SPF result.

How to read an SPF record: a worked example#

Put the rules together on a real record. Take this one, which is a common shape for a domain sending through Microsoft 365 plus one on-premises server.

A receiver checks these terms in order. If the message came from 198.51.100.10, it passes on the first term and never looks further. If it came from Microsoft's servers, the 'include' passes. Anything else reaches '~all' and is marked. Reverse the order and put '~all' first, and every message would softfail — which is exactly why 'all' is always last.

Why syntax mistakes break mail#

Small syntax errors have real consequences. A record that starts 'v=spf2', uses 'include=' with an equals sign instead of a colon, or leaves a stray space after a colon is not parsed as SPF, so your legitimate mail quietly loses a layer of protection.

The most common breakage is the DNS lookup limit. RFC 7208 section 4.6.4 requires evaluators to limit the total number of DNS-querying terms to 10. The mechanisms that count are 'include', 'a', 'mx', 'ptr' and 'exists', plus the 'redirect' modifier. 'ip4', 'ip6' and 'all' cost nothing — a record can list hundreds of IPs without a single lookup.

Nested includes count toward the same ten, so a handful of provider includes can quietly push you over. Exceed the limit and the record returns 'permerror', which most receivers treat as a fail. The spec also recommends limiting 'void' lookups — queries that return no record — to two.

ip4 vs a vs mx: which mechanism to use#

These three all authorize your own servers, but they behave very differently. The choice is really stability versus DNS lookups.

'ip4' never costs a lookup but must be updated by hand when an address changes. 'a' and 'mx' track DNS automatically, so they follow an IP change on their own — but each spends one of your ten lookups, and 'mx' can resolve to several hosts, each of which the receiver must resolve, capped at 10 address records by the spec.

Common misconceptions about SPF syntax#

• 'include' copies the other record's text. It does not — it runs a separate SPF check on that domain, and only a pass there counts as a match (RFC 7208 section 5.2).
• You must write the '+' qualifier. You do not; a missing qualifier defaults to '+' (pass).
• ip4 entries count toward the 10-lookup limit. They do not — only DNS-querying terms do.
• 'ptr' is a normal mechanism to use. RFC 7208 says it SHOULD NOT be published; it is slow and unreliable.
• 'redirect' and 'include' are interchangeable. They are not: 'include' adds senders and continues, 'redirect' replaces the record and only fires if nothing matched.
• A domain can have several SPF records. Only one is valid — two or more return 'permerror'.

How this shows up in AI Emaily#

AI Emaily is a mail client, so it does not publish or edit your SPF record — that record lives in your domain's DNS, and you change it at your registrar, not inside an email app. To test a record's syntax or count its lookups, use a dedicated SPF checker; that is not a job we do.

Where SPF touches AI Emaily is on the reading side. It treats every incoming message as untrusted input, and authentication results — SPF among them — are part of how it decides which mail is genuine and which shows the hallmarks of spoofing or phishing. When AI Emaily sends on your behalf, it goes through your existing provider's servers, which your current 'include' already authorizes, so your syntax does not change. We build AI Emaily, and the job it does is triaging and defending the mail that reaches you — not managing your DNS.