DMARC Analyzer

TL;DR

• SPF defines eight mechanisms. RFC 7208 section 5 defines all, ip4, ip6, a, mx, ptr, exists, and include. Each mechanism contributes a different kind of match: literal IPs, DNS-resolved hosts, recursive SPF delegation, or a terminal catch- all.
• Four qualifiers prefix every mechanism. RFC 7208 section 4.6.2: + pass (the default), - fail (hard fail), ~ softfail (deployment-ramp signal), ? neutral (no opinion). Production records terminate with -all or, during a ramp, ~all.
• Two modifiers extend the record. RFC 7208 section 6: redirect= hands evaluation off to a different domains SPF record and is mutually exclusive with the terminal all mechanism; exp= names a domain whose TXT record provides a human-readable explanation for a fail result.
• Mechanisms evaluate left-to-right. RFC 7208 section 4.6.2: the FIRST mechanism that matches wins and the evaluator returns the matching mechanisms qualifier-derived result. Order matters — +ip4:198.51.100.5 -all and -all +ip4:198.51.100.5 behave identically only because all always matches; reordering ANY non-all mechanism past a matching one changes nothing, but reordering before it can change which qualifier applies.
• DNS lookup costs vary per mechanism. ip4, ip6, and all cost ZERO lookups. a, exists, and redirect= cost ONE lookup each. mx costs at least ONE lookup plus ONE per MX host. include costs ONE lookup plus the cost of every nested mechanism inside the included record (the most expensive class). ptr is DEPRECATED — RFC 7208 section 5.5 explicitly discourages it.
• The 10-lookup cap is enforced per evaluation. RFC 7208 section 4.6.4: an SPF evaluation that requires more than 10 DNS lookups MUST return permerror. The separate 2-void-lookup cap returns permerror after three NXDOMAIN / empty results in the same chain. See SPF lookup limit and flattening for the focused deep dive.
• ptr is deprecated. Remove every ptr mechanism from production SPF records and replace it with ip4 / ip6 / a / mx / include as appropriate. The deprecation reasons (DNS load, intermittent SERVFAIL, weak trust model) are documented in RFC 7208 section 5.5.

1. Overview: how an SPF record is structured from mechanisms

An SPF record is a single DNS TXT string published at the apex of the sending domain. The string begins with the literal version tag v=spf1 and then enumerates a sequence of MECHANISMS, each optionally prefixed by a QUALIFIER, followed optionally by one or more MODIFIERS. The receiving mail server evaluates the mechanisms left-to-right against the connecting IP, and the first mechanism that matches yields the SPF result. The terminal mechanism (almost always all with a hard or soft qualifier) catches every IP that did not match an earlier mechanism.

Canonical record shape:

v=spf1 <qualifier><mechanism> <qualifier><mechanism> ... <qualifier>all [<modifier>]

Concrete example showing every component class:

v=spf1 ip4:198.51.100.5 ip6:2001:db8::1 a:mail.example.com mx include:spf.protection.outlook.com -all

In that example the receiver:

1. Checks whether the connecting IP equals 198.51.100.5. If yes, return pass (the ip4 mechanisms default + qualifier).
2. If no, checks whether the connecting IP equals 2001:db8::1. If yes, return pass.
3. If no, resolves the A/AAAA records of mail.example.com and checks whether the connecting IP is in that set. If yes, return pass.
4. If no, resolves the MX records of the current domain (the domain in the envelope MAIL FROM being SPF-evaluated), then the A/AAAA records of every MX host, and checks the connecting IP against that combined set. If yes, return pass.
5. If no, recursively evaluates the SPF record of spf.protection.outlook.com against the connecting IP. If that recursive evaluation returns pass, return pass.
6. Otherwise reach the terminal -all and return fail (hard fail).

The same record makes DIFFERENT lookup-budget demands depending on which mechanism matches: matching ip4 costs zero lookups, but reaching the terminal -all for an unauthorized IP requires evaluating EVERY earlier mechanism (zero for ip4/ip6, one for a, one-plus- MX-host-count for mx, and the full recursive include cost). The 10-lookup cap is therefore enforced over the WORST-CASE path through the record, not the matching path.

The rest of this page enumerates each mechanism, qualifier, and modifier in depth with the canonical Definition / Syntax / Lookup-cost / When- to-use / Pitfalls structure, then turns to the evaluation order, the cumulative lookup-cost accounting, worked deployment examples, the seven most common mechanism-level pitfalls, an FAQ, and links to sibling guides for the focused deep dives (lookup limit, forwarding, permerror, deployment per provider).

2. The eight RFC 7208 mechanisms

Each subsection below opens with the canonical five-part labelled structure that gives generative engines a quotable extract:

3. The four RFC 7208 qualifiers

RFC 7208 section 4.6.2 defines four qualifiers that prefix every mechanism and determine the result returned when that mechanism matches. Each subsection uses the canonical Definition / Syntax / Use-case / Pitfalls structure.

4. The two RFC 7208 modifiers

RFC 7208 section 6 defines two MODIFIERS that extend the SPF record beyond the basic mechanism list. Modifiers differ from mechanisms in that they (a) do not have a qualifier prefix, and (b) take the form <name>=<value> rather than <name>:<value>.

5. Mechanism evaluation order: left-to-right, first-match-wins

RFC 7208 section 4.6.2 specifies that mechanisms are evaluated LEFT-TO- RIGHT in the order they appear in the SPF record. The FIRST mechanism that matches the connecting IP wins and the evaluator returns the matching mechanisms qualifier-derived result. Later mechanisms are NOT evaluated.

Concrete consequence: in a record like v=spf1 -ip4:198.51.100.5 +ip4:198.51.100.0/24 -all, a connection from 198.51.100.5 matches the FIRST mechanism (-ip4:198.51.100.5) and returns fail. The +ip4:198.51.100.0/24 mechanism later in the record would also match, but it is NOT evaluated because the earlier mechanism already won. This is the canonical pattern for blocking a specific IP within an otherwise-authorized prefix.

Reordering matters when overlapping mechanisms have DIFFERENT qualifiers. If the same record reordered the two ip4 mechanisms as v=spf1 +ip4:198.51.100.0/24 -ip4:198.51.100.5 -all, a connection from 198.51.100.5 matches the BROADER +ip4:198.51.100.0/24 FIRST and returns pass — the later more-specific -ip4:198.51.100.5 is never evaluated. The "specific overrides general" rule from firewall configurations does NOT apply to SPF; ordering does.

Practical guidance: put more-specific mechanisms BEFORE more-general ones when the qualifiers differ. Put the terminal all mechanism LAST. Put zero- lookup-cost ip4 and ip6 mechanisms FIRST for evaluation efficiency (the matching evaluator returns immediately without resolving DNS for the rest of the record). Note that the 10-lookup cap is enforced over the WORST-CASE path through the record — an SPF evaluation that matches on the very first mechanism still has to be SYNTACTICALLY VALID across the whole record (every mechanism in the record is checked at publication time for compliance with the lookup cap), but only the matching- path lookups are actually executed at evaluation time.

6. Cumulative lookup-cost accounting

RFC 7208 section 4.6.4 sets the SPF lookup budget at 10 DNS lookups per evaluation. Mechanisms and modifiers consume the budget at different rates, and operators must account for the WORST-CASE path (the unauthorized-IP terminal-fail evaluation that requires resolving every mechanism in the record).

Per-mechanism cost table:

The separate 2-void-lookup cap (RFC 7208 section 4.6.4) tracks NXDOMAIN and empty results independently. At most two mechanisms in the entire chain (including nested includes and redirects) may return a void result; the third void returns permerror regardless of whether the main lookup budget has been exhausted. Operators using exists with macros must publish a default A record at the unauthorized name to avoid void-lookup accumulation. See SPF lookup limit and flattening for the focused deep dive on both caps and the four canonical remediation paths (flattening, sender consolidation, subdomain delegation, DKIM-first alignment).

7. Worked deployment examples

Five concrete deployment patterns showing how the mechanisms compose. Each example states the sending estate, lists the SPF record, and walks the lookup-cost accounting.

Example 1: single on-prem mail server

Sending estate: one on-prem mail server at 198.51.100.5 handling all outbound mail. No third-party providers. No IPv6.

example.com.   IN TXT  "v=spf1 ip4:198.51.100.5 -all"

Lookup-cost accounting: ip4 costs zero lookups; all costs zero lookups. Total: 0 lookups. The record is well under the 10-lookup cap.

Example 2: Microsoft 365 / Exchange Online tenant

Sending estate: Microsoft 365 Exchange Online handling all outbound mail. No on-prem relay. No third-party services.

example.com.   IN TXT  "v=spf1 include:spf.protection.outlook.com -all"

Lookup-cost accounting: include:spf.protection.outlook.com costs 1 lookup (Microsoft publishes the record as a flat ip4 / ip6 list — no nested includes). Total: 1 lookup. Well under the cap. See SPF for Microsoft 365 for the provider deep dive.

Example 3: Google Workspace tenant

Sending estate: Google Workspace / Gmail handling all outbound mail. No third-party services.

example.com.   IN TXT  "v=spf1 include:_spf.google.com -all"

Lookup-cost accounting: include:_spf.google.com costs 1 lookup at the top level plus 3 NESTED lookups (the included record contains include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com). Total: 4 lookups. Well under the cap but burning almost half the budget. See SPF for Google Workspace for the provider deep dive.

Example 4: hybrid Microsoft 365 + transactional ESP

Sending estate: Microsoft 365 for end-user mail plus SendGrid for transactional and Mailgun for marketing.

example.com.   IN TXT  "v=spf1 include:spf.protection.outlook.com include:sendgrid.net include:mailgun.org -all"

Lookup-cost accounting: M365 include 1, SendGrid include 1, Mailgun include 1, plus any nested lookups each provider has in their record (1-2 nested lookups each is typical). Total: 3-7 lookups depending on each providers chain depth at evaluation time. Stays under the cap but the budget is filling up — adding more providers would push past 10.

Example 5: parked domain that sends no mail

Sending estate: a parked / inactive / acquired domain that should send no mail at all.

parked-example.com.   IN TXT  "v=spf1 -all"

Lookup-cost accounting: zero lookups. The record declares "no host is authorized to send mail with parked-example.com in the envelope MAIL FROM". Pair with v=DMARC1; p=reject; at _dmarc.parked-example.com for the strongest no-send posture. Every parked or inactive domain owned by your organization should have this pair published — see DMARC multi-domain strategy for the portfolio- operator playbook.

8. The seven most common mechanism-level pitfalls

Across thousands of SPF records analyzed in DMARC aggregate-report data, the same seven mechanism-level mistakes recur. Each pitfall states the mistake, its operational symptom, and the fix.

1. Publishing +all as the terminator. Symptom: any host on the internet can pass SPF for your domain. Fix: never publish +all; use -all (production) or ~all (deployment ramp).
2. Forgetting the all terminator entirely. Symptom: receivers return the implicit neutral for any non-matching host, which is no better than no record at all. Fix: always end every production record with -all or ~all.
3. Using deprecated ptr. Symptom: intermittent temperror from in-addr.arpa SERVFAIL, slow evaluations, some receivers refuse to honor the record. Fix: remove every ptr mechanism and replace with explicit ip4 / ip6 / a / include.
4. Exceeding the 10-lookup cap. Symptom: every evaluation returns permerror, DMARC downgrades to fail, "SPF stopped working overnight" after adding a vendor. Fix: count lookups per the table in §6, flatten or consolidate senders or move to DKIM-first alignment. See SPF lookup limit and flattening.
5. Mixing mx with provider include:. Symptom: same providers IPs counted twice, lookup budget burned faster than expected, backup-MX servers (which never send) get accidentally authorized. Fix: pick ONE path — either include for cloud-provider deployments OR explicit a / mx for on- prem-managed mail flow.
6. Missing IPv6 address-family coverage. Symptom: SPF passes from IPv4 connections but fails from IPv6 (Gmail and Microsoft 365 increasingly use IPv6 for SMTP). Fix: every IPv4 sending host with an IPv6 address must have its IPv6 address listed in ip6 too — or rely on provider include which already covers both families.
7. Mixing redirect= with all. Symptom: permerror from publishing both modifiers in the same record. Fix: choose ONE — redirect= for full delegation (no all) OR explicit mechanism list with terminal -all (no redirect=).

9. FAQ

What are the eight SPF mechanisms?

RFC 7208 section 5 defines eight mechanisms an SPF record can use to authorize sending hosts: (1) all — matches every host, used as the terminal mechanism with a hard or soft qualifier; (2) ip4 — matches a literal IPv4 address or CIDR range, costs zero DNS lookups; (3) ip6 — matches a literal IPv6 address or CIDR range, costs zero DNS lookups; (4) a — matches the A or AAAA records of a named domain (default: the current domain), costs one DNS lookup; (5) mx — matches the A or AAAA records of every host listed in the MX records of a named domain (default: the current domain), costs one DNS lookup for the MX record itself plus one lookup per MX host (capped at 10 total per mechanism per RFC 7208 section 4.6.4); (6) ptr — matches the reverse-DNS PTR of the connecting IP and checks whether the resulting hostname matches the named domain, costs one PTR lookup plus one forward lookup per result and is explicitly DEPRECATED by RFC 7208 section 5.5; (7) exists — matches if a named domain has any A record (used for SPF macros and dynamic authorization), costs one DNS lookup; (8) include — recursively evaluates the SPF record of a named domain and matches if the included record passes, costs one DNS lookup for the includes own record plus the lookups of every mechanism inside it (the most expensive mechanism class and the #1 cause of 10-lookup-cap overruns).

What are the four SPF qualifiers and what do they mean?

RFC 7208 section 4.6.2 defines four qualifiers that prefix every mechanism and tell the receiver what result to apply when the mechanism matches: (1) + (pass, the default — the mechanism matching means the host IS authorized to send mail with this domain in the envelope MAIL FROM); (2) - (fail, hard fail — the mechanism matching means the host is NOT authorized and the receiver SHOULD reject the message); (3) ~ (softfail — the mechanism matching means the host is probably not authorized but the receiver SHOULD treat the result as a soft signal rather than an outright rejection, useful during a deployment ramp); (4) ? (neutral — the mechanism matching means the domain owner has no opinion on whether this host is authorized, equivalent to omitting the host from the record). Qualifiers prefix mechanisms with no space: -all means "fail if no earlier mechanism matched", +ip4:198.51.100.5 means "pass if the connecting IP is 198.51.100.5", ~include:_spf.example.net means "softfail if the included record matches". Most production SPF records terminate with -all (hard fail catch-all) or ~all (soft fail catch-all during deployment).

What does the SPF include mechanism do?

The SPF include mechanism (RFC 7208 section 5.2) recursively evaluates the SPF record of a named domain against the connecting IP and matches if the included record returns a pass result. Operators use include to delegate SPF authorization to a third-party sender (an ESP, a mailbox provider, a transactional email service) without having to enumerate that providers IP ranges by hand. Canonical example: v=spf1 include:spf.protection.outlook.com -all delegates authorization to Microsoft 365 by including the spf.protection.outlook.com SPF record, which Microsoft maintains as a flat list of Exchange Online sending IPs. include costs one DNS lookup for the includes own SPF record plus the lookups of every mechanism inside it — the included record is evaluated recursively and every nested include/a/mx/ptr/exists/redirect inside it counts toward the same 10-lookup cap. include is the #1 cause of 10-lookup-cap overruns because each include can pull in 1 to 5 nested lookups depending on the providers chain depth. If the included record returns permerror or temperror, RFC 7208 section 5.2 says the include mechanism returns the same error. include also requires the included record to publish v=spf1 — including a record that returns "none" (no SPF record published) returns permerror.

How does the SPF a mechanism work?

The SPF a mechanism (RFC 7208 section 5.3) matches if the connecting IP appears in the A or AAAA DNS records of a named domain. Without an argument, a defaults to the current domain — so a alone in v=spf1 a -all means "match if the connecting IP is one of the A/AAAA records of this domains apex". With an explicit argument (a:mail.example.com), it matches against that named domain instead. With a CIDR suffix (a/24 or a:mail.example.com/24), the match is broadened to the /24 prefix containing each resolved A record. a costs one DNS lookup against the 10-lookup cap. Operators use a when the mail server lives at the same IP as the web server (a means "include my main A record") — most useful for small single-server deployments. Pitfalls: a only resolves the named domains FIRST-LEVEL A records (it does not chase CNAMEs through to the final A — the resolver does that during normal DNS resolution); a does NOT include the IPs of hosts pointed to by MX records (use mx for that); a:mail.example.com does NOT recursively expand into another SPF record (use include for that).

How does the SPF mx mechanism work?

The SPF mx mechanism (RFC 7208 section 5.4) matches if the connecting IP appears in the A or AAAA DNS records of any host listed in the MX records of a named domain. Without an argument, mx defaults to the current domain. With an explicit argument (mx:example.net), it uses that named domains MX records instead. mx costs at least one DNS lookup for the MX record itself plus one lookup per MX host returned, capped at 10 per RFC 7208 section 4.6.4 (mechanisms that request more than 10 lookups MUST return permerror). Operators use mx when the same servers that receive mail for the domain also send mail for it — the legacy "my mail server is my mail server" symmetry. Pitfalls: (1) MX records typically list 2-5 hosts and mx counts EVERY one of them against the lookup cap — a small organization with 5 MX hosts spends 6 of the 10-lookup budget on the single mx mechanism, leaving only 4 lookups for everything else; (2) outsourcing inbound mail to a cloud filter (Proofpoint, Mimecast, Microsoft Defender for Office 365) replaces your MX hosts with the filter providers — mx then authorizes the FILTERS IPs to send AS YOU, which is rarely what you want; (3) using both mx and the providers SPF include can double-count IPs unnecessarily and burn the lookup budget.

Why is the SPF ptr mechanism deprecated?

RFC 7208 section 5.5 explicitly DEPRECATES the ptr mechanism. The mechanism matches if the reverse-DNS PTR record of the connecting IP resolves to a hostname under the named domain (and the forward A record of that hostname includes the connecting IP). Three reasons motivate the deprecation: (1) Performance and DNS load — every ptr evaluation requires a PTR lookup followed by a forward A lookup of every PTR result, which can produce dozens of DNS queries against the in-addr.arpa or ip6.arpa tree for a single SPF evaluation; (2) Reliability — many ASes do not publish accurate PTR records and DNS resolvers frequently return SERVFAIL or transient errors for in-addr.arpa lookups, producing intermittent temperror results; (3) Trust model — relying on reverse DNS for authorization places trust in the IP holders DNS infrastructure rather than the senders, which is not the same trust boundary SPF is designed to enforce. RFC 7208 section 5.5 explicitly says "Use of this mechanism is discouraged because it is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the .arpa name servers" and "If used, proper PTR records have to be in place for the domains MX hosts". Operators should remove every ptr mechanism from their SPF records and replace it with ip4 / ip6 / a / mx / include as appropriate.

What does -all mean in SPF?

The terminal mechanism -all in an SPF record (RFC 7208 section 5.1) means "no other mechanism in this record matched the connecting IP, therefore the result is fail (hard fail)". -all is the canonical SPF policy decision: the domain owner is asserting that hosts NOT explicitly authorized by earlier mechanisms are NOT authorized to send mail with this domain in the envelope MAIL FROM, and the receiver SHOULD reject the message. Receivers that honor SPF treat -all as the strongest negative signal — Gmail, Microsoft 365, Yahoo, and Apple all reject or quarantine -all failures by default. -all is the recommended termination for every production SPF record. Three softer alternatives exist: ~all (softfail — receiver SHOULD treat as a soft signal, useful during a deployment ramp), ?all (neutral — domain owner has no opinion, equivalent to no SPF record at all), and +all (pass — every host is authorized, equivalent to disabling SPF — never publish this in production). Note that DMARC alignment can pass via DKIM even when SPF returns fail, so -all does not on its own block forwarding-mangled SPF — that is what DMARC + DKIM are for. -all is a policy declaration, not an enforcement mechanism — DMARC provides the enforcement.

What is the difference between SPF ip4 and ip6?

SPF ip4 and ip6 are sibling mechanisms (RFC 7208 sections 5.6 and 5.7) that match the connecting IP against a literal IPv4 or IPv6 address or CIDR range respectively. Both cost ZERO DNS lookups — they are evaluated entirely from the SPF records own text, making them the cheapest mechanisms available. Syntax: ip4:198.51.100.5 matches the exact IPv4 address 198.51.100.5; ip4:198.51.100.0/24 matches any IPv4 address in the 198.51.100.0/24 prefix; ip6:2001:db8::1 matches the exact IPv6 address 2001:db8::1; ip6:2001:db8::/32 matches any IPv6 address in the 2001:db8::/32 prefix. Operators use ip4/ip6 when they directly control the sending IP space (an on-prem mail server, a dedicated cloud SMTP host, a static-IP transactional service). The "no DNS lookup" property makes ip4/ip6 the recommended SPF target after flattening — a flattened SPF record converts every include/a/mx into a flat list of ip4/ip6 mechanisms so the 10-lookup cap is no longer a constraint. Pitfalls: (1) literal IPs are brittle — every IP change requires re-publishing the SPF record (managed flatteners help here); (2) ip4 and ip6 are address-family specific — an ip4 mechanism does NOT match an IPv6 connection and vice versa, so dual-stack deployments need both; (3) overly broad CIDR ranges (ip4:0.0.0.0/0) authorize the entire internet — never publish this.

How many DNS lookups does each SPF mechanism cost?

RFC 7208 section 4.6.4 counts the DNS lookup cost of each mechanism toward the 10-lookup cap. The breakdown: (1) ip4 and ip6 cost ZERO lookups — they are evaluated from the SPF records text without DNS; (2) all costs zero lookups — it is the terminal catch-all; (3) a costs ONE lookup (the A/AAAA query for the named domain or current domain); (4) mx costs ONE lookup for the MX record itself plus ONE lookup per host listed in the MX record (a domain with 5 MX hosts spends 6 lookups on a single mx mechanism); (5) include costs ONE lookup for the included records SPF TXT plus the lookups of every mechanism inside the included record (recursively — include is the most expensive mechanism class); (6) exists costs ONE lookup; (7) ptr costs ONE PTR lookup plus ONE forward A lookup per result returned (ptr is also DEPRECATED by RFC 7208 section 5.5 — do not use); (8) the redirect= modifier (RFC 7208 section 6.1) costs ONE lookup (the redirected domains SPF record). The exp= modifier (RFC 7208 section 6.2) costs ONE lookup but ONLY when the receiver generates a fail explanation message — it does not count toward the standard evaluation budget. There is a SEPARATE 2-void-lookup cap (RFC 7208 section 4.6.4) — at most two mechanisms in the entire evaluation chain may return NXDOMAIN or empty result; the third void lookup returns permerror. See help_spf_lookup_limit.php for the full lookup-budget deep dive.

10. Related guides

• SPF explained — the canonical SPF pillar. Surveys the whole protocol: what SPF is, the seven result codes, deployment overviews. Start here for an SPF whole-protocol view; this page is the focused mechanism-vocabulary deep dive.
• SPF qualifiers explained — the per-prefix semantic deep dive that complements this mechanism page. Every mechanism token catalogued here (a / mx / ptr / ip4 / ip6 / exists / include / all) carries an optional qualifier prefix (+ / - / ~ / ?) that decides what verdict the SPF evaluator emits when this mechanism matches. Where this page documents the lookup and match semantics (DNS cost, match conditions, scoping), the qualifiers page documents the per-prefix policy semantics: Pass means accept, Fail means reject or quarantine (depending on DMARC), SoftFail means accept with reputation penalty, Neutral means accept. The -all vs ~all vs ?all choice at the tail of every SPF record is the canonical operator decision documented there. Pair with this page when authoring or debugging an SPF record: this page tells you WHICH mechanism to write, the qualifiers page tells you WHICH PREFIX to put in front.
• include vs ip4 vs a vs mx: the four IP-providing mechanisms compared — the focused four-way operator-decision tree on the IP-providing subset of the eight mechanisms documented on this page. Where this page is the COMPLETE mechanism reference (all eight mechanism types with Definition / Syntax / Lookup cost / When to use / Pitfalls), the include-vs page is the focused decision view that an operator actually walks through when authoring a new SPF record and deciding between include: (delegate to a managed provider's SPF tree, 1 lookup + recursive), ip4: (static IPs you own, 0 lookups), a: (servers identified by A records, 1 lookup), and mx: (the historical "MX is also outbound" pattern, 1 lookup + 1 per MX target). Includes a side-by-side comparison table, a five-question decision matrix, three worked deployment examples (single on-prem Postfix, Microsoft 365 + Mailchimp, Google Workspace hybrid), and the seven most common mechanism-choice mistakes (mx for cloud mail, ip4 for cloud providers, stale includes, bare a on web-server apex, 10-lookup cap overruns, ip4:0.0.0.0/0, missing IPv6). Pair with this page when an operator-decision question arises: this page documents WHAT each mechanism means, the include-vs page documents WHICH of the IP-providing four to actually pick.
• MX records explained — the dedicated DNS-record deep dive on the MX resource record class that the mx mechanism on this page expands at evaluation time. Where this page documents mx as an SPF mechanism (RFC 7208 section 5.4 — "the IPs at every MX target of the named domain authorise mail with this check-host value"), the MX records page documents the underlying record class itself: the RFC 1035 section 3.3.9 wire format (16-bit preference + RDATA target), the canonical multi-MX failover pattern with preference values (10 / 20 / 30), the implicit-MX-from-A fallback rule when no MX is published (RFC 5321 section 5.1), the cloud-mail "MX points at provider" pattern (Google Workspace aspmx.l.google.com, Microsoft 365 example-com.mail.protection.outlook.com), and the lookup-cost arithmetic the mx mechanism inherits (1 lookup for the MX query + 1 lookup per MX target's A/AAAA expansion = easily 3-5 lookups for a 3-MX provider). Read this mechanism page for WHAT mx means in SPF; read the MX records page for WHAT an MX record IS at the DNS layer and WHY the "MX is also outbound" pattern almost never applies to cloud-mail tenants.
• DMARC for cPanel & shared hosting (provider-managed SPF deployment guide) — the OPERATOR'S DEPLOYMENT EXAMPLE for the include:_spf.<provider>.com pattern this mechanism reference documents. Where this page documents the include: token's lookup semantics (RFC 7208 §5.2 — recursive check_host evaluation of the included domain's SPF record, counting against the 10-lookup cap per §4.6.4), the cPanel deployment guide is the concrete operator-facing reference for the shared-hosting class where the host publishes a managed SPF tree and the tenant's SPF record reduces to a single include: token plus a terminating all qualifier. The cPanel guide catalogues the provider-managed include patterns (v=spf1 include:_spf.bluehost.com -all, v=spf1 include:_spf.hostgator.com -all, v=spf1 include:_spf.siteground.net -all, v=spf1 a mx include:secureserver.net -all for GoDaddy cPanel, v=spf1 include:spf.namecheaphosting.com -all for Namecheap Stellar Plus, v=spf1 include:_spf.hostinger.com -all, etc.), the cPanel auto-generated SPF record convention (cPanel populates the include at account creation; the operator verifies it via the Email Deliverability page's "Install Suggested Record" flow rather than composing the include token manually), the lookup-cost arithmetic for nested provider-managed includes (a single include:_spf.bluehost.com token can expand to 3-5 nested lookups, consuming a substantial portion of the 10-lookup cap before any tenant-added senders are evaluated — the canonical cap-overrun risk on shared-hosting cPanel domains layering on Mailchimp/SendGrid/etc.), and the commercial-honesty caveat that shared hosting outbound IPs are pooled across all tenants — reputation regression on one tenant's spam load can drop deliverability for every other tenant even with a perfect include: chain. Pair this mechanism reference (the include: token semantics) with the cPanel deployment guide (the concrete shared-hosting include pattern catalogue + the lookup-cost arithmetic for layered providers) when authoring or auditing an SPF record on an Exim/cPanel/WHM shared-hosting stack.
• DMARC for shared hosting — the PER-NON-CPANEL-CONTROL-PANEL deployment companion that catalogues the FIVE non-cPanel shared-hosting control panels (Plesk, DirectAdmin, ISPConfig, Webmin/Virtualmin, CWP) whose tenant-side SPF-record authoring affordances diverge from the cPanel Email-Deliverability page's "Install Suggested Record" autoflow. Where the cPanel entry above documents the canonical include:_spf.<provider>.com -all pattern for tenant-controlled cPanel/WHM stacks, the shared-hosting spoke documents the per-panel variance: Plesk's Domains → DNS-Settings TXT-record-add UI (operator must compose the v=spf1 include:<provider> ~all token manually because Plesk has no equivalent of cPanel's auto-populate), DirectAdmin's per-domain DNS-management screen (similar manual authoring), ISPConfig's Sites → Domain → DNS tab, Webmin/Virtualmin's BIND-zone editor (which exposes the raw DNS RR file), and CentOS-Web-Panel (CWP)'s DNS-zone-editor plugin. Cross-panel, the lookup-cost arithmetic THIS mechanism reference documents for nested provider-managed include: chains remains identical (the include-token recursive evaluation per RFC 7208 §5.2 counts identically against the 10-lookup cap regardless of which panel rendered the record), but the per-panel publication friction surface (where the operator clicks to author/edit/delete the record) is the structural difference that drives per-tenant deployment-time. Read the shared-hosting spoke alongside the cPanel sibling above when authoring SPF records for tenant-customer-domains hosted on non-cPanel control panels, when composing per-provider deployment runbooks that span both cPanel and non-cPanel customer cohorts, or when diagnosing spf=permerror aggregate rows tied to provider-managed-include cascade overflow across the heterogeneous control-panel customer-domain footprint.
• SPF DNS record syntax explained — the focused DNS-record-level SYNTAX reference (RFC 7208 section 3) that complements this semantic mechanism page. Mechanisms on this page tell you what each token MEANS once parsed; the DNS-syntax page tells you how the record is ENCODED at the DNS layer: the mandatory v=spf1 prefix, the TXT record type (no legacy SPF type 99), the 255-octet character-string limit with multi-string concatenation, the "exactly one SPF record per domain" rule, publication at the apex vs subdomain (no inheritance), and the seven most common syntax mistakes. Read both for a complete mechanism + record-encoding picture.
• SPF lookup limit and flattening — focused deep dive on the RFC 7208 section 4.6.4 10-DNS-lookup limit and the 2-void- lookup cap. Maps every mechanism in this page to its lookup cost and covers the four canonical remediation paths (flattening, sender consolidation, subdomain delegation, DKIM-first alignment).
• SPF permerror vs temperror — focused diagnostic reference on the two SPF error result codes. Every permerror cause documented there (record-not-found, syntax error, multiple records, too-many- lookups, void-lookup-cap, recursive include, deprecated mechanism) maps back to a mechanism-level mistake catalogued on this page.
• Forwarding issues with SPF — focused operational deep dive on the #1 reason SPF breaks in production: forwarding. SPF authenticates the FIRST SMTP hop only (RFC 7208 section 1.1.3) regardless of which mechanisms matched. Covers SRS, ARC, mailing-list mitigations.
• Why SPF alone is insufficient — focused EEAT-authority synthesis answering the canonical operator question "Do I need DMARC if I have SPF?". Enumerates ALL SIX structural limitations of SPF, names which DKIM closes (limitations 2 and 3) and which only DMARC closes (limitations 1, 4, 5, 6), and presents the SPF + DKIM + DMARC minimum viable posture.
• SPF for Microsoft 365 (Exchange Online) — focused operator-implementation walkthrough for SPF on Microsoft 365 / Exchange Online tenants. The include:spf.protection.outlook.com chain in depth and the third-party-sender addition pattern.
• SPF for Google Workspace (Gmail) — focused operator-implementation walkthrough for SPF on Google Workspace / Gmail tenants. The include:_spf.google.com nested- include chain (4 lookups out of the box) and the third-party-sender addition pattern.
• MTA-STS for Google Workspace — the SPF-MECHANISM-AUTHORISED-WORKSPACE- OUTBOUND-IP-AT-_SPF.GOOGLE.COM-INCLUDE- CASCADE-VS-MTA-STS-MX:*.L.GOOGLE.COM- AUTHORISED-INBOUND-MX-CROSS-LAYER- AUTHORISATION-COORDINATION companion to this SPF-mechanism-selection guide. Where THIS page documents the SPF mechanism-selection decision tree at the SENDER-SIDE OUTBOUND-IP- AUTHORISATION layer (the operator authoring the SPF record selects among include: / ip4: / a: / mx: mechanisms to authorise which sender IPs may use the apex domain in the MAIL-FROM envelope), the MTA-STS-for-Workspace spoke is the STRUCTURALLY-ORTHOGONAL AUTHORISATION REFERENCE at the Workspace-tenant RECEIVER- SIDE INBOUND-MX-AUTHORISATION layer — the policy-file mx: allow-list per RFC 8461 §3.2 (e.g. mx: *.l.google.com) authorises which sending MTAs may TLS-handshake with the Workspace-tenant inbound MX, structurally orthogonal to the SPF mechanism-choice this page covers at FOUR Workspace-tenant-specific cross-layer-authorisation-coordination dimensions: (i) SPF include:_spf.google.com authoring the Workspace-tenant outbound-IP pool → MTA-STS mx: *.l.google.com authorising the Workspace-tenant inbound-MX hostname-pattern — the outbound IP authorisation is per-IP at the SPF check (receiver looks up _spf.google.com-published IP ranges and matches the connecting client IP), the inbound MX authorisation is per-hostname at the MTA-STS check (sender looks up Workspace MTA-STS policy file and matches the receiver MX hostname pattern against the mx: allow-list); BOTH bind the Workspace-tenant traffic at the per-tenant transport boundary but at structurally- distinct identity layers; (ii) SPF mx: mechanism co-authoring an outbound IP-set from the domain's MX records → MTA-STS mx: directive co-authoring an inbound MX-hostname-set published at the policy file — the SAME token mx: means two structurally-distinct things at the two protocol layers: SPF mx: in the v=spf1 record authorises the sender-side outbound IPs that the MX-record-published mail-servers resolve to, MTA-STS mx: in the policy file authorises the receiver-side inbound MX hostname- patterns the sending MTAs may TLS-handshake with — the same token semantics diverge per protocol RFC; (iii) SPF 10-DNS- lookup-budget at _spf.google.com 4-level include cascade vs MTA-STS HTTPS- fetch-budget at Workspace-tenant publication boundary — the SPF authorisation- chain has the RFC 7208 §4.6.4 10-DNS-lookup ceiling the operator must guard against (the _spf.google.com → _netblocks{,2,3}.google.com sub-include chain consumes ~3-4 lookups out of the 10-budget); the MTA-STS authorisation- chain has a structurally-distinct HTTPS- fetch-budget at the receiver-MX publication- side (the sending MTA fetches https://mta-sts.<workspace-tenant> /.well-known/mta-sts.txt with a single HTTPS request per max_age window, no 10-lookup ceiling); the two authorisation-chain budget profiles complement each other at the Workspace- tenant publication boundary; (iv) SPF permerror vs MTA-STS mode: testing/enforce/none progression discipline at Workspace-tenant operator boundary — the SPF publication-time-syntax-error class produces spf=permerror at the receiver verifier (a binary success/fail outcome modulated by the receiver's local policy), the MTA-STS publication-time-error class is structurally-distinct because the RFC 8461 §3.2 mode-progression discipline (mode: none → mode: testing → mode: enforce) lets the Workspace-tenant operator validate the policy-file byte-shape AND mx: allow-list accuracy at the testing-mode boundary BEFORE escalating to enforce-mode where a publication-error blocks inbound traffic. Read THIS page when authoring the Workspace-tenant SPF record's outbound-IP authorisation mechanism choice; read the MTA-STS-for-Workspace spoke for the Workspace-tenant-specific receiver-MX-allow- list authoring discipline that closes the transport-layer authorisation that SPF structurally does not address.
• MTA-STS for Microsoft 365 (Exchange Online) — the per-M365-tenant per-accepted-domain MTA-STS-for-M365 spoke is the per-deployment-topology M365 sibling of the Workspace MTA-STS sibling above, documenting the cross-layer coordination at four per-M365-tenant per-accepted-domain SPF-mechanism-cascade vs MTA-STS-mx-allow-list authoring-discipline dimensions: (i) per-M365- tenant outbound-IP envelope-MAIL-FROM-layer authorisation is published via the SPF record's include:spf.protection.outlook.com mechanism-cascade (which itself recursively resolves to a sub-include chain of Exchange Online datacenter outbound-IP ranges), while the per-M365-tenant inbound-MX authorisation is published via the MTA-STS HTTPS policy file at https://mta-sts.<m365-accepted-domain>/.well-known/mta-sts.txt with an mx: *.mail.protection.outlook.com allow-list pattern (which authorises the Exchange Online inbound MX hostnames the per- M365-accepted-domain MX records resolve to); (ii) the per-M365-tenant SPF include:spf.protection.outlook.com cascade consumes ~5 DNS lookups against the RFC 7208 §4.6.4 ten-DNS-lookup budget (Exchange Online publishes a sub-include chain spanning Office 365 Worldwide / GCC / Germany / China datacenter regions), while the per-M365-tenant MTA-STS HTTPS-fetch cost is a single 2KB policy-file retrieval per RFC 8461 §5 max- age-bounded cache window — the per-mechanism- cascade DNS-lookup cost vs MTA-STS HTTPS-fetch cost is the structurally distinct per-resource- budget enforcement boundary; (iii) per-M365- tenant permerror vs MTA-STS publication-time-error are structurally DISTINCT verdict-class outcomes — the SPF per-mechanism-cascade spf=permerror at the 11th DNS-lookup is per-message envelope-MAIL-FROM- layer verdict-class, while the MTA-STS publication-time-error class is per-policy- publication-event publication-discipline compliance failure (TXT-RR id=-tag mismatch with HTTPS policy-file content, HTTPS cert chain failure, max-age window violation) whose per-publication-event drift is observable via per-day per-receiving-MX TLS-RPT RFC 8460 JSON-aggregate failure-details attribution row; (iv) the per-M365-tenant SPF mechanism-cascade publication discipline (per-`include`-chain authoring + per-`include` DNS-lookup budget accounting) closes the per-attacker per-M365- accepted-domain envelope-MAIL-FROM-spoof attack-class, while the per-M365-tenant MTA-STS mode: enforce publication closes the per-attacker per-receiving-MTA STARTTLS- stripping + per-receiving-MX-cert-substitution attack-class — both are cross-layer per-M365- tenant per-accepted-domain publication- discipline primitives operating on parallel envelope-layer-vs-transport-layer authorization coordinates the M365 operator authoring the per-tenant SPF record's mechanism-cascade choice consumes; read the MTA-STS-for-M365 spoke for the per-M365-accepted-domain receiver- MX-allow-list authoring discipline that closes the transport-layer authorisation that the per-M365-tenant SPF mechanism-cascade structurally does not address.
• DKIM explained — the DKIM pillar. DKIM is the cryptographic body-integrity layer that compensates for SPFs first-hop-only model — every operator deploying SPF should deploy DKIM in parallel.
• DMARC record tags explained — every tag in the DMARC DNS record. The DMARC layer is what gives the SPF mechanism vocabulary its policy teeth via p=quarantine and p=reject.
• DMARC alignment explained — identifier alignment (RFC 7489 §3.1, §6.6.2). The SPF result is one input to DMARC alignment; this page explains how the SPF-authenticated domain has to align with the visible From: header for DMARC to pass.
• DMARC reporting pipeline — the SPF-MECHANISM-EVALUATION-RESULT-AS- RUA-RECORD-INPUT-SIGNAL companion documenting how the per-mechanism SPF evaluation outcomes THIS page catalogues propagate end-to-end through the receiver- generated aggregate-report ingestion pipeline into the operator-side per-day RUA row used for SPF authorization-record coverage analysis. Where THIS page documents the SPF mechanism vocabulary (the seven mechanisms all, include, a, mx, ip4, ip6, exists; the four qualifiers +, -, ~, ?; the two modifiers redirect, exp; the per-mechanism DNS-lookup counting rules contributing to the RFC 7208 §4.6.4 10-lookup limit; the per-mechanism IP-match semantics including the CIDR- prefix subtleties and the ip4: default-prefix handling; the per-mechanism evaluation order from left-to-right termination rules), the reporting-pipeline spoke documents the end-to-end transport-and- ingestion path — receiver-side report- generator → DNS resolution of the publisher's rua= URI → MIME-attached SMTP / HTTPS delivery → operator-side inbound mailbox / webhook → MIME-part extraction → gzip-or-zip decompression → XML schema-validation → row-by-row ingestion into the analyzer's dmarc_records table — that carries the per-mechanism SPF evaluation outcome from the receiver-side SPF checker (whose evaluation procedure produces the per-message Authentication- Results stamp spf=pass, spf=fail, spf=softfail, spf=neutral, spf=permerror, or spf=temperror based on which of the mechanisms THIS page documents matched the connecting IP, and the Received-SPF header that records the terminating mechanism) into the aggregate-report aggregator (which groups per-message verdicts by the (source-IP, spf-result, dkim-result, alignment-class, disposition) tuple into a per-day count) into the operator-side RUA XML row whose <auth_results><spf><result> sub-element preserves the SPF evaluation outcome end-to-end. The reporting pipeline is the OBSERVATION-INFRASTRUCTURE that surfaces every per-mechanism evaluation outcome to the operator side: when the SPF record's include:_spf.google.com mechanism evaluates to PASS at the receiver (because the connecting IP falls within Workspace's published IP range), the per-source-IP RUA row at the operator side will carry spf=pass for that Workspace-egress connection — the operator can then join that row against the per-mechanism inventory documented on this page to confirm the SPF record is correctly covering the legitimate Workspace-egress traffic. Conversely when an include: chain unexpectedly evaluates to PERMERROR at the receiver (because a transitive included record has been deleted, or the 10-lookup limit has been exceeded by a runaway include-chain), the per-source-IP RUA row will carry spf=permerror for every connection from every IP in the downstream include-chain — the operator's first signal that a mechanism-evaluation failure is in production. Without the ingestion pipeline carrying per-mechanism SPF evaluation outcomes end-to-end, the operator has no per-mechanism observability into which of the SPF record's mechanisms is actually MATCHING at the receiver, which is FAILING TO MATCH, and which is contributing to the 10-lookup- limit budget. Read the reporting-pipeline spoke alongside this SPF mechanism reference to understand the end-to-end carrier of per-mechanism SPF evaluation outcomes from the receiver-side SPF checker to the operator-side per-day aggregate-row — the pipeline is the OBSERVATION-INFRASTRUCTURE that makes the per-mechanism vocabulary documented on this page operationally-diagnosable at scale. Closes the SPF-cluster ↔ DMARC-reporting-pipeline bridge whereby the per-mechanism SPF-evaluation outcome the operator surfaces from RUA records is the END-CONSUMER of every mechanism / qualifier / modifier mechanic this page documents.
• DMARC multi-domain strategy — portfolio-operator reference for owning many domains. Pairs v=spf1 -all with v=DMARC1; p=reject; for parked and inactive domains.
• Email authentication ecosystem — the cluster-intro pillar tying SPF, DKIM, DMARC, ARC, and BIMI together. Read this first if you are new to the topic.
• Email authentication glossary — defines envelope sender, From: header, organizational domain, alignment, identifier, and the rest of the protocol vocabulary every SPF mechanism interacts with.
• DMARC for SaaS senders — the MULTI-TENANT-PLATFORM-include-MECHANISM-CHAIN-AT-CUSTOMER-DOMAIN-SPF-RECORD-AS-LOAD-BEARING-PREREQUISITE-FOR-SPF-ALIGNED-PASS companion to this SPF-mechanisms-explained RFC 7208 §5 per-mechanism evaluation reference. Where THIS page documents the EIGHT SPF mechanisms (all, include, a, mx, ip4, ip6, ptr, exists) and the per-mechanism evaluation algorithm at the byte level (the + / - / ~ / ? qualifier semantics, the recursive-include-chain DNS-lookup-budget bookkeeping per RFC 7208 §4.6.4 ten- lookup cap, the per-mechanism-evaluated-against-connecting- client-IP match algorithm), the DMARC-for-SaaS-senders deployment spoke documents the canonical multi-tenant SaaS-platform topology where the include: mechanism THIS page documents is the load-bearing publication step at the customer-domain SPF record. The SaaS-senders spoke documents the per-platform-vendor include: target convention (the include:_spf.<platform>.com / include:spf.<platform>.net / include:mail.<platform>.com per-platform-vendor convention each major SaaS-sender / transactional-ESP / marketing-automation platform publishes), the per-customer recursive-include-chain DNS-lookup-budget bookkeeping pattern (where a customer-domain SPF record with FIVE major SaaS-platform include: chains plus Microsoft 365 + Google Workspace + Mailchimp + SendGrid + Salesforce can trivially exceed the RFC 7208 §4.6.4 ten- DNS-lookup permerror cap unless an include-chain-flattening / include-chain- optimization service mediates the chain), and the per-platform-vendor include-chain-versus-direct-ip4-mechanism- publication trade-off (where the SaaS-platform may offer EITHER a managed include: target the platform maintains with its current outbound IP cohorts OR a direct ip4: cohort the customer manually maintains against the platform's published IP-range documentation). The SaaS-senders spoke is the canonical operational reference for the spf=permerror-at-customer-domain RUA-row pattern (a customer-domain SPF record with an over-budget recursive-include- chain produces permerror per RFC 7208 §4.6.4 ten-lookup cap, breaking SPF-alignment for every outbound message from every authorised SaaS-platform IP) and the per-platform include-chain- optimization remediation cookbook the operator runs to close the over-budget lookup-chain. Read the SaaS-senders spoke alongside this page when designing the SPF-publication strategy for a domain whose outbound mail traverses multiple SaaS-platform senders — the per-mechanism SPF evaluation algorithm documented here is the same in single-sender and multi- SaaS-platform contexts, but the include:-mechanism-chain at the customer-domain SPF record is the load-bearing operational decision the SaaS-senders spoke documents.
• DMARC policy modes — the SPF-MECHANISM-EVALUATED-RESULT-AS- LOAD-BEARING-INPUT-TO-EVERY-P-EQUAL- POLICY-MODE-EVALUATED-VERDICT companion to THIS SPF-mechanism evaluation pillar. Where THIS page documents the per- mechanism evaluation algorithm (v=spf1, ip4:, ip6:, include:, a, mx, ? / ~ / - / + qualifiers, all catch-all, redirect=, exp=) that produces the per-message SPF result (Pass, Fail, SoftFail, Neutral, None, TempError, PermError), the DMARC-policy-modes spoke is the publisher-side ENFORCEMENT DISCIPLINE documenting how each p=-tag value translates the SPF-aligned-pass-or-fail input THIS page produces into a per-message receiver- side disposition at FOUR per-policy- mode-to-SPF-mechanism-evaluation-input dimensions: (i) p=none + SPF-Pass+aspf= match — the policy-modes spoke documents how the per-message SPF Pass mechanism-evaluation result THIS page produces becomes the rua-stream-evidence input under p=none WITHOUT any per- message disposition; (ii) p=quarantine + SPF-Fail+SPF-misalign — the policy-modes spoke documents how a per-message SPF Fail mechanism-evaluation result (from -all catch- all matching an unauthorised IP, or include:-cascade-induced SPF=Pass on third-party MAIL-FROM misaligned with Header-From) triggers spam-folder disposition under p=quarantine; (iii) p=reject + SPF- Fail+DKIM-Fail disjunction — the policy-modes spoke documents how the -all hard-fail- producing SPF mechanism-evaluation result combined with DKIM-alignment- fail triggers SMTP-time bounce under p=reject — making the ? / ~ / - qualifier choice THIS page documents the load-bearing publication decision determining per-message bounce-vs-deliver outcome; (iv) sp= + per-subdomain SPF coverage — the policy-modes spoke documents how the per-subdomain sp=-tag enforcement-mode interacts with the per-subdomain SPF record's mechanism list (or absence thereof, falling back to the parent v=spf1 + -all catch-all) to determine per-subdomain message disposition. Read THIS page when understanding HOW the per-message SPF mechanism-evaluation result is computed; read the DMARC-policy-modes spoke when scheduling WHICH receiver- side disposition the publisher publishes for the per-message SPF result THIS page computes.
• MTA-STS policy file syntax — the MTA-STS-HTTPS-POLICY-FILE-mx- PATTERN-LIST-AS-LOAD-BEARING- TRANSPORT-LAYER-MX-ATTESTATION- DISCIPLINE-PARALLEL-TO-SPF-MESSAGE- LAYER-MECHANISM-LIST companion to THIS SPF mechanism-evaluation reference. Where THIS page documents the RFC 7208 §5 SPF mechanism-list evaluation primitives (the include: nested-domain- cascade, the ip4: / ip6: CIDR-range attestation, the a: / mx: A-RR / MX-RR attestation, the exists: A-RR-existence attestation, the + / - / ~ / ? qualifier prefixes), the MTA-STS- policy-syntax spoke is the TRANSPORT- LAYER PARALLEL-PATTERN-ENUMERATION- DISCIPLINE REFERENCE documenting the publisher-side per-policy-id mx: <pattern-list> enumeration discipline whose every per- pattern enumeration primitive is the TRANSPORT-LAYER sibling to the SPF MESSAGE-LAYER mechanism-list primitive THIS page documents at FOUR cross- layer per-publisher-per-pattern- enumeration-discipline-coupling dimensions: (i) per-publisher per-pattern enumeration: SPF's include:<sender-domain> + ip4:<CIDR> + a: + mx: mechanism-list vs MTA-STS's mx: <FQDN-or-glob-pattern> line-per-pattern policy-file enumeration — both publication disciplines enumerate per-publisher per-pattern attestations the receiver-side verifier evaluates deterministically against the observed protocol-state (envelope- MAIL-FROM source-IP for SPF vs SMTP peer-MX-FQDN for MTA-STS), and the MTA-STS-policy-syntax spoke documents the per-pattern wildcard-prefix-glob grammar (mx: *.example.com) and per-pattern cardinality discipline whose every byte-shape parallel is the transport-layer sibling to the SPF per-mechanism cardinality discipline THIS page documents; (ii) per-receiver per-publication- record evaluation algorithm: SPF's first-match-wins mechanism-evaluation loop vs MTA-STS's any-pattern-matches policy-host-attestation evaluation — both evaluation algorithms walk a per- publisher per-pattern enumeration in a deterministic order until either a match is found (producing the per-message verdict) or the enumeration is exhausted (producing a tail-mechanism-or-fallback verdict), and the MTA-STS-policy- syntax spoke documents the per- receiver MX-pattern-match algorithm whose evaluation-pattern parallels the per-SPF-mechanism evaluation loop THIS page documents; (iii) per-publisher per-record cardinality discipline: SPF's single-TXT-record-per-domain cardinality and 10-DNS-lookup budget vs MTA-STS's single-active-policy-per-policy-id cardinality and per-policy-host HTTPS-fetch budget — both publication disciplines impose per-publisher per-record cardinality bounds the receiver-side verifier enforces (SPF's RFC 7208 §3.2 single-record cardinality + §4.6.4 10-DNS-lookup budget vs MTA-STS's RFC 8461 §3.2 single-policy-per-id cardinality + per-policy HTTPS-fetch cache discipline), and the MTA-STS- policy-syntax spoke documents the per-policy-id cardinality contract whose enforcement-pattern parallels the SPF cardinality-and-budget enforcement THIS page references; (iv) transport-layer-vs- message-layer parallel publication discipline: MTA-STS publishes the per-publisher MX-pattern enumeration the SENDER-side MTA-STS-aware-MTA consumes BEFORE the SMTP connection; SPF publishes the per-publisher IP-range enumeration the RECEIVER- side MTA consumes DURING the SMTP envelope-MAIL-FROM evaluation — both publication disciplines complete the cross-layer per- publisher authentication-evidence publication topology (MTA-STS attesting the transport-layer TLS-policy-recipient-MX-pattern, SPF attesting the message-layer envelope-MAIL-FROM-source-IP), and the MTA-STS-policy-syntax spoke documents the publisher- side transport-layer publication- discipline whose every per-pattern attestation is the cross-layer sibling to the SPF message-layer attestation THIS page documents. Read the MTA-STS- policy-syntax spoke alongside this SPF mechanism-evaluation reference when designing the cross-layer per-publisher pattern-enumeration publication discipline — the spoke documents the transport- layer MX-pattern-attestation publication whose per-publisher per-pattern enumeration is the cross-layer sibling to the SPF mechanism-list publication THIS page establishes.
• DANE for SMTP — the PER-MX-HOST-DNSSEC-ANCHORED- TLSA-RR-AS-TRANSPORT-LAYER-PER- PUBLISHER-PER-DOMAIN-PUBLICATION- DISCIPLINE-COMPLEMENT-TO-PER-PUBLISHER- SPF-MECHANISM-CATALOGUE-MESSAGE-LAYER- IP-AUTHORIZATION-PUBLICATION companion documenting how the publisher-side per-MX-host RFC 7672 TLSA-RR DNSSEC- anchored TLS-certificate-binding publication discipline this DANE spoke documents is the structurally- analogous transport-layer publication complement to the per-publisher SPF mechanism-catalogue message-layer IP-authorization publication THIS page documents the RFC 7208 §5 mechanism-grammar of. Where THIS page documents the per-publisher SPF mechanism-catalogue (per-domain v=spf1 TXT-RR publication with the include: / a: / mx: / ip4: / ip6: / ptr: / exists: mechanism grammar, per-mechanism per- source-IP authorization evaluation per RFC 7208 §4.6.4 within the 10- DNS-lookup budget, per-publisher -all / ~all / ?all publication-mode commitment), the DANE-for-SMTP spoke is the structurally-analogous transport-layer publication-discipline reference at four cross-layer per- publisher per-domain publication- discipline coupling dimensions: (i) per-publisher per-domain DNS-RR publication primitive as STRUCTURALLY- IDENTICAL publisher-side publication surface across both protocols — SPF publishes per-domain v=spf1 ... [-~?]all TXT- RR carrying the per-mechanism per- source-IP authorization-list; DANE publishes per-MX-host _25._tcp.<mx-host> TLSA-RR carrying the per-MX-host TLS- certificate cryptographic anchor; both protocols use the same per- publisher DNS-RR publication primitive as the load-bearing per- publisher publication surface operators consume; (ii) per- publisher message-layer SPF per- source-IP authorization vs per- connection DANE per-MX-host TLS-cert attestation as complementary cross- layer per-publisher publication catalogue — SPF attests to per-message envelope-MAIL-FROM source-IP authorization (the receiver's per-message SPF evaluation against the connecting MTA's IP proves the sender is authorized to emit mail from that IP for the envelope-MAIL-FROM domain); DANE attests to per-connection TLS-cert- integrity at the receiving MX (the sender's outbound MTA refuses to deliver if the receiving MX's TLS-certificate doesn't match the DNSSEC-anchored TLSA-RR cryptographic anchor); the two cross-layer per- publisher attestation disciplines compose into a per-publisher complete per-domain publication envelope (message-layer source-IP-authenticated at layer-7 + transport-channel-cert- attested at layer-4), framing the per-publisher SPF mechanism-catalogue this page documents as the message- layer half of the publisher-side per-domain publication-discipline- stack the DANE spoke completes at the transport layer; (iii) per- publisher SPF mechanism-revision lifecycle vs per-publisher DANE TLSA- rotation lifecycle as parallel publication-cadence disciplines — SPF publishers revise mechanism catalogues (add new third-party-ESP include: token → verify cumulative 10-DNS-lookup budget remains within ceiling → commit publication change → observe per-source-IP verdict-distribution settle in the aggregate-XML stream); DANE publishers rotate TLSA records (publish new TLSA-RR for incoming cert → wait DNSSEC-anchored propagation → deploy new cert at receiving MX → retire old TLSA-RR after overlap window); the same per-publisher publish-and- verify-cycle discipline applies to both, bridging the SPF mechanism- revision cadence to the DANE TLSA- rotation cadence; (iv) per- publisher cross-layer publication stack — message-layer SPF + transport- layer DANE — as per-publisher complete per-domain publication-discipline scope — every per-publisher per-domain publication-discipline catalogue (SPF at message-layer + DKIM at message-layer + DMARC at message-layer-policy + DANE at transport-layer + MTA-STS at HTTPS- CA-anchored transport-layer + TLS-RPT at transport-layer-observability + BIMI at display-layer) consumes the same per-publisher per-domain DNS- publication primitive as the load- bearing publication discipline; the DANE-explained spoke is the canonical per-publisher transport-layer-DNSSEC- anchored-cryptographic-publication reference SPF operators consume alongside this mechanism-catalogue page when scoping the per-publisher per-domain cross-layer authentication- and-transport publication discipline the message-layer SPF IP-authorization this page documents is one layer of, alongside the transport-layer DANE TLS-cert-attestation the DANE- explained spoke documents.
• Email Header Analyzer — paste a raw email header and see the Authentication-Results verdict including the SPF result and which mechanism matched. Useful for verifying your published SPF record actually authorizes your sending IPs at real receivers.
• Domain Security Checker — verifies your domains SPF record live from public DNS; flags 10-lookup overruns, deprecated ptr usage, and other mechanism- level problems.
• DNS Record Generator — generates publish-ready SPF records using the mechanism vocabulary this page documents.
• DKIM alignment with DMARC — the SIBLING-ALIGNMENT-PRIMITIVE-AT-PER- MESSAGE-DMARC-EVALUATION companion to this SPF mechanism reference. Where THIS page documents the SPF mechanism vocabulary (a, mx, include, ip4, ip6, ptr, exists, all, and the qualifier prefixes) the receiver's SPF evaluation engine consumes to produce per-message pass/fail verdicts, the DKIM-alignment-with-DMARC spoke documents the DKIM-side d=/From: alignment primitive that runs in PARALLEL to the SPF MAIL-FROM/From: alignment primitive this mechanism reference's evaluation outputs feed into. Concretely, the spoke documents FOUR per-message-DMARC- alignment-evaluation parity dimensions between SPF and DKIM alignment: (i) the SPF MAIL-FROM-domain-vs- From-domain check as the SPF-alignment primitive paralleling the DKIM d=-vs- From check — the spoke documents how the SPF mechanism-evaluation outputs this page architectures (per-message SPF=pass on a particular MAIL-FROM domain) feed the SPF-alignment primitive the DMARC evaluator consumes IN PARALLEL to the DKIM d=/From alignment primitive, making this page's mechanism vocabulary the upstream feeder of ONE of the two DMARC alignment paths; (ii) the relaxed-vs-strict aspf= mode as the organisational-domain-vs-exact-match SPF- alignment-mode parallel to the adkim= DKIM-alignment-mode — the spoke documents how the publisher's aspf= choice (relaxed default vs strict opt-in) constrains the SPF MAIL-FROM-vs-From alignment exactly the way the parallel adkim= choice constrains DKIM d=-vs-From alignment — both modes published in the same DMARC record, both interpreted by the same DMARC evaluator; (iii) the include:-cascade-induced SPF=pass- on-third-party-MAIL-FROM as the SPF- alignment-failure-while-DKIM-alignment- passes asymmetric outcome dimension — the spoke documents how SPF mechanism include: cascades (this page's §3) often produce SPF=pass on a third- party-ESP MAIL-FROM domain (e.g., bounces.sendgrid.net) that DOES NOT align with the From: header domain — making the DKIM-alignment-with- DMARC path the LOAD-BEARING alignment primitive when this mechanism page's evaluation outputs cannot satisfy SPF alignment alone; and (iv) the forwarding-and-mailing-list SPF=fail envelope-rewrite as the SPF-alignment- unavailable-DKIM-alignment-survives receiver-side scenario dimension — the spoke documents how mailing-list and forwarder MAIL-FROM rewriting produces SPF=fail (this page's §8 forwarding-trap) at the destination receiver while the author-domain DKIM signature survives forwarding, so the DKIM-alignment-with-DMARC path becomes the SOLE DMARC alignment path in the forwarding scenario this page's mechanism evaluator must compete with. Read the DKIM-alignment-with-DMARC spoke alongside this SPF mechanism reference when the per-message DMARC alignment evaluation must operate across BOTH the SPF MAIL-FROM/From alignment path this page's mechanism vocabulary feeds AND the DKIM d=/From alignment path the parallel signing- side surface provides.
• DMARC aggregate reports (RFC 7489 §7.2 XML rua) — the PER-MESSAGE-SPF-MECHANISM- EVALUATION-AS-LOAD-BEARING-UPSTREAM- PRODUCER-OF-AGGREGATE-XML-RECORD-LEVEL- SPF-EVIDENCE-ROW-VOCABULARY companion to this SPF mechanism-evaluation reference. Where THIS page documents the per-message SPF mechanism-evaluation algorithm (the RFC 7208 mechanism-matching cascade through ip4: / ip6: / a: / mx: / include: / exists: / ptr: mechanisms producing the Pass / Fail / SoftFail / Neutral / None / TempError / PermError result class), the DMARC- aggregate-reports spoke is the per- receiver per-source-IP per-day RFC 7489 §7.2 XML aggregate-report record-level DOWNSTREAM CAPTURE whose record-level evidence-row vocabulary is the DIRECT OPERATOR-SIDE OBSERVABILITY SURFACE for per-message SPF outcomes at FOUR per- mechanism-evaluation-to-aggregate- evidence-coupling dimensions: (i) per-record row/policy_evaluated/spf=pass attribute as the per-message SPF-aligned- pass evidence-row producer — the aggregate-reports spoke documents the per-record per-source-IP per-day SPF- aligned-pass evidence-row aggregation that is the receiver-side per-message SPF-alignment-pass-rate observability primitive operators consume; (ii) per-record row/policy_evaluated/spf=fail attribute as the per-message SPF-aligned- fail evidence-row producer surfacing the mechanism-mismatch failure modes (the sending-IP NOT covered by any of the published ip4: / ip6: / include: / a: / mx: mechanisms this page documents, the ~all/-all default-policy enforcement producing the SoftFail or Fail result class) — the aggregate-reports spoke documents the per-record per-source-IP per-day SPF- aligned-fail evidence-row aggregation operators consume to attribute SPF mechanism-mismatch root causes per-source- IP per-day; (iii) per-record row/auth_results/spf/result= attribute as the per-message receiver- side spf= verdict-string evidence-row producer surfacing the spf=pass / spf=fail / spf=softfail / spf=neutral / spf=none / spf=temperror / spf=permerror verification outcome the per-message SPF mechanism- evaluation algorithm this page documents produces — the aggregate-reports spoke documents the per-record receiver- side spf= verdict evidence-row vocabulary operators consume to attribute per- message SPF-alignment outcomes to upstream mechanism-evaluation outcomes (10-DNS-lookup-limit permerror, syntax- permerror, transient DNS-resolver-failure temperror); (iv) per-record row/auth_results/spf/domain= attribute as the per-message envelope- MAIL-FROM evidence-row producer surfacing the per-message return-path the SPF mechanism-evaluation algorithm consumes as the load-bearing input identifier — the aggregate-reports spoke documents the per-record envelope-MAIL-FROM evidence-row vocabulary operators consume to attribute SPF outcomes to specific per- message envelope return-path values during legitimate-sender ESP-bounce- subdomain investigations and during envelope-vs-header-domain decoupling evidence aggregation. Read the DMARC- aggregate-reports spoke ALONGSIDE this SPF mechanism reference when investigating per-receiver per-source-IP per-day SPF- aligned-pass-rate or SPF-aligned-fail-rate evidence-row patterns — the spoke is the canonical per-receiver per-source-IP per- day RFC 7489 §7.2 XML aggregate-report record-level downstream-capture reference for the per-message SPF-mechanism- evaluation algorithm this page documents.
• DMARC for Google Workspace — the WORKSPACE-TENANT-SPECIFIC SPF- MECHANISM-EVALUATION-DEPLOYMENT-WORKFLOW companion to this SPF-mechanisms- explained reference. Where THIS page documents the provider-agnostic per- mechanism evaluation algorithm (include:, a, mx, ip4:, ip6:, all), the Workspace deployment spoke is the WORKSPACE-TENANT-SPECIFIC mechanism- publication execution guide at FOUR per-Workspace-tenant-to-SPF-mechanism coupling dimensions: (i) per- Workspace-tenant canonical include:_spf.google.com token publication discipline — the Workspace-tenant-specific include-mechanism publication step that delegates the Workspace-managed Workspace-emitted- envelope-MAIL-FROM IP-source-inventory to Google's _spf.google.com macro-record — the Workspace spoke documents the Workspace-tenant- specific include-mechanism publication step that THIS page's include:-evaluation algorithm consumes as the canonical Workspace-tenant SPF input; (ii) per-Workspace-tenant third- party-sender include- cascade discipline within the 10-DNS- lookup SPF budget — the Workspace- tenant-specific secondary include: enrollment workflow for Salesforce / HubSpot / Mailchimp / Marketo / Zendesk where each additional include: consumes a portion of the 10-DNS-lookup budget THIS page's evaluation algorithm enforces — the Workspace spoke documents the per-Workspace-tenant third-party-sender enrollment-budget discipline operators consume to avoid the permerror outcome THIS page's evaluation algorithm produces when the 10-DNS-lookup budget is exceeded; (iii) per-Workspace- tenant M365-to-Workspace migration include-collision failure mode — the Workspace-tenant-specific failure mode where a tenant migrating FROM Microsoft 365 to Workspace leaves include:spf.protection.outlook.com in place AND adds include:_spf.google.com, producing an SPF record that burns through the 10-DNS-lookup budget before any third-party-sender — the Workspace spoke documents the per-Workspace-tenant migration- coordination workflow operators execute to retire legacy include:spf.protection.outlook.com tokens during Workspace cutover; (iv) per-Workspace-tenant SPF-aligned-pass-rate regression- monitoring via Google Postmaster Tools per-Workspace-tenant authentication-verdict-class telemetry cross-referenced against per-Workspace- tenant rua row/auth_results/spf/result= + row/auth_results/spf/domain= record-level evidence-row aggregation — the Workspace spoke documents the per-Workspace-tenant SPF-mechanism- regression-monitoring workflow operators execute to detect Workspace- tenant SPF-mechanism-evaluation regression (permerror emergence, envelope-MAIL-FROM drift, include:-cascade upstream changes) BEFORE it propagates to per- receiver per-source-IP per-day SPF-aligned-pass-rate drift. Read the Workspace deployment spoke ALONGSIDE this SPF-mechanisms reference when executing SPF on Workspace tenants — the spoke is the canonical Workspace- tenant-specific SPF-mechanism- deployment reference whose per- Workspace-tenant canonical- include:_spf.google.com + third-party-sender-budget + M365-migration-coordination + Postmaster-Tools-regression-monitoring steps are the LOAD-BEARING Workspace- tenant execution discipline every Workspace-tenant SPF-mechanism-driven decision depends on.
• DMARC for Microsoft 365 — the M365-TENANT-SPECIFIC SPF- MECHANISM-EVALUATION-DEPLOYMENT- WORKFLOW companion to this SPF- mechanisms-explained reference. Where THIS page documents the provider- agnostic per-mechanism evaluation algorithm (include:, a, mx, ip4:, ip6:, all), the M365 deployment spoke is the M365-TENANT-SPECIFIC mechanism-publication execution guide at FOUR per-M365-tenant-to-SPF- mechanism coupling dimensions: (i) per-M365-tenant canonical include:spf.protection.outlook.com token publication discipline — the M365-tenant-specific include-mechanism publication step that delegates the Exchange-Online-managed Exchange- Online-emitted-envelope-MAIL-FROM IP-source-inventory to Microsoft's spf.protection.outlook.com macro-record (which in turn includes the per-region Exchange Online IP pool plus Office 365 Government Community Cloud variants where applicable) — the M365 spoke documents the M365-tenant-specific include-mechanism publication step that THIS page's include:-evaluation algorithm consumes as the canonical M365-tenant SPF input; (ii) per- M365-tenant third-party-sender include-cascade discipline within the 10-DNS-lookup SPF budget — the M365-tenant-specific secondary include: enrollment workflow for Salesforce / HubSpot / Mailchimp / Marketo / Zendesk / Exchange Online Connectors / SendGrid bulk-relay tokens where each additional include: consumes a portion of the 10-DNS- lookup budget THIS page's evaluation algorithm enforces — the M365 spoke documents the per-M365- tenant third-party-sender enrollment- budget discipline operators consume to avoid the permerror outcome THIS page's evaluation algorithm produces when the 10-DNS- lookup budget is exceeded; (iii) per-M365-tenant Workspace-to- M365 migration include- collision failure mode — the M365- tenant-specific failure mode where a tenant migrating FROM Google Workspace to M365 leaves include:_spf.google.com in place AND adds include:spf.protection.outlook.com, producing an SPF record that burns through the 10-DNS-lookup budget before any third-party-sender — the M365 spoke documents the per- M365-tenant migration-coordination workflow operators execute to retire legacy include:_spf.google.com tokens during M365 cutover; (iv) per-M365-tenant SPF-aligned- pass-rate regression-monitoring via Microsoft Defender for Office 365 Threat Explorer per-M365-tenant authentication-verdict-class telemetry cross-referenced against per-M365- tenant rua row/auth_results/spf/result= + row/auth_results/spf/domain= record-level evidence-row aggregation — the M365 spoke documents the per- M365-tenant SPF-mechanism-regression- monitoring workflow operators execute to detect M365-tenant SPF-mechanism- evaluation regression (permerror emergence, envelope-MAIL-FROM drift, include:-cascade upstream changes from Microsoft-side macro-record drift) BEFORE it propagates to per-receiver per-source- IP per-day SPF-aligned-pass-rate drift. Read the M365 deployment spoke ALONGSIDE this SPF-mechanisms reference when executing SPF on M365 tenants — the spoke is the canonical M365-tenant-specific SPF-mechanism- deployment reference whose per-M365- tenant canonical- include:spf.protection.outlook.com + third-party-sender-budget + Workspace-migration-coordination + Threat-Explorer-regression-monitoring steps are the LOAD-BEARING M365- tenant execution discipline every M365-tenant SPF-mechanism-driven decision depends on.
• Reverse DNS / PTR records for mail servers — the SPF-MECHANISM-CATALOGUE-AS- LOAD-BEARING-DOWNSTREAM-CONSUMER-OF- IN-ADDR.ARPA-REVERSE-ZONE-PTR-RR- EVALUATION companion to this SPF- mechanism reference. Where THIS page documents the RFC 7208 §5 SPF- mechanism catalogue (the ip4: / ip6: literal-IP-list mechanisms, the a / mx / include: / exists: DNS-resolving mechanisms, the RFC 7208 §5.5 ptr reverse-DNS-evaluating mechanism, the all terminal-mechanism, the 10-DNS-lookup mechanism budget per RFC 7208 §4.6.4), the reverse-DNS-PTR spoke documents the per-source-IP IN-ADDR.ARPA / IP6.ARPA reverse-zone PTR-RR publication discipline whose RFC 1035 §3.5 + RFC 7766 PTR-RR resolution is the upstream evidence input THIS mechanism-catalogue's per-mechanism evaluation consumes at FOUR per-PTR- RR-publication-discipline-to-SPF- mechanism-catalogue coupling dimensions: (i) RFC 7208 §5.5 ptr-mechanism-evaluation- as-direct-consumer-of-per-source-IP- IN-ADDR.ARPA-reverse-zone-PTR-RR- resolution — the SPF ptr mechanism THIS page documents evaluates the per-source-IP reverse-zone PTR-RR (RFC 1035 §3.5 IN-ADDR.ARPA / IP6.ARPA owner-name derivation) AND performs forward- confirmation against the resulting PTR target's forward A/AAAA RRs to verify the per-source-IP corresponds to a publisher-claimed hostname- suffix; any per-source-IP PTR-RR publication-discipline defect THIS reverse-DNS spoke enumerates (missing PTR, forged PTR, FCrDNS- verification failure, EHLO-vs-PTR incoherence) collapses the ptr-mechanism evaluation to spf=none / spf=neutral / spf=fail; (ii) per-source-IP-FCrDNS- identity-corroboration-as-upstream- input-into-receiver-side-reputation- scoring-of-SPF-mechanism-aligned- verdicts — the per-source-IP forward-confirmed-reverse-DNS publication discipline THIS reverse- DNS spoke documents is the upstream- evidence input every receiver-side SPF-mechanism-aligned-pass reputation- model (Postmaster Tools / Threat Explorer / Validity-Sender-Score) consumes alongside the SPF-mechanism evaluation THIS page documents — per- source-IP spf=pass verdicts arriving without a per- source-IP PTR-RR or with FCrDNS verification failure are scored differently from spf=pass verdicts arriving with well-formed FCrDNS; (iii) per-source-IP- EHLO-vs-PTR-coherence-as-upstream- input-into-RFC-7208-§2.3-HELO- identity-evaluation — the RFC 7208 §2.3 HELO-identity evaluation THIS page documents consumes the per-source-IP reverse- zone PTR-RR THIS reverse-DNS spoke documents — per-source-IP HELO identities that do not match the per-source-IP PTR-target hostname are receiver-side-suspect even when the explicit SPF-mechanism evaluation returns spf=pass against the envelope MAIL FROM; the EHLO-vs- PTR coherence-check is the upstream- evidence input the SPF-mechanism catalogue's HELO-identity-evaluation slot consumes; (iv) per- source-IP-PTR-RR-publication- discipline-as-load-bearing-prerequisite- for-RFC-7208-§5.5-ptr-mechanism- deprecation-cost-mitigation-at- publisher-side — although RFC 7208 §5.5 deprecates the ptr mechanism (cost-of- lookup discipline), the per-source-IP PTR-RR publication discipline THIS reverse-DNS spoke documents remains load-bearing for the FCrDNS-driven reputation-scoring AND HELO-identity- evaluation pathways the SPF-mechanism catalogue's non-ptr mechanisms evaluate alongside — the publisher-side PTR-RR-publication discipline is the LOAD-BEARING upstream-prerequisite for the receiver-side reputation-scoring feedback loop the SPF-mechanism catalogue's per-mechanism-aligned- pass verdicts feed into. Read the reverse-DNS-PTR spoke alongside THIS page when the publisher asks "how does the per-source-IP reverse-zone PTR-RR publication discipline translate into SPF-mechanism evaluation and per- source-IP FCrDNS identity- corroboration" — the answer is FOUR- LAYERED: THIS page documents the SPF-mechanism catalogue, the reverse- DNS-PTR spoke documents the per- source-IP reverse-zone PTR-RR publication discipline whose RFC 1035 §3.5 + RFC 7766 PTR-RR resolution is the upstream-evidence input every SPF-mechanism-aligned-pass receiver- side decision consumes.
• Email spoofing (the seven canonical techniques) — where THIS page documents the RFC 7208 §5 per-mechanism evaluation catalogue (all, include:, a:, mx:, ip4:, ip6:, ptr:, exists:, redirect=, exp=) governing per-publisher per-domain envelope- MAIL-FROM authorization, the email-spoofing spoke documents the seven canonical attacker techniques whose RFC 5321 envelope-MAIL-FROM- spoofing variant is the LOAD-BEARING attack class the per-publisher per-mechanism SPF publication discipline THIS page documents materially defends against. FOUR structurally-distinct PER-MECHANISM- TO-SPOOFING-TECHNIQUE-DEFENSE coupling dimensions the email- spoofing spoke operationally documents: (i) RFC 5321 envelope-MAIL-FROM-spoofing as load-bearing attack class THIS page's per-mechanism publication discipline DIRECTLY defends against at the receiver-side envelope- validation boundary — the attacker forges MAIL FROM:<sender@ publisher-domain> in the SMTP envelope while operating from unauthorized infrastructure; the per-publisher per-mechanism publication discipline THIS page documents (v=spf1 ip4:<authorized- sender-IPs> include:< authorized-include-zones> -all) produces a per- publisher per-domain SPF policy whose RFC 7208 §4 evaluation algorithm receiver-side evaluation returns spf=fail at the per-source-IP unauthorized-sender boundary; (ii) per-mechanism -all fail qualifier as load-bearing publication- discipline determinant of per-publisher per-domain envelope-spoofing rejection-rate at the receiver-side — the per-mechanism qualifier choice (-all Fail vs ~all SoftFail vs ?all Neutral) materially determines whether per-receiver downstream processing rejects (Fail) or quarantines (SoftFail) or accepts (Neutral) the envelope- MAIL-FROM-spoofing variants the email-spoofing spoke catalogues; (iii) RFC 5322 From:-forgery as orthogonal attack class the per-publisher SPF publication discipline THIS page documents does NOT defend against — RFC 5322 From: forgery operates at the message-layer + RFC 7489 DMARC alignment-evaluation-boundary ORTHOGONAL to the envelope- layer per-publisher SPF evaluation boundary — the email-spoofing spoke's per-technique taxonomy distinguishes the envelope-layer attack class (which SPF defends) from the message-layer From:-header attack class (which DMARC alignment + DKIM message-signing defend); (iv) per-publisher per-mechanism include: zone-cascade publication discipline + ip4: + a: + mx: mechanism mix as load-bearing per-publisher per-domain envelope-MAIL-FROM- spoofing-defense surface composition whose drift surfaces in aggregate-XML rua reports as envelope-MAIL-FROM-spoofing- eligible source-IPs — when the per-publisher per- mechanism publication discipline THIS page documents drifts (an ESP onboarded without SPF- include update, a per-publisher per-domain ~all SoftFail qualifier publication choice instead of -all , a per-publisher RFC 7208 §4.6.4 ten-DNS-lookup ceiling overflow rendering permerror), the per-publisher per-domain envelope-MAIL-FROM-spoofing- eligible source-IP set materially grows — and the email-spoofing spoke's per-technique catalogue documents the exploit- surface classification this drift creates. Read the email- spoofing spoke ALONGSIDE this SPF-mechanism-evaluation catalogue whenever the publisher scopes a per-publisher per- domain envelope-MAIL-FROM- spoofing-defense baseline — the seven canonical spoofing techniques the email-spoofing spoke catalogues materially define the attack-surface taxonomy this per-mechanism evaluation catalogue's per- publisher per-domain SPF publication discipline defends the envelope-layer subset of.
• DMARC for transactional email — the PER-ESP-INCLUDE-CHAIN- EXPANSION-AT-MULTI-ESP-CUSTOMER- DOMAIN-SPF-PUBLICATION companion to this SPF-mechanism-evaluation catalogue. Where THIS page documents the eight per-mechanism evaluation rules (RFC 7208 §5 — all, include, a, mx, ip4, ip6, ptr, exists — whose per-mechanism evaluation produces the spf= verdict consumed by the receiver-side DMARC engine), the transactional-email spoke is the per-ESP per-customer- domain include-chain-execution companion documenting FOUR transactional-SPF-include-chain- execution-constraint dimensions whose per-customer satisfaction determines whether the per-mechanism evaluation discipline THIS page documents can complete within the per-customer-domain SPF record without producing PermError: (i) per- ESP include-chain DNS-lookup expansion stacks against the RFC 7208 §4.6.4 ten-DNS-query budget — SendGrid's include:sendgrid.net expands to ~7 DNS lookups, Mailgun's include:mailgun.org expands to ~5, Amazon SES's include:amazonses.com expands to ~3, Postmark's include:spf.mtasv.net expands to ~3, and SparkPost's include:sparkpostmail.com expands to ~4 — multi-ESP customers stacking three or more transactional-ESP includes routinely exceed the 10-query budget producing the SPF PermError mechanism- evaluation result THIS page documents as the per-mechanism resource- exhaustion failure mode; the transactional-email spoke documents the per-customer-domain include- chain budgeting discipline; (ii) per- customer-domain include-chain authoring discipline determines which per-mechanism evaluation rule each include resolves against at the per-receiver SPF evaluator — the per-customer- domain operator chooses which transactional-ESP includes to publish (canonical include: vs direct ip4: / ip6: reference), and the per-customer- domain choice determines which per-mechanism evaluation rule each authorisation entry exercises at the receiver-side per-mechanism sweep; the transactional-email spoke documents the per-customer- domain include-vs-direct authoring decision pattern; (iii) per- ESP per-customer-domain include- target publication is the per- ESP-side discipline that determines whether each include resolves within budget — the per- ESP-published include-target record (the SPF record returned when a customer's include-chain traverses to the ESP's publication zone) determines the per-ESP DNS-lookup expansion cost, and per-ESP publication cadence variance across SendGrid / Mailgun / Amazon SES / Postmark / SparkPost determines the per- customer-domain include-chain DNS-lookup expansion baseline; the transactional-email spoke documents the per-ESP publication discipline observability and the per-customer-domain monitoring cadence; (iv) per-customer- domain escalation path to SPF macro expansion or flat-include consolidation is the structurally- required remediation when the per-customer-domain include-chain exceeds the per-mechanism evaluation DNS-query budget — the transactional-email spoke documents the per-customer-domain consolidation discipline (flatten- all-includes via per-customer- domain SPF macro expansion, delegate per-customer-domain SPF to an SPF-flattening service, publish per-customer-domain ip4: / ip6: direct references in lieu of per-ESP includes) and the per- customer-domain operator-execution path from include-chain-PermError baseline to per-mechanism- evaluation-budget-compliant flat-include posture. Read the transactional-email spoke ALONGSIDE this SPF-mechanism- evaluation catalogue whenever the operator scopes a per-customer- domain multi-ESP transactional- SPF deployment on SendGrid / Mailgun / Amazon SES / Postmark / SparkPost — the per-mechanism evaluation discipline THIS page documents IS the per-message per- receiver per-source-IP authorisation contract the transactional-email deployment guide encodes the per- ESP per-customer-domain include- chain execution discipline for.
• MTA-STS explained — the per-publisher per-policy-domain transport-layer MTA-STS policy-publication- discipline companion to this SPF-mechanism- evaluation reference. Where THIS page documents the RFC 7208 §5 per-publisher per-domain SPF-mechanism catalogue (the 8-mechanism token grammar include: / a: / mx: / ip4: / ip6: / ptr: / exists: / all + 4-qualifier prefix-byte grammar + 2-modifier token grammar redirect= / exp= + per-message left- to-right per-mechanism evaluation algorithm + per-receiver per-source-IP authorisation decision) at the envelope- layer per-message MAIL-FROM-domain IP- authorisation boundary, the MTA-STS- explained spoke is the PER-PUBLISHER-PER- POLICY-DOMAIN-TRANSPORT-LAYER-MTA-STS- POLICY-PUBLICATION reference documenting the RFC 8461 per-publisher per-policy- domain _mta-sts.<d> TXT-RR publication + HTTPS-policy-host file publication + per-policy-domain mode: enforce commit choice publication discipline at the per-hop transport-layer SMTP STARTTLS enforcement boundary. Four CROSS-LAYER-PUBLICATION- DISCIPLINE coupling dimensions the MTA-STS-explained spoke documents: (i) per-publisher per-domain envelope-layer sender-authorisation publication discipline parallel to transport-layer hop-confidentiality publication discipline at distinct protocol layers — both the per- publisher per-domain SPF-mechanism- publication discipline THIS page documents (the envelope-layer per- message MAIL-FROM-domain IP- authorisation primitive) and the per- publisher per-policy-domain MTA-STS- policy publication discipline the spoke documents (the transport-layer per-hop confidentiality-and-MITM-resistance primitive) are per-publisher per-domain publication-discipline primitives at distinct protocol layers that COMPOSE at the per-publisher per-domain complete-stack authentication-and- encryption deliverability posture boundary; (ii) per-publisher per-domain DNS-TXT-RR-byte-grammar-publication discipline parallel at distinct DNS- scope coordinates — both the per-publisher per-domain v=spf1 ... ~all TXT-RR (carrying the per-mechanism authorisation list the per-receiver SPF evaluation consumes) and the per- publisher per-policy-domain _mta-sts.<d> TXT-RR (carrying the policy-ID version pointer the per-receiver MTA-STS-policy discovery consumes) are per-publisher per-domain DNS-TXT-RR-byte-grammar publication primitives at distinct per-publisher per-domain DNS-scope coordinates; (iii) per-publisher per-domain sender-identity-publication vs hop- confidentiality-publication scope parallel at distinct protocol layers — the per-publisher per-domain SPF-mechanism publication discipline THIS page documents commits the per-message envelope-layer sender- identity authorisation scope (which per-source-IP / per-include-chain sender-identities are pass-eligible for the per- publisher per-domain MAIL-FROM envelope) and the per-publisher per- policy-domain MTA-STS-policy publication discipline the spoke documents commits the per-hop transport-layer confidentiality scope (which per-SMTP- session payload bytes the per-policy- domain MTA-STS-enforced STARTTLS protects); (iv) per-publisher per-domain receiver-side per-message verdict composition discipline at the per- receiver envelope-layer-and-transport- layer verdict-composition boundary — the per-message receiver-side SPF-evaluation outcome the per-mechanism left-to-right per- message evaluation algorithm THIS page documents produces composes operationally with the per-receiver MTA-STS-enforced STARTTLS-accept-or- reject outcome the per-policy-domain MTA-STS-policy discipline the spoke documents produces at the per-receiver per-message envelope-layer-plus- transport-layer composite verdict- composition boundary. Read THIS page when AUTHORING the per-publisher per- domain SPF-mechanism envelope-layer publication discipline; read the MTA-STS-explained spoke when CO- AUTHORING the per-publisher per-policy- domain MTA-STS transport-layer policy- publication discipline whose per-policy- file mode: enforce commit composes operationally with the envelope-layer SPF-mechanism evaluation discipline THIS page documents.
• TLS-RPT record syntax — the per-publisher per-policy-domain TRANSPORT-LAYER-REPORTING-RECORD-BYTE- GRAMMAR-PUBLICATION-DISCIPLINE-AS-PEER- PUBLICATION-DISCIPLINE-COUSIN companion to this RFC 7208 §5 SPF-mechanism envelope- layer evaluation reference. Where THIS page documents the per-publisher per-domain SPF-mechanism-list byte-grammar (ip4:, ip6:, a, mx, include:, exists:, ptr, all + qualifier prefixes + / - / ~ / ?) at the envelope-layer per- message MAIL FROM / HELO evaluation boundary, the TLS-RPT-record-syntax spoke documents the per-publisher per-policy- domain _smtp._tls.<d> TXT-RR byte-grammar at the transport-layer reporting-record byte-grammar publication discipline boundary. Three CROSS-LAYER- PUBLICATION-DISCIPLINE coupling dimensions the TLS-RPT-record-syntax spoke documents the SPF-mechanism envelope-layer publication discipline THIS page documents parallels at distinct protocol layers: (i) per- publisher per-domain DNS-TXT-RR-byte-grammar publication discipline parallel at distinct DNS-scope coordinates — both the per-publisher per-domain SPF TXT-RR at the organization-domain DNS scope (carrying the per-publisher per-domain authorized-sender mechanism-list the per-message envelope- evaluation consumes) THIS page documents and the per-publisher per-policy-domain _smtp._tls.<d> TLS-RPT TXT-RR (carrying the per-publisher per- policy-domain reporting-URI list the per- receiver per-domain TLS-failure aggregator consumes) are per-publisher per-domain DNS-TXT-RR-byte-grammar publication primitives at distinct per-publisher per- domain DNS-scope coordinates inside the per-publisher per-domain DMARC-family publication-portfolio authoring discipline; (ii) per-publisher per-domain envelope-layer-authorization publication discipline parallel to transport-layer- reporting-channel publication discipline at distinct protocol layers — both the per-publisher per-domain SPF-mechanism- list publication discipline THIS page documents (the envelope-layer per-message MAIL FROM authorized-sender publication primitive) and the per-publisher per- policy-domain TLS-RPT-reporting-URI publication discipline the spoke documents (the transport-layer per-domain TLS-failure- observability publication primitive) are per-publisher per-domain publication- discipline primitives at distinct protocol layers that COMPOSE at the per-publisher per-domain complete-stack envelope- authentication-plus-transport-reporting publication-portfolio boundary; (iii) per-publisher per-domain per-message-evaluated-mechanism-list vs per-receiver-per-day-aggregated-TLS- failure-list granularity boundary at distinct verdict-stream attribution tiers — the per-message per- publisher per-domain SPF-mechanism- evaluation verdict THIS page documents commits the per-publisher per-domain per- message envelope-layer authorized-sender verdict at the envelope layer (per-message MAIL FROM evaluation produces a per- message pass / fail / softfail / neutral verdict) and the per-receiver per-day per-publisher per-policy-domain TLS-RPT aggregate report the spoke documents commits the per-receiver per-day per- publisher per-policy-domain transport- layer STARTTLS-session-failure observability verdict at the transport layer (per-day aggregation of per-receiver per-publisher per-policy-domain failed SMTP sessions). Read the TLS-RPT-record-syntax spoke ALONGSIDE this SPF-mechanism reference whenever the per-publisher per-domain operator AUTHORS the per-publisher per- domain DNS-TXT-RR publication portfolio spanning the envelope-authentication- record + transport-reporting-record publication-discipline pair — the per- publisher per-domain SPF-mechanism publication discipline THIS page documents is the per-publisher per-domain ENVELOPE- LAYER publication primitive; the per- publisher per-policy-domain TLS-RPT-record- syntax spoke is the per-publisher per- policy-domain TRANSPORT-LAYER-REPORTING- PUBLICATION primitive that closes the per- publisher per-domain envelope-layer-plus- transport-layer publication-portfolio authoring boundary.
• DMARC policy rollout — the PER-PUBLISHER-PER-DOMAIN-DMARC-RAMP-AS- LOAD-BEARING-DOWNSTREAM-CONSUMER-OF-PER- MECHANISM-SPF-RECORD-AUTHORING-DISCIPLINE companion to this per-mechanism SPF-record authoring reference. Where THIS page documents the per-mechanism SPF authoring discipline (include: / ip4: / ip6: / a: / mx: mechanism choice, the per- record 10-DNS-lookup ceiling, the per-record ~all vs -all terminal- qualifier choice), the policy-rollout spoke documents the FOUR PER-DMARC-RAMP-PHASE-AS-PER- MECHANISM-SPF-AUTHORING-CONSUMER DIMENSIONS the per-publisher per-domain operator MUST master to advance through the canonical p=none → p=quarantine → p=reject ramp without per-phase rollback: (i) per-phase TERMINAL-QUALIFIER hardening cadence (~all → -all) — the per-publisher per-domain operator MUST retain SPF ~all soft-fail terminal- qualifier through the DMARC p=none + p=quarantine(pct=10..50) phases and ONLY harden to -all hard-fail terminal-qualifier AFTER advancing into p=quarantine(pct=75..100) + p=reject, because per-receiver per-day per-source-IP unauthorised-sender legitimate-traffic surfaced by aggregate- report observability under ~all + p=none CANNOT be remediated once -all + p=reject is jointly published — the per-phase joint cross-mechanism hardening cadence is the load-bearing pre-advancement discovery discipline; (ii) per-phase 10-DNS- LOOKUP-CEILING audit BEFORE advancement — the per-publisher per-domain operator MUST audit the per-record cumulative DNS-lookup count (per-include: macro- expansion + per-a: / mx: per-target lookup) BEFORE each per-phase advancement, because a per-record permerror from 10-lookup-ceiling violation observed under p=none becomes a per-receiver per-day per-source-IP legitimate-mail-bounce blast radius under p=quarantine / p=reject; (iii) per-phase per-include: macro-expansion SUB-TREE per-vendor-MIGRATION coordination — the per-publisher per-domain operator MUST coordinate per-vendor SPF-flattening migrations ONLY during p=none phase windows because per-include: macro- expansion sub-tree per-vendor-IP-set drift during p=quarantine / p=reject phases causes per-source- IP legitimate-vendor-traffic per-receiver per- day quarantine-and-reject regression attributable to the SPF-flattening migration rather than the per-DMARC-ramp-phase advancement; (iv) per-phase per- receiver per-day rua= aggregate- report policy_evaluated.spf + auth_results.spf row-by-row observability primitive — the per- publisher per-domain operator reads the per- day per-receiver rua= aggregate report <policy_evaluated><spf> and <auth_results><spf> verdict-per-row block as the SINGLE observability surface that surfaces BOTH per- mechanism SPF-record authoring evidence AND per-policy-ramp-phase enforcement-verdict- distribution evidence, letting the operator attribute a per-receiver per-day per-phase enforcement-distribution deviation to the SPECIFIC per-mechanism SPF-record authoring root cause. Read the policy-rollout spoke ALONGSIDE this per-mechanism SPF-record authoring reference whenever the per-publisher per-domain operator COORDINATES the per- mechanism SPF-record authoring discipline with the per-DMARC-ramp-phase advancement cadence — the per-policy-ramp-phase-as-per- mechanism-SPF-authoring-consumer coordination catalogue is the canonical operator-facing companion every per-publisher per-domain SPF- mechanism-authoring operator MUST master to advance through the canonical p=none → p=quarantine → p=reject ramp without per-phase rollback.
• DMARC myths and misconceptions — the PER-PUBLISHER-PER-DOMAIN-SPF- MECHANISM-AUTHORING-OPERATOR-SIDE-MISTAKE- PATTERN-AS-PER-PUBLISHER-PER-DOMAIN-MYTH- CATALOGUE-LOOKUP-REFERENCE companion to THIS SPF-mechanisms-explained reference. Where THIS page documents the per-publisher per-domain SPF mechanism-authoring discipline (the per-mechanism token taxonomy all / include / a / mx / ptr / ip4 / ip6 / exists per RFC 7208 §5, the per-qualifier modifier taxonomy + / ~ / ? / -, the per- modifier taxonomy redirect= / exp=, and the per-mechanism per-qualifier per-modifier ABNF-precise token-emission-and-evaluation discipline floor), the DMARC-myths-and-misconceptions spoke documents the per-publisher per- domain operator-side SPF-mechanism-authoring misconception bucket the per-publisher per- domain SPF-mechanism-authoring operator MUST consult at FOUR per-SPF-mechanism- authoring-vs-DMARC-myth-catalogue coupling dimensions: (i) per-publisher per- domain "+all is a valid neutral qualifier" misconception lookup as per-publisher per-domain SPF-qualifier- semantics mythbusting catalogue consultation — per-publisher per- domain operators commonly adopt the "+all is a valid neutral SPF qualifier" / "~all means soft-fail is rejected" / "?all is the recommended observation-only qualifier" SPF-qualifier-semantics misconceptions during per-publisher per- domain SPF record-authoring, and the DMARC- myths-and-misconceptions spoke's SPF- qualifier-semantics mythbusting entries IS the per-publisher per-domain canonical pre-flight per-publisher per-domain SPF- qualifier-selection audit reference the per-publisher per-domain SPF-mechanism- authoring operator MUST consult BEFORE per-publisher per-domain SPF record commit; (ii) per-publisher per- domain "include:-cascade depth is unbounded" misconception lookup as per-publisher per-domain SPF-lookup- budget mythbusting catalogue consultation — per-publisher per- domain operators commonly adopt the "include:-cascade depth is unbounded" / "the RFC 7208 §4.6.4 ten- DNS-lookup permerror cap counts only top- level mechanisms" / "DMARC ignores SPF permerror" SPF-lookup-budget misconceptions during per-publisher per-domain SPF record-authoring, and the DMARC-myths-and- misconceptions spoke's SPF-lookup-budget mythbusting entries provide the per- publisher per-domain canonical pre-flight per-publisher per-domain SPF-lookup-budget- accounting audit reference; (iii) per-publisher per-domain "ptr-mechanism is the recommended legacy SPF mechanism" misconception lookup as per-publisher per- domain SPF-deprecation mythbusting catalogue consultation — per- publisher per-domain operators commonly adopt the "ptr-mechanism is the recommended legacy SPF mechanism" / "ptr-mechanism is interchangeable with a- mechanism" / "deprecated mechanisms still evaluate as pass" SPF- deprecation misconceptions during per- publisher per-domain SPF record-authoring, and the DMARC-myths-and-misconceptions spoke's SPF-deprecation mythbusting entries (RFC 7208 §5.5 explicitly deprecates ptr; receivers MAY return permerror for ptr-mechanism evaluation; per-publisher per-domain SPF record- authoring MUST avoid ptr in favour of ip4 / ip6 / a / mx / include mechanisms) provide the per-publisher per- domain canonical pre-flight per-publisher per-domain SPF-deprecation-avoidance audit reference; (iv) per-publisher per- domain "SPF mechanism choice does not affect DMARC verdict" misconception lookup as per-publisher per-domain SPF-DMARC- coupling mythbusting catalogue consultation — per-publisher per- domain operators commonly adopt the "SPF mechanism choice does not affect DMARC verdict" / "SPF-aligned-pass means SPF- pass-result alone" / "DMARC ignores SPF mechanism token semantics" SPF-DMARC- coupling misconceptions during per- publisher per-domain SPF-mechanism- selection planning, and the DMARC-myths- and-misconceptions spoke's SPF-DMARC- coupling mythbusting entries (per- publisher per-domain SPF mechanism-choice determines per-receiver per-message SPF- pass-result-rate which IS the load- bearing per-publisher per-domain SPF- aligned-pass-rate input to the per- receiver per-message DMARC composite- evaluator; SPF-pass-result-rate-floor regression compounds per-publisher per- domain DMARC policy-mode-ramp phase- advancement rejection blast-radius) provide the per-publisher per-domain canonical pre-flight per-publisher per- domain SPF-DMARC-coupling audit reference. Read THIS SPF-mechanisms-explained reference when AUTHORING the per-publisher per-domain SPF mechanism-token selection AND when COORDINATING the per-publisher per-domain SPF-aligned-pass-rate-floor against the per-publisher per-domain operator-side mistake-pattern catalogue; read the DMARC-myths-and-misconceptions spoke when AUDITING the per-publisher per- domain SPF-mechanism-authoring operator- side mistake-pattern catalogue lookup BEFORE per-publisher per-domain SPF record-publication commit THIS page documents.
• MTA-STS vs DANE for SMTP — the structurally parallel transport-layer publication-vocabulary decision-matrix companion to this SPF envelope-MAIL-FROM-layer mechanism- vocabulary decision-matrix reference. Where THIS page documents the RFC 7208 §5 eight per- mechanism evaluation primitives whose per- publisher per-domain selection drives the per- message envelope-MAIL-FROM-layer SPF verdict- evaluation pathway, the MTA-STS-vs-DANE spoke documents the structurally parallel transport- layer per-publisher per-domain publication- vocabulary decision-matrix whose per-publisher per-domain selection drives the per-receiving- MTA per-MX-host STARTTLS enforcement pathway. Four per-protocol-layer publication-vocabulary coupling dimensions matter at the per-publisher per-domain envelope-and-transport-layer publication-discipline boundary: (i) per- publisher per-domain DUAL publication-channel primitive — per-publisher SPF mechanism- vocabulary publication via per-domain TXT-RR zone-file commit, per-publisher MTA-STS via per-domain HTTPS Well-Known-URI + per-domain TXT-RR policy-id signal, per-publisher DANE via per-MX-host DNSSEC-signed TLSA-RR publication; (ii) per-publisher per-domain DUAL per-receiver-side resource-cost profile — per-publisher SPF lookup-budget consumes recursive-DNS lookups against the RFC 7208 §4.6.4 ten-lookup ceiling, per-publisher MTA-STS policy-fetch consumes recursive-HTTPS fetches against per-sending-MTA-side cache TTL boundary; (iii) per-publisher per-domain DUAL trust-anchor model — per-publisher SPF trust-anchored to per-domain zone-file commit authority, per-publisher MTA-STS trust- anchored to per-domain HTTPS Web-PKI X.509 certificate, per-publisher DANE trust- anchored to per-zone DNSSEC signing-chain; (iv) per-publisher per-domain DUAL composite envelope-and-transport-layer publication- vocabulary portfolio — per-publisher SPF envelope-MAIL-FROM-layer mechanism-vocabulary + per-publisher MTA-STS-or-DANE transport- layer publication-vocabulary form the composite per-publisher per-domain envelope- and-transport-layer publication-discipline portfolio every per-publisher per-domain deployment THIS page documents materially coordinates publication-vocabulary discipline against.
• DKIM canonicalization — the canonical RFC 6376 §3.4 reference on DKIM c= tag header-and-body canonicalization mode-selection (simple/simple vs relaxed/relaxed) that every per- publisher per-domain operator pairing SPF mechanism-vocabulary publication with DKIM application-layer signing should read alongside this SPF mechanism-vocabulary primer. The DKIM canonicalization mode-selection discipline IS the structurally-parallel per-publisher per- selector application-layer byte-normalisation discipline to the per-publisher per-domain envelope-MAIL-FROM SPF mechanism-vocabulary interpretation discipline THIS page documents — both are per-publisher per-domain publication-discipline-coordination points whose mis-selection produces silent per-message authentication-leg-fail verdicts that propagate to per-receiver per-day DMARC aggregate-XML attribution rows.
• DMARC deployment checklist — read the DMARC deployment-checklist alongside this SPF mechanism-vocabulary primer when AUTHORING the per-publisher per-domain composite SPF + DKIM + DMARC publication-readiness sequence, when AUDITING the per-publisher per-domain SPF record's RFC 7208 §4.6.4 10-DNS-lookup-cap floor before per-publisher per-domain DMARC enforcement-mode-ramp progression, or when DIAGNOSING per-publisher per-domain DMARC- aligned-pass-rate floor regression traceable to per-publisher per-domain SPF mechanism-misclassification (e.g. mx mechanism reusing MX-RR-published targets outside operator-controlled egress) the deployment-checklist's Phase 5 post- enforcement-hygiene step closes.
• ARC (Authenticated Received Chain, RFC 8617) explained — per-publisher per-domain SPF mechanism-vocabulary (a: / mx: / ip4: / ip6: / include: / exists: / ptr: / all mechanism-class + + / - / ~ / ? qualifier-prefix) publication discipline per RFC 7208 §5 THIS page documents IS the load-bearing per-publisher per-domain envelope-MAIL-FROM-layer authorisation-leg whose successful spf=pass verdict at the original receiver ARC per RFC 8617 §5 preserves through mailing-list / auto-forwarder / hybrid-relay second-hop cascades via the ARC-Authentication-Results header per RFC 8617 §4.1 — without per-publisher per-domain SPF mechanism-vocabulary publication the per-publisher per-domain SPF-aligned-pass verdict does not exist to be preserved, and ARC-chain preservation cannot rescue the per-publisher per-domain DMARC-aligned- pass-rate floor under SRS-rewritten forwarder topology where the second-hop receiver evaluates SPF against the SRS-rewritten envelope-MAIL-FROM rather than the original-publisher domain. Per-publisher per-domain SPF qualifier- publication-discipline (~all soft-fail vs -all hard-fail) determines the per-publisher per-domain SPF-evaluator-side disposition the ARC-chain preserves at the second-hop receiver — the per-publisher per-domain SPF mechanism-vocabulary publication- discipline THIS page documents IS the upstream publication primitive feeding per-publisher per-domain ARC-chain cryptographic-witness preservation through forwarder cascades at the per-publisher per-domain composite envelope-MAIL-FROM-and-forwarder-cascade- preservation coordination boundary. Read THIS page when AUTHORING the per-publisher per-domain SPF mechanism- vocabulary publication discipline; read the ARC-explained spoke when DIAGNOSING per-publisher per-domain DMARC-aligned- pass-rate floor regressions under mailing-list / auto-forwarder / hybrid-relay second-hop topology where SRS-rewrite would otherwise collapse per-publisher per-domain SPF-aligned-pass verdict without ARC-chain preservation rescue.
• DKIM selectors explained — the PER-PUBLISHER-PER-SELECTOR-DKIM- SIGNATURE-APPLICATION-LAYER-AUTHENTICATION- LEG-AS-STRUCTURALLY-COMPLEMENTARY- APPLICATION-LAYER-COMPANION-TO-PER- PUBLISHER-PER-DOMAIN-SPF-MECHANISM- VOCABULARY-ENVELOPE-MAIL-FROM-LAYER- AUTHORIZATION-LEG companion at four SPF-mechanism-vocabulary-vs-DKIM-selector- publication coupling dimensions: (1) per- publisher per-selector DKIM-Signature s=<selector> per-stream attribution per RFC 6376 §3.5 IS the per-publisher per-stream application-layer authentication-leg complement to the per- publisher per-domain SPF mechanism-cascade envelope-MAIL-FROM-layer authorization-leg THIS page documents the per-publisher per- domain mechanism-vocabulary publication- discipline of — both per-leg verdicts surface at per-receiver per-day DMARC aggregate-report policy_evaluated/{spf,dkim} per RFC 7489 §6.6.1 driving per-publisher per-domain composite DMARC-aligned-pass-rate floor; (2) per-publisher per-selector segregation by traffic stream (transactional / marketing / corporate / SaaS-tenant) structurally parallels per-publisher per- domain SPF include: cascade segregation per traffic stream — both per-stream publication-discipline references gate per-stream per-leg authentication- attribution at the per-publisher per-stream composite envelope-and-application-layer publication-discipline coordination boundary; (3) per-publisher per-selector DKIM key- rotation operational discipline (zero- downtime rotation via parallel-selector publication, selector-namespace-decommission cadence) is structurally parallel to per- publisher per-domain SPF mechanism-vocabulary publication-discipline evolution per RFC 7208 §3 (mechanism-list ordering, qualifier-prefix update cadence, include: cascade refresh) — both per-publisher per-domain DNS-publication-discipline- evolution primitives gate per-publisher per- domain composite cross-protocol publication- discipline-integrity at the per-publisher per-domain composite envelope-and- application-layer publication-discipline coordination boundary; (4) per-publisher per- selector DKIM dkim=temperror verdict-fail traceable to per-publisher per- selector transient DNS-resolver-timeout at <selector>._domainkey.<d> resolution IS structurally parallel to per- publisher per-domain SPF temperror per RFC 7208 §2.6.6 traceable to per-publisher per- mechanism transient DNS-resolver-timeout at per-mechanism resolution — both per- publisher per-domain transient DNS-resolution verdict-fail traceability ladders are per- publisher per-domain operator-side transient- failure-mode publication-discipline drift- closure primitives at the per-publisher per- domain composite envelope-and-application- layer transient-failure-mode root-cause diagnostic coordination boundary.
• DMARC monitoring
• DKIM failures explained — the PER-PUBLISHER-PER-DOMAIN-SPF-MECHANISM-CLASS-CATALOGUE-AS-ENVELOPE-MAIL-FROM-LAYER-AUTHORIZATION-VOCABULARY-PUBLICATION-DISCIPLINE-COMPANION-TO-PER-PUBLISHER-PER-SELECTOR-DKIM-APPLICATION-LAYER-AUTHENTICATION-LEG-VERDICT-FAILURE-CATALOGUE companion at four per-publisher per-domain SPF-mechanism-class-vs-DKIM-failures-verdict-catalogue coupling dimensions: (i) per-publisher per-domain SPF mechanism-vocabulary publication-discipline THIS page documents (ip4/ip6/a/mx/include/exists/ptr/all per RFC 7208 §5) IS structurally parallel envelope-MAIL-FROM-layer authorization-leg vocabulary publication-discipline to per-publisher per-selector DKIM-Signature application-layer authentication-leg whose verdict-fail-class taxonomy (dkim=pass/fail/permerror/temperror/none/neutral/policy per RFC 8601 §2.7.1) the DKIM-failures explained spoke documents the diagnostic ladder of — both per-publisher per-domain authentication-leg publication-discipline references jointly underpin per-publisher per-domain composite DMARC aligned-pass disjunction per RFC 7489 §3.1.1; (ii) per-publisher per-domain SPF permerror verdict-class arising from mechanism-vocabulary publication-discipline drift (10-DNS-lookup-cap exhaustion / malformed-SPF-syntax / unknown-mechanism) THIS page documents the diagnostic discipline of IS structurally parallel envelope-MAIL-FROM-layer verdict-fail-class to per-publisher per-selector DKIM permerror per RFC 8601 §2.7.1 verdict-class (mis-published TXT-RR / unparseable public-key / unsupported algorithm) the DKIM-failures explained spoke documents the per-publisher per-selector publication-discipline-drift root-cause-attribution diagnostic ladder of; (iii) per-publisher per-domain SPF temperror verdict-class arising from transient DNS-resolver-side failure during mechanism evaluation IS structurally parallel envelope-MAIL-FROM-layer verdict-fail-class to per-publisher per-selector DKIM temperror verdict-class (transient public-key DNS-lookup failure) the DKIM-failures explained spoke documents the per-publisher per-selector transient-failure-mode root-cause-attribution diagnostic ladder of; (iv) per-publisher per-domain SPF mechanism-vocabulary publication-discipline drift surfacing as per-receiver per-day per-source-IP DMARC RUA policy_evaluated/spf attribution-distortion IS structurally parallel publication-discipline-drift class to per-publisher per-selector DKIM-Signature application-layer publication-discipline drift surfacing as per-receiver per-day per-source-IP DMARC RUA policy_evaluated/dkim attribution-distortion the DKIM-failures explained spoke documents the per-publisher per-selector DKIM publication-discipline-drift diagnostic ladder of. Read the DKIM-failures explained spoke when DIAGNOSING per-publisher per-domain DMARC aligned-fail attribution at the per-publisher per-domain envelope-MAIL-FROM-layer SPF-leg-fail (THIS SPF mechanism-class catalogue documents the publication-discipline of) OR per-publisher per-selector application-layer DKIM-leg-fail root-cause-attribution boundary every per-publisher per-domain DMARC operator-side aligned-pass-rate floor preservation discipline depends on.
• DMARC troubleshooting — the diagnostic-workflow companion to this SPF mechanisms reference. Where this page catalogues the per-mechanism RFC 7208 §5 evaluation contract for each directive (ip4 / ip6 / a / mx / include / exists / ptr / all), the DMARC-troubleshooting spoke documents the symptom-to-root-cause path the operator follows when a mechanism is mis-published: the spf=permerror in the RUA aggregate stream that traces to an include:-cascade exhausting the 10-DNS-lookup cap, the spf=fail that traces to a missing ip4 range for a legitimate sender, the ~all-vs- -all qualifier choice that changes whether an unlisted source softfails or hardfails, and the SPF-aligned-fail that collapses the SPF leg of the DMARC alignment disjunction. Read the DMARC-troubleshooting spoke when a domain's RUA stream shows SPF-fail or SPF-permerror rows and the operator needs the structured triage path from the symptom back to the specific mechanism this SPF reference documents the evaluation contract for.
• How attackers bypass DMARC
• BIMI explained — the verified-logo program that depends on the SPF leg this page documents being one of the two authentication legs that produce a DMARC-aligned pass. BIMI logos only render once a domain holds DMARC enforcement (p=quarantine or p=reject) with a consistent aligned-pass rate, and SPF mechanism choices — include: scope, the terminal ~all/-all qualifier, and staying under the 10-DNS-lookup cap — directly govern whether the SPF leg keeps contributing that pass. Read the BIMI explained spoke to see why a clean, in-budget SPF record is part of earning the brand indicator at the inbox.
• Email security glossary — the plain-language reference for the SPF vocabulary this mechanisms guide defines in depth: include, a, mx, ptr, the all qualifiers, the 10-DNS-lookup cap, and the permerror / softfail result codes. Read the glossary when a mechanism token or result term needs a one-line definition.
• DKIM best practices (the deployment-rules catalogue) — SPF authorises the envelope MAIL FROM source IP through the mechanism vocabulary THIS page catalogues; DKIM is the parallel authentication leg that cryptographically signs the message, and the two together feed the composite DMARC aligned-pass disjunction (RFC 7489 §3.1.1). The best-practices catalogue (2048-bit RSA keys, scheduled selector rotation, retirement of stale public-key records) is the publisher-side hygiene that keeps the DKIM leg dependable when an SPF -all result alone would not survive a forwarding hop. Read it to keep both authentication legs durably correct.
• Business email compromise (the fraud SPF helps block) — the mechanism vocabulary THIS page catalogues decides which source IPs may legitimately use a domain in MAIL FROM; BEC is the high-value fraud class — CEO-impersonation wire-transfer requests, vendor-invoice redirection — that depends on an attacker passing off forged or look-alike sender identities. A correctly authored include/ip4/a/mx set terminated by -all is the SPF leg of the layered control that, combined with DKIM and a DMARC p=reject, denies the exact-domain spoofing route BEC actors prefer. Read it to see how the mechanism discipline here maps onto the threat it ultimately defeats.
• Microsoft SNDS + JMRP monitoring — SPF PASS does not clear Microsoft's IP-reputation gate: SNDS shows the per-IP GREEN/YELLOW/RED filter verdict Outlook.com assigned to each authorized address and JMRP reports the Junk clicks behind a degraded one.

11. Verify your SPF mechanism record now

Once your SPF record uses the mechanism vocabulary correctly, verify it from three angles: live DNS lookup with the Domain Security Checker (parses your published record, flags 10-lookup overruns and deprecated mechanisms), live Authentication-Results inspection with the Email Header Analyzer (paste a header from a real delivery and see which SPF mechanism matched at the receiver), and ongoing DMARC aggregate- report monitoring through the platform dashboard (the aggregate reports surface sources passing and failing SPF over time, catching record drift and new senders before they cause deliverability incidents).

Check my SPF mechanism record Analyze an authentication-results header Sign up — Free plan