SPF (Sender Policy Framework, RFC 7208) is a DNS-based email authentication mechanism that lets a domain owner publish, as a DNS TXT record, the list of IP addresses authorised to send mail on the domain's behalf. Receiving mail servers query the SPF record to verify whether the connecting SMTP server is on the published list.

What does an SPF record look like?

An SPF record is a single DNS TXT record at the domain apex, starting with v=spf1 and ending with an "all" mechanism. A typical minimal record is: example.com. IN TXT "v=spf1 include:_spf.google.com -all" — authorising Google Workspace as the only sender and rejecting all other sources.

What is the SPF 10-lookup limit?

RFC 7208 §4.6.4 caps the number of DNS lookups an SPF evaluation may perform at 10 (include, a, mx, ptr, exists, and redirect each count). Exceeding the cap returns permerror and the SPF check fails for every recipient. Domains with many third-party senders must "flatten" their record (resolve include chains to ip4/ip6 mechanisms) to stay inside the limit.

What is the difference between -all, ~all and ?all?

-all (hard fail) tells receivers to reject mail from unauthorised IPs. ~all (soft fail) marks unauthorised mail as suspicious but still delivers it. ?all (neutral) provides no policy guidance. Production SPF records should use -all once aligned senders are confirmed; ~all is the migration default during initial rollout.

Why does SPF break when mail is forwarded?

SPF authenticates the SMTP envelope sender (MAIL FROM / Return-Path), which is rewritten by most forwarders to their own bounce address. The receiver then sees a forwarder IP not on the original domain's SPF list, producing a fail. This is why DKIM — which signs the message content and survives forwarding — is the alignment mechanism DMARC relies on for forwarded traffic.

Is SPF alone enough to stop spoofing?

No. SPF authenticates the envelope sender, not the visible From: header users see. An attacker can publish a permissive SPF record on their own domain and pass SPF while still showing your domain in From:. DMARC closes this gap by requiring SPF or DKIM authentication AND identifier alignment with the From: header.

Can I publish multiple SPF records for one domain?

No. RFC 7208 §4.5 requires exactly one v=spf1 TXT record per domain. Two SPF records returns permerror and breaks authentication. To combine senders, merge their mechanisms into a single record (e.g. v=spf1 include:_spf.google.com include:spf.mandrillapp.com -all).

SPF Explained: Sender Policy Framework, RFC 7208, Mechanisms, Qualifiers, and the 10-Lookup Limit

Everything a domain owner needs to publish, validate, and maintain a Sender Policy Framework record — from minimal one-line records to multi-sender flattened deployments — with full RFC 7208 syntax, the 10-lookup limit explained, and worked examples for Google Workspace, Microsoft 365, and transactional senders.

This reference is provided in English. SPF is specified in English-language RFCs and the canonical syntax (v=spf1, include:, -all) does not translate; we keep the body in the source language so technical terms are consistent with the specifications.

TL;DR

SPF (Sender Policy Framework, RFC 7208) is a DNS TXT record that lists the IP addresses authorised to send mail for a domain.
Receivers query the SPF record at the envelope-sender domain (MAIL FROM / Return-Path) and check the connecting IP against the published list.
Outcomes are pass, fail, softfail, neutral, none, temperror, or permerror.
SPF has a hard 10-DNS-lookup limit (RFC 7208 §4.6.4). Exceeding it returns permerror and fails authentication.
SPF authenticates the envelope sender, not the visible From: header — an attacker can pass SPF on their own domain while spoofing you in From:. SPF must be combined with DMARC to actually stop spoofing.
Forwarding breaks SPF: the forwarder rewrites the envelope, so the receiver sees an unauthorised IP. DKIM survives forwarding; that is why DMARC alignment typically depends on DKIM, not SPF.

1. What is SPF?

SPF (Sender Policy Framework) is an email authentication standard defined in RFC 7208 that lets a domain owner publish a DNS TXT record listing the IP addresses (or hostnames, or other SPF records) authorised to originate mail on the domain's behalf. When a receiving mail server accepts an SMTP connection, it extracts the envelope sender's domain (MAIL FROM), looks up that domain's SPF record, and checks whether the connecting IP is on the authorised list.

SPF was originally specified in RFC 4408 (2006) and obsoleted by RFC 7208 (April 2014, the current standard). It is one of three complementary email-authentication primitives — alongside DKIM (cryptographic signing) and DMARC (policy + reporting) — that together harden SMTP against spoofing, phishing, and brand impersonation.

Crucially, SPF authenticates only the envelope sender (the MAIL FROM address used during SMTP negotiation), not the header From: address users actually see in their inbox. An attacker can publish a permissive SPF record on a domain they control, pass SPF against that domain, and still write any value they like in the From: header. SPF alone does not stop spoofing — that gap is exactly what DMARC was invented to close.

2. How SPF works, step by step

A sender connects to a receiving mail server and issues MAIL FROM:<billing@example.com> during SMTP negotiation.
The receiver extracts the envelope-sender domain (example.com) and queries DNS for the TXT record at that name. SPF records start with v=spf1 and end with an all mechanism.
The receiver evaluates each mechanism left-to-right against the connecting IP. The first matching mechanism produces a result — pass, fail, softfail, or neutral — and evaluation stops.
If no mechanism matches before the terminating all, the all mechanism's qualifier (+/-/~/?) produces the final result.
The result is recorded in the message's Authentication-Results: header and is consumed downstream by the DMARC evaluator (for alignment with the From: domain) and by anti-spam scoring engines.

Two extra SPF-result conditions exist outside the mechanism-matching loop:

none — the domain published no SPF record at all.
temperror — a transient DNS failure (e.g. timeout). Receivers SHOULD defer (4xx) and retry.
permerror — the SPF record is malformed, recursive, or exceeds the 10-lookup limit. Permanent failure; SPF cannot authenticate the message.

3. SPF DNS syntax

An SPF record is a single TXT record at the domain apex:

example.com.   IN   TXT   "v=spf1 ip4:198.51.100.0/24 include:_spf.google.com ~all"

Anatomy:

v=spf1: Version tag. Must appear first; without it the record is not an SPF record. RFC 7208 §4.5 requires exactly one v=spf1 TXT record per domain — two records returns permerror.
Mechanisms (ip4, ip6, a, mx, include, exists, ptr, all): Each mechanism defines a set of IPs to match against the connecting IP. Evaluated left-to-right; first match wins. See §4 below for each one.
Qualifiers (+, -, ~, ?): Prefix each mechanism. Define the result on match: + pass (default), - fail, ~ softfail, ? neutral. See §5 below.
Modifiers (redirect=, exp=): Optional. redirect= outsources evaluation to another domain's SPF record; exp= publishes an explanation string for SPF failures (rarely used).

The record must be ASCII-safe and ≤ 255 characters per TXT string (DNS limit). Longer records are split into multiple double-quoted strings within the same TXT record — DNS resolvers concatenate them on receipt.

4. SPF mechanisms explained

ip4:<cidr> / ip6:<cidr>: Direct IP-range authorisation. Costs zero DNS lookups — preferred for performance and for staying inside the 10-lookup limit. Example: ip4:198.51.100.0/24.
include:<domain>: Outsources the IP list to another domain's SPF record. The most common mechanism — used to delegate to SaaS senders (e.g. include:_spf.google.com for Google Workspace, include:spf.mandrillapp.com for Mandrill). Costs one DNS lookup per include, plus any lookups the included record itself triggers — the total counts toward the 10-lookup limit.
a / a:<domain>: Authorises every IP returned by the domain's A/AAAA record. With no argument it uses the SPF record's own domain. Costs one DNS lookup.
mx / mx:<domain>: Authorises every IP of the domain's MX hosts. Tempting (it tracks your inbound mail servers) but often wrong — the inbound MX servers are usually NOT the outbound sending servers. Costs one DNS lookup against the limit of 10; the address lookups for the MX hosts are capped separately, at 10.
ptr: Deprecated. RFC 7208 §5.5 explicitly SHOULD NOT be used. Performs a reverse DNS lookup on the connecting IP and matches against the PTR record. Slow, fragile, and easily spoofed. Never use in new SPF records.
exists:<domain>: Passes if the named domain has any A record. Used for macro-driven per-IP whitelisting (e.g. exists:%{ir}.spf.example.com creates a per-IP DNS-based whitelist). Costs one DNS lookup. Rare; mostly used by large senders.
all: The catch-all mechanism, MUST appear last. Matches every IP. The qualifier on all (-all, ~all, ?all, +all) determines the result for any IP not matched by earlier mechanisms. Costs zero DNS lookups.

5. SPF qualifiers explained

Each mechanism may be prefixed by a qualifier that determines the SPF result on a match. The qualifier only matters on the matching mechanism — others are silently skipped.

Qualifier	Result on match	Receiver action	When to use
`+` (implicit default)	`pass`	Deliver normally	All legitimate sender mechanisms
`-`	`fail` (hardfail)	Reject (5xx SMTP)	Terminating `-all` in production
`~`	`softfail`	Accept but mark suspicious (often → spam)	Terminating `~all` during rollout
`?`	`neutral`	No policy guidance, treat as `none`	Rare; effectively disables SPF for that match

Production guidance: end every SPF record with -all (hardfail) once you have confirmed all legitimate senders are listed. Use ~all only during the initial rollout window when you are still discovering shadow senders.

6. The SPF 10-lookup limit

RFC 7208 §4.6.4 caps the number of DNS queries an SPF evaluation may perform at 10. The cap exists to prevent SPF from being weaponised into a DNS-amplification DoS vector. Each of these mechanisms counts as 1 lookup toward the cap:

include (plus all lookups inside the included record)
a
mx (the address lookups for its MX hosts have their own cap of 10)
ptr (deprecated; do not use)
exists
redirect= modifier

ip4, ip6, and all cost zero lookups — they are evaluated against the connecting IP directly without DNS.

Exceeding the cap returns permerror, which fails authentication for every recipient — not just the ones causing the overflow. A permerror result is also a DMARC fail, so an over-budget SPF record can take down legitimate mail flow on every receiver that honours DMARC.

Domains with many third-party senders typically use SPF flattening — periodically resolving include chains down to their underlying ip4/ip6 ranges and republishing the flattened record. Flattening trades one operational cost (a daily/weekly cron to re-resolve includes) for one architectural risk (your record diverges from the upstream sender's truth until the next refresh). Use the DNS Generator tool to model a flat record before publishing it.

7. SPF examples

7.1 Google Workspace only

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

Authorises every Google Workspace sending IP and rejects every other source. Suitable for a single- tenant Google Workspace deployment with no transactional senders.

7.2 Google Workspace + Microsoft 365 (hybrid)

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

Two SaaS senders combined into one record. Two include lookups consumed (~5-7 internal lookups total inside the includes); plenty of headroom inside the 10-lookup limit.

7.3 Google Workspace + Mailgun + on-prem relay

example.com.   IN   TXT   "v=spf1 ip4:198.51.100.10 include:_spf.google.com include:mailgun.org -all"

Direct IP authorisation (ip4:, costs 0 lookups) for an on-prem MTA, plus two SaaS includes. Total lookup cost is dominated by the includes, not the ip4:.

7.4 Non-sending domain — block everything

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

A "null SPF" record. Use on every domain that does NOT send legitimate mail — parked domains, brand look-alikes, internal-only domains. Publishing v=spf1 -all on a non-sending domain is the single most effective anti-spoofing measure available for that domain.

7.5 Subdomain delegation

news.example.com.   IN   TXT   "v=spf1 include:spf.sendgrid.net -all"

Each subdomain has its own SPF record. Lets you scope different senders to different subdomains — e.g. SendGrid for marketing on news.example.com, Google Workspace for staff on example.com. A subdomain inherits NO SPF settings from the parent domain.

8. SPF best practices

Always terminate with -all in production. ~all is only acceptable during the first 2-4 weeks of rollout while you discover shadow senders.
Publish v=spf1 -all on every non-sending domain. Parked domains, brand look-alikes, and internal-only domains should explicitly refuse to authorise any sender.
Use ip4/ip6 over a/mx where the ranges are stable. Zero DNS lookups, faster evaluation, lookup-limit headroom.
Stay well inside the 10-lookup limit. Target ≤ 7 lookups so future SaaS additions do not push you over the cap. Flatten or consolidate if you approach 8.
Never use ptr. Deprecated, slow, and a security liability.
Combine with DKIM and DMARC. SPF alone is insufficient — see §10. Deploy all three in parallel; DMARC ties SPF and DKIM to the visible From: header.
Audit SPF records quarterly. Third- party senders change IPs; include chains grow; the 10-lookup margin erodes. Re-verify using a DNS validation tool.
Subdomain SPF is separate. Subdomains do NOT inherit the parent's SPF record. Publish an explicit SPF record (or a v=spf1 -all null record) on every subdomain that sends mail OR is at risk of being spoofed.

9. Common SPF mistakes

Publishing two v=spf1 TXT records. RFC 7208 §4.5 requires exactly one. Two records returns permerror and breaks authentication. Merge mechanisms into a single record instead.
Exceeding the 10-lookup limit. Especially common after adding a third or fourth SaaS sender. Use a validator that resolves the full include graph before publishing.
Ending with +all. Means "everyone passes" — equivalent to no SPF at all and defeats the entire point. Almost certainly a typo.
Forgetting to add a SaaS sender. Marketing tools, helpdesk platforms, e-signature services, and CI/CD systems all send mail on your behalf. Discover them via DMARC aggregate reports in this dashboard, then add the corresponding include: mechanism.
Trusting mx for outbound senders. Inbound MX servers are usually NOT outbound sending servers. Most cloud mail platforms (Google, Microsoft) separate them. Audit before adding mx.
Using ptr. Deprecated by RFC 7208. Mail forwarders rewriting HELO / EHLO hostnames cause it to fail unpredictably.
Treating SPF as a spoofing defence. SPF authenticates the envelope sender, not the visible From: header. Without DMARC, SPF cannot stop spoofing.

10. SPF troubleshooting

permerror — "Too many DNS lookups": The include graph exceeds 10 lookups. Audit the chain (some SaaS providers' SPF records contain their own nested includes), then flatten or replace high-cost includes with direct ip4 ranges.
permerror — "Two SPF records": Two TXT records starting with v=spf1 on the same domain. Merge their mechanisms into a single record and delete the duplicate.
fail from a legitimate sender: The sender's IP is not on your SPF list. Either (a) add the sender's include: mechanism, (b) authorise their direct ip4 range, or (c) confirm the sender is supposed to be sending on your behalf — many "missing" senders are actually unauthorised SaaS sign-ups or shadow IT.
fail when forwarded: Expected. Forwarders rewrite the envelope sender, so the receiver checks SPF against the forwarder's IP — which isn't on your list. DKIM survives forwarding and is what DMARC alignment depends on for forwarded traffic.
softfail on production traffic: Your record terminates with ~all instead of -all. Migrate to -all once you have confirmed every legitimate sender is listed.
temperror — intermittent failures: DNS resolver timeouts. Usually transient; if it persists, check authoritative-DNS reachability for every domain in the include chain.
none result: No SPF record found at the envelope-sender domain. Publish one — even v=spf1 -all on a non-sending domain prevents spoofing of that domain.

11. Frequently Asked Questions

What is SPF?: SPF (Sender Policy Framework, RFC 7208) is a DNS-based email authentication mechanism that lets a domain owner publish, as a DNS TXT record, the list of IP addresses authorised to send mail on the domain's behalf. Receiving mail servers query the SPF record to verify whether the connecting SMTP server is on the published list.
What does an SPF record look like?: An SPF record is a single DNS TXT record at the domain apex, starting with v=spf1 and ending with an all mechanism. A typical minimal record is: example.com. IN TXT "v=spf1 include:_spf.google.com -all" — authorising Google Workspace as the only sender and rejecting all other sources.
What is the SPF 10-lookup limit?: RFC 7208 §4.6.4 caps the number of DNS lookups an SPF evaluation may perform at 10 (include, a, mx, ptr, exists, and redirect each count). Exceeding the cap returns permerror and the SPF check fails for every recipient. Domains with many third-party senders must "flatten" their record (resolve include chains to ip4/ ip6 mechanisms) to stay inside the limit.
What is the difference between -all, ~all and ?all?: -all (hard fail) tells receivers to reject mail from unauthorised IPs. ~all (soft fail) marks unauthorised mail as suspicious but still delivers it. ?all (neutral) provides no policy guidance. Production SPF records should use -all once aligned senders are confirmed; ~all is the migration default during initial rollout.
Why does SPF break when mail is forwarded?: SPF authenticates the SMTP envelope sender (MAIL FROM / Return-Path), which is rewritten by most forwarders to their own bounce address. The receiver then sees a forwarder IP not on the original domain's SPF list, producing a fail. This is why DKIM — which signs the message content and survives forwarding — is the alignment mechanism DMARC relies on for forwarded traffic.
Is SPF alone enough to stop spoofing?: No. SPF authenticates the envelope sender, not the visible From: header users see. An attacker can publish a permissive SPF record on their own domain and pass SPF while still showing your domain in From:. DMARC closes this gap by requiring SPF or DKIM authentication AND identifier alignment with the From: header.
Can I publish multiple SPF records for one domain?: No. RFC 7208 §4.5 requires exactly one v=spf1 TXT record per domain. Two SPF records returns permerror and breaks authentication. To combine senders, merge their mechanisms into a single record (e.g. v=spf1 include:_spf.google.com include:spf.mandrillapp.com -all).

DMARC explained — the policy + reporting standard that ties SPF and DKIM to the visible From: header. SPF is one of the two authentication mechanisms DMARC consumes.
DMARC myths and misconceptions — the SPF-ENVELOPE-MAIL-FROM-VS-VISIBLE- FROM-HEADER-SEMANTIC-SCOPE-DISTINCTION-AS- CANONICAL-REFUTATION-OF-DMARC-AT-P-EQUAL- REJECT-STOPS-ALL-PHISHING-MYTH companion to this SPF protocol-mechanics reference. Where THIS page documents the SPF protocol at the protocol-semantic level (RFC 7208 §1.1.3: SPF authenticates the MAIL FROM SMTP envelope return-path domain, §2.4: the SPF check operates on the connecting client IP and the envelope MAIL-FROM domain, §4.5: the check_host() algorithm that produces the pass/fail/softfail/neutral/temperror/ permerror/none result, §10.1: the explicit non-coverage of the visible From: header), the DMARC-myths-and-misconceptions spoke is the OPERATOR-MENTAL-MODEL-CORRECTION catalogue cataloguing the 18 distinct misconceptions about DMARC that recur in operator rollout-blocker decision-making, FOUR of which directly engage with the SPF-semantic-scope mechanics THIS page documents and which this SPF pillar is the canonical refutation-source for: (i) Myth 1 ("DMARC at p=reject stops all phishing") — the canonical "DMARC is a phishing-silver-bullet" myth, refuted at the SPF-semantic-scope level by THIS page's envelope-MAIL-FROM-domain scope: SPF (and by extension DMARC's SPF leg) ONLY authenticates the SMTP envelope-return-path; phishing attacks using DISPLAY-NAME spoofing ("Acme Bank" <attacker@evil.example>), LOOKALIKE-DOMAIN registration (acme-bank.com instead of acmebank.com), DOMAIN REGISTRATION of newly-registered confusables, and Punycode HOMOGRAPH attacks all PASS DMARC because the attacker's own domain is correctly SPF-authenticated and aligned — the attack surface lives ENTIRELY outside the protocol-defined SPF / DKIM / DMARC scope; (ii) Myth 9 ("DMARC at p=reject blocks lookalike- domain phishing") — the lookalike-domain variant of Myth 1, refuted by the same SPF-semantic- scope mechanic: a lookalike domain (acme-bank.com) PUBLISHES ITS OWN SPF record listing the attacker's IPs, so the attacker's outbound mail PASSES SPF on the lookalike domain, ALIGNS with the lookalike domain's From: header, and PASSES DMARC — only domain-monitoring services / registrar-watch / receiver- side lookalike-detection close this attack class; (iii) the implicit "SPF protects the From: header" confusion — refuted by THIS page's RFC 7208 §10.1 explicit-scope-disclaimer section: the SPF specification EXPLICITLY notes the check operates on MAIL FROM (RFC 5321 envelope sender) NOT on the From: header (RFC 5322 message-header sender) — the two are byte-distinct fields with STRUCTURALLY ORTHOGONAL semantic scope, and bridging them is the ENTIRE PURPOSE of DMARC's alignment evaluation built ATOP SPF (and DKIM); (iv) the "-all at the tail of SPF blocks all unauthorised mail" misconception — refuted by THIS page's -all qualifier section: -all only causes the receiver to FAIL the SPF check for the envelope-MAIL-FROM domain when the connecting IP is not enumerated; the receiver's actual rejection decision still depends on whether the receiver HONOURS SPF-fail at the SMTP layer (most modern receivers defer to DMARC's p= policy rather than rejecting on bare SPF-fail), so -all alone does NOT guarantee rejection — DMARC p=reject + SPF-fail- ALIGNED is the combination that actually triggers receiver rejection for the envelope-return-path-aligned attack class. Read the myths catalogue alongside this SPF protocol-mechanics reference when designing operator-facing rollout documentation that must overcome the "DMARC at p=reject solves phishing" oversimplification operators raise when planning the post-rollout threat posture — the myths catalogue is the canonical misconception-correction substrate; this SPF protocol-mechanics reference is the canonical SPF- semantic-scope refutation source for the FOUR myths whose root cause is confusion about which message-header field SPF actually authenticates.
SPF mechanisms explained — the dedicated mechanism-vocabulary deep dive on the eight RFC 7208 mechanisms (a / mx / ptr / ip4 / ip6 / exists / include / all), the four qualifiers (+ / - / ~ / ?), and the two modifiers (redirect= / exp=) defined in RFC 7208 sections 5 and 6. Each component gets its own labelled subsection with the canonical Definition / Syntax / DNS lookup cost / When to use / Pitfalls structure. Operators authoring or debugging SPF records land here for the per-mechanism reference this pillar intentionally only surveys.
SPF qualifiers explained — the focused per-qualifier semantic deep dive on the four prefix tokens (+ = Pass, - = Fail, ~ = SoftFail, ? = Neutral) defined in RFC 7208 sections 4.6.2 and 4.6.4. Where the mechanisms page above documents WHICH token to match (ip4 / include / a / mx / all), this page documents WHAT THE RECEIVER DOES when the match succeeds — the qualifier is the policy verb the SPF evaluator emits on first-match, and the -all vs ~all vs ?all choice at the tail of every record is the canonical operator decision that determines the SPF default for unmatched IPs. Covers the four result codes, the strict-vs-permissive trade-off (-all for production / ~all for monitoring / ?all for testing), the canonical receiver mapping (Pass → accept, Fail → reject or quarantine depending on DMARC, SoftFail → accept with reputation penalty, Neutral → accept), the implicit- + default rule for any mechanism without an explicit prefix, and the seven most common qualifier mistakes (missing -all, ~all instead of -all at p=reject, ?all in production, +all open relay, qualifier on redirect=, qualifier on exp=, mismatched qualifier-and-policy posture). Read once you understand the mechanism vocabulary on the mechanisms page and need the per- prefix policy semantics.
include vs ip4 vs a vs mx: the four IP-providing SPF mechanisms compared — the focused operator-decision-tree deep dive on the four IP-providing mechanisms operators actually pick between when authoring or modifying an SPF record: include: (RFC 7208 §5.2, 1 lookup + included records lookups, managed providers), ip4: (§5.6, 0 lookups, static IPs you own), a: (§5.3, 1 lookup, A- record-identified servers), and mx: (§5.4, 1 lookup + 1 per MX target, historical "MX is also outbound" pattern). Where the mechanisms page above documents ALL EIGHT mechanism types as a complete reference, this include-vs page is the focused four-way comparison for the IP- providing subset — each mechanism gets a labelled Definition / Syntax / Lookup cost / When to use / When NOT to use / Common pitfalls subsection, plus 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). Read when you have the mechanism survey on this pillar and the per-mechanism reference on the mechanisms page, and need to decide WHICH mechanism to write for your specific deployment.
MX records explained — the DNS-RR foundation the SPF mx mechanism evaluates against the connecting client IP — the SPF-MX-MECHANISM-DNS-FOUNDATION companion to this SPF protocol pillar. Where THIS page documents the SPF protocol's eight mechanisms (RFC 7208 §5 — all, include, a, mx, ip4, ip6, ptr, exists) and the SPF check-host algorithm that authorises the SMTP MAIL FROM connecting client IP against the published policy, the MX-records spoke documents the DNS-RR-MECHANICS-LAYER reference the SPF mx mechanism (§5.4) evaluates against: the canonical <preference> <target> wire format (RFC 1035 §3.3.9), the per-MX preference-value semantics, the A/AAAA resolution chain (mx matches if the connecting client IP appears in ANY MX target's A or AAAA RRset), the 1-lookup-plus-N-per-target SPF lookup cost (the lookup-limit-trap source for domains with 10+ MX records or wide round-robin pools), the 0 . "null MX" RFC 7505 sentinel (causes mx to evaluate to a no-match), and the historical "MX is also outbound" anti-pattern that silently breaks SPF when a receiving domain switches its MX to a cloud provider whose MX targets are NOT in its outbound IP pool. Read the MX-records spoke when authoring an SPF record that uses the mx mechanism and you need the DNS-RR reference for the published MX RRset the mechanism resolves against.
DANE explained (RFC 7672 DANE-for-SMTP) — the SPF-AS-ENVELOPE-LAYER-IP- AUTHENTICATION-LEG-VS-DANE-AS-TRANSPORT- LAYER-TLS-AUTHENTICATION-LEG-PROTOCOL- PAIRING companion reference. Where THIS page documents the SPF envelope-MAIL- FROM-layer IP-authentication mechanism (the v=spf1 TXT record, the ip4:/ip6:/ include:/a:/ mx: mechanism repertoire, the 10-DNS-lookup budget, the SOFTFAIL / FAIL qualifier semantics, the RFC 7208 SPF-evaluation algorithm), the DANE-explained spoke documents the STRUCTURALLY-ORTHOGONAL TRANSPORT-LAYER TLS-authentication mechanism that operates at a DIFFERENT layer of the message life-cycle. SPF authenticates the sending-host IP at envelope-MAIL- FROM reception (the "is this connecting IP authorised to send mail for the envelope-MAIL-FROM domain" question); DANE authenticates the receiving MTA's TLS certificate during the STARTTLS handshake (the "is this MTA's certificate the one the domain owner authorised, as bound by DNSSEC-signed TLSA records" question). The two protocols cover ORTHOGONAL authentication slices: SPF answers "WHO is allowed to SEND on behalf of this domain" at the IP-authorisation layer; DANE answers "WHICH receiver MTA's TLS certificate is operator- authorised" at the transport-layer. Read this when planning a layered sender-side and receiver-side authentication posture: SPF (envelope- IP) + DKIM (application-layer signature) + DMARC (alignment evaluation) at the message-identity layer compose with MTA-STS or DANE (TLS certificate + connection encryption) at the transport-layer to produce a defense-in-depth email- authentication stack. The DANE- explained spoke documents the RFC 7672 TLSA record format (_25._tcp. <mx-hostname>), the DNSSEC dependency (the operator's authoritative DNS zone MUST be DNSSEC-signed before TLSA records have cryptographic-trust value), the certificate-usage / selector / matching- type byte fields, and the receiver-side TLSA-validation logic that closes the STARTTLS-strip and opportunistic-TLS-downgrade attack vectors SPF and DKIM do NOT cover.
SPF DNS record syntax explained — the focused DNS-record-level SYNTAX deep dive (RFC 7208 section 3) that complements the semantic mechanisms reference above. Covers the mandatory v=spf1 version tag, the TXT record type (no legacy type 99), the 255-octet character-string limit and multi-string concatenation rule, whitespace and case-sensitivity rules, the "exactly one SPF record per domain" rule, publication at the apex vs subdomain with no inheritance, and the seven most common syntax mistakes (missing prefix, multiple records, 255-character overflow, tabs, U-labels, apex CNAMEs, wrong publication name). Pair this with the mechanisms page above: mechanisms = what each token MEANS; DNS syntax = how the record is ENCODED at the DNS layer.
SPF 10 DNS lookup limit and SPF flattening — the dedicated deep dive on the permerror-on-overlimit failure class covered in section 5 of this pillar. Operators who hit the limit (M365 + Google Workspace + transactional ESPs + SaaS marketing tools all add many include: mechanisms that compound past 10) land here for the per-provider count, the flattening tradeoff, and the recommended remediation sequence.
DNS propagation — the publisher-side TTL-bounded publish-and-verify cycle that gates every SPF-record change — the DNS-INFRASTRUCTURE-PUBLISHER-SIDE-PROPAGATION-LAYER companion to this SPF protocol pillar. Where THIS pillar documents the RFC 7208 check_host() evaluation, the eight mechanisms, the four qualifiers, and the seven result codes RECEIVERS emit when they query the published SPF record, the dns_propagation spoke documents the PUBLISHER-SIDE TTL-BOUNDED PUBLISH-AND-VERIFY CYCLE that gates EVERY SPF-record change between authoring intent and global receiver-side verdict realisation. Three structurally-distinct SPF-propagation operational classes the spoke covers that THIS pillar intentionally elides: (i) SPF record-publish propagation window — when an operator publishes a new SPF record at the authoritative DNS server (Cloudflare / Route 53 / Azure DNS / Google Cloud DNS / cPanel Zone Editor), the record does NOT instantly become visible to every receiver-side resolver worldwide; instead, the record propagates through the caching-resolver hierarchy at a rate gated by the TTL value (typically 300s / 3600s / 86400s — the latter producing a 24-hour propagation tail). Operators who change an SPF record and immediately send a test message often see the OLD record consulted, producing a false-fail diagnostic that resolves only after the TTL-bounded propagation cycle completes; (ii) SPF include:-chain propagation cascade — when an operator's SPF record uses include: against a third-party SPF helper record (e.g. include:_spf.google.com / include:spf.protection.outlook.com), a change to the third-party's helper record propagates INDEPENDENTLY of the operator's own record, and the receiver-side check_host() evaluation recursively resolves the operator's record AND the third-party's helper record against their respective TTL-cached states — producing a cross-record propagation-window race condition the spoke catalogues per-major-ESP (Google Workspace 1-hour TTL, Microsoft 365 1-hour TTL, SendGrid 5-minute TTL, Mailgun 5-minute TTL, Amazon SES 5-minute TTL); (iii) SPF record-deprecation propagation tail — when an operator REMOVES an SPF record (or switches from a permissive ?all to a strict -all qualifier), receiver-side resolvers continue to consult the cached prior version until the TTL expires, meaning a DMARC-aligned reject-policy publisher who tightens SPF cannot rely on the new strict record being honoured until the TTL-bounded propagation cycle completes globally. Required reading once an operator publishes a new SPF record and reports "the change isn't taking effect" or "different receivers see different verdicts for the same test message".
TLS-RPT record syntax (RFC 8460 §3) — the SPF-FOUNDATIONAL-PROTOCOL-PILLAR- DNS-TXT-RR-BYTE-GRAMMAR-PARALLEL-WITH- TLS-RPT-DNS-TXT-RR-BYTE-GRAMMAR companion to this SPF protocol pillar. Where THIS pillar documents the RFC 7208 SPF TXT-RR byte grammar (the leading v=spf1 version-sentinel-token, the eight mechanisms all/ip4/ip6/a/mx/ptr/ include/exists with their RFC 7208 §5 byte-grammar, the four qualifiers +/-/~/?, the modifiers redirect= / exp=, the 450-character TXT-record byte-budget, the 255-octet TXT-chunk concatenation discipline, and the publisher-side single-record-per- apex normative semantics per RFC 7208 §3.2), the TLS-RPT record-syntax spoke is the RFC 8460 §3 TLS-RPT TXT-RR byte-grammar companion whose publisher- side strict-byte-grammar TXT-RR publication discipline mirrors the foundational SPF TXT-RR byte-grammar discipline THIS pillar documents. The SPF-FOUNDATIONAL-PROTOCOL-PILLAR-DNS-TXT- RR-BYTE-GRAMMAR-PARALLEL-WITH-TLS-RPT- DNS-TXT-RR-BYTE-GRAMMAR cross-reference establishes FOUR structurally-distinct publisher-side TXT-RR version-sentinel- coexistence dimensions: (i) version-sentinel-token byte-grammar parallel — SPF requires the literal leading v=spf1 sentinel per RFC 7208 §4.5 as the receiver-side identification primitive that distinguishes SPF TXT records from same-host TXT siblings (DKIM, DMARC, TLS-RPT, BIMI, verification tokens); TLS-RPT requires the literal leading v=TLSRPTv1 sentinel per RFC 8460 §3.1 as the same kind of receiver-side identification primitive (distinguishing TLS-RPT TXT records from same-host TXT siblings, including SPF at the apex when the apex hosts both SPF and TLS-RPT-relevant subdomains); both protocols' version- sentinel-token discipline gates receiver-side parser dispatch and publisher-side typos at the sentinel boundary (v=spf2 / v=TLSRPT1) silently collapse the entire publication; (ii) TXT-record-byte-budget-and- chunk-concatenation parallel — SPF TXT-RR byte-budget caps at 450 characters with 255-octet TXT-chunk concatenation per RFC 7208 §3.4 (the include: / nested-lookup budget interacts with the byte-budget for large publishers); TLS-RPT TXT-RR byte-grammar follows the same RFC 1035-mandated 255-octet TXT-chunk concatenation discipline at the DNS layer (the receiver-side TXT-record reassembly applies the same chunk- boundary-respecting concatenation before parsing the leading sentinel); both protocols share the publisher- side-must-honour-255-octet-chunk boundary publication discipline that the RFC 1035 TXT-RR wire-encoding format imposes on every TXT-RR-based protocol; (iii) publisher- side-single-record-per-apex publication parallel — SPF normatively forbids multiple v=spf1 TXT records at the same apex per RFC 7208 §3.2 (multiple records produce receiver-side permerror verdict); TLS-RPT normatively forbids multiple v=TLSRPTv1 TXT records at _smtp._tls.<policy- domain> per RFC 8460 §3.1 (multiple records produce receiver-side publisher-side-publication-error and the receiver discards the publication per RFC 8460 §3.1 normative semantics); both protocols share the publisher-side- single-version-record-per-discovery-name discipline that gates receiver-side publication-validity and the same operator-side audit-tool obligation to detect accidental duplicate publication (a common publisher-side mistake when operators migrate between TXT-record management UIs or copy-paste between zones); (iv) RFC-mandated- publisher-side-record-publication- precondition parallel — SPF publication is the RFC 7208 normative prerequisite for receiver-side SPF evaluation (no TXT RR published → receiver-side spf=none verdict and publisher's IP-authorisation contract collapses); TLS-RPT publication is the RFC 8460 normative prerequisite for receiver-side TLS-failure reporting (no TXT RR published → receiver-side no-reports-sent and publisher's transport-failure-observation feedback loop collapses); both protocols share the publisher-side-publication-is-the- contract-bootstrap discipline where the protocol's INTENDED publisher-side contract requires the foundational TXT- RR publication as the prerequisite before any receiver-side processing can execute. Pair this page (the SPF foundational protocol pillar) with the TLS-RPT record-syntax spoke (the RFC 8460 §3 TLS-RPT TXT-RR byte-grammar publication-discipline reference) when an operator authors a publisher-side DNS-TXT-RR-based authentication-or- reporting protocol record and needs to apply the same version-sentinel-token / 255-octet-chunk-concatenation / single- record-per-apex / publisher-side- publication-is-contract-bootstrap discipline across BOTH the application- layer SPF TXT-RR and the transport- layer TLS-RPT TXT-RR publication contexts.
SPF for Google Workspace — the provider-specific deep dive on include:_spf.google.com, the canonical Google Workspace SPF record, the third-party-sender catalogue (Mailchimp / SendGrid / Mailgun / HubSpot / Salesforce / Amazon SES / Marketo / Zendesk), and the Workspace-only failure modes (Inbound Gateway, default routing, secondary domains, gmail.com aliases) that readers of this pillar most commonly hit when they try to author an SPF record against the _spf.google.com tree.
SPF for Microsoft 365 — the sibling provider-specific deep dive on include:spf.protection.outlook.com, the canonical Exchange Online SPF record, the Centralized Mail Transport / Direct-Delivery / Edge Transport hybrid topologies, the onmicrosoft.com failure mode, and the same third-party-sender catalogue (Mailchimp / SendGrid / Mailgun / Salesforce / HubSpot / Amazon SES / Marketo / Zendesk) tuned to the M365 Defender portal / message-trace operational lens. Readers running Exchange Online land here for the M365-specific failure modes this pillar intentionally leaves out.
DMARC for Office 365 hybrid — the SPF-PROTOCOL-CASCADE-ACROSS-HYBRID- PUBLISHER companion documenting the canonical hybrid-Exchange tenant case where the SPF protocol mechanics documented on THIS page CASCADE across TWO simultaneous outbound-IP cohorts under a single author-domain. Documents FOUR hybrid-publisher SPF-protocol coordination dimensions (the hybrid author-domain SPF record MUST contain BOTH the on-prem Exchange Server outbound IP set via ip4: / ip6: literal mechanisms AND the EXO outbound IP set via the include:spf.protection.outlook.com sub-include cascade — omitting either produces SPF-fail outcomes for the omitted path; the include:spf.protection.outlook.com sub-include cascade depth — the EXO include resolves into FOUR nested sub-includes (spf-a.outlook.com, spf-b.outlook.com, plus further nested mechanisms) consuming ~5-6 DNS lookups of the RFC 7208 §4.6.4 ten-lookup ceiling and leaving ~4-5 lookups for additional third-party- sender includes — the hybrid publisher's SPF-lookup-budget is SUBSTANTIALLY tighter than a single-path publisher's budget; per-path SPF alignment outcomes DIVERGE — messages routed via on-prem Exchange Server arrive with Mail From: domain matching the on-prem-published SPF authority, while messages routed via EXO arrive with Mail From: domain either matching EXO's authority OR rewritten to the tenant's onmicrosoft.com domain depending on the centralized-mail- transport topology — the per-path SPF alignment outcome is path-dependent and observable per-path only via per-source- IP RUA-aggregate-report row attribution; the terminating all qualifier choice — a hybrid publisher migrating from on-prem-only to EXO-coexistence MUST defer the ~all → -all tightening until the per-path SPF audit confirms ALL legitimate paths (on-prem outbound, EXO send-connector outbound, centralized- mail-transport relay outbound, direct- delivery outbound) are accounted for in the publisher's SPF record). Read the hybrid spoke when an SPF reader hits the canonical hybrid-Exchange topology and the SPF protocol mechanics documented on THIS pillar must compose with the per-path SPF authority record coordination the hybrid spoke documents.
DMARC for cPanel — the cPanel-tenant DMARC deployment guide (the SPF-COMPANION-MECHANISM-FOR-CPANEL-TENANT companion to this SPF protocol pillar) — the SPF-COMPANION-MECHANISM-FOR-CPANEL-TENANT companion documenting the cPanel-tenant DMARC deployment workflow whose Phase 2 SPF-alignment prerequisite consumes the SPF protocol mechanics documented on THIS page. Where THIS page is the SPF protocol pillar (RFC 7208 check_host evaluation, the eight mechanisms, the four qualifiers, the seven result codes), the dmarc_for_cpanel spoke is the CPANEL-TENANT DEPLOYMENT REFERENCE that documents how the SPF mechanics translate to cPanel's shared-MTA operational surface. The cPanel-tenant SPF deployment has FIVE distinct SPF-mechanic adaptations vs the M365/GW tenant-tier deployments the cross-reference makes explicit: (i) cPanel shared-outbound-MTA include pattern — most cPanel platforms route outbound mail through a shared MTA whose IP block must be added to the customer's SPF record via an include:<provider-spf-domain> mechanism (cPanel hosts typically publish a platform-wide SPF helper record at spf.<hosting-provider>.com); (ii) cPanel + third-party-ESP-relay SPF compounding — when a cPanel tenant also uses SendGrid / Mailgun / Amazon SES, the SPF record compounds the cPanel-provider include AND the ESP include, consuming multiple of the 10 include:-lookup budget documented in THIS page's section 7; (iii) cPanel operator-empowerment ceiling forces ?all qualifier degradation — many cPanel shared-hosting platforms force operators to use ?all (Neutral rather than -all Fail) because the platform cannot enumerate ALL legitimate sending IPs for an -all hard-fail record without breaking tenants who use third-party ESPs from outside the platform's IP block; (iv) cPanel reseller-tier operators have NO direct access to the platform's outbound IP allocation — the reseller-tier cPanel operator must accept the provider's include: mechanism on faith, meaning the lookup-budget arithmetic documented in THIS page's section 7 is operationally opaque; (v) cPanel + external DNS hosting (Cloudflare / Route 53 fronting a cPanel server) means the operator publishes SPF via the external provider's UI rather than cPanel's Zone Editor, so the cPanel-specific propagation timing on the dmarc_for_cpanel page does NOT apply while THIS SPF pillar's protocol semantics still do. Read the cPanel deployment spoke when the cPanel-tenant operator is in the Phase 2 SPF-prerequisite-validation step of the DMARC deployment workflow.
DMARC for shared hosting — the SPF-COMPANION-MECHANISM-FOR-SHARED-HOSTING-TENANT companion documenting the shared-hosting tenant DMARC deployment workflow whose SPF-alignment prerequisite consumes the SPF protocol mechanics documented on THIS page. The shared-hosting tenant deployment surface differs from cPanel-tenant (sibling spoke listed above) and from M365/GW enterprise-tenant in FIVE structurally-distinct SPF-mechanic adaptations: (i) multi-panel SPF helper-record variance — Plesk publishes via Hosting Settings → DNS Settings, DirectAdmin via Admin Level → DNS Administration, ISPConfig via DNS → SPF Wizard, and WHM-reseller via WHM → DNS Functions → Edit DNS Zone, each with provider-specific SPF helper-record naming (spf.<hosting-provider>.com vs relay.<provider>.net vs mail.<provider>.com) that the shared-hosting deployment spoke catalogues but THIS SPF pillar's section 5 include: mechanism mechanics evaluate identically; (ii) shared-MTA outbound IP-pool include cascade — every shared-hosting platform routes outbound mail through a shared MTA whose IP-pool fluctuates as the platform scales, so the tenant operator MUST consume the platform's include: mechanism rather than attempting to enumerate ip4: / ip6: ranges directly (the shared-hosting spoke documents the per-platform helper-record canonical syntax this SPF pillar's Section 5 mechanism evaluation must dereference); (iii) reseller-tier nested-include compounding — a WHM-reseller tenant publishes SPF against the reseller's helper record, which itself include:s the underlying platform's helper record, producing a two-hop include chain whose DNS-lookup-budget cost consumes 2 of the 10-lookup limit documented in THIS page's section 7 BEFORE the tenant adds ESP includes; (iv) shared-hosting ~all softfail recommendation — most shared-hosting platforms recommend ~all (SoftFail) rather than -all (HardFail) for the same operator-empowerment-ceiling reason documented for the cPanel sibling above, but with a wider provider-recommendation spread (Plesk default is ~all, DirectAdmin default is ?all, ISPConfig has no default and forces operator choice); and (v) shared-hosting + external DNS delegation (Cloudflare / Route 53 fronting a shared-hosting server) means the operator publishes SPF via the external provider's UI rather than the hosting panel's Zone Editor, so the shared-hosting-specific propagation timing on the dmarc_for_shared_hosting page does NOT apply while THIS SPF pillar's protocol semantics still do. Read the shared-hosting deployment spoke when the Plesk / DirectAdmin / ISPConfig / WHM-reseller tenant operator is in the Phase 2 SPF-prerequisite- validation step of the DMARC deployment workflow and the cPanel sibling spoke doesn't match the operator's actual hosting panel.
DMARC for SaaS senders — the SAAS-MARKETING-PLATFORM-MANAGED- SPF-INCLUDE-AS-DELEGATED-CUSTOMER-TENANT- SENDING-IDENTITY companion to this SPF protocol pillar. Where THIS page documents the canonical RFC 7208 SPF mechanism semantics (the v=spf1 version anchor, the include: / ip4: / ip6: / a / mx mechanisms, the per-mechanism DNS-lookup cost against the RFC 7208 §4.6.4 ten-lookup limit, the per-qualifier verdict map + / - / ~ / ?) — i.e. the SPF-PROTOCOL-MECHANISM-SEMANTICS side of the SPF authentication protocol — the DMARC-for-SaaS-senders spoke is the SAAS-MARKETING-PLATFORM-MANAGED-SPF- INCLUDE-CONSUMER companion documenting how the SPF mechanism semantics THIS page documents get exercised at the customer-tenant SPF-record-publication boundary when the operator delegates per-platform outbound mail to a SaaS marketing platform. Concretely, the spoke documents FOUR SaaS-marketing-platform- SPF-include-coordination dimensions: (i) each SaaS marketing platform publishes a canonical SPF include the customer-tenant operator must append to their existing SPF record — Salesforce Marketing Cloud's include:_spf.exacttarget.com (which itself recursively includes platform-managed sub-includes, consuming 2-3 DNS lookups), HubSpot's include:servers.mcsv.net, Marketo's include:mktomail.com, Mailchimp's include:servers.mcsv.net (shared with HubSpot's parent infrastructure), and Pardot's include:_spfa.pardot.com each must be appended to the customer- tenant SPF record — and the cumulative SaaS-include cost against the 10-DNS- lookup limit THIS page documents must be measured per portfolio member; (ii) SaaS-platform SPF includes are an exhaustion-pressure source on the SPF lookup limit — a customer- tenant already running 5-6 DNS lookups for Microsoft 365's include:spf.protection.outlook.com + Google Workspace's include:_spf.google.com + transactional ESP includes (SendGrid / Mailgun / Amazon SES) cannot afford another 2-3-lookup SaaS-marketing- platform include without exceeding the RFC 7208 §4.6.4 limit and producing permerror verdicts — the SaaS-senders spoke documents the SPF-flattening / SPF-rewriting consolidation options (e.g. Scott Kitterman's spf-tools + AutoSPF / EasyDMARC SPF macros / per-tenant subdomain delegation) the customer-tenant must apply to stay under the limit; (iii) SaaS- platform SPF includes evolve independently of customer-tenant oversight — Salesforce Marketing Cloud, HubSpot, and Marketo each periodically expand their published shared-IP-pool by adding new ip4: ranges to their managed SPF includes (an operationally- invisible change to the customer-tenant operator), and the customer-tenant's SPF-pass rate is therefore subject to per-platform-managed SPF-include contents the customer cannot directly audit — the SaaS-senders spoke documents the per-platform SPF-include change-monitoring discipline the operator must maintain to detect platform-side SPF-include drift; and (iv) SaaS-platform SPF- include lookup-cost mistakes are a primary cause of customer-tenant SPF permerror — when the customer-tenant operator adds a SaaS marketing platform SPF include without first auditing the cumulative lookup count, the SPF evaluation hits the void-lookup / over-limit failure mode the SPF pillar THIS page documents — and the per-receiver policy_evaluated/spf verdict in the RUA aggregate-report stream surfaces as permerror for ALL of the customer-tenant's outbound mail, not just the SaaS-platform egress. Read the DMARC-for-SaaS-senders spoke alongside this SPF pillar when the customer-tenant's outbound mail- flow inventory includes any SaaS marketing platform — especially when the customer-tenant already runs Microsoft 365 / Google Workspace + one or more transactional ESPs and the SPF lookup limit is approaching the RFC 7208 §4.6.4 ceiling.
SPF forwarding issues (the second-hop break) — the focused deep dive on the canonical SPF failure class: SPF authenticates the IP of the connecting MTA, so when a recipient forwards a message to a second mailbox the forwarding MTA's IP is checked against the ORIGINAL sender's SPF record and will almost always fail. Covers the four forwarding-class diagnostics (mailing-list forwarding, .forward-file forwarding, vacation-rule forwarding, and consumer-domain auto-forwarding), the Sender Rewriting Scheme (SRS) mitigation that some forwarders apply, why DKIM + DMARC's alignment rule is the structural fix, and the ARC (Authenticated Received Chain) protocol that allows downstream receivers to honour upstream authentication verdicts. Required reading once an operator reports "SPF works in send-to-self test but fails when subscribers receive the message".
ARC (Authenticated Received Chain) explained — the RFC-8617-PER-HOP-AAR-AMS-AS- SEALING-PROTOCOL-AS-CRYPTOGRAPHIC-CHAIN- OF-CUSTODY-PRESERVING-SPF-VERDICT-ACROSS- FORWARDER-SECOND-HOP-BREAK companion to this SPF protocol pillar reference. Where THIS page documents the RFC 7208 §5 SPF per-message evaluation algorithm (the per-source-IP envelope-MAIL-FROM authorisation lookup, the per-mechanism per-qualifier verdict-cascade, the 10-DNS- lookup ceiling at §4.6.4, the seven SPF result values pass/fail/softfail/neutral/ none/permerror/temperror), and the forwarder-second-hop break catalogue (§10.4 mailing-list / .forward / vacation- rule / consumer-domain auto-forward scenarios where the per-receiver SPF evaluation at the SECOND hop fails because the connecting MTA is the FORWARDER not the original sender), the ARC spoke documents the RFC 8617 three-header sealing protocol whose per-forwarder per-hop attestation chain is the cryptographic-chain-of-custody mechanism preserving the SPF=pass verdict the original-hop receiver computed BEFORE the forwarder's second-hop SPF=fail break, at FOUR per-SPF-forwarder-break-vs-ARC- chain-of-custody coupling dimensions: (i) SPF=pass at original hop vs SPF=fail at forwarder second hop as canonical per-message ARC-chain motivating scenario — the canonical SPF forwarder-second-hop-break THIS page documents is the operationally-load-bearing motivating scenario for the ARC protocol; the original-hop receiver computes SPF=pass against the original sender's IP and envelope domain, then forwards the message; the second-hop receiver computes SPF=fail against the FORWARDER's IP and the original envelope domain; ARC bridges the verdict gap by attesting the original-hop SPF=pass verdict in the ARC-Authentication-Results header so the second-hop receiver can honour the original-hop verdict; (ii) SPF=permerror cascade across forwarder chains as ARC-AAR attestation preservation target — when the original sender's SPF record breaches the RFC 7208 §4.6.4 10-DNS-lookup ceiling and emits SPF=permerror at the original hop, the ARC-Authentication-Results emitted at each forwarder hop preserves the per-hop permerror state for downstream receivers — the ARC spoke documents the per-hop AAR attestation discipline that surfaces the original-hop permerror to the second- and-subsequent-hop receivers; (iii) SRS-rewriting (Sender Rewriting Scheme) as ALTERNATIVE forwarder-second- hop-break workaround vs ARC-chain-of- custody approach — SRS rewrites the envelope-MAIL-FROM at the forwarder boundary so the second-hop SPF evaluation succeeds against the forwarder's domain; ARC does NOT rewrite the envelope but attests the original verdict in a downstream-honoured header — the ARC spoke documents the ARC vs SRS coexistence decision and the per-receiver per-policy treatment that determines whether the downstream verdict honours the SRS- rewritten SPF=pass at the forwarder or the ARC-attested original SPF=pass at the original sender; (iv) SPF verdict in aggregate-report <policy_evaluated><spf> per-row aggregate evidence vs ARC-chain <auth_results> per-row ARC-attested evidence — the DMARC aggregate-report per-row XML evidence the SPF-protocol evaluation THIS page documents serialises into includes a per-row SPF disposition AND a per-row ARC chain-evaluation field; the per- receiver per-row aggregate evidence the operator analyses must distinguish ARC-chain-honoured SPF=pass rows from original-hop SPF=pass rows to correctly attribute legitimate forwarder traffic — the ARC spoke documents the per-row ARC evaluation discipline that supplements the per-row SPF disposition THIS page's verdict catalogue produces. Read the ARC spoke immediately after the SPF forwarding-issues spoke when the operator is designing a per-publisher SPF publication discipline whose forwarder- second-hop-break tolerance depends on the per-hop ARC-chain attestation discipline downstream receivers honour.
SPF permerror vs temperror (failure-mode reference) — the failure-mode reference for the two SPF result values that are NOT plain pass/fail. spf=permerror is a permanent failure (malformed SPF record, exceeded the 10-DNS-lookup limit, or include: chain references a non-existent record); DMARC treats permerror as a fail per RFC 7489 §6.6.2 and applies the policy verdict. spf=temperror is a transient DNS failure (resolver unreachable, NXDOMAIN race condition, DNSSEC SERVFAIL); DMARC treats temperror as non-authoritative and the receiver typically retries or applies a softer verdict. The diagnostic distinction matters because permerror requires fixing the published SPF record while temperror requires fixing DNS infrastructure. Pairs with the lookup-limit spoke above as the operational reference for the SPF result-types DMARC consumes.
DMARC troubleshooting — the SPF-VERDICT-AS-DMARC-COMPOSITE- INPUT-AT-DIAGNOSTIC-TIME companion to this SPF pillar. Where THIS page documents the per-message SPF envelope-MAIL-FROM-authorization- evaluation primitive that produces the receiver-side spf= verdict at the per-message-evaluation boundary, the DMARC-troubleshooting spoke documents the composite-verdict diagnostic catalogue whose SPF-aligned-pass leg consumes that verdict at four SPF-verdict-to-DMARC- diagnostic-class coupling dimensions: (i) spf=pass + DMARC-fail diagnostic class — the canonical misalignment scenario where the per-message SPF mechanism evaluation produces spf=pass on the envelope MAIL FROM domain BUT the envelope MAIL FROM organisational-domain does NOT align with the per-message From: <header-domain> organisational-domain under the published aspf=r relaxed-mode or aspf=s strict-mode alignment rule, producing spf=pass but DMARC fail (an SPF-aligned-pass MISS — common on transactional-ESP bounce-domains that publish at bounce.<ESP>.com rather than bounce.<customer-domain>); (ii) spf=fail + DKIM-aligned- pass + DMARC-pass diagnostic class — the canonical forwarding-relay scenario where the SPF leg legitimately fails (forwarder rewrites envelope MAIL FROM after second-hop relay) but the DKIM leg survives and produces DKIM-aligned- pass, carrying the DMARC composite to pass; (iii) spf=permerror diagnostic class — where the published SPF record exceeds the RFC 7208 §4.6.4 10-DNS-lookup ceiling, contains a syntactic error (multiple TXT RRs at the apex, malformed mechanism token, IDN not A-label- encoded), or contains a redirect loop, producing permanent SPF-permerror that the publisher must fix at the record-authoring layer; (iv) spf=temperror diagnostic class — where the receiver's per-message DNS-resolution of one of the SPF record's mechanism lookups returns SERVFAIL (DNS-fetch-failure), producing transient SPF-temperror that the receiver MAY retry. Read the DMARC-troubleshooting spoke alongside this SPF pillar when diagnosing per-message DMARC-composite-failure rows in RUA aggregate reports, when attributing per-source-IP SPF-verdict-failure clusters to specific publisher-side SPF-record defects, or when sequencing the SPF-side remediation work that unblocks the publisher's p=quarantine → p=reject rollout cutover.
DMARC reporting pipeline — where the spf= verdict surfaces in the operator dashboard — the END-TO-END OBSERVABILITY-INFRASTRUCTURE reference for the daily RUA aggregate-report stream that carries every spf=pass / spf=fail / spf=softfail / spf=neutral / spf=temperror / spf=permerror / spf=none verdict this pillar documents back to the operator dashboard. Where this pillar tells you the receiver evaluates SPF per RFC 7208 §4 check_host and emits a result token, the reporting-pipeline spoke documents the 6-stage end-to-end operational architecture that materialises each per-message verdict as per-source-IP-per-day aggregate counters in the operator's dashboard: Stage 1 ingestion (the IMAP / Microsoft Graph inbound-mailbox transport layer the report stream arrives over from every receiving organisation), Stage 2 format detection and extraction (the RUA XML / ZIP / GZ / TAR.GZ multi-format envelope receiver-side report-generators emit), Stage 3 parsing (the RUA XML traversal that extracts every <auth_results><spf><result> + <auth_results><spf><domain> + <auth_results><spf><scope> per-record element from each receiver-side <record> block — the scope sub-element distinguishes the mfrom-checked envelope-sender SPF result from the helo- checked EHLO-domain SPF result this pillar's check_host algorithm produces), Stage 4 storage and deduplication, Stage 5 retention policies, and Stage 6 analysis and alerting (the per-source-IP / per-envelope-sender-domain drill-down views the dashboard surfaces for SPF operators). Plus the dedicated IMAP- and Microsoft-Graph-setup sections that document the inbound-mailbox transport- layer configuration every operator MUST configure before any spf=- verdict aggregate counter materialises in the dashboard. Read the reporting- pipeline spoke when an SPF operator asks "where does the spf= verdict from this pillar's check_host evaluation actually surface in the daily aggregate report stream I see in my operator dashboard", "why does my published rua= URI receive zero per-day reports despite spf=pass in my own send-to-self test", or "which per-stage failure in the report pipeline produces the spf=missing observability gap on a known-authorised outbound IP" — the spoke is the authoritative end-to-end operator reference for the report-stream observability infrastructure every SPF verdict eventually flows through.
DMARC deployment checklist — the PROTOCOL-PREREQUISITE downstream operator-companion to this SPF pillar. Where THIS page documents the SPF protocol at standards-overview depth (RFC 7208 check_host evaluation, the eight mechanisms, the four qualifiers, the seven SPF result codes), the deployment-checklist spoke documents the DOWNSTREAM DMARC-PUBLICATION OPERATIONAL WORKFLOW that consumes the SPF verdict this pillar's protocol produces. Concretely the deployment- checklist spoke's Phase 1 step DEMANDS a working SPF record (a v=spf1 record with all legitimate senders enumerated via include: / ip4: / ip6: mechanisms, a non-?all tail policy, zero permerror from the 10-DNS-lookup-limit, and the organizational-domain alignment with the visible From: header) as the OPERATIONAL PRE-CONDITION for Phase 2 (DMARC record publication with p=none + working rua= mailbox) and every downstream phase (Phase 3 instrumentation, Phase 4 monitoring cadence). Critically: a misconfigured SPF record produces spf=permerror or spf=fail aggregate-report rows that BLOCK the operator from advancing past Phase 4 of the deployment checklist — every residual SPF-fail verdict from an authorised sender means the rollout-advance to p=quarantine / p=reject documented on the checklist will quarantine legitimate mail. Read the deployment-checklist spoke when an SPF operator finishes the SPF authoring work documented on this pillar and needs to know "what's next" in the broader DMARC deployment workflow — the checklist is the canonical downstream operator reference for the FULL deployment path the SPF protocol on this pillar is the first protocol-prerequisite for.
DMARC policy modes — the SPF-ENVELOPE-LAYER-AUTHENTICATION- LEG-VS-DMARC-PUBLISHER-POLICY-TAG-PER- TIER-DISPOSITION-CONTRACT companion to this SPF protocol pillar. Where THIS page documents the SPF protocol at standards-overview depth (RFC 7208 check_host evaluation, the eight mechanisms, the four qualifiers, the seven SPF result codes pass / fail / softfail / neutral / none / permerror / temperror), the DMARC-policy-modes spoke documents the DOWNSTREAM PUBLISHER-CONTROLLED ENFORCEMENT-TIER CONTRACT each receiver applies when this pillar's per-message SPF verdict FAILS (or PASSES but with envelope-vs- Header-From-domain alignment-mismatch). Concretely the policy-modes spoke documents per-tier receiver-side disposition semantics (p=none = pass-through with RUA visibility only; p=quarantine = junk-folder / hold-queue / spam-folder; p=reject = SMTP 550 5.7.1 envelope reject), per-tier sender-side rollout-risk profile (p=none = zero false-positive blast-radius; p=quarantine = bounded per-tier blast- radius via pct= subsampling tag; p=reject = full envelope-rejection blast-radius for every SPF-and-DKIM- unaligned message), per-tier RUA- aggregate-report disposition-row visibility budget (which spf= verdict rows appear under which disposition column), and the canonical p=none → p=quarantine pct=10 → p=quarantine pct=100 → p=reject pct=10 → p=reject pct=100 ramp ladder every publisher follows during phased DMARC deployment downstream of this SPF pillar's verdict-of-record. Without the policy-modes spoke a reader knows WHAT verdict the SPF protocol on this pillar produces, but not WHAT receiver-side consequence the publisher-chosen DMARC p= tag OBLIGATES the receiver to apply when the SPF verdict goes against the connecting client IP — this link closes that policy-contract-resolution gap at the envelope-authentication- verdict-to-publisher-enforcement-tier translation layer.
Why SPF alone is insufficient — the authoritative answer to the most common reader objection raised against this pillar ("why do I need DMARC if I have SPF?"). Covers the four structural limitations SPF cannot close on its own: the From: header spoofing gap (SPF authenticates MAIL FROM, not the visible From: header), the forwarding gap (SPF breaks on the second SMTP hop), the mailing-list gap (List-managers rewrite MAIL FROM but cannot rewrite From:), and the missing reporting channel. Pairs with this pillar as the rationale for the SPF + DKIM + DMARC layered defense.
Email security glossary — the broader threat-actor and attack-taxonomy context — the canonical security-context glossary for the broader threat model SPF sits within as ONE control in a defense-in-depth stack. Where this pillar is the AUTHENTICATION-PROTOCOL deep dive (RFC 7208 mechanism syntax, qualifier semantics, the 10-DNS-lookup ceiling per §4.6.4, flattening strategies, per-provider deployment), the security_glossary is the THREAT-CONTEXT that justifies SPF's existence as a control. Concretely: SPF defends specifically against the envelope-MAIL-FROM-IP-spoofing attack variant within the broader email-borne attack taxonomy the glossary catalogues (phishing / spear-phishing / whaling / BEC / look-alike-domain attacks / OAuth consent phishing / MFA-fatigue / token theft / supply-chain compromise). SPF maps to MITRE ATT&CK T1566.001 (Spearphishing Attachment) and T1566.002 (Spearphishing Link) as a Defence-Evasion prevention control, and to the cyber kill-chain Delivery stage as the receiver-side authentication gate that blocks unauthorised-IP delivery. The glossary is also the canonical cross-walk for operators arriving from a SOC / SIEM / SOAR / EDR background who need to understand where SPF sits in the defence-in-depth stack relative to endpoint controls (EDR), identity controls (phishing-resistant MFA), gateway controls (SEG), data controls (DLP), and response controls (SOC + IR runbooks). Read the security_glossary spoke when an operator asks "how does SPF fit into our broader security programme" — the glossary is the canonical mapping from this protocol pillar to the threat-actor, attack-taxonomy, and incident-response vocabulary the rest of the security organisation works in.
Phishing protection — the operator-facing defense-in-depth playbook SPF contributes the envelope-authentication layer to — the LAYERED-DEFENSE OPERATOR PLAYBOOK companion to this SPF pillar. Where this pillar documents the SPF protocol at the RFC 7208 level (mechanism vocabulary, qualifier semantics, the 10-DNS-lookup ceiling per §4.6.4, the check_host() evaluation algorithm per §4, flattening strategies, per-provider deployment), the phishing- protection spoke documents the FULL defense-in-depth control stack SPF contributes ONE LAYER to: (i) authentication- protocol layer (the SPF + DKIM + DMARC + BIMI + MTA-STS + DANE + ARC controls this pillar's cluster catalogues, of which SPF provides the ENVELOPE-SENDER-IP- AUTHORISATION half — RFC 5321 MAIL FROM spoofing protection by enumerating authorised sending IPs in the domain's published v=spf1 record), (ii) gateway- control layer (SEG + sandbox URL analysis + attachment detonation), (iii) endpoint layer (EDR + browser isolation + WebAuthn / FIDO2 phishing-resistant MFA), (iv) identity layer (Conditional-Access + impossible-travel + token-binding), (v) user-behaviour layer (continuous phishing simulation + reporter- button workflow + JIT training), (vi) response layer (SOC + SIEM correlation + SOAR playbook automation + tabletop-exercise cadence). The SPF half is the operationally FIRST anti-phishing layer most operators deploy historically because it precedes DMARC by a decade (RFC 7208 published 2014, DMARC RFC 7489 published 2015, the earlier SPF RFC 4408 dated 2006) and because it requires no message-content changes (unlike DKIM which requires the signing infrastructure and key-management discipline of RFC 6376) — but SPF alone is structurally insufficient against phishing because (a) SPF authenticates only the envelope MAIL FROM, leaving the visible RFC 5322 From: header wide open to spoofing, (b) SPF breaks across every forwarder hop, making the protection brittle for high-value targets routinely forwarded, (c) SPF emits no per-receiver feedback, providing zero observability into phishing attempts at the protocol layer. Read this spoke once you have SPF deployed per this pillar and need the operator-side reference for how the envelope-authentication primitive composes with the broader anti- phishing control stack sitting ABOVE (gateway / endpoint / identity / user / response) and BELOW (transport-security / DNS-integrity) the email-authentication layer — including the DMARC-at-enforce + DKIM-cryptographic- authentication adjacent layers that close the structural gaps SPF cannot close alone.
Email spoofing explained — the THREAT-TAXONOMY companion to this protocol pillar. Where this pillar documents SPF at the RFC 7208 protocol level (mechanism vocabulary, qualifier semantics, the 10-DNS-lookup ceiling per §4.6.4, the check_host() evaluation algorithm per §4, flattening strategies, per-provider deployment templates), the email-spoofing pillar documents the SEVEN CANONICAL THREAT-TECHNIQUES the protocol layer this SPF pillar belongs to is engineered to defeat: (1) direct domain spoofing via RFC 5322 From: forgery — the DKIM-territory threat-technique SPF cannot defeat alone because SPF authenticates only the envelope MAIL FROM, leaving the visible RFC 5322 From: header wide open; (2) envelope MAIL FROM spoofing per RFC 5321 — the threat-technique SPF UNIQUELY defeats among the three authentication protocols by enumerating the authorised sending IPs in the published v=spf1 record, denying connection-IP-based forgery at the receiver's boundary MX; (3) display-name spoofing — the social-engineering variant SPF cannot defeat because the envelope-IP authorisation is orthogonal to the visible display-name; (4) lookalike-domain registration; (5) IDN homograph attacks (Unicode confusables per UTS #39); (6) cousin-domain registration; (7) subdomain takeover via abandoned DNS. The email-spoofing pillar's section 4 ("How SPF defends against spoofing") documents the SPECIFIC threat-techniques SPF defeats versus the ones it does not — critical operator knowledge when scoping the deployment of the protocol documented here. Read the email-spoofing pillar once you understand SPF at the protocol level on this page and need the THREAT-TECHNIQUE taxonomy reference for which forgery patterns the SPF envelope-IP-authorisation primitive actually closes versus which require adjacent controls (DKIM for body-cryptographic-integrity that survives forwarders, DMARC for alignment-enforcement closing the envelope-vs-header gap, BIMI for visual brand confirmation, MITRE ATT&CK T1566 for the broader phishing chain).
Reverse DNS / PTR records for mail servers — the operator deep dive on the in-addr.arpa / ip6.arpa reverse-zone record class that SPF's deprecated ptr mechanism (RFC 7208 section 5.5 — "SHOULD NOT BE PUBLISHED") historically relied on. Where this pillar documents why the ptr mechanism is forbidden in new deployments (excessive DNS load, PTR records controlled by the IP-block holder not the domain owner so SPF-via-PTR is forgeable, semantics not portable across receivers), the reverse-DNS page documents why PTR records still matter operationally OUTSIDE the SPF record: every modern SMTP receiver performs an FCrDNS (Forward-Confirmed reverse DNS) check on the connecting IP per RFC 1912 section 2.1 BEFORE any SPF / DKIM / DMARC evaluation runs — missing or generic (cust-203-0-113-1.isp.example) PTR is a top cause of "valid SPF + DKIM + DMARC but mail still spam-foldered" because the connection is penalised at the trust-baseline gate beneath the protocol layer this pillar documents. Read this page for the SPF record syntax, then the reverse-DNS page for the SMTP-connection-layer reputation check that gates SPF evaluation entirely.
BIMI explained — the SPF-ALIGNED-PASS-AS-BIMI- ENVELOPE-AUTHENTICATION-PREREQUISITE- COMPONENT companion to this SPF protocol pillar. Where THIS page documents the SPF envelope-MAIL-FROM authentication mechanism (RFC 7208 per-mechanism per-qualifier evaluation + 10-DNS-lookup limit + per-result-code taxonomy + per-IP cohort authorization), the BIMI- explained pillar is the DOWNSTREAM- CONSUMER-OF-SPF-ALIGNED-PASS companion documenting the four operationally-distinct SPF-BIMI- prerequisite dimensions every operator deploying brand-indicator display must coordinate the SPF authentication infrastructure documented on this page against: (i) BIMI display gating at every BIMI-aware mailbox provider (Gmail, Yahoo Mail, AOL, Apple iCloud Mail in iOS 16+) REQUIRES SPF-aligned- pass OR DKIM-aligned-pass at the receiver-side DMARC evaluation — making the SPF envelope-MAIL-FROM authentication mechanism THIS page documents one of the two BIMI authentication-prerequisite legs (and the load-bearing leg for direct-path mail where the envelope- MAIL-FROM remains intact) — the BIMI-explained pillar documents the per-receiver BIMI- display authentication-prerequisite contract that makes SPF authentication-infrastructure investment operationally rewarded with brand-indicator display at the receiver UI; (ii) SPF qualifier choice (-all Fail vs ~all SoftFail vs ?all Neutral) determines per-receiver SPF-result- code-to-DMARC-disposition mapping which gates BIMI eligibility at Gmail (where SoftFail with relaxed-mode aspf=relaxed STILL yields DMARC-pass-via-SPF + BIMI-display if DKIM-aligned-pass is absent) — the BIMI- explained pillar documents the qualifier-to-BIMI-eligibility translation that operationally determines whether SPF authoring choices documented on this page produce BIMI-display continuity or BIMI-display loss at the receiver UI; (iii) SPF-aligned- pass survival across forwarding (the SECOND-HOP-BREAK pattern documented at the forwarding- issues spoke this page references) directly determines whether forwarded mail retains BIMI display at the final receiver — the BIMI-explained pillar documents why operators with Gmail-recipient-heavy auto- forwarding cohorts MUST architect their DKIM signing infrastructure for BIMI-display continuity because SPF-aligned-pass collapses to SPF-aligned-fail across the forwarder hop and DKIM-aligned-pass becomes the load-bearing remaining BIMI- authentication leg; and (iv) SPF 10-DNS-lookup permerror at high-volume publishers (especially the Workspace + M365 + third-party SaaS cohorts) collapses ALL SPF evaluations to SPF=permerror → DMARC=fail → BIMI=skipped at the receiver UI — the SPF flattening / SPF subdomain delegation / per-vendor include budget discipline documented on this page is the load-bearing BIMI-display-availability engineering discipline at scale — the BIMI- explained pillar documents the operational impact of SPF permerror on BIMI display availability across the SPF- overheavy publisher cohort. Read the BIMI-explained pillar AFTER the SPF authentication infrastructure documented on this page is operationally stable AND the publisher's DMARC publication has reached p=quarantine pct=100 or p=reject — the BIMI pillar is the AUTHORITATIVE downstream- consumer reference for the brand-indicator reward that SPF-aligned-pass publication operationally unlocks.
DMARC policy rollout — the SPF-ALIGNED-PASS-RATE-CONVERGENCE- AS-PER-RAMP-STAGE-PUBLISHER-COMMITMENT- CHECKPOINT-PREREQUISITE companion to this SPF protocol pillar. Where THIS page documents the SPF protocol (per-domain v=spf1 TXT-RR authoring, per-mechanism evaluation, ip4: / ip6: / include: / mx: / a: mechanism semantics, RFC 7208 §4.6.4 10-DNS-lookup cap discipline, the per-domain +all / -all / ~all / ?all publication-mode commitment), the DMARC policy rollout spoke is the OPERATOR-FACING PHASED-ENFORCEMENT- RAMP whose per-stage publisher-side commitment depends on consistent per-source-IP SPF-aligned-pass evidence the SPF protocol THIS page documents materialises at every receiver-side per-message evaluation. The four-axis SPF- PROTOCOL-VS-DMARC-ROLLOUT-RAMP coordination model exposes the structurally-distinct per-ramp- stage SPF-publication-discipline dimensions: (i) per- publisher p=none monitoring-stage ramp commitment depends on the per-domain SPF v=spf1 TXT-RR publication being PRODUCTION- STABLE — without per-publisher per-domain SPF TXT-RR publication-byte-grammar compliance (no permerror-class syntactic mistakes), the per- ramp-stage p=none monitoring evidence the RUA pipeline emits is structurally polluted by SPF-evaluation failures attributable to publication-byte-grammar drift rather than legitimate-publisher per-source-IP authorisation gaps — the DMARC policy rollout spoke documents the per-publisher per-domain SPF-stability prerequisite that every p=none monitoring-stage operator must verify BEFORE the per-stage rua-stream evidence becomes operationally trustworthy; (ii) per-publisher p=quarantine pct=<n> partial- enforcement ramp-gate advancement decisions are gated on per-source-IP SPF-aligned-pass-rate convergence — every per- source-IP per-day rua-stream row showing spf=fail or spf=permerror STRUCTURALLY DISQUALIFIES that per-source-IP from the per-ramp-stage advancement decision until the per-source- IP gap is closed by SPF v=spf1 TXT-RR republication (typically adding the missing include: for the unauthorised-but-legitimate third-party ESP) — the DMARC policy rollout spoke documents the per- source-IP SPF-aligned-pass- rate-convergence ramp-gate decision-discipline every per- ramp-stage operator must execute against the per- publisher SPF v=spf1 TXT-RR publication THIS pillar documents; (iii) per- publisher per-ramp-stage sp=-tag subdomain-coordination commitment depends on the per- subdomain SPF v=spf1 TXT-RR publication discipline (per- subdomain SPF publication produces per-subdomain per-source-IP SPF-aligned- pass evidence the per- subdomain DMARC enforcement depends on) — making the per- publisher per-subdomain SPF v=spf1 TXT-RR publication-stability the STRUCTURAL PREREQUISITE for every per-subdomain sp=-tag rollout-coordination commitment — the DMARC policy rollout spoke documents the per-subdomain sp=-tag rollout-coordination discipline that every per- publisher per-subdomain SPF TXT-RR publication enables at the per-subdomain ramp-stage commitment boundary; and (iv) per-publisher p=reject terminal-stage commitment depends on the per-domain SPF chain being STABLE against future include: cascade churn (every third-party ESP adding / removing IPs from their _spf.<esp> include destination is a per-source-IP authorisation churn the per-publisher per-domain SPF chain delegates to the per-ESP operator — making the per-publisher p=reject commitment a per-domain DEPENDENT-CONTRACT on every per-ESP include: delegate's per-source-IP authorisation-stability operational discipline) — the DMARC policy rollout spoke documents the per- publisher p=reject terminal-stage commitment- decision discipline that every SPF include:- cascade-publishing operator must coordinate against BEFORE the p=reject flip materialises a legitimate-mail-loss risk attributable to per- ESP per-source-IP authorisation drift the per-publisher SPF v=spf1 TXT- RR documented on this page cannot internally guarantee. Read the DMARC policy rollout spoke WHEN authoring or modifying the per- publisher per-domain SPF v=spf1 TXT-RR documented on this page (audit the per-domain SPF publication-stability AND the per-ramp-stage publisher-side commitment IN THE SAME CHANGE-SET), and WHEN diagnosing a per-ramp- stage advancement- blocking dmarc=fail rate that correlates with per-source-IP spf=fail / spf=permerror evidence the rua pipeline emits.
DMARC aggregate (RUA) reports — the SPF-VERDICT-AS-PER-ROW-AUTH- RESULTS-SPF-XML-EVIDENCE-STREAM-AT- FOUR-PER-SPF-RESULT-CODE-TO-RUA-FIELD- MAPPING-DIMENSIONS companion to this canonical SPF protocol-mechanics pillar. Where THIS page documents the RFC 7208 SPF evaluation algorithm (the v=spf1 sentinel-token TXT- RR publication, the seven mechanism types all / include: / a: / mx: / ptr: / exists: / ip4:+ip6:, the four qualifier prefixes +/-/~/?, the seven result codes pass / fail / softfail / neutral / none / permerror / temperror, the RFC 7208 §4.6.4 10-DNS- lookup limit), the aggregate-reports spoke is the RECEIVER-EMITTED-PER-ROW- EVIDENCE-XML-SCHEMA companion documenting which SPF-evaluation bytes the receiver preserves verbatim in the per-row aggregate-report XML for the publisher's per-source-IP per-day analysis. Concretely, the spoke documents FOUR per-SPF-result-code to RUA-field mapping dimensions: (i) envelope-MAIL-FROM domain → per-row <auth_results><spf> ><domain> — the receiver-emitted per-row XML records the RFC 5321 envelope-MAIL- FROM domain literal the SPF evaluator evaluated against the connecting client IP — providing the publisher with per-source-IP per-day attribution evidence for which envelope-MAIL-FROM domain the receiver computed the per-message SPF verdict against (the canonical evidence the publisher reads to disambiguate own-domain envelope from third-party-ESP-envelope from forwarder-rewritten envelope when the per-row SPF verdict surfaces as spf=fail); (ii) raw SPF evaluation outcome → per-row <auth_results><spf> ><result> — the receiver-emitted per-row XML records the RFC 8601 SPF verdict (pass / fail / softfail / neutral / none / permerror / temperror) — the per- receiver per-day verdict-distribution evidence the publisher monitors as the canonical SPF-infrastructure-health KPI whose regression-rate-threshold gates every per-tag publication change THIS page documents; (iii) per-row <source_ip> per- connecting-client IP attribution — the receiver-emitted per-row XML records the per-source-IP literal the SPF evaluator processed against the publisher's enumerated ip4:/ ip6:/a:/mx:/ include: mechanism set — providing per-source-IP per-day evidence the publisher reads to detect WHICH sender enumerated under the v=spf1 mechanism cascade (own outbound MTA / cloud-mailbox- provider include: target / third-party- ESP include: target / forwarder relay IP at second hop) produced each per- row verdict; (iv) per-row <policy_evaluated><spf> post-alignment SPF-leg verdict DISTINCT from the raw-verification result — the receiver-emitted per-row XML records the DMARC-side- post-alignment SPF-leg verdict separately from the raw SPF result — even when the per-row <auth_results><spf> ><result>pass</result> records a raw spf=pass verdict, the <policy_evaluated><spf> emits fail when the envelope-MAIL-FROM organisational domain does NOT align with the From: header organisational domain per the aspf= tag mode — the STRUCTURAL DISTINCTION between the raw- verification result and the post- alignment-evaluation result is the load-bearing evidence the publisher reads to attribute SPF-aligned-pass- rate convergence per-source-IP per- day on the p=none → p=quarantine → p=reject ramp THIS page's SPF authoring discipline feeds. Read the aggregate-reports spoke ALONGSIDE this canonical SPF protocol-mechanics pillar to close the feedback loop between the per-mechanism per-qualifier publication discipline and the per- receiver per-day per-row XML evidence stream every receiver emits.
DKIM selectors explained — the DKIM-PER-SELECTOR-NAMESPACE-AS-LOAD- BEARING-SIBLING-MESSAGE-LAYER-AUTHENTICATION- PUBLICATION-DISCIPLINE-TO-SPF-PER-DOMAIN- MECHANISM-LIST-PUBLICATION-DISCIPLINE companion to this SPF protocol-mechanics pillar. Where THIS page architectures the per-publisher per-domain SPF v=spf1 TXT-record mechanism- list publication discipline (the include: / ip4: / a / mx mechanism byte-grammar, the per-mechanism per-qualifier semantics, the per-domain mechanism-list cardinality rule, the 10-DNS-lookup budget per RFC 7208 §4.6.4), the DKIM-selectors- explained spoke is the per-publisher per- selector MESSAGE-LAYER publication- discipline reference STRUCTURALLY PARALLELING this SPF publication discipline at FOUR per-publisher authentication-record publication dimensions: (i) per- publisher per-name namespace publication- discipline — DKIM per-selector FQDN <selector>._domainkey.<d> per RFC 6376 §3.6.1 vs SPF per-domain apex / subdomain <d> per RFC 7208 §3.1 — the DKIM- selectors-explained spoke documents the per-publisher per-selector publication- namespace discipline (one selector-FQDN per signing tenant; selector-name semantic partitions multi-tenant signers by purpose / vintage / rotation cycle) STRUCTURALLY PARALLELING the per-publisher per-domain SPF publication-namespace discipline this page architectures (one apex-or-subdomain- FQDN per scope; per-scope publication boundary partitions multi-domain senders by organisational structure); both are per-publisher per-name FQDN-publication primitives the receiver-side validator consumes by NAME LOOKUP at the canonical location; (ii) per-publisher per- record rotation-cadence publication- discipline — DKIM per-selector retirement and republication (rotate within 6-12 months via new-selector publication + empty-p= old-selector retirement) vs SPF per-domain mechanism- list republication (per-mechanism IP-block add / remove / include: cascade update) — the DKIM- selectors-explained spoke documents the per-publisher per-selector rotation- cadence-publication discipline (the canonical 90-day-to-12-month rotation floor the operationally-mature publisher executes against) STRUCTURALLY PARALLELING the per-publisher per-domain SPF mechanism- list rotation discipline this page architectures (the per-mechanism-add / per-mechanism-remove / per-include:- cascade-restructure operations the operationally-mature publisher executes against); both are per-publisher per-record publication-rotation-discipline primitives the receiver-side validator absorbs through TTL-bounded cache invalidation; (iii) per-publisher per-record per-tenant partitioning publication-discipline — DKIM per-tenant selector partitioning (per- ESP-selector / per-marketing-platform- selector / per-transactional-pipeline- selector / per-acquired-domain-selector) vs SPF per-tenant include:-cascade partitioning (per-ESP include: / per-marketing-platform include: / per-transactional- pipeline include: / per-acquired-domain include:) — the DKIM-selectors-explained spoke documents the per-publisher per-tenant selector-partitioning publication discipline (one selector per signing tenant gives per-tenant abuse-isolation, independent rotation cadence, and per- receiver per-source-IP DKIM-pass-row attribution) STRUCTURALLY PARALLELING the per-publisher per-tenant SPF include:-cascade partitioning discipline this page architectures (one include: per delegated SPF- publisher gives per-delegated-publisher IP-block management, independent ESP coordination, and per-receiver per-source- IP SPF-pass-row attribution); (iv) per-publisher per-record cardinality publication-discipline — DKIM allows exactly one TXT record per selector-FQDN per RFC 6376 §3.6.2.2 vs SPF allows exactly one v=spf1 TXT record per scope per RFC 7208 §3.2 — the DKIM-selectors-explained spoke documents the per-publisher per-selector cardinality publication-discipline (duplicate records cause receiver-side permerror) STRUCTURALLY PARALLELING the per-publisher per-domain SPF cardinality publication- discipline this page architectures (duplicate v=spf1 records cause receiver-side permerror); both are per-publisher per-name TXT-record- cardinality publication-discipline primitives the receiver-side validator enforces. Read the DKIM-selectors- explained spoke when publishing or auditing a per-publisher per-domain SPF mechanism- list ALONGSIDE a per-publisher per-tenant DKIM selector portfolio — both are per- publisher authentication-record publication- discipline primitives the receiver-side validator parses to produce the per-message Authentication-Results header DMARC alignment depends on.
DKIM cryptography basics — the SPF-PER-DOMAIN-DNS-TXT-RECORD-IP- AUTHORIZATION-LIST-PUBLICATION-DISCIPLINE- AS-LOAD-BEARING-SIBLING-MESSAGE-LAYER- AUTHENTICATION-MECHANISM-WHOSE-PARALLEL- PUBLICATION-PRIMITIVE-IS-THE-PER-PUBLISHER- PER-SELECTOR-CRYPTOGRAPHIC-KEYPAIR- PUBLICATION-DISCIPLINE companion to this SPF protocol-mechanics pillar. Where THIS page architectures the per-publisher per- domain SPF v=spf1 TXT-record IP-AUTHORIZATION-LIST publication discipline (the per-mechanism per-qualifier byte-grammar, the 10-DNS-lookup budget per RFC 7208 §4.6.4, the per-domain mechanism-list cardinality rule) — a per-publisher per-domain AUTHORISATION-PUBLICATION primitive that uses NO cryptography (every receiver-side SPF verifier reads the published mechanism- list bytes from DNS and compares the connecting-client envelope-IP against the authorised CIDR set) — the cryptography- basics spoke is the per-publisher per- selector CRYPTOGRAPHIC-KEYPAIR-PUBLICATION primitive STRUCTURALLY PARALLELING this SPF publication discipline at FOUR cross-mechanism message-layer-authentication publication- primitive comparison dimensions: (i) per-publisher publication-primitive choice — SPF per-domain DNS-TXT IP- authorisation-list publication vs DKIM per- selector DNS-TXT RSA-2048 / Ed25519 public- key publication — both are per- publisher per-FQDN DNS-TXT publication primitives the receiver-side validator consumes by lookup, but SPF publishes an IP-CIDR list the verifier compares against the envelope-source IP whereas DKIM publishes a public-key the verifier uses to validate the per-message signature math — the cryptography-basics spoke documents the FUNDAMENTALLY-DIFFERENT publication- primitive on the DKIM side that produces the same per-message authentication-pass outcome SPF produces via IP-authorisation; (ii) per-publisher per-receiver- survival-guarantee — SPF envelope-source-IP rewriting at every per-forwarder hop STRUCTURALLY BREAKS SPF (the well-known "SPF forwarder break" the SPF-forwarding- issues spoke catalogues) vs DKIM cryptographic-signature survival of body- and-header modifications via the canonicalization algorithm-pair choice the cryptography-basics spoke documents — the cross-mechanism complementarity (SPF-pass on direct mail, DKIM-pass on forwarder-mediated mail) is precisely the reason DMARC requires the disjunction (SPF-aligned-pass OR DKIM- aligned-pass) and not either alone; (iii) per-publisher per-record cryptographic- primitive choice — SPF has NO cryptographic- primitive choice (the mechanism-list publication is byte-literal) vs DKIM per- publisher per-selector RSA-2048-vs-Ed25519 keypair-generation choice (RFC 8463 introduces Ed25519 as the modern modernisation pair to RSA-2048) the cryptography-basics spoke documents — the cross-mechanism asymmetry (SPF publishes a byte-literal authorisation list with no cryptographic semantics vs DKIM publishes a cryptographic public-key whose algorithm choice the publisher commits to per-selector at signing time) is a load-bearing cross-mechanism difference the operationally-mature publisher coordinates across both mechanisms; (iv) per-publisher per- record rotation-discipline — SPF mechanism- list republication (per-mechanism IP-block add / remove / include:-cascade update) vs DKIM per-selector keypair rotation (90-day-to-12-month floor with new-selector publication + overlap-window + empty-p= old-selector retirement) — the cryptography- basics spoke documents the per-publisher per-rotation overlap-vs-cutover discipline that determines whether DKIM signatures survive the rotation cycle, STRUCTURALLY PARALLELING (but more cryptographically sensitive than) the SPF mechanism-list republication discipline this page documents at the per-mechanism IP-block update granularity. Read the cryptography- basics spoke as the CROSS-MECHANISM COMPANION when planning a coordinated per-publisher message-layer-authentication publication strategy that uses SPF's envelope-MAIL-FROM IP-authorisation publication AND DKIM's per-selector cryptographic-keypair publication in complementary roles every modern DMARC deployment depends on both legs of.
MTA-STS vs DANE comparison — the MTA-STS-VS-DANE-AS-TRANSPORT- LAYER-TLS-ENFORCEMENT-PUBLICATION- CHOICE-COMPLEMENT-TO-SPF-MESSAGE- LAYER-ENVELOPE-MAIL-FROM-AUTHENTICATION- PUBLICATION companion to THIS SPF protocol reference. Where THIS page documents the RFC 7208 SPF protocol (per-publisher v=spf1 TXT-record publication, per-mechanism evaluation algorithm, per-source-IP envelope- MAIL-FROM authentication outcome, per-qualifier tail-mechanism graceful-degradation), the MTA-STS- vs-DANE spoke is the TRANSPORT- LAYER-TLS-ENFORCEMENT-PUBLICATION- CHOICE COMPLEMENT REFERENCE documenting the publisher-side per- domain transport-layer TLS- enforcement-publication choice (RFC 8461 MTA-STS vs RFC 7672 DANE-for-SMTP) whose transport- layer publication discipline is the complement to the SPF message-layer envelope-MAIL-FROM authentication- publication discipline THIS page documents at FOUR cross-layer per- publisher-publication-choice- coupling dimensions: (i) per- publisher per-domain publication- LAYER complement: SPF publishes per-domain message-layer envelope- MAIL-FROM authentication (IP-list- attestation), MTA-STS-vs-DANE publishes per-domain transport- layer TLS-enforcement (HTTPS- policy-host or DNSSEC-TLSA-RR attestation) — both publication disciplines complete the cross-layer per-publisher per-domain authentication-and- enforcement publication topology (SPF attesting message-layer envelope-MAIL-FROM-source-IP, MTA-STS-or-DANE attesting transport-layer recipient-MX- TLS-enforcement), and the MTA-STS- vs-DANE spoke documents the publisher-side transport-layer publication-discipline complement to the SPF message-layer publication-discipline THIS page documents; (ii) per- publisher per-record DNSSEC- dependency: SPF requires no DNSSEC for publication ( v=spf1 TXT-record is consumed at face-value); DANE-for-SMTP REQUIRES DNSSEC- signed zones for trust bootstrap; MTA-STS uses HTTPS- CA trust without DNSSEC — the MTA-STS-vs-DANE spoke documents the per-publisher DNSSEC-deployment-prerequisite differential whose publication- deployment-prerequisite choice is the transport-layer publication discipline parallel to the SPF message-layer no-DNSSEC-required publication discipline THIS page documents; (iii) per- receiver per-publication evaluation-pattern: SPF's per- source-IP per-mechanism evaluation produces the per-message spf=<result> verdict that feeds DMARC alignment; MTA-STS-vs-DANE's per-recipient-MX-TLSA-validation produces the per-SMTP-connection TLS-enforcement verdict that feeds downstream TLS-RPT observation — both publication disciplines impose per-receiver per-publication evaluation-patterns whose per- receiver outcome is the input to a downstream feedback loop (DMARC alignment for SPF, TLS-RPT observation for MTA- STS-or-DANE), and the MTA-STS- vs-DANE spoke documents the per-receiver per-SMTP-connection evaluation algorithm whose cross-layer evaluation pattern parallels the per-receiver per- message SPF evaluation THIS page documents; (iv) per-publisher per- domain publication-discipline- AS-DEFENSE-STACK: SPF closes the message-layer envelope- forging defense surface; MTA- STS-or-DANE closes the transport-layer in-flight TLS-stripping / DNS-MX- redirection defense surface — both publication-disciplines commit per-publisher per-domain operational choices the attacker-attack-surface against the publisher's per-domain mail-flow taxonomy maps onto (envelope-MAIL-FROM-spoof defense via published SPF vs in-flight-TLS-strip / DNS-MX-redirect defense via published MTA-STS-or-DANE), and the MTA-STS-vs-DANE spoke documents the per- publisher transport-layer defense-publication choice whose defense-stack completion-discipline complements the SPF message- layer defense-publication discipline THIS page documents. Read the MTA- STS-vs-DANE spoke ALONGSIDE this SPF protocol reference when authoring the per-domain cross-layer publication-discipline defense-stack — the spoke documents the transport- layer TLS-enforcement- publication choice whose cross-layer publication- decision parallels the SPF message-layer publication- decision THIS page establishes.
DNS Record Generator — interactive wizard for building SPF, DKIM, DMARC, BIMI, MTA-STS, CAA, and TLS-RPT records with validation and lookup-limit accounting.
Domain Security Checker — live DNS lookups for SPF, DKIM, DMARC, MTA-STS, CAA, BIMI, and DNSSEC against any domain.
Email Header Analyzer — paste a raw email header to see SPF, DKIM, and DMARC pass/fail results inline with explanation.
Email deliverability — the SPF-PASS-RATE-AS-INBOX-PLACEMENT- INPUT companion to THIS RFC 7208 Sender Policy Framework protocol reference. Where THIS page documents the RFC 7208 SPF protocol contract (the v=spf1 ... -all TXT record at the apex, the mechanism evaluation order per §4.6.2, the 10-DNS-lookup limit per §4.6.4, the qualifier-vs-mechanism interaction, the RFC5321.MailFrom domain authentication scope) as the PROTOCOL-CONTRACT every legitimate sender MUST satisfy, the deliverability spoke documents the receiver-side reputation- scoring feedback loop whose per-source-IP SPF-pass-rate is one of the load-bearing inputs to the inbox-placement decision the major mailbox providers (Microsoft / Gmail / Yahoo / Mail.ru / Comcast / Apple iCloud / AOL) execute on every inbound message. Four SPF-PROTOCOL-VS-DELIVERABILITY axes the deliverability spoke documents that THIS page is the protocol-foundation reference for: (1) SPF-pass-rate-as- reputation-signal — the deliverability spoke's per-source-IP sender-reputation model treats the per-IP SPF-pass-rate across the receiver's observation window as a primary positive- reputation signal (per Feb 2024 Gmail / Yahoo bulk-sender requirements ≥ 99% SPF + DKIM alignment); this page's v=spf1 ... -all protocol contract is the publisher-side configuration the per-IP SPF-pass-rate depends on; (2) SPF-permerror-as- deliverability-disqualifier — the deliverability spoke's "rua-stream spf=permerror across all sources" symptom traces the per-record auth-result back to the RFC 7208 §4.6.4 10-DNS-lookup limit / §11.1.1 receiver-side permerror enforcement contract this page documents, attributing the receiver-side reputation degradation to the publisher-side over-budget include chain; (3) SPF-shared-IP-reputation contamination — the deliverability spoke's "shared-ESP-pool reputation drift" symptom traces the per-source-IP SPF-pass / SPF-fail distribution back to the per-tenant include:-chain composition this page's mechanism-evaluation documentation defines the resolution rules for; (4) SPF-alignment-vs-DMARC- alignment in the deliverability decision path — the deliverability spoke's "DMARC = fail despite SPF = pass" inbox- placement degradation traces the per-message Authentication-Results SPF smtp.mailfrom domain AGAINST the RFC5322.From domain to attribute the alignment-mode-mismatch deliverability impact; this page's RFC5321.MailFrom authentication- scope documentation is the protocol- foundation reference for that diagnostic. Read THIS page to UNDERSTAND the RFC 7208 SPF protocol contract; read the deliverability spoke to UNDERSTAND how the per-source-IP SPF-pass-rate that contract produces translates into the inbox- placement decision at the major mailbox providers.
DMARC for Google Workspace — the WORKSPACE-TENANT-SPF- DEPLOYMENT-INSTANTIATION companion to this SPF-protocol-mechanics reference. Where THIS page documents the per- message SPF evaluation protocol mechanics (per-domain v=spf1 TXT-RR publication-byte-grammar, include:-mechanism delegation cascade, 10-DNS-lookup budget, terminal-qualifier publication-mode commitment), the Workspace-deployment spoke is the WORKSPACE-TENANT SPF-DEPLOYMENT- CONFIGURATION REFERENCE documenting how each SPF protocol primitive instantiates concretely on Google Workspace. Concretely the spoke documents FOUR per-Workspace-tenant- configuration-vs-SPF-protocol- primitive-instantiation dimensions: (i) per-Workspace-tenant include:_spf.google.com macro-include cascade is the Workspace-tenant SPF-mechanism- delegation primitive instantiation — the Workspace-deployment spoke documents the per-tenant v=spf1 include:_spf.google.com ~all minimal publication every Workspace operator must publish at the per-tenant organisational-domain apex SPF TXT-RR — the _spf.google.com macro- include itself nested-includes the per-egress-region Gmail IP-pool SPF-mechanism delegates (the macro-include cascade THIS page documents at the SPF-protocol- mechanism-delegation tier); (ii) per-Workspace-tenant SPF lookup-budget pressure from third- party-ESP-sender additions is the Workspace-tenant SPF-protocol 10-DNS-lookup ceiling operational invariant — the Workspace- deployment spoke documents how the per-tenant include:_spf.google.com cascade consumes ~5 lookups, leaving ~5 lookups for per-tenant third-party-ESP-sender additions (include:mailgun.org, include:_spf.salesforce.com, etc.) before crossing the RFC 7208 §4.6.4 10-DNS-lookup ceiling and emitting spf=permerror the SPF protocol mechanics THIS page documents; (iii) per- Workspace-tenant Gmail egress IP- pool authorisation-stability dependency is the Workspace-tenant SPF-protocol per-source-IP- authorisation operational invariant — the Workspace-deployment spoke documents the per-tenant Gmail egress IP-pool authorisation- stability dependency every Workspace operator must monitor via aggregate- report stream because the per- message spf=pass verdict THIS page documents depends on the per-source-IP authorisation coverage the _spf.google.com macro- include cascade publishes; and (iv) per-Workspace-tenant terminal-qualifier publication-mode commitment is the Workspace-tenant SPF-protocol per-domain publication- discipline primitive — the Workspace-deployment spoke documents the per-tenant -all- production-grade vs ~all-softfail terminal-qualifier choice every Workspace operator must make at the per-tenant SPF TXT-RR publication tier in coordination with the per-tenant DMARC posture — terminal--all-fail publication is the Workspace-tenant SPF publication-discipline contract the SPF protocol mechanics THIS page documents prescribes as the canonical publisher-side defense against authentication-evasion class bypass-window techniques. Read the Workspace-deployment spoke ALONGSIDE this SPF-protocol- mechanics reference when deploying SPF on a Google Workspace tenant — the spoke documents how each SPF protocol primitive THIS page establishes instantiates concretely on the Google Workspace cloud-only deployment architecture.
TLS-RPT explained — the TLS-RPT-AS-TRANSPORT-LAYER- TELEMETRY-PUBLICATION-COMPLEMENT-TO- SPF-MESSAGE-LAYER-AUTHENTICATION- PUBLICATION companion to this SPF protocol-mechanics reference. Where THIS page documents the per-publisher per-domain message-layer SPF publication discipline (RFC 7208 v=spf1 TXT-RR byte- grammar, include:-mechanism delegation cascade with 10-DNS-lookup budget per RFC 7208 §4.6.4, qualifier- choice -all / ~all / ?all commitment, per-source-IP envelope- MAIL-FROM authentication evaluation), the TLS-RPT-explained spoke is the publisher-side per-domain RFC 8460 transport-layer telemetry-publication reference whose four CROSS-LAYER-PER- PUBLISHER-PUBLICATION-DISCIPLINE- COUPLING dimensions parallel and complement the SPF authentication- publication discipline this page establishes: (i) publisher- side per-domain TXT-record publication primitive parallel — SPF's per-domain <d> IN TXT "v=spf1 ... -all" and TLS-RPT's per-domain _smtp._tls.<d> IN TXT "v=TLSRPTv1; rua=mailto:..." are both per-publisher per-domain TXT-record publications the publisher elects to advertise into the global DNS namespace — SPF at the apex (or the per-sending-subdomain) and TLS-RPT at the _smtp._tls-prefixed sub- zone — and both publications drive receiver-side decision-making the publisher cannot directly observe without the corresponding telemetry stream (DMARC rua for SPF authentication evidence, TLS-RPT rua for per-recipient-MX TLS-failure evidence); (ii) per-source- IP SPF-evaluation outcome vs per- MX-host TLS-RPT-evaluation outcome attribution parallel — SPF evaluates per-source-IP per-message and produces a per-source-IP spf=pass/softfail/fail/ temperror/permerror result, while TLS-RPT evaluates per- recipient-MX per-SMTP-connection and produces a per-MX-host tls-success or per- failure-class (starttls-not- supported, certificate-host- mismatch, sts-policy-fetch-error, tlsa-invalid, etc.) attribution; the TLS-RPT-explained spoke documents the per-failing-MX-host TLS-failure attribution that is the transport-layer per-publisher per-recipient-MX evidence stream the per-publisher operates alongside the per-source-IP SPF evaluation evidence THIS page's protocol mechanics produce; (iii) per-publisher per-source- IP SPF-pass rate vs per-publisher per-MX-host TLS-success rate as complementary operational signals — the per- publisher per-day per-source-IP SPF-pass rate (extracted from the rua aggregate-XML stream feeding on the SPF protocol mechanics THIS page documents) and the per- publisher per-day per-MX-host TLS-success rate (extracted from the per-recipient-MX TLS-RPT JSON report stream the spoke documents) are complementary publisher-side operational-health signals every cross-layer publication-discipline ramp consumes; a per-publisher SPF-pass rate at 99 % combined with a per-publisher TLS-success rate at 60 % indicates the publisher's message-layer authentication is solid but transport-layer TLS enforcement is failing on a substantial fraction of inbound traffic to the publisher's MX RR-set — evidence the TLS-RPT-explained spoke documents the per-failure- class root-cause discovery workflow for; and (iv) per-publisher cross-layer publication-discipline stack coordination — the per- publisher per-domain TXT-record publication topology stacks SPF (message-layer authentication- publication), DKIM (message-layer cryptographic-publication), DMARC (message-layer policy + telemetry publication), MTA-STS / DANE (transport-layer enforcement- publication), and TLS-RPT (transport-layer telemetry- publication) into a coordinated per-domain publication discipline the publisher operates as a stack; the TLS-RPT-explained spoke documents the per-publisher per- domain transport-layer telemetry- publication discipline whose cross-layer coordination with the SPF message-layer authentication- publication discipline THIS page documents is the load-bearing publisher-side cross-layer publication-discipline contract every adjacent surface (DMARC publication + MTA-STS publication + DANE publication) structurally consumes. Read the TLS-RPT- explained spoke alongside this SPF-protocol-mechanics reference when authoring the per-publisher per-domain cross-layer publication-discipline stack — the SPF message-layer authentication-publication primitive THIS page establishes is the load-bearing message-layer publication-discipline whose receiver-side authentication evidence the TLS-RPT transport- layer telemetry-publication complement structurally completes.
MTA-STS explained — the TRANSPORT-LAYER-TLS- ENFORCEMENT-PUBLICATION-DISCIPLINE companion to this SPF message- layer IP-authentication-publication reference. Where THIS pillar documents the per-publisher RFC 7208 per-domain SPF TXT-RR publication discipline whose per-source-IP authorisation evaluation operates at the MESSAGE LAYER (matching the envelope-MAIL-FROM client-IP against the publisher's authorised-sender mechanism set, verified at the receiver by the Authentication-Results: spf=pass verdict), the MTA-STS-explained spoke documents the per-publisher RFC 8461 _mta-sts.<domain> TXT-record + HTTPS-served policy publication discipline whose per-connection TLS-channel- integrity enforcement operates at the TRANSPORT LAYER (forcing STARTTLS-with-valid-cert at the receiving MX, enforced at the sending MTA per the publisher- side policy commitment), bridging the message-layer IP- authentication-publication discipline this page documents to the transport-layer TLS- enforcement discipline the MTA-STS spoke documents at four cross-layer per-publisher- publication-discipline coupling dimensions: (i) per-publisher per-domain DNS-TXT-RR publication primitive as STRUCTURALLY- IDENTICAL publisher-side surface across both protocols — SPF publishes the per-domain <domain> TXT-RR carrying the v=spf1 ... ~all mechanism-and-qualifier binding; MTA-STS publishes the per-domain _mta-sts.<domain> TXT-RR carrying the v=STSv1; id=<policy-id> version-and-policy-pointer binding, with the actual policy served over HTTPS at https://mta-sts.<domain>/.well-known/mta-sts.txt; the per-publisher DNS-TXT-RR publication discipline this page documents for SPF is the per-publisher publication- primitive the MTA-STS spoke documents at the transport- layer layer, both enforcing the same per-publisher-per-domain DNS-TXT-publication discipline operators consume; (ii) per-message SPF source-IP- authorisation vs per-connection MTA-STS TLS-channel-enforcement as complementary cross-layer per-publisher attestation publication — SPF authorises per-message envelope-MAIL-FROM client-IP (the receiver's mechanism evaluation proves the sending IP is on the publisher's authorised-sender list); MTA-STS enforces per-connection TLS- channel-integrity (the sender's outbound MTA refuses to deliver if the receiving MX's TLS handshake or certificate- validation fails); the two cross-layer publication- disciplines compose into a per- publisher complete authentication- and-confidentiality envelope (message-source IP-authentication at layer 3 + transport-channel TLS-enforcement at layer 4), framing the publisher-side IP- authentication discipline this page documents for SPF as the message-layer half of the publisher-side per-domain cryptographic-and-authentication- discipline-stack the MTA-STS spoke completes at the transport layer; (iii) per-publisher SPF mechanism-revision lifecycle vs per-publisher MTA-STS policy-id- versioning lifecycle as parallel publication-cadence disciplines — SPF publishers revise mechanism sets (add new include cascade → wait propagation window → audit per-source-IP evaluation evidence in rua reports → remove deprecated mechanisms); MTA-STS publishers version policies (bump id= in the TXT-RR → deploy new policy at the HTTPS endpoint → rely on receiver-side max_age= cache-expiry to propagate); the same per-publisher publish- and-verify-cycle discipline applies to both, bridging the SPF mechanism-revision cadence this page documents to the MTA-STS policy-versioning cadence the MTA-STS spoke documents; (iv) per-publisher cross-layer publication stack coordination as per-publisher operational discipline scope — every per-publisher per- domain publication-discipline catalogue (SPF at layer-3 + DKIM at layer-7 + DMARC at layer-7- policy + MTA-STS at layer-4 + TLS-RPT at layer-4-observability + BIMI at layer-7-display) consumes the same per-publisher per-domain DNS-TXT publication discipline as the load-bearing publication primitive; the MTA-STS-explained spoke is the canonical per-publisher transport-layer publication- discipline reference SPF operators read alongside this pillar when scoping the per- publisher cryptographic-and- authentication-discipline stack their per-domain operational posture consumes. Read the MTA-STS spoke alongside this SPF pillar when designing the per-publisher per-domain cross- layer authentication-and- transport-publication discipline that the message- layer SPF IP-authentication this page documents is one layer of, alongside the transport-layer MTA-STS TLS- channel-enforcement the MTA-STS spoke documents.
DMARC monitoring — the SPF-PER-MESSAGE-ENVELOPE-IP- VERDICT-AS-LOAD-BEARING-CROSS-MESSAGE- INPUT-TO-DMARC-MONITORING-AGGREGATE-KPI- STREAM companion documenting how the per- message Authentication-Results: spf=pass / spf=fail / spf=softfail / spf=neutral / spf=temperror / spf=permerror verdict this SPF pillar's RFC 7208 §2.6 evaluation algorithm produces is the second of TWO cross-message inputs (alongside the DKIM per-selector cryptographic verdict) the DMARC monitoring aggregate-XML KPI stream consumes for every <record>-level alignment-success-rate, alignment- failure-rate, per-receiver disposition- distribution, per-source-IP alignment- stratification, and per-day verdict-rate regression dashboard the DMARC monitoring spoke documents. Where THIS pillar documents the per-message SPF evaluation protocol mechanics (per-domain v=spf1 TXT-RR publication- byte grammar, the include: / a: / mx: / ip4: / ip6: mechanism cascade with the RFC 7208 §4.6.4 10-DNS-lookup budget, -all / ~all / ?all publication-mode commitment, the per-source-IP authorisation evaluation against the envelope-MAIL-FROM domain), the DMARC monitoring spoke is the per-domain AGGREGATE-VIEW reference whose KPI cohort consumes the per-message SPF verdict catalogue this pillar establishes at four SPF-protocol-primitive- to-monitoring-KPI-aggregation coupling dimensions: (i) per-message SPF verdict catalogue → per-domain SPF- pass-rate KPI as load-bearing cross- message aggregate contract — the per-message spf=pass verdict is the load-bearing numerator of the per- domain SPF-pass-rate KPI the monitoring spoke tracks across the 90-day rolling window; the per-domain numerator-cohort is partitioned per-source-IP, per- receiver, per-day so per-source-IP regression events surface in the monitoring spoke's Pattern E per-verdict- shift detection view that triggers the per-source-IP authorisation-publication review this pillar documents the operational discipline of; (ii) per-message SPF-aligned-pass verdict → per-domain SPF-alignment- rate KPI as load-bearing per-source-IP aggregate contract — the receiver's per-message SPF-aligned-pass outcome (SPF-pass AND the envelope-MAIL- FROM domain organisationally-aligns with the visible From: header per RFC 7489 §3.1.2) is the per-source-IP load-bearing aggregate metric the monitoring spoke uses to attribute per- source-IP envelope-MAIL-FROM-bounce- domain misconfiguration to specific outbound tenants in the per-source-IP stratification dashboard; the per-source- IP SPF-aligned-pass-rate distribution is the canonical signal that surfaces a sender using a third-party ESP whose bounce-domain is the ESP's own domain (e.g. bounces.sendgrid.net) rather than the publisher's organisational domain — producing SPF-pass + SPF-not- aligned + DMARC-fail-via-SPF-leg whose rescue depends on the DKIM-aligned-pass path; (iii) per-message SPF permerror / temperror verdict → per- day per-receiver SPF-error-rate KPI as load-bearing publication-discipline regression detector — when the receiver emits spf=permerror at non-zero rates, the monitoring spoke's per-receiver per-day distribution view surfaces the RFC 7208 §4.6.4 10-DNS- lookup-limit-exhaustion regression (typical pattern: a third-party ESP include token added without auditing the cumulative recursive-include cost) the publication-discipline this pillar documents the rescue protocol for; the per-receiver per-day distribution is the canonical KPI that surfaces a new permerror cohort at the operationally- observable boundary; (iv) per- message SPF verdict series → 90-day SPF-pass-rate trend as load-bearing enforcement-readiness gate — the per-domain SPF-pass-rate trend the monitoring spoke tracks across the 90-day rolling window is the load-bearing enforcement-readiness gate the DMARC rollout discipline (p=none → p= quarantine → p=reject) consumes to determine whether the per-domain SPF publication is stable enough — across every legitimate-sender's source-IP space — to commit to the next enforcement- policy tightening; the 90-day SPF-pass- rate convergence pattern is the canonical signal the monitoring spoke surfaces to operators evaluating the per-tenant readiness for the next p=- stage commitment, paired with the per- source-IP SPF-aligned-pass-rate distribution for per-third-party-ESP DMARC-alignment- readiness analysis. Read the DMARC monitoring spoke alongside this SPF pillar when scoping per-domain SPF publication- and-authorisation observability, per- source-IP regression-event detection, per-receiver permerror / temperror surveillance, and 90-day per-domain SPF- pass-rate convergence analysis for the DMARC enforcement-ramp gate.
Email authentication glossary — the SPF-PROTOCOL-PILLAR-AS-LOAD- BEARING-CONSUMER-AND-PRODUCER-OF- CANONICAL-DEFINED-TERM-DEFINITIONS companion to this SPF protocol pillar. Where THIS page documents the RFC 7208 SPF-TXT-record byte- grammar (the v=spf1 first-position version tag, the mechanism token-list with ip4: / ip6: / a / mx / include: / ptr / exists / all, the per-mechanism qualifier prefixes + / - / ~ / ?, the 10-DNS-lookup mechanism budget per RFC 7208 §4.6.4, the seven RFC 8601 §2.7.2 result-class verdicts spf=none / spf=neutral / spf=pass / spf=fail / spf=softfail / spf=temperror / spf=permerror), the email-authentication-glossary spoke documents the canonical DefinedTerm JSON-LD reference whose per-term entity-first definition-lede is the upstream-vocabulary substrate every SPF-protocol-concept this pillar documents consumes at FOUR per-SPF- protocol-to-glossary-defined-term coupling dimensions: (i) per- SPF-mechanism-token-vocabulary-as- load-bearing-consumer-of-canonical- defined-term-definition — every per-mechanism-token slot THIS page documents (the ip4: / ip6: literal-IP-list mechanisms, the a / mx / ptr / include: / exists: DNS-resolving mechanisms, the all terminal-mechanism) CONSUMES the canonical glossary-spoke DefinedTerm definition for the underlying protocol-concept the mechanism- token enumerates — operator-side per-mechanism selection requires prior canonical-definition fluency in the underlying protocol-concept the mechanism-token enumerates; (ii) per-SPF-qualifier-and- identifier-vocabulary-as-load- bearing-consumer-of-canonical- defined-term-definition — the per-mechanism qualifier-prefix grammar (+ Pass / - Fail / ~ SoftFail / ? Neutral), the RFC 5321 envelope-MAIL-FROM identifier evaluated under RFC 7208 §4.1, the HELO identity evaluated per RFC 7208 §2.3, and the organisational-domain derivation from the PSL all CONSUME the canonical glossary-spoke DefinedTerm definitions for each per-qualifier- and-identifier semantic — operator- side qualifier-and-identifier- publication discipline requires prior canonical-definition fluency in the four-term qualifier-and- identifier vocabulary the glossary spoke documents; (iii) per- SPF-verdict-class-receiver-side- vocabulary-as-load-bearing-consumer- of-canonical-defined-term-definition — the seven RFC 8601 §2.7.2 spf=none / spf=neutral / spf=pass / spf=fail / spf=softfail / spf=temperror / spf=permerror result- class verdicts THIS page documents CONSUME the canonical glossary-spoke DefinedTerm definition for each verdict-class semantic — operator- side SPF-troubleshooting per- symptom decision-tree traversal requires prior canonical-definition fluency in the seven-verdict-class vocabulary the glossary spoke documents; (iv) per-SPF- protocol-AI-retrieval-engine- citation-vocabulary-as-load-bearing- producer-of-canonical-defined-term- definition — every SPF- protocol-concept THIS page documents PRODUCES the per-term entity-first definition the glossary-spoke DefinedTermSet JSON-LD root cites as the canonical reference for AI- retrieval-engine citation (Perplexity / ChatGPT / Claude / Gemini / Google AI Overviews / Bing Copilot) — the bi-directional citation loop between THIS SPF- protocol pillar and the glossary- spoke DefinedTerm JSON-LD entries is the AI-retrieval-engine canonical- reference foundation the cluster relies on for per-term deep-link citability of every SPF-protocol- concept. Read the email- authentication-glossary spoke alongside THIS page when the operator asks "what is the canonical definition of the SPF- protocol-concept this pillar enumerates" — the answer is FOUR- LAYERED: THIS page documents the SPF-protocol pillar, the email- authentication-glossary spoke documents the canonical DefinedTerm definition for every SPF-protocol- concept the pillar enumerates.
DMARC attacker bypass techniques — the 22-TECHNIQUE PER-PUBLISHER PER-DOMAIN ATTACKER-BYPASS CLASSIFICATION-FRAMEWORK companion to this SPF pillar reference. Where THIS page documents the SPF protocol primer (RFC 7208 mechanism catalogue, per-mechanism qualifier-evaluation semantic, 10-DNS-lookup budget ceiling, per-publisher per-domain record-publication discipline), the attacker-bypass spoke is the per- publisher per-domain attacker-side SPF-evaluation-bypass technique- classification documenting the FIVE SPF-targeted attacker-bypass technique-classes the per-publisher per-domain operator MUST defend against at the per-mechanism SPF- publication boundary: (i) SPF-permerror-induction via deliberate 10-lookup-budget overflow — attacker observes the per-publisher per-domain SPF record carries a near-ceiling per-mechanism DNS-lookup count and injects a transient include-chain expansion event (cooperating upstream-include-publisher publishes a temporary include-chain extension) to push the per-receiver evaluation over the §4.6.4 budget ceiling, producing per-receiver permerror that causes the per-publisher per-domain DMARC evaluator to bypass SPF- alignment entirely; (ii) SPF- softfail-tolerance exploitation under per-receiver permissive-policy stance — attacker observes the per-publisher per-domain SPF record terminates in ~all (softfail) rather than -all (fail) and emits per-source-IP per-message flow from outside the authorized per-mechanism IP-pool, exploiting per-receiver disposition variance where some per-receivers treat softfail as no-bypass-defence signal; (iii) SPF-mechanism- misconfiguration exploitation via per-mechanism +all / +include / bare-ptr-mechanism attack surface — attacker scans the per-publisher per-domain SPF record for misconfigurations (operator-published +all catch-all, mistaken +include:<attacker-controlled-host>, deprecated ptr mechanism whose reverse-DNS-based authorization the attacker spoofs); (iv) SPF-include-supply-chain- compromise via per-include-target operator-side breach — attacker compromises an upstream per-publisher per-domain include- target operator (small SaaS sender, marketing-platform provider) whose per-publisher per-domain include: token grants the attacker's per-source-IP message-flow the per-publisher per- domain SPF-authorized status; (v) SPF-record-misalignment bypass via cousin-domain / look-alike-domain attacker From: header injection — attacker registers a per-publisher per-domain homoglyph cousin-domain (rn-vs-m, l-vs-I, cyrillic-vs- latin), publishes the attacker's own authorized SPF record at the cousin-domain, and uses the cousin- domain From: header to bypass the per-publisher per-domain SPF evaluation entirely. Read THIS page when AUTHORING the per-publisher per-domain SPF protocol record; read the DMARC-attacker-bypass spoke when DESIGNING the per-publisher per-domain SPF-evaluation-attacker- defence posture against the 22- technique attacker-bypass classification framework — the spoke is the canonical attacker- bypass technique catalogue the per- publisher per-domain SPF posture THIS page documents must structurally defend against.
DMARC for Microsoft 365 — the M365-TENANT-SPF-INCLUDE- PUBLICATION-EXECUTION-DISCIPLINE companion to this per-publisher per- domain SPF protocol-record publication-discipline reference. Where THIS page documents the per- publisher per-domain SPF protocol- record authoring discipline (per- mechanism ip4: / ip6: / a: / mx: / include: publication, per-publisher per-domain RFC 7208 §4.6.4 10-DNS-lookup budget compliance, per-publisher per-domain qualifier discipline + / - / ~ / ?, per-publisher per- domain all terminator publication), the M365-deployment spoke is the PER-M365-TENANT EXECUTION- DISCIPLINE COMPANION documenting how the per-publisher per-domain SPF protocol-record publication discipline instantiates concretely on Microsoft 365 at FOUR per-M365-tenant-SPF- include-publication-vs-per-publisher- per-domain-SPF-protocol-record- publication-instantiation dimensions: (i) per-M365-tenant include:spf.protection.outlook. com publication is the per- M365-tenant SPF-include-publication instantiation — the M365- deployment spoke documents how the per-tenant authoritative DNS-zone include:spf.protection.outlook. com publication is the canonical Microsoft-managed SPF- include the per-publisher per-domain SPF protocol-record THIS page documents structurally requires for per-message outbound-source authorisation through Exchange Online Protection; (ii) per-M365- tenant authorised-outbound-sender include-chain expansion is the per- M365-tenant RFC 7208 §4.6.4 10-DNS- lookup budget compliance instantiation — the M365- deployment spoke documents how the per-tenant authorised-outbound-sender include-chain (3rd-party ESPs, on-premises connectors, hybrid Exchange relays) consumes per-tenant SPF-lookup budget that the per- publisher per-domain SPF permerror diagnostic ladder THIS page documents must structurally accommodate; (iii) per-M365-tenant Exchange- Online-Protection-managed include- target SPF posture is the per-M365- tenant per-IP-range SPF-authorisation instantiation — the M365- deployment spoke documents how the per-tenant Microsoft-managed include- target's per-IP-range ip4: / ip6: publication discipline at spf.protection.outlook.com is the canonical per-tenant SPF- authorisation backing the per-message envelope-mail-from per-publisher per- domain SPF evaluation THIS page documents; and (iv) per-M365- tenant per-accepted-domain DMARC publication is the per-M365-tenant DMARC-side companion of the per- publisher per-domain SPF publication — the M365- deployment spoke documents how the per-tenant per-accepted-domain DMARC publication consumes the per-publisher per-domain SPF-evaluation result THIS page documents at the per-message DMARC alignment-and-policy-mode evaluation tier, structurally pairing the per-publisher per-domain SPF publication discipline with the per- M365-tenant DMARC deployment discipline.
CAA records explained — the per-publisher per-domain CAA-record publication-discipline companion to this SPF-protocol-pillar reference. Where THIS page documents the per-publisher per-domain RFC 7208 SPF TXT-record IP-authorization publication discipline (the v=spf1 version-prefix-byte sequence, the a / mx / ip4 / ip6 / include mechanism-token publication, the per-publisher per-domain authorized-sender-IP set, the per-domain TXT publication at the authoritative-DNS zone apex), the CAA-records spoke is the PER-PUBLISHER-PER-DOMAIN-RFC-8659-CA- ISSUANCE-AUTHORIZATION-PUBLICATION reference documenting the per-publisher per-domain <domain> CAA 0 issue "<ca>" per-CA-authorisation publication-discipline at the same per-publisher per-domain authoritative-DNS zone apex. Four PER- PUBLISHER-PER-DOMAIN-AUTHORITATIVE-DNS- PUBLICATION-DISCIPLINE-COUPLING dimensions the CAA-records spoke documents: (i) per-publisher per-domain authoritative-DNS zone-apex publication discipline parallel — both the per-publisher per-domain SPF TXT publication and the per-publisher per-domain CAA-record publication are authored at the publisher's authoritative-DNS zone-apex, so the same per-publisher per-zone publication cadence + per-zone DNSSEC signing discipline + per- zone TTL choice that governs SPF-record publication also governs CAA-record publication; (ii) per-publisher per- domain authorization-publication scope parallel — SPF publishes WHICH per- source-IP is authorized to envelope-MAIL- FROM mail for the publisher domain, while CAA publishes WHICH per-CA is authorized to issue TLS certs for the same publisher domain, making both per-publisher per-domain authorization-publication primitives at distinct trust layers (per-source-IP envelope-sender authorization vs per-CA TLS- cert-issuance authorization); (iii) per-publisher per-domain whitelist-default-deny publication- discipline parallel — SPF -all publishes an explicit hard- fail default-deny per-source-IP authorization-set boundary, structurally paralleling CAA's 0 issue ";" explicit zero-CA authorization-set boundary; both are per-publisher per-domain explicit- default-deny publication-discipline primitives; (iv) per-publisher per- domain DNS-publication-discipline- correctness coupling — a per-zone DNS-publication mistake (typo, truncated record, missing record) breaks both SPF-pass evaluation AND CAA-enforcement at the same per-zone DNS-authoritative-zone integrity boundary, so the same per-publisher per- zone change-management + per-zone canary- validation + per-zone DNSSEC-signing-cadence discipline applies to both. Read the CAA- records spoke alongside this SPF-protocol- pillar reference when the per-publisher per- domain DNS-publication-discipline this page documents needs to be coordinated with the per-publisher per-domain CA-issuance- authorization publication-discipline at the same authoritative-DNS zone-apex publication boundary.
Email authentication ecosystem — the per-publisher per-domain four-protocol integration framework (SPF envelope-MAIL- FROM authorization + DKIM per-message cryptographic-signature + DMARC alignment- and-policy + ARC forwarder-rescue) THIS SPF protocol primer is the per-envelope- layer per-source-IP authorization-leg chapter of, at four cross-protocol ecosystem-integration coupling dimensions: (i) per-publisher per-domain SPF publication as the per-envelope per-source- IP per-message MAIL-FROM authorization- attestation primitive whose per-receiver per-message verdict is the per-message SPF-leg input to the per-receiver per- message DMARC composite-verdict — the email-authentication-ecosystem framework explicitly documents SPF as the per-envelope- per-source-IP authorization-layer protocol whose per-message spf=pass / spf=fail / spf=softfail / spf=neutral / spf=none / spf=permerror / spf=temperror verdict the per- receiver per-message DMARC composite- verdict evaluator consumes at the RFC 7489 §6.6.2 alignment-and-policy junction; (ii) per-publisher per-domain SPF identifier-alignment-with-DMARC (RFC 7489 §3.1.2) as the per-message SPF-leg DMARC- composite-verdict input the ecosystem framework treats as load-bearing peer to per-publisher per-selector DKIM identifier- alignment — the SPF-checked envelope-MAIL-FROM domain MUST align with the per-message RFC 5322 From: header domain (relaxed-mode same-organisational- domain or strict-mode byte-identical match per the publisher-published aspf= tag) for the SPF leg to contribute a DMARC-aligned-pass verdict; (iii) per-publisher per-domain SPF publication-discipline structurally fails across legitimate forwarder envelope- rewrites (RFC 7208 §2.6.6) requiring SPF- complement protocols (DKIM cryptographic- signing + ARC chain-of-custody preservation) within the broader ecosystem framework to cover the per-publisher per-domain forwarder-survivability gap — the email-authentication-ecosystem framework explicitly catalogues the SPF forwarder- break failure-mode and documents the per- publisher per-selector DKIM-aligned-pass + RFC 8617 ARC-sealing rescue compositions the per-publisher per-domain operator ships ALONGSIDE the per-publisher per- domain SPF publication to close the per- publisher per-domain composite DMARC- aligned-pass-rate forwarder-coverage gap; (iv) per-publisher per-domain SPF- verdict + SPF-aligned-vs-unaligned surfacing in the per-receiver per-day per-source- IP per-row auth_results.spf RUA-XML evidence stream the ecosystem framework's monitoring layer materially consumes — the per-publisher per- domain operator's SPF publication- discipline (mechanism-token choice + qualifier-strictness + ten-DNS-lookup budget compliance per RFC 7208 §4.6.4 + include-chain authoring) materially determines the per-row auth_results .spf evidence the email-authentication- ecosystem framework's per-publisher per- domain analytics dashboards consume. Read the email-authentication-ecosystem pillar alongside this SPF protocol primer when the per-publisher per-domain operator is positioning SPF within the broader four- protocol authentication-publication discipline, when coordinating per-publisher per-domain SPF publication with per- publisher per-domain DKIM + DMARC + ARC publication-decisions, or when authoring per-publisher per-domain per-protocol authentication-publication runbooks that must coordinate the per-message SPF envelope-MAIL-FROM authorization-leg with the broader per-publisher per-domain authentication-publication discipline.
RFC 7208 — Sender Policy Framework — the SPF specification itself. Obsoletes the older RFC 4408.
RFC 7489 — DMARC — the policy standard that consumes SPF results.
BIMI SVG Tiny PS requirements — the per-publisher per-domain BIMI SVG Tiny PS asset-publication-discipline companion to this SPF-protocol-pillar reference. Where THIS page documents the per-publisher per-domain RFC 7208 SPF TXT- record IP-authorization publication discipline (the v=spf1 version- prefix, the per-publisher per-domain authorized-sender-IP set, the per-source-IP envelope-MAIL-FROM authentication outcome that feeds the per-message DMARC alignment evaluation), the BIMI SVG Tiny PS requirements spoke is the PER-PUBLISHER-PER- DOMAIN-BIMI-SVG-TINY-PS-ASSET-FORMAT- PUBLICATION reference documenting the BIMI Group Tiny PS SVG profile (baseProfile="tiny-ps", square viewBox, forbidden script / animation / external-reference / raster element list), the per-publisher per-domain default._bimi.<d-domain> TXT-RR publication, and the per-receiver BIMI logo-display gate SVG-fetch trust chain. Four CROSS-PROTOCOL-PILLAR- AUTHENTICATION-TO-DISPLAY-LAYER-PUBLICATION- COUPLING dimensions the BIMI SVG Tiny PS requirements spoke documents: (i) per-publisher per-domain SPF- aligned-pass verdict as upstream prerequisite for BIMI display-gate eligibility — every per-receiver BIMI logo-display evaluation requires DKIM-aligned-pass OR SPF-aligned-pass at the per-message DMARC alignment boundary, so the per-publisher per-domain SPF authentication-publication- discipline this page documents is the load- bearing upstream prerequisite for the BIMI SVG Tiny PS asset display-gate eligibility the BIMI SVG Tiny PS requirements spoke documents; (ii) per-publisher per- domain authoritative-DNS TXT-RR byte- grammar publication discipline parallel — both the per-publisher per-domain SPF TXT-RR byte-grammar this page documents at the zone apex and the per-publisher per-domain BIMI-record TXT-RR byte-grammar at default._bimi.<d-domain> the BIMI SVG Tiny PS requirements spoke documents are per-publisher per-domain authoritative-DNS TXT-RR byte-grammar publication primitives at distinct protocol-pillar layers (per-domain SPF IP- authorization vs per-domain BIMI display- asset pointer); (iii) per-publisher per-domain SPF-record validation outcome as per-message DMARC-alignment-feed input to BIMI display-gate evaluation — the per-publisher per-domain SPF-record validation outcome (per-source-IP authorized / not-authorized verdict) this page documents feeds the per-message DMARC alignment evaluation that gates the per- receiver BIMI logo-display eligibility the BIMI SVG Tiny PS requirements spoke documents; (iv) per-publisher per- domain authentication-and-display posture composition boundary — the per- publisher per-domain SPF authentication- publication-discipline THIS page documents and the per-publisher per-domain BIMI SVG- Tiny-PS asset-format-publication-discipline the BIMI SVG Tiny PS requirements spoke documents compose at the per-publisher per- domain authentication-and-display posture boundary where the authentication-layer verdict gates the display-layer asset rendering. Read the BIMI SVG Tiny PS requirements spoke alongside this SPF- protocol-pillar reference when DESIGNING the per-publisher per-domain cross-protocol- pillar authentication-and-display posture composition that pairs per-publisher per- domain SPF authentication-publication- discipline with per-publisher per-domain BIMI SVG-Tiny-PS asset-format publication- discipline.
DMARC for transactional email — the per-publisher per-domain TRANSACTIONAL-EMAIL-DEPLOYMENT companion to this SPF-protocol-pillar reference. Where THIS page documents the per-publisher per-domain RFC 7208 SPF TXT-record IP-authorization publication discipline (the v=spf1 version-prefix, the per-publisher per-domain authorized- sender-IP set via ip4: / ip6: / a: / mx: / include: mechanisms, the cumulative 10-DNS-lookup budget, the terminal -all / ~all / ?all qualifier-policy choice), the DMARC- for-transactional-email spoke documents the per-publisher per-domain high- volume transactional-sender DMARC deployment discipline whose per-ESP per-publisher per-domain SPF-record composition discipline is the load- bearing per-message envelope-MAIL-FROM authentication prerequisite. The composition operates through the per- ESP SPF-record-cumulative-include- composition challenge: a per-publisher per-domain operator deploying transactional email via multiple per- ESP senders (SendGrid + Mailgun + Postmark + Amazon SES + internal app servers) must compose the per-publisher per-domain SPF TXT-RR with cumulative include:sendgrid.net + include:mailgun.org + include:spf.mtasv.net + include:amazonses.com statements that collectively must stay within the 10-DNS-lookup budget THIS page documents — the per-ESP SPF- include-budget-coordination is the single most-failing per-publisher per- domain transactional-sender deployment discipline because each per-ESP SPF record itself nests include: sub-records that consume additional lookups from the per-publisher per-domain budget. The DMARC-for-transactional-email spoke documents the per-ESP-include-budget- coordination operational discipline + per-publisher per-domain SPF-flattening rescue pattern + per-publisher per- domain subdomain-delegation pattern that close the SPF-budget breach. Read THIS page when AUTHORING the per- publisher per-domain SPF TXT-RR byte- grammar discipline; read the DMARC- for-transactional-email spoke when COMPOSING the per-publisher per-domain per-ESP cumulative SPF-include-budget- coordination operational discipline for a per-publisher per-domain transactional-sender DMARC deployment whose per-message envelope-MAIL-FROM SPF-authentication green-state baseline is the load-bearing per-recipient transactional-email delivery prerequisite.
Multi-domain DMARC strategy — the PER-PUBLISHER-PER-PORTFOLIO-MULTI-DOMAIN- SPF-INCLUDE-CASCADE-COORDINATION-AS-LOAD-BEARING- CROSS-DOMAIN-SPF-PUBLICATION-DISCIPLINE companion to this SPF protocol pillar. Where THIS page documents the SPF protocol at the per-publisher per-domain byte level (the RFC 7208 v=spf1 mechanism syntax with include: / a: / mx: / ip4: / ip6: mechanisms, the qualifier prefix + / ~ / - / ? verdict semantics, the 10-DNS-lookup cap per RFC 7208 §4.6.4, the per-publisher per-domain envelope-MAIL-FROM IP-authentication verdict-catalogue), the multi-domain-DMARC- strategy spoke is the PER-PUBLISHER-PER- PORTFOLIO-CROSS-DOMAIN-SPF-PUBLICATION- COORDINATION companion documenting the per-publisher per-portfolio per-primary + per-secondary + per-brand-extension + per- parked-domain SPF-record-publication coordination discipline whose per-portfolio cumulative SPF-include-cascade budget arithmetic across the per-publisher per-portfolio domain inventory is the load-bearing SPF-publication-discipline precondition the per-publisher per-portfolio uniformly-enforced DMARC posture cascades from. Four SPF-vs-multi-domain-DMARC coupling dimensions matter at the per- publisher per-portfolio cross-domain publication-coordination boundary: (i) per-publisher per-portfolio per-primary- domain SPF include-cascade publication — the per-primary-domain v=spf1 include:<esp1> include:<esp2> -all cascade publication discipline THIS page documents coordinates with the per-publisher per- portfolio per-secondary + per-brand- extension SPF-record publication so that the cumulative 10-DNS-lookup ceiling per RFC 7208 §4.6.4 is preserved across EVERY per-publisher per-portfolio sending subdomain at the per-receiver per-message SPF-evaluation boundary; (ii) per-publisher per-portfolio per-secondary-domain SPF- record-publication discipline — when the per-publisher operates secondary brand domains for marketing / transactional / newsletter mail streams, each per- secondary-domain v=spf1 record's per-ESP include: composition is coordinated against the per-publisher per-portfolio uniformly- enforced DMARC posture the multi-domain- strategy spoke documents so per-secondary- domain SPF-aligned-pass produces a per- receiver per-message DMARC-pass verdict feeding the per-publisher per-portfolio aggregate DMARC-pass-rate floor; (iii) per-publisher per-portfolio per-parked- domain locked-down SPF defensive publication — the per-parked-domain v=spf1 -all + DKIM-empty- p= + DMARC p=reject defensive-publication discipline the multi- domain-strategy spoke documents prevents per-attacker per-parked-domain spoofing campaigns from polluting the per-publisher per-portfolio aggregate DMARC-pass-rate stream the per-receiver BIMI / inbox-trust eligibility evaluators consume; (iv) per- publisher per-portfolio organisational- domain identification at the receiver-side DMARC aspf=relaxed / aspf=strict SPF-alignment evaluator — the Public-Suffix-List-anchored organisational-domain identification rule the multi-domain-strategy spoke documents determines which per-publisher per- portfolio domain is identified as the organisational-domain whose SPF-alignment verdict the per-receiver per-message DMARC composite-evaluator consumes when producing the per-message DMARC verdict. Read THIS page when AUTHORING the per-publisher per- domain SPF TXT-RR byte-grammar publication discipline; read the multi-domain-DMARC- strategy spoke when COORDINATING the per- publisher per-portfolio per-primary + per- secondary + per-brand-extension + per- parked-domain SPF-include-cascade-budget arithmetic across the per-publisher per- portfolio domain inventory whose per- publisher per-portfolio uniformly-enforced DMARC posture is the load-bearing per- publisher per-portfolio cross-domain publication-discipline floor every per- publisher per-domain SPF record's per- receiver per-message spf=pass verdict feeds at the per-publisher per-portfolio aggregate DMARC-pass-rate floor preservation boundary.
TLS-RPT report format (RFC 8460 §4 JSON-aggregate schema) — the per-receiver per-publisher per-day RFC 8460 §4 TLS-RPT JSON-aggregate-report byte-grammar reference companion to this SPF protocol-pillar explanation. Where THIS page documents the per-publisher per- domain RFC 7208 SPF envelope-MAIL-FROM- layer DNS TXT-RR publication discipline (the v=spf1 record syntax, the eight mechanism-vocabulary tokens — a / mx / ip4 / ip6 / include / exists / ptr / all — the qualifier prefixes, the redirect= / exp= modifiers, and the RFC 7208 §4.6.4 ten-DNS-lookup ceiling), the TLS-RPT report-format spoke documents the structurally parallel per-publisher per-domain RFC 8460 transport-layer _smtp._tls.<domain> DNS TXT-RR publication (v=TLSRPTv1; rua=mailto:...) and the per-day per-receiver JSON- aggregate-report byte-grammar whose result-type enum (starttls-not-supported, certificate-host-mismatch, certificate- expired, certificate-not-trusted, validation-failure, sts-policy-fetch- error) IS the per-publisher per-domain transport-layer STARTTLS-handshake- survival observability primitive. Four per-protocol-layer publication-vs- observability coupling dimensions matter at the per-publisher per-domain composite envelope-and-transport-layer publication discipline boundary: (i) per-publisher per-domain dual DNS TXT-RR publication discipline — SPF v=spf1 per-domain root TXT-RR coexists with TLS-RPT v=TLSRPTv1 per-domain _smtp._tls TXT-RR at the per-publisher per-domain shared DNS- publication-cadence boundary, both consuming the per-publisher per-domain zone-file commit-and-propagation discipline; (ii) per-receiver-side per- message envelope-layer SPF verdict-vs- per-receiver-side per-day transport-layer TLS-RPT verdict — the per-message envelope-MAIL-FROM-vs-published-SPF verdict THIS page documents IS the per- message envelope-layer observability feed that surfaces at receiver-side Authentication-Results; Received-SPF at per-message granularity, and the per-publisher per- day per-receiver TLS-RPT JSON-aggregate- report-emission feed the report-format spoke documents IS the structurally parallel per-day-granularity transport- layer observability feed for STARTTLS- handshake failures; (iii) per-publisher per-domain RUA-style aggregate-report feed-back-channel discipline — SPF itself has no aggregate-report mechanism (the per-publisher per-domain envelope-layer evidence comes back through DMARC RUA aggregate reports at the per-message layer), and the TLS-RPT report-format spoke documents the structurally parallel per-publisher per-domain transport-layer RUA-style feed-back-channel that surfaces STARTTLS-handshake failures the per- publisher per-domain envelope-layer SPF- pass verdict THIS page documents IS cryptographically-orthogonal to (envelope- layer SPF success does NOT imply transport-layer TLS success and vice- versa); (iv) per-publisher per-domain composite publication-and-observability coordination — the per-publisher per- domain SPF + DKIM + DMARC + ARC + MTA-STS + TLS-RPT publication-portfolio THIS page's authentication-protocol-layer component IS load-bearing for the envelope-layer per-message authorization outcome, while the TLS-RPT report-format spoke's transport-layer per-day per- receiver observability feed IS load- bearing for the per-publisher per-domain transport-layer egress-stack-health evidence stream every per-publisher per- domain composite publication-and- observability discipline consumes at the publication-portfolio coordination floor. Read THIS page when AUTHORING the per-publisher per-domain envelope-MAIL- FROM-layer SPF TXT-RR publication; read the TLS-RPT report-format spoke when EVALUATING the per-publisher per-day per- receiver transport-layer STARTTLS- handshake-failure JSON-aggregate-report evidence stream every per-publisher per- domain composite envelope-and-transport- layer publication discipline depends on for per-publisher per-domain publication-portfolio-coordination floor.
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 envelope-MAIL-FROM authorisation with DKIM application-layer signing should read alongside this SPF primer. Where THIS page locks the per- publisher per-domain envelope-MAIL-FROM authorisation leg at the application-layer- adjacent envelope boundary, the DKIM- canonicalization reference locks the parallel per-publisher per-selector application-layer DKIM-Signature-header-and-body byte- normalisation discipline that determines whether per-receiver per-message DKIM verification succeeds after forwarder / mailing-list-server / MTA whitespace modification — together they close the per- publisher per-domain composite envelope-and- application-layer authentication-leg publication-and-survival discipline.
DKIM alignment with DMARC — the application-layer DKIM-alignment composite-partner to the envelope-MAIL-FROM- layer SPF-alignment evaluation THIS SPF deep- dive page documents. Where the SPF mechanism- class evaluation produces the per-message envelope-MAIL-FROM-domain-vs-From:-domain SPF- alignment leg (the aspf=r/s relaxed-vs-strict mode selection per RFC 7489 §3.1.2), the DKIM alignment evaluation produces the per-message DKIM-d=-tag-vs- From:-domain alignment leg (the adkim=r/s mode selection per RFC 7489 §3.1.1) — both feed the per-message DMARC composite-pass algorithm requiring at-least-one DKIM-or-SPF aligned-pass. The per-publisher per- domain SPF publication discipline THIS page documents is therefore the envelope-MAIL-FROM- layer COMPOSITE PARTNER to the per-publisher per-domain DKIM application-layer authentication publication discipline at the per-publisher per- domain DMARC identifier-alignment composite- evaluation boundary.
BIMI Verified Mark Certificates (VMC and CMC)
MTA-STS for Google Workspace
MTA-STS for Microsoft 365
DMARC records explained
DMARC forensic (RUF) failure reports
DKIM replay attacks
Business email compromise (BEC) playbook — the PER-PUBLISHER-PER-DOMAIN-SPF- ENVELOPE-MAIL-FROM-LAYER-AUTHENTICATION-LEG- AS-LOAD-BEARING-FORENSIC-EVIDENCE-INPUT-TO- THE-BEC-INCIDENT-RESPONSE-WORKFLOW companion to this SPF protocol-mechanics reference. Where THIS page documents the per-publisher per-domain SPF protocol at the protocol- semantic level (RFC 7208 §1.1.3 envelope- MAIL-FROM-domain scope, §4.5 check_host() algorithm producing the pass/fail/softfail/ neutral/temperror/permerror/none result- vocabulary, §10.1 explicit non-coverage of the visible From: header), the BEC playbook is the FINANCE-TREASURY-FRAUD- TEAM operational-workflow reference whose per-message SPF-evaluator-side verdict- attribution this SPF primer documents the publication-discipline of IS ONE OF THE TWO per-message authentication-leg forensic data points the BEC investigator parses at FOUR per-publisher per-domain SPF-vs-BEC coupling dimensions: (i) per-message Received-SPF header envelope- MAIL-FROM-domain attribution as Stage 3 evidence-collection input — the per-message Received-SPF: pass / fail / softfail verdict header per RFC 7208 §9.1 identifies the SMTP envelope-return-path domain the connecting client claimed at MAIL FROM time, which is the SECOND MOST IMPORTANT BEC- forensic data point after the DKIM-Signature d= tag — a CEO-fraud message that produces Received-SPF: pass (envelope-from=attacker-controlled.example) rather than the impersonated victim's envelope-MAIL-FROM domain is immediate evidence that the message did NOT originate from the victim's authorised egress infrastructure, even though the visible From: header was rewritten to appear so; (ii) per-publisher per- domain SPF mechanism-vocabulary publication- decision (-all vs ~all) as BEC-defense readiness floor — per RFC 7208 §4.6.4, only -all hard-fail enforcement instructs the receiver to reject mail from unauthorised IPs at the SMTP envelope-MAIL- FROM layer; per-publisher per-domain SPF ~all soft-fail publication leaves the per-receiver per-message receiver-side disposition decision ambiguous, opening the per-attacker per- target-domain BEC envelope-MAIL-FROM spoofing attack-window the BEC playbook documents the per-organisation per-finance- team operational closure of; (iii) per-publisher per-domain SPF result-class drift (permerror from 10-DNS-lookup limit per RFC 7208 §4.6.4 + temperror from per-receiver DNS-resolver-timeout) as BEC-investigator per-receiver per-day per-source-IP diagnostic ladder — per- publisher per-domain SPF result-class drift surfaces in per-receiver per-day DMARC RUA policy_evaluated/spf attribution evidence-stream the BEC investigator parses in Stage 4 chronological-reconstruction to distinguish per-attacker per-target-domain impersonation-via-SPF-publication-drift from per-attacker per-target-domain impersonation- via-look-alike-domain-registration (the per-attacker per-domain SPF-passes-on-attacker- domain DMARC-bypass attack-class catalogued in help_dmarc_attacker_bypass.php); (iv) per-publisher per-domain SPF publication-discipline drift as load-bearing per-message authentication-leg forensic- evidence trigger feeding per-publisher per- domain DMARC RUF forensic-report emission per RFC 7489 §7.3 — per- publisher per-domain SPF-evaluator-side spf=fail verdict triggers per- message AFRF forensic-report emission under fo=1 publication-decision per RFC 7489 §6.3, which is the per-message forensic-evidence stream the BEC IR investigation consumes alongside per-day DMARC RUA aggregate-XML report attribution per RFC 7489 §7.2. Read the BEC playbook WITH this SPF primer when the finance / treasury / fraud team escalates a suspected BEC incident to the security operations team for per-message authentication-leg forensic-evidence reconstruction at the per-publisher per-domain envelope-MAIL-FROM- layer-and-BEC-incident-response coordination boundary the per-publisher per-domain SPF TXT-RR publication-discipline THIS page documents the envelope-MAIL-FROM-layer publication-discipline of and the BEC playbook spoke documents the finance- treasury-fraud-team incident-response workflow of.
DKIM explained (cryptographic message signing with a private key, the public key published in DNS, and receiver-side signature verification) — SPF and DKIM are the two authentication mechanisms DMARC evaluates: SPF authorizes the envelope sending IP, while DKIM cryptographically signs the message so an aligned pass survives forwarding that breaks SPF. Read the DKIM primer next — together with this SPF guide it covers both legs of the DMARC pass.
DKIM signatures explained — the byte-layout companion to the DKIM leg this SPF guide pairs with. Where SPF authorizes the envelope IP, the DKIM-Signature header carries the b=/bh=/d=/s= tag grammar that makes the message leg survive the forwarding that breaks SPF — read it to see exactly what a receiver verifies on the leg that complements this one.
DKIM for Microsoft 365 — the provider-specific companion that pairs the DKIM leg with the SPF leg this pillar documents on a Microsoft 365 tenant. Where THIS page covers SPF end-to-end, the DKIM-for-M365 spoke walks the selector1/selector2._domainkey CNAME-delegated key publication, the Admin Center DKIM-signing enablement step, and the <tenant>.onmicrosoft.com-vs-custom-domain signing-identity alignment gotcha. On an M365 tenant you publish BOTH legs — include:spf.protection.outlook.com here and the selector CNAMEs there — and a message needs at least one aligned-passing to survive a p=reject DMARC policy; read the DKIM-for-M365 spoke for the message- signature half of the M365 authentication pair.
DMARC alignment explained — an spf=pass on its own does not satisfy DMARC: the SPF-authenticated MAIL FROM domain must also align with the visible RFC5322.From domain (relaxed or strict). This spoke documents that alignment rule — the reason a passing SPF record this page configures only contributes to a DMARC pass when its identifier matches the From domain. Read it to see how the SPF leg this page covers feeds the DMARC composite verdict.
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.

13. Audit your SPF record now

DMARC Analyzer's free Domain Security Checker performs live SPF lookups, validates the syntax against RFC 7208, counts DNS lookups against the 10-lookup limit, and flags every common misconfiguration covered above. Imported aggregate reports also show every IP that actually attempted to send mail for your domain — the surest way to find shadow senders missing from your SPF record.

Check my SPF record Sign up — Free plan