DMARC Analyzer

TL;DR

The four SPF qualifiers (RFC 7208 section 4.6.2) determine the receivers result code when a mechanism matches. Each qualifier is a single-character prefix on a mechanism token:

• + (Pass) — default qualifier when none is specified. Produces spf=pass. Receiver treats the sender as authorised.
• - (Fail) — strong unauthorised signal. Produces spf=fail. Receiver may reject, discard, or quarantine per RFC 7208 §4.7. Use -all in production for any domain with a complete sender inventory.
• ~ (SoftFail) — weak unauthorised signal. Produces spf=softfail. Receiver should not reject solely on SoftFail. Use ~all only during initial deployment as a monitoring-mode placeholder.
• ? (Neutral) — no definitive statement. Produces spf=neutral, treated equivalent to no SPF record. Rarely the right choice; avoid ?all in production.

The qualifier almost always attaches to the terminal all mechanism — and -all is the canonical production answer. The default Pass qualifier (implicit when no prefix is written) is what makes ip4:198.51.100.42 identical to +ip4:198.51.100.42. The Domain Security Checker surfaces your records terminal qualifier and flags suboptimal choices like +all (authorises everything) or ?all (no enforcement value).

1. What SPF qualifiers are and where they appear

A qualifier in an SPF record is a single-character prefix that determines the result code the receiver returns when a sender matches the qualified mechanism. The four qualifiers defined in RFC 7208 section 4.6.2 are:

• + → Pass (the default; produces spf=pass)
• - → Fail (produces spf=fail)
• ~ → SoftFail (produces spf=softfail)
• ? → Neutral (produces spf=neutral)

The qualifier attaches to any mechanism token — ip4, ip6, a, mx, ptr, include, exists, or all. In practice the qualifier other than + is overwhelmingly used on the terminal all mechanism to express "what should the receiver do with anything not matched by an earlier mechanism." Per-mechanism qualifiers other than + are rare but legal: -include:ex-vendor.example is valid SPF that says "treat any match in the ex-vendors include subtree as Fail."

Why qualifiers matter: the qualifier is the policy signal SPF gives to the receiver. A sender that produces spf=fail tells the receiver "I know this is unauthorised — act on it." A sender that produces spf=softfail tells the receiver "I think this is unauthorised but do not act on this alone." A sender that produces spf=neutral tells the receiver "I have no opinion." DMARC consumes these results when determining alignment, so the qualifier choice indirectly affects DMARC enforcement.

Scope note: this page covers the four qualifiers in depth. The mechanism vocabulary (a, mx, include, ip4, ip6, ptr, exists, all) and the modifiers (redirect=, exp=) are covered in the comprehensive SPF mechanisms explained reference.

2. The four qualifiers at a glance

Side-by-side comparison of the four SPF qualifiers (RFC 7208 section 4.6.2). The result code is what the receiver returns in the Authentication-Results header when a sender matches the qualified mechanism.

3. The + (Pass) qualifier (RFC 7208 §4.6.2)

Definition: The plus qualifier (+) marks a mechanism as producing the Pass result code when the sender matches. Pass means the receiver should treat the sender as authorised by the domains SPF policy. Pass is the default qualifier when no prefix is specified on a mechanism.

Syntax: +<mechanism> or simply <mechanism> with no prefix (the two forms are byte-equivalent at the receiver). So +ip4:198.51.100.42 and ip4:198.51.100.42 produce identical behaviour; +include:_spf.google.com and include:_spf.google.com are identical. The terminal +all is legitimately distinct (and almost always a misconfiguration — see below).

Receiver behaviour: A sender that matches a +-qualified mechanism causes the receiver to record Received-SPF: pass and spf=pass in the Authentication-Results header (RFC 8601). The receiver treats the SPF check as successful. For DMARC purposes, Pass also enables the SPF half of DMARC alignment (the SPF-authenticated MAIL FROM domain is checked for alignment with the From: header domain per RFC 7489).

When to use: The implicit Pass qualifier applies to every explicitly listed mechanism in your SPF record — ip4:198.51.100.42, include:spf.protection.outlook.com, a:mail.example.com, mx. You do not need to write the + prefix; the default is Pass. The explicit + prefix is useful only when you want to be unambiguous in documentation or when a tool auto-generates SPF records and wants explicit qualifiers throughout.

When NOT to use: Do NOT use +all at the end of an SPF record — it authorises EVERY IP address on the internet to send mail as your domain. This is the most-warned-against SPF anti-pattern: it defeats SPF entirely, provides zero protection against spoofing, and effectively declares your domain open for impersonation. Always terminate the record with -all (strict enforcement, recommended) or ~all (monitoring mode, during deployment).

Common pitfalls: (1) Copy-pasting +all from an outdated tutorial — replace with -all immediately. (2) Treating the explicit + prefix as somehow different from the implicit default — they are byte-equivalent at the receiver. (3) Writing +ip4:0.0.0.0/0 "to authorise everything" — equivalent to +all and equally catastrophic. (4) Confusing per-mechanism + (harmless explicit-default) with terminal +all (catastrophic open-relay semantic).

4. The - (Fail) qualifier (RFC 7208 §4.6.2)

Definition: The minus qualifier (-) marks a mechanism as producing the Fail result code when the sender matches. Fail means the receiver should treat the sender as explicitly unauthorised by the domains SPF policy. RFC 7208 section 4.7 allows the receiver to reject at SMTP, discard, or quarantine, though the standard does not mandate any specific action.

Syntax: -<mechanism>. The two canonical usages: (a) -all at the end of the record (Fail anything not previously matched), and (b) per-mechanism -include:ex-vendor.example or -ip4:<range> to revoke a specific senders authorisation while keeping the rest of the record permissive.

Receiver behaviour: A sender that matches a --qualified mechanism causes the receiver to record Received-SPF: fail and spf=fail in the Authentication-Results header. Per RFC 7208 §4.7, the receiver MAY reject the SMTP transaction with a 550 5.7.1 response, MAY quarantine to a spam folder, or MAY deliver with the Fail result recorded for downstream filtering. Major receivers (Gmail, Microsoft 365, Yahoo, Apple iCloud) typically combine spf=fail with DMARC enforcement: if DMARC is p=reject and SPF fails, the message is rejected; if DMARC is p=none and SPF fails, the message is usually delivered with spf=fail recorded.

When to use: Use -all in production for any domain with a complete sender inventory. This is the canonical production answer and the recommended end-state of every SPF deployment. Also use per-mechanism - for: (a) revoking an ex-vendors authorisation while keeping their include subtree visible (-include:ex-vendor.example), (b) explicitly blocking a known-bad IP range while permitting the rest of a CIDR (-ip4:198.51.100.42 ip4:198.51.100.0/24 — note first-match-wins means the more specific Fail wins).

When NOT to use: Do NOT use -all until you have confirmed every legitimate sender is listed in the record — switching to -all with a missing sender will cause that senders mail to be rejected. Do NOT use -all if you have not enabled DMARC aggregate reporting (rua=) to surface unexpected rejections. Do NOT use -all on a domain whose sender inventory is volatile (frequent vendor adds/removes) — stay on ~all until inventory stabilises.

Common pitfalls: (1) Flipping to -all before completing sender discovery — breaks legitimate mail. (2) Combining -all with an incomplete include tree (the include resolves but lacks the actual sending IPs — every message Fails). (3) Forgetting that -all only affects senders NOT matched by an earlier mechanism; a stale +include:ex-vendor.example still authorises that vendors infrastructure regardless of the terminal -all. (4) Expecting -all alone to enforce rejection without DMARC — many receivers tolerate spf=fail unless DMARC also says reject. (5) Writing --all (typo) — the second minus is parsed as part of a malformed mechanism and the record is invalid.

5. The ~ (SoftFail) qualifier (RFC 7208 §4.6.2)

Definition: The tilde qualifier (~) marks a mechanism as producing the SoftFail result code when the sender matches. SoftFail means "the domain believes the sender is probably unauthorised but is not willing to make a strong policy statement." RFC 7208 section 4.6.2 explicitly defines SoftFail as a weaker signal than Fail; receivers should record the result but not reject solely on this signal.

Syntax: ~<mechanism>. The overwhelmingly common usage is ~all at the end of an SPF record. Per-mechanism SoftFail (~include:soon-to-be-removed.example or ~ip4:<deprecating-range>) is rare but legal — useful as a transition state when deprecating a sender without immediate hard-fail.

Receiver behaviour: A sender that matches a ~-qualified mechanism causes the receiver to record Received-SPF: softfail and spf=softfail in the Authentication-Results header. Most receivers (Gmail, Microsoft 365, Yahoo) treat SoftFail as a non-pass signal but do not reject solely on this result. The practical delivery effect is typically: the message is delivered (often to the inbox if other signals are good) with spf=softfail recorded. DMARC counts SoftFail as a non-pass for the SPF half of alignment, so DMARC enforcement may still fire if DMARC is at quarantine or reject.

When to use: Use ~all during the initial 30-90 day SPF deployment window when you are still discovering legitimate senders. The SoftFail signal lets DMARC aggregate reports surface unexpected senders without breaking their delivery while you complete the inventory. Once 30 consecutive days show zero unexplained SoftFails for legitimate sources, flip to -all for production enforcement. Per-mechanism ~ is useful during a sender deprecation: flag the soon-to-be-removed mechanism with ~ for two weeks, monitor for any remaining legitimate traffic, then remove.

When NOT to use: Do NOT use ~all indefinitely in production — it provides weak enforcement and signals to spoofers that your domain is not seriously protected. Do NOT use ~all as a permanent fixture on a domain at DMARC p=reject — the combination is incoherent (DMARC reject says "reject the message" but SPF SoftFail says "do not reject solely on this"; you want SPF Fail + DMARC reject for consistent semantics). Do NOT use ~all if your domain sends no mail (use v=spf1 -all instead, the null-sender canonical form).

Common pitfalls: (1) Leaving ~all in place indefinitely after initial deployment — the canonical SPF deployment ramp is ~all → -all over 30-90 days. (2) Expecting SoftFail to cause rejection at SMTP — most receivers deliver SoftFailed mail. (3) Pairing ~all with DMARC p=reject — incoherent policy signal; pair -all with DMARC p=reject instead. (4) Using ~all on a domain whose sender inventory is supposedly complete — flip to -all and let aggregate reports flag any missed senders. (5) Misreading the tilde as a no-op — SoftFail does affect DMARC alignment computation even if it does not affect SMTP-time delivery.

6. The ? (Neutral) qualifier (RFC 7208 §4.6.2)

Definition: The question-mark qualifier (?) marks a mechanism as producing the Neutral result code when the sender matches. Neutral means "the domain has explicitly declined to make a statement about this sender." RFC 7208 section 4.6.2 defines Neutral as equivalent to "no SPF record found" for the matching senders — the receiver should treat it the same as if SPF were not deployed at all.

Syntax: ?<mechanism>. The overwhelmingly rare canonical form is ?all at the end of an SPF record. Per-mechanism Neutral (?include:unverified.example) exists in the spec but has essentially no production use case — most operators reach for SoftFail or Fail instead.

Receiver behaviour: A sender that matches a ?-qualified mechanism causes the receiver to record Received-SPF: neutral and spf=neutral in the Authentication-Results header. The receiver treats the result as equivalent to no SPF record — the message is delivered, but SPF provides no positive or negative signal. DMARC counts Neutral as a non-pass for SPF alignment, so the DMARC verdict depends entirely on DKIM (which must pass and align for the message to pass DMARC).

When to use: Almost never. The canonical use case sometimes cited is a parent domain whose subdomains have their own SPF records and the parent itself sends no mail — but even there, the more correct answer is v=spf1 -all (explicit "no senders authorised, reject any direct send from the parent domain"). The Neutral qualifier exists in the spec for completeness and to give operators a way to publish a record that intentionally provides no enforcement signal — but in practice this is rarely the right answer.

When NOT to use: Do NOT use ?all as a "weak default" — if you want weak enforcement, use ~all instead (SoftFail at least signals non-pass; Neutral signals nothing). Do NOT use ?all on a domain that sends mail — it tells receivers nothing about your sending posture and weakens DMARC alignment. Do NOT use ?all as a placeholder during SPF deployment — use ~all with DMARC rua reporting instead.

Common pitfalls: (1) Treating ?all as equivalent to "I have not decided yet" — receivers cannot distinguish intentional Neutral from accidental Neutral, and you get zero protective value either way. (2) Confusing ?all with "the safe choice" — it is strictly weaker than ~all which is strictly weaker than -all; moving down the ladder removes protection. (3) Inheriting ?all from a copy-pasted template and never revisiting — audit your SPF records quarterly and replace any ?all with -all (or ~all if still in deployment monitoring). (4) Using ?all on a null-sender parking domain — use v=spf1 -all for the canonical "this domain does not send mail" semantic.

7. Receiver-side interpretation matrix

How major receivers actually treat each SPF result code in 2026, based on observable Authentication-Results headers, public documentation, and DMARC enforcement behaviour. Specific SMTP-time rejection behaviour depends on per-tenant policy and may vary.

Key takeaways:

1. Fail (-) is necessary but not sufficient for rejection. Most receivers only reject spf=fail when DMARC is also at p=quarantine or p=reject. SPF Fail alone usually results in delivery-to-spam, not rejection.
2. SoftFail (~) is almost always delivered. The qualifier signals "probably not legitimate" but receivers do not act on it alone. SoftFail mainly affects DMARC alignment (counts as non-pass) and downstream reputation scoring.
3. Neutral (?) provides no protective value. Receivers treat it equivalent to no SPF record; the only way to pass DMARC for a Neutral-qualified sender is via DKIM.
4. Pass (+) enables DMARC alignment. Without Pass on the connecting senders mechanism, DMARC must rely on DKIM to pass — a single point of failure if DKIM also fails (e.g. message forwarded and body modified).

8. Four worked deployment examples

8.1 Production: complete inventory with hard fail

Scenario: a company has audited every legitimate sender (Microsoft 365 for corporate mail, SendGrid for transactional, on-prem MTA at 198.51.100.42 for monitoring alerts) and is ready for strict enforcement.

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

Rationale: -all declares Fail for any sender not matched above. The complete sender inventory protects legitimate mail; spoofing attempts return spf=fail and (paired with DMARC p=reject) are rejected. This is the canonical production end-state for any DMARC-enforcement-bound domain.

8.2 Deployment monitoring: ~all with DMARC rua

Scenario: a company is rolling out SPF for the first time. They have published an initial sender list but want 60 days of aggregate reports to surface any missed senders before switching to strict enforcement.

example.com.  IN  TXT  "v=spf1 ip4:198.51.100.42 include:spf.protection.outlook.com include:sendgrid.net ~all"
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Rationale: ~all returns SoftFail for unmatched senders — they are still delivered (so legitimate-but-missed mail does not break) but the SoftFail result is logged in the receivers Authentication-Results header and surfaces in the DMARC aggregate reports. After 60 days of clean reports (no SoftFail for legitimate sources), flip ~all to -all and DMARC p=none to p=quarantine.

8.3 Null-sender domain (no mail expected)

Scenario: a parked domain or apex-only domain that sends no mail (e.g. example-brand.com whose only use is the marketing website — no transactional mail, no corporate mail, no automation alerts).

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

Rationale: -all with no preceding mechanisms declares "no IP is authorised to send mail as this domain." Any spoofing attempt returns spf=fail. Pair with DMARC p=reject for explicit rejection. Do NOT use v=spf1 ?all (Neutral, no enforcement) or v=spf1 ~all (SoftFail, weak enforcement) for a null-sender domain — the canonical answer is v=spf1 -all.

8.4 Vendor deprecation: per-mechanism SoftFail

Scenario: a company is migrating off SendGrid to Mailgun. They want SendGrid traffic to start SoftFailing immediately to surface any forgotten integrations, while keeping Mailgun fully authorised.

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

Rationale: the per-mechanism ~include:sendgrid.net returns SoftFail for any sender that matches the SendGrid include subtree — the message is still delivered but the spf=softfail result surfaces in DMARC aggregate reports. After two weeks of clean reports (no legitimate SendGrid traffic remaining), remove the ~include:sendgrid.net entirely; the terminal -all then Fails any remaining SendGrid traffic.

9. The seven most common qualifier-choice mistakes

1. Using +all in production. Authorises every IP on the internet to send mail as your domain; defeats SPF entirely. Almost always a copy-paste error from an outdated tutorial. Fix: replace with -all (recommended) or ~all if still in deployment monitoring.
2. Leaving ~all indefinitely after initial deployment. SoftFail is a deployment-monitoring state, not a production end-state. Spoofers learn that your domain is not under strict enforcement. Fix: after 30-90 days of clean aggregate reports, flip ~all to -all.
3. Using ?all for "soft enforcement". Neutral provides ZERO protective signal — receivers treat it equivalent to no SPF record. Strictly weaker than ~all for the same scenario. Fix: replace with ~all (during deployment) or -all (in production).
4. Omitting the terminal qualifier entirely. A record like v=spf1 ip4:198.51.100.42 with no terminal all clause has an implicit Neutral terminal per RFC 7208 — provides zero enforcement for unmatched senders. Fix: always end the record with an explicit qualified all token (-all, ~all, or rarely ?all).
5. Pairing ~all with DMARC p=reject. Incoherent policy: SPF says "do not reject solely on this" but DMARC says "reject the message." The DMARC reject still fires (DMARC is the controlling policy) but the qualifier mismatch suggests confused operator intent. Fix: use -all when DMARC is at quarantine or reject; reserve ~all for DMARC p=none.
6. Flipping to -all before completing sender inventory. Switching to hard fail with a missing legitimate sender causes that senders mail to be rejected — a production outage for the missed sender. Fix: stay on ~all until 30 consecutive days of aggregate reports show no unexplained SoftFails for legitimate sources, THEN flip.
7. Writing per-mechanism - on an include you do not control. A record like -include:partner.example attempts to revoke a partners include — but the partner can change their record at any time and the revoke may need re-targeting. Fix: simply remove the include:partner.example entirely; the terminal -all then Fails any partner-originated traffic by default.

10. FAQ

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

The minus-all (-all, Fail) qualifier tells the receiver that any sender not explicitly authorised in the SPF record should be treated as Fail — receivers may reject, discard, or quarantine the message per RFC 7208 section 4.7 guidance. The tilde-all (~all, SoftFail) qualifier tells the receiver that any unauthorised sender should be treated as SoftFail — the message is probably not legitimate, but receivers should not reject solely on this result. The practical difference: -all delivers strong enforcement (receivers act on the fail signal), ~all delivers monitoring-mode behaviour (the result is recorded but typically not acted upon at SMTP time). Use -all in production for any domain with a complete sender inventory. Use ~all only during initial deployment when you are still discovering legitimate senders and want to avoid blocking them by accident. Migrating from ~all to -all is the canonical SPF enforcement-ramp playbook.

What does +all mean in an SPF record?

The plus-all (+all, Pass) qualifier authorises EVERY IP address on the internet to send mail as the domain — it makes SPF unconditionally pass for any sender. This is almost always a misconfiguration: it defeats SPF entirely (every spam, phishing, and impersonation message gains SPF pass) and provides zero protection. The plus qualifier (+) is the default qualifier when none is specified, so +ip4:198.51.100.42 is identical to ip4:198.51.100.42. But +all means "authorise everything" which is never the operator intent. If you find +all in an SPF record, replace it with -all (strict enforcement, recommended) or ~all (soft enforcement, monitoring mode). Some sources confuse +all with the more reasonable +ip4:... or +include:... forms — only +all is dangerous; the plus prefix on a specific mechanism is just an explicit version of the default Pass qualifier.

When should I use SPF ?all instead of -all or ~all?

Almost never. The question-mark-all (?all, Neutral) qualifier makes no statement about senders not explicitly listed — the receiver treats the result as equivalent to no SPF record at all. This is sometimes recommended for a parent domain whose subdomains have their own SPF records and the parent itself sends no mail — but even there, the more correct answer is a v=spf1 -all record (explicit "no senders authorised"). The ?all qualifier is rarely the right choice because (1) it provides no protective signal, (2) it tells receivers nothing about your sending posture, and (3) it makes DMARC alignment harder to reason about. Use -all for production enforcement, ~all only during initial deployment monitoring, and ?all essentially never. The fourth qualifier (?) exists in the spec for completeness but has no canonical production use case.

What is SPF SoftFail and how do receivers treat it?

SPF SoftFail (~, tilde) is the result code receivers return when a sender matches a mechanism prefixed with ~ — typically ~all at the end of an SPF record. RFC 7208 section 4.6.2 defines SoftFail as "the domain believes the host is not authorised but is not willing to make a strong policy statement." Most receivers treat SoftFail as a soft signal: Gmail and Microsoft 365 record spf=softfail in the Authentication-Results header but typically do not reject or move to spam based on SoftFail alone (DMARC, content filtering, and reputation drive the final disposition). The practical effect: a SoftFailed message is usually delivered, but the result counters DMARC pass if DMARC is also failing (DMARC requires either SPF or DKIM to pass and align; SoftFail counts as a non-pass for DMARC purposes). Use ~all only during pre-enforcement monitoring; switch to -all once you have confirmed the legitimate sender inventory is complete.

Does the default SPF qualifier matter if I do not write it?

The default qualifier for ANY SPF mechanism with no explicit prefix is Pass (+). So v=spf1 ip4:198.51.100.42 include:_spf.google.com -all is exactly equivalent to v=spf1 +ip4:198.51.100.42 +include:_spf.google.com -all. The default Pass means a match on that mechanism produces spf=pass. The default does not extend to the terminal all mechanism: v=spf1 ip4:198.51.100.42 (with NO all clause) is a record that produces Pass for the listed IP and Neutral for everything else (per RFC 7208 the implicit terminal is Neutral, not Pass). Best practice is to ALWAYS terminate the record with an explicit qualified all clause (-all, ~all, or rarely ?all) so the records intent is unambiguous to the receiver.

Can I use SPF qualifiers on specific mechanisms instead of just all?

Yes. Any mechanism token in an SPF record can carry an explicit qualifier prefix (+, -, ~, or ?). So -include:ex-vendor.example is a valid mechanism that says "if the sender matches this include, treat the match as Fail" — useful for selectively flagging a sender that should never legitimately send mail as your domain. Similarly ~ip4:198.51.100.0/24 says "if the sender is in this range, treat it as SoftFail." In practice, per-mechanism qualifiers other than + are rare: most operators rely on the default Pass for explicitly listed mechanisms and use the qualifier only on the terminal all token. The two notable exceptions: (1) a -include:vendor.example to revoke authorisation for a known-bad provider whose include subtree might still authorise their IPs, and (2) ~ip4:... during traffic-shifting to mark IPs as soon-to-be-removed without immediate hard-fail. The DMARC Analyzer Domain Security Checker surfaces per-mechanism qualifier choices in its SPF analysis.

Is SPF -all required for DMARC enforcement?

No, SPF -all is not technically required for DMARC enforcement — DMARC operates on the aligned authentication result (either SPF or DKIM passing and aligning), not on the SPF qualifier specifically. However, -all is STRONGLY recommended for any domain at DMARC p=quarantine or p=reject. The reason: DMARC enforcement only takes effect when authentication fails or fails to align. If your SPF record is ~all (SoftFail), a spoofed message from an unauthorised IP returns spf=softfail (counted as non-pass for DMARC) — and DMARC reject still fires. The qualifier matters for non-DMARC-aware receivers and for SPF-only enforcement at the SMTP layer. Modern best practice is -all + DMARC p=reject — they reinforce each other and provide both pre-DMARC-evaluation (SPF rejection at SMTP) and post-DMARC-evaluation (DMARC reject) defence layers. Always pair -all with a complete sender inventory; -all with a missing legitimate sender breaks delivery.

Why do receivers sometimes ignore SPF Fail and deliver the message anyway?

Receivers may deliver an spf=fail message for several reasons that all stem from RFC 7208 section 4.7 explicitly NOT mandating rejection. The RFC says "the receiver MAY take Local Policy action on a Fail result" but does not require rejection. Common reasons receivers deliver despite Fail: (1) the receiver weights other signals (DKIM pass, sender reputation, content filtering, DMARC p=none) more heavily than raw SPF, (2) the message was forwarded and the receiver detects the forwarder pattern, (3) the receiver runs ARC-validation and trusts an upstream ARC chain, (4) the receiver applies different policies to different mailbox tenants (an enterprise customer with strict policy may reject; a consumer mailbox may deliver to spam folder), (5) DMARC is at p=none which overrides SPF Fail with a "monitor only" disposition. The qualifier (-all) is necessary but not sufficient for actual rejection — pair with DMARC p=reject for predictable behaviour.

How do I migrate from SPF ~all to -all safely?

The canonical SPF enforcement-ramp playbook: (1) Deploy v=spf1 ... ~all in production for 30-90 days with DMARC rua reporting enabled. (2) Review aggregate reports daily to identify any legitimate sender that returns spf=softfail — add it to the SPF record via include, ip4, or a as appropriate. (3) Verify the cumulative DNS-lookup cost stays under 10 (RFC 7208 section 4.6.4) as you add senders. (4) Once 30 consecutive days show ZERO unexplained softfails for legitimate sources, flip ~all to -all. (5) Monitor the next 30 days for new spf=fail entries in aggregate reports and add any missed senders. (6) For DMARC-enforcement-bound domains, also confirm DMARC alignment — SPF pass alone is not enough; the SPF-authenticated MAIL FROM domain must align with the From: header domain (relaxed alignment by default; see help_dmarc_alignment.php). The DMARC Analyzer rolling SPF + DMARC dashboard surfaces softfail-to-fail trend lines for exactly this migration.

11. Related guides

• SPF explained — Sender Policy Framework (RFC 7208). The pillar page covering SPF end-to-end: the protocol overview, the seven result codes, alignment, deployment workflow. Read first if you are new to SPF.
• SPF mechanisms explained — the COMPLETE 8-mechanism reference (a, mx, ptr, ip4, ip6, exists, include, all) + 4 qualifiers + 2 modifiers. The comprehensive vocabulary deep dive that complements THIS per-qualifier deep dive.
• SPF DNS record syntax explained — the DNS-record-level SYNTAX reference (RFC 7208 section 3): the v=spf1 prefix, the TXT record type, the 255-octet character-string limit, the single-record rule, and per-subdomain publication. The syntactic layer that hosts the qualifier tokens this page documents semantically.
• include vs ip4 vs a vs mx — focused decision-view spoke for the four IP-providing mechanisms operators routinely pick between (RFC 7208 section 5).
• SPF lookup limit explained — the RFC 7208 §4.6.4 10-DNS-lookup cap, the cumulative cost accounting, and the SPF flattening playbook.
• SPF permerror vs temperror — the focused diagnostic deep dive on the two error result codes. Both are non-pass for DMARC; both have specific qualifier-independent causes.
• SPF forwarding issues — the SRS / ARC / MUNGE / .forward catalogue. Qualifier choice does not fix forwarder failures — that requires ARC validation.
• SPF for Microsoft 365 — the Microsoft-365-specific deployment guide. Always pair the Microsoft 365 include with -all in production.
• SPF for Google Workspace — the Google-Workspace-specific deployment guide. Same -all production rule applies.
• Why SPF alone is insufficient — the four structural limitations of SPF that motivate the DMARC + DKIM + ARC additions. Qualifier choice is necessary but not sufficient for spoofing protection.
• DKIM explained — the cryptographic-signing companion to SPF. Modern best practice publishes BOTH SPF (with -all) and DKIM.
• DMARC alignment explained — the identifier-alignment deep dive (strict vs relaxed for both adkim and aspf). SPF alignment depends on the SPF-authenticated MAIL FROM domain matching the From: header domain — the qualifier determines pass/fail.
• DMARC policy modes — the p=none / p=quarantine / p=reject ladder. Pair SPF -all with DMARC p=reject for the strongest enforcement combination.
• DMARC record tags explained — the DMARC tag-by-tag reference. SPF and DKIM are the two underlying authentication mechanisms DMARC consumes.
• Email authentication ecosystem — the cluster-intro pillar surveying SPF + DKIM + DMARC + BIMI + MTA-STS + TLS-RPT + CAA + ARC interlocking.
• Email authentication glossary — the term-of-art reference covering qualifier, mechanism, modifier, Pass, Fail, SoftFail, Neutral, and every other vocabulary item this page uses.
• Email security & privacy glossary — the SPF-QUALIFIER-CHOICE-RESOLVES-BACK- TO-SECURITY-AND-PRIVACY-VOCABULARY- DEFINITIONS companion to this SPF qualifier protocol-mechanic reference. Where THIS page documents the four SPF qualifier prefixes at the protocol-mechanic level (RFC 7208 §4.6.2 / §4.6.4: + = Pass, - = Fail, ~ = SoftFail, ? = Neutral; the first-match qualifier emission at the terminal -all/~all/ ?all/+all tail choice; the receiver-side decision tree per qualifier outcome), the email-security- and-privacy-glossary spoke is the THREAT- AND-DEFENSE-VOCABULARY companion (distinct from the email-authentication-glossary's protocol-mechanic-vocabulary role at line 1117 of this page) documenting the canonical single-sentence definitions for FOUR security-and-privacy terms-of-art whose OPERATIONAL-MEANING the SPF qualifier-choice mechanism THIS page documents directly engages with: (i) open-relay threat-class — the glossary's canonical definition of open-relay as the unrestricted-authorisation permitting any sender IP to claim the envelope-MAIL-FROM domain authority is what the +all tail qualifier on THIS page is the canonical SPF- publication mistake creating: any IP passes SPF, granting universal envelope-domain authorisation to attackers; (ii) authorization- bypass threat-class — the glossary's canonical definition of authorization-bypass as the unintended- SPF-pass-equivalence-for-unenumerated- senders is what the ?all Neutral terminal qualifier on THIS page opens: Neutral verdicts MUST be treated as if no SPF policy were published per RFC 7208 §2.6.2, leaving the receiver to fall back to OTHER signals (reputation, DKIM, DMARC) that may themselves be attacker-favourable; (iii) graduated-enforcement- discipline — the glossary's canonical definition of graduated- enforcement as the staged-progression- from-monitoring-to-enforcement-discipline per the canonical DMARC rollout sequence is what the ~all SoftFail terminal qualifier on THIS page encodes: SoftFail signals "should-have-passed- SPF-but-did-not" without forcing receiver-side rejection, allowing publisher-side observability via RUA aggregate reports before tightening to Fail; (iv) reject-at-SMTP-time discipline — the glossary's canonical definition of reject-at-SMTP- time-discipline as the production- ready-policy-posture-rejecting- unauthorised-mail-at-the-SMTP-banner- rather-than-accepting-and-quarantining is what the -all Fail terminal qualifier on THIS page combined with DMARC p=reject produces: receivers MAY reject at SMTP- time per RFC 7208 §8.4, achieving the canonical production-ready SPF posture. Read the email-security-and-privacy- glossary spoke alongside this SPF qualifier reference when designing the SPF-rollout-staging documentation that must correlate per-qualifier-choice on the publisher-side record authoring with the per-threat-class defense coverage at the receiver-side envelope-MAIL-FROM evaluation — the glossary is the canonical security- and-privacy-vocabulary substrate; THIS page is the canonical SPF-qualifier protocol-mechanic reference whose terminal-qualifier choice determines the per-threat-class defense profile the glossary's vocabulary catalogues.
• Phishing protection — the SPF-TERMINAL-QUALIFIER-CHOICE- AS-PHISHING-REJECTION-STRICTNESS-KNOB companion to this SPF qualifier protocol-mechanic reference. Where THIS page documents the four SPF qualifier prefixes at the protocol-mechanic level (RFC 7208 §4.6.2 / §4.6.4: + = Pass, - = Fail, ~ = SoftFail, ? = Neutral), the phishing-protection spoke is the DEFENSE-PROGRAM-EFFECTIVENESS-MEASUREMENT companion documenting how each terminal- qualifier choice directly calibrates the publisher's phishing-defense posture across four per-qualifier defense- effectiveness dimensions: (i) +all = unconditional phishing-traffic acceptance posture — the canonical publication-mistake creating an open- relay-equivalent posture where every attacker-controlled IP passes SPF and the application-layer DMARC stack must rely solely on DKIM-alignment to distinguish legitimate-publisher mail from attacker phishing-traffic; the phishing-protection spoke documents the per-domain emergency-remediation playbook for the +all misconfiguration-discovery scenario; (ii) ?all Neutral = attacker-favourable receiver-side fallback posture — Neutral verdicts trigger receiver-side fallback to reputation + DKIM + ad-hoc filters, many of which are attacker-tunable in phishing campaigns (freshly-registered domain reputation, missing-DKIM- signature fallback to SPF-Neutral, attacker-controlled ad-hoc-filter- bypass via display-name spoofing); the spoke documents how the ?all Neutral terminal- qualifier is the canonical signal of a publisher who has not committed to phishing-defense and the per-domain migration playbook to advance to ~all / -all; (iii) ~all SoftFail = graduated-enforcement- observability staging posture — the canonical staging-posture for a publisher in the DMARC enforcement- ramp who needs receiver-side observability of unauthorised-sender traffic via aggregate-report rua streams without immediate rejection; the phishing-protection spoke documents how the ~all SoftFail posture turns the publisher's aggregate-report stream into the empirical sender-inventory evidence layer the publisher uses to discover legitimate-but-unenumerated senders BEFORE tightening to -all production posture; (iv) -all Fail = production-grade reject-at-SMTP-time phishing-defense posture — the canonical production-grade publisher-side posture rejecting unauthorised-sender phishing-traffic at SMTP-banner-time per RFC 7208 §8.4; the spoke documents how -all combined with DMARC p=reject pct=100 produces the SUPERSET phishing-defense posture rejecting direct-domain-spoof attacks BEFORE the message reaches the receiver-side application-layer evaluation engine. Read the phishing-protection spoke alongside this SPF-qualifier reference when designing the publisher's SPF- enforcement-ramp roadmap that progressively tightens the terminal qualifier from staging (~all) through production (-all) to achieve the per-domain phishing- defense-effectiveness target the spoke catalogues — the spoke is the canonical per-qualifier defense- effectiveness companion documenting the operational meaning of each qualifier choice for the publisher's phishing-defense program.
• How attackers bypass weak DMARC — the SOFTFAIL-QUALIFIER-AS-CANONICAL- ATTACKER-BYPASS-VECTOR-AT-FOUR-SPF- TERMINAL-QUALIFIER-CHOICE-VS-22- TECHNIQUE-BYPASS-CATALOGUE-COVERAGE- DIMENSIONS companion to this SPF qualifier-grammar reference. Where THIS page documents the four RFC 7208 §4.6.2 qualifier prefixes (+/-/~/?) producing Pass / Fail / SoftFail / Neutral result classes (and the four canonical terminal-qualifier choices +all / -all / ~all / ?all the publisher selects to define the SPF-record catch-all policy), the attacker-bypass spoke is the OFFENSIVE-PERSPECTIVE 22- TECHNIQUE-CATALOGUE companion documenting which per-terminal- qualifier publication discipline closes vs leaves open the SPF-leg attacker- bypass surface. Concretely, the spoke documents FOUR SPF-terminal-qualifier- choice vs 22-technique-bypass-catalogue coverage dimensions: (i) ~all-softfail-as- canonical-bypass-surface for the receiver-side "MAY accept" semantic of RFC 7208 §4.6.4 — the attacker-bypass spoke documents how the ~all qualifier's receiver-side semantic (the receiver MAY accept the message even though it falls outside the publisher's mechanism-matched set) is the canonical SPF-leg-bypass surface the attacker exploits when the protected domain publishes ~all instead of -all — the attacker-bypass spoke names this as authentication-evasion-class technique #7 (softfail-bypass via receiver-side permissive interpretation) and provides the SOC analyst with the canonical -all-production-grade publication mitigation pathway; (ii) ?all-neutral and +all-pass as catastrophic publication-discipline failures producing universal SPF-leg-bypass coverage — the attacker-bypass spoke documents how the ?all-neutral semantic (no receiver-side authentication signal) and +all-pass semantic (every connecting IP authorised) each produce universal SPF-leg-bypass — the attacker-bypass spoke names this as authentication-evasion-class technique #6 (catch-all-pass open-relay publication discipline) and provides the SOC analyst with the canonical registrar-publication-audit mitigation pathway; (iii) per-mechanism qualifier prefix discipline as per-include-cascade trust-delegation- scope-bound bypass-surface — the attacker-bypass spoke documents how a publisher who publishes +include:<third-party-ESP-pool> without per-ESP IP-pool audit cryptographically extends the SPF-pass verdict to every co-tenant in the ESP- pool — the attacker-bypass spoke names this as alignment-evasion-class technique #5 (shared-IP-pool co-tenant SPF-pass extension) and provides the SOC analyst with the canonical per- include-cascade-trust-boundary publication-audit mitigation pathway; (iv) -all-fail terminal-qualifier as load-bearing publication-discipline closing all SPF-leg-bypass surfaces classified by the catalogue — the attacker- bypass spoke documents how the -all-fail terminal- qualifier semantic (the receiver MUST reject the message as unauthorised) is the only terminal-qualifier choice closing the SPF-leg attacker-bypass surface at the receiver-side reject- at-SMTP-time discipline — the attacker- bypass spoke names this as the canonical publisher-side defense publication discipline against authentication-evasion-class techniques #6 and #7. Read the attacker-bypass spoke ALONGSIDE this SPF qualifier- grammar reference to understand which per-terminal-qualifier publication choice the publisher makes structurally defeats vs structurally leaves open as a residual attacker-bypass vector — the spoke is the AUTHORITATIVE offensive- perspective catalogue the per-qualifier publication discipline THIS page documents is the publisher-side defense against.
• DMARC myths and misconceptions
• DMARC for shared hosting — the per-shared-hosting-tenant per-custom- domain DMARC-DEPLOYMENT-TUTORIAL companion to this RFC 7208 per-publisher per-domain SPF qualifier byte-grammar reference. Where THIS page documents the per-publisher per- domain SPF qualifier byte-grammar — the per-mechanism qualifier prefix (+ pass, - fail, ~ softfail, ? neutral per RFC 7208 §4.6.2), the per- record terminal qualifier (-all hard-fail vs ~all soft-fail vs ?all neutral vs +all publisher-side-anti- pattern), the per-mechanism qualifier precedence rule (first-match wins per RFC 7208 §4.7), and the per-publisher per- domain -all-as-DMARC-prerequisite deployment discipline — the DMARC-for- shared-hosting spoke documents the structurally-paired per-shared-hosting- tenant per-custom-domain DMARC deployment tutorial whose per-publisher per-domain SPF qualifier publication discipline THIS page documents is the load-bearing per- publisher per-domain SPF-leg pre-condition for DMARC-alignment-pass at p=quarantine / p=reject tiers. The composition operates through three per- shared-hosting-tenant per-custom-domain SPF-qualifier-and-DMARC-ramp dependencies the per-publisher per-domain DMARC deployment tutorial materially relies on: (i) per-shared-hosting-tenant per-custom- domain SPF record terminal qualifier (-all vs ~all vs ?all) determines per-receiver per-message SPF-verdict outcome (fail vs softfail vs neutral), which determines whether the per-shared-hosting- tenant per-custom-domain DMARC-alignment- pass evaluation has a SPF-leg-pass to compose with DKIM-leg-pass; (ii) per- shared-hosting-tenant per-custom-domain SPF mechanism qualifier prefix (+include: per-SaaS-relay cone authorisation vs -mx / -ip4: per-non-mx-host explicit-exclusion) determines whether the per-shared-hosting-tenant per-custom- domain operator's SaaS-relay CNAME- delegated DKIM escape hatch (the spoke's load-bearing operator-empowerment-ceiling escape pattern) actually composes with the per-publisher per-domain SPF cone- authorisation surface; (iii) per-shared- hosting-tenant per-custom-domain SPF terminal qualifier transition cadence (~all → -all post-DMARC-p=reject ramp- completion) is the per-publisher per- domain hardening-discipline lock-step the DMARC-deployment-tutorial THIS page's qualifier byte-grammar reference documents prescribes as the per-publisher per-domain authentication-record- publication maturity signal. Read THIS page when AUTHORING the per-publisher per-domain SPF qualifier byte-grammar publication discipline; read the DMARC- for-shared-hosting spoke when AUTHORING the per-shared-hosting-tenant per-custom- domain DMARC deployment tutorial as the per-publisher per-custom-domain downstream consumer whose per-publisher per-domain DMARC-alignment-pass evaluation materially depends on the SPF-qualifier publication discipline THIS page documents as the load-bearing per- publisher per-domain SPF-leg pre- condition.
• DKIM alignment with DMARC — the DKIM-leg-alignment-verdict protocol-mechanic deep-dive (RFC 6376 d=-tag identifier alignment with the RFC 5322 From: header organisational domain, the relaxed vs strict adkim= mode toggle, the per- signer per-selector DKIM-aligned-pass composition rule when multiple DKIM signatures are present) whose per-message verdict the SPF-qualifier-choice THIS page documents COMPOSES with at the DMARC receiver-side decision boundary. The composition produces FOUR per-leg-outcome composition dimensions the SPF-qualifier publisher must reason about jointly with the DKIM-alignment publisher: (i) SPF-aligned-pass + DKIM-aligned-pass composite-pass — the canonical -all-and-aligned-DKIM publisher posture; both legs pass and the DMARC verdict is pass regardless of which leg fired; (ii) SPF-aligned-fail + DKIM-aligned-pass fallback-pass — the canonical ARC-or-forwarder-rewrite scenario where the SPF leg fails (envelope-MAIL-FROM misaligned via SRS) but the DKIM signature survives intact; DMARC passes on the DKIM leg alone, which is why the SPF ~all-softfail terminal-qualifier choice is acceptable ONLY for publishers who have ALSO deployed aligned DKIM as the load- bearing fallback; (iii) SPF-aligned-pass + DKIM-aligned-fail fallback-pass — the canonical forward-only-no-rewrite scenario where the SPF leg passes (envelope unchanged) but the DKIM signature breaks (subject re-write, body modification, encoding round- trip); DMARC passes on the SPF leg alone, which is why the SPF -all-hard-fail terminal- qualifier choice is the publisher's load-bearing DKIM-fragility insurance; (iv) SPF-aligned-fail + DKIM-aligned- fail composite-fail — the canonical attacker-spoofing or catastrophically-broken-forwarder scenario; DMARC verdict is the published p=-tag policy (none / quarantine / reject), which is why publishers MUST ramp through p=none RUA-aggregate- observability before tightening to p=quarantine / p=reject regardless of which terminal qualifier they publish. Read the DKIM-alignment- with-DMARC spoke ALONGSIDE this SPF qualifier reference when designing the joint SPF-qualifier-publication- and-DKIM-alignment-publication discipline that the publisher's DMARC composite-verdict at the receiver materially depends on.
• Domain Security Checker — verifies your SPF record (terminal qualifier, mechanism count, cumulative DNS-lookup cost, alignment with DMARC) plus the full SPF / DKIM / DMARC / BIMI / MTA-STS / TLS-RPT / CAA stack.
• DNS Record Generator — the SPF record-generator wizard (Enterprise plan). Interactive qualifier selection that defaults to -all for production records.
• DMARC monitoring — the SPF-QUALIFIER-CHOICE-AS-UPSTREAM- DETERMINANT-OF-MONITORING-KPI-DISTRIBUTION companion to this SPF qualifier byte-shape reference. Where THIS page documents the four canonical RFC 7208 §4.6.2 mechanism- prefix qualifier bytes (+ pass / - hardfail / ~ softfail / ? neutral) the publisher prepends to every SPF mechanism token in the v=spf1 TXT-record this page architects, the DMARC-monitoring spoke documents the per- publisher per-domain KPI dashboard whose per-day per-receiver per-source-IP SPF- aligned-pass-rate distribution is DIRECTLY SHAPED by which qualifier byte the publisher chose for the all mechanism (and per- mechanism overrides) at the trailing edge of the v=spf1 record. The SPF-QUALIFIER-CHOICE-VS-DMARC-MONITORING- KPI-DASHBOARD cross-reference establishes FOUR coupling dimensions: (i) per- publisher per-domain -all-vs- ~all-vs-?all terminal-qualifier choice as upstream determinant of per-source-IP SPF=fail-vs- softfail-vs-neutral distribution in the monitoring KPI dashboard — the per-publisher per-domain terminal- qualifier choice this page documents (-all hardfail vs ~all softfail vs ?all neutral) is the upstream publisher-side authorization- boundary verdict-modifier whose downstream per-receiver evaluator output partitions the monitoring spoke's per-day per-source- IP per-disposition aggregate-row cohort into SPF=fail (hardfail terminal, receiver may apply DMARC-policy-driven reject/quarantine) vs SPF=softfail (softfail terminal, receiver typically accepts but flags) vs SPF=neutral (no-verdict terminal, receiver applies no SPF-driven penalty) per-source-IP cohort distribution; the monitoring KPI dashboard's per-source-IP SPF-result-axis distribution this page's qualifier-choice directly determines; (ii) per- publisher per-domain -all-hardfail terminal choice as upstream prerequisite for the monitoring KPI dashboard's per-source-IP DMARC-disposition reject-rate-on-SPF-fail KPI trajectory — the per- publisher per-domain terminal-qualifier choice of -all this page documents as the canonical production choice produces per-receiver spf=fail verdicts at unauthorized-source-IP cohorts that the per-receiver DMARC evaluator THEN translates into per-source-IP dmarc=fail rows feeding the monitoring spoke's per-day per- source-IP DMARC-policy-disposition-rate KPI; per-source-IP reject-disposition spikes at unauthorized cohorts in the monitoring dashboard are the canonical downstream signal of -all- hardfail terminal-qualifier publisher- side authorization-boundary enforcement; (iii) per-publisher per-domain per-mechanism non-terminal qualifier choice as upstream determinant of per- source-IP per-mechanism-class verdict- cohort partitioning in the monitoring KPI dashboard — the per- publisher per-domain per-mechanism non-terminal qualifier choice this page documents (e.g. ~include:legacy-provider.example softfail-on-fail vs ?include:partner.example neutral-on-fail vs +include:trusted.example explicit-pass) is the per-mechanism publisher-side authorization-verdict- modifier whose downstream per-receiver evaluator output partitions the monitoring spoke's per-source-IP per-mechanism-class verdict cohort (per-receiver per-day per-source-IP aggregate-row attributable to a specific legacy-provider include vs trusted- partner include); the monitoring spoke's per-mechanism-cohort attribution depends on the per-mechanism qualifier-choice this page's authoring discipline produces; (iv) per-publisher per-domain qualifier-byte authoring- discipline drift as upstream regression- signal feeding the monitoring KPI dashboard's per-day-bucket SPF-result- axis distribution-drift alert — the per-publisher per-domain qualifier- byte authoring-discipline this page documents (the discipline of choosing -all terminal at production, the discipline of NOT using ?all in production, the discipline of choosing per-mechanism non-terminal qualifiers consistent with the publisher's authorization-boundary intent) is the upstream publisher-side SPF-record-state whose drift (e.g. a regression from -all to ~all during a per-mechanism edit) manifests as a per-source-IP SPF-result-axis distribution-shift in the per-day-bucket aggregate-cohort the monitoring spoke ingests; the monitoring spoke's per-day-bucket SPF-result-axis- distribution-drift alert is the canonical downstream signal of upstream qualifier- byte authoring-discipline drift this page documents the canonical-discipline- reference for. Read the DMARC-monitoring spoke alongside this SPF qualifier-byte reference when operating per-publisher per-domain SPF authorization-boundary observability through the per-day per- source-IP per-disposition KPI dashboard.
• Email spoofing techniques and defenses — the SEVEN-TECHNIQUE-SPOOFING-ATTACK- CATALOGUE companion to this SPF qualifier-prefix-byte reference. Where THIS page documents the four SPF qualifier-prefix bytes at the protocol-mechanic level (RFC 7208 §4.6.2 / §4.6.4: + = Pass, - = Fail, ~ = SoftFail, ? = Neutral) plus the terminal -all / ~all / ?all / +all publication commitment, the email-spoofing spoke documents the seven-technique attack catalogue whose source-IP-forgery and direct-domain From: forgery variants the per-publisher terminal qualifier choice THIS page documents structurally gates at four SPF-qualifier-as-anti- spoofing coupling dimensions: (i) -all hardfail terminal qualifier produces the receiver-side hardfail verdict on every spoofing-attempt from an unauthorized source-IP that the email-spoofing catalogue defense section calls out as the canonical publisher discipline for production domains — attackers attempting the direct-domain spoofing technique (technique #1 in the catalogue) from any source-IP outside the per- publisher SPF-authorized set produce spf=fail, feeding downstream DMARC p=reject disposition at the receiver-side composite-verdict boundary; (ii) ~all softfail terminal qualifier opens the per- receiver-policy soft-disposition window the email-spoofing catalogue documents as the staging-mode publication discipline — publishers in p=none monitoring stage commonly pair ~all with the staging ramp so receivers softfail spoofing attempts without rejecting at SMTP time, producing the per-source-IP evidence the email-spoofing catalogue threat-modelling section consumes during the pre-enforcement observability window; (iii) ?all neutral and +all permit-all terminal qualifiers structurally OPEN the per-publisher domain to direct- domain spoofing the email-spoofing catalogue catalogues as the canonical authoring-discipline regression class — the catalogue defense-in-depth recommendations section explicitly flags +all publication as effectively authorizing ALL source-IPs to spoof the per- publisher domain at the SPF- evaluation boundary, materially eliminating the SPF defense layer against the direct-domain spoofing technique class; (iv) per- mechanism non-terminal qualifier choice partitions the per-source-IP spoofing-attempt verdict cohort the email-spoofing catalogue per- technique attribution discipline consumes — operators publishing per-include:< esp-pool> non-terminal qualifier overrides (e.g., ?include:<legacy-pool> to neutralize a mistrusted delegate) produce per-source-IP verdict partitioning the email- spoofing catalogue forensic- analysis section consumes when attributing spoofing attempts to specific per-publisher per- delegate trust boundaries. Read the email-spoofing catalogue alongside this SPF qualifier-byte reference when translating the per- publisher per-domain terminal- qualifier-byte authoring discipline this page documents into the per- attack-technique anti-spoofing defense surface mapping the operator threat-model and incident-response program requires.
• TLS-RPT record syntax explained — the RFC 8460 §3 _smtp._tls.<domain> TXT-record byte-grammar reference covering the v=TLSRPTv1 required version-token prefix, the rua=mailto: and rua=https:// reporting-endpoint token publication, and the per-publisher per-domain transport-layer reporting-channel publication discipline. THIS page documents the SPF terminal-qualifier byte-grammar (the + / - / ~ / ? RFC 7208 §4.6.2 receiver-side decision-tree prefix tokens authored at the per-publisher per-domain SPF apex publication boundary as TXT-record byte-grammar terminal-disposition tokens governing the envelope-MAIL-FROM authorization-perimeter receiver-side rejection-vs-accept disposition); the TLS-RPT-record-syntax spoke is the cross-protocol DNS-RR byte-grammar publication peer documenting the transport-layer observability TXT-record byte-grammar token catalogue (v=TLSRPTv1; rua=mailto: terminal-mailbox-endpoint tokens, the rua=https:// JSON-POST-endpoint token, the per-token ; delimiter discipline at the RFC 8460 §3 record-grammar level) — both the SPF-qualifier-byte terminal-disposition-token publication and the TLS-RPT-record byte-grammar publication share the per-publisher per-domain TXT-record publication substrate, the per-publisher per-domain RFC-published byte-grammar authoring discipline, and the per-publisher per-domain zone-editor commit cadence — the SPF qualifier-byte AUTHORS the per-publisher per-domain envelope-MAIL-FROM receiver-disposition perimeter and the TLS-RPT-record byte-grammar AUTHORS the per-publisher per-domain transport-layer observability reporting-channel-endpoint registration at the same TXT-record DNS publication substrate. Read the TLS-RPT-record-syntax spoke alongside this SPF-qualifier-byte reference when authoring the per-publisher per-domain DNS-zone-file commit batch that includes BOTH the SPF terminal-qualifier (-all in production) AND the TLS-RPT record (v=TLSRPTv1; rua=mailto:tlsrpt@<d>) as the unified per-publisher per-domain envelope-layer-authorization + transport-layer -observability dual-RR publication discipline.
• DMARC for transactional email — the PER-TRANSACTIONAL-ESP-INCLUDE-CASCADE companion to this SPF-qualifier reference. Where THIS page documents the four RFC 7208 §4.6.2 terminal-disposition prefix tokens (+all / -all / ~all / ?all) at the per-publisher per-domain SPF apex, the transactional- email spoke documents the per-ESP include:-token catalogue (SendGrid's include:sendgrid.net, Mailgun's include:mailgun.org, Postmark's include:spf.mtasv.net, Amazon SES's include:amazonses.com, SparkPost's include:sparkpostmail.com, Mailjet's include:spf.mailjet.com, Mandrill's include:spf.mandrillapp.com, Resend's include:_spf.resend.com) whose per-tenant per-customer-domain publication is the upstream authorization-mechanism-list that the terminal qualifier disposition-tokens gate at four ESP-cascade-vs-qualifier coupling dimensions: (i) per-ESP include-cascade lookup-cost accounting against the RFC 7208 §4.6.4 10-DNS- lookup ceiling that determines whether the -all-terminal-qualifier can be reached without permerror; (ii) per-ESP include-cascade provisional staging via ~all-softfail during the per-ESP onboarding window before per-ESP-aligned-pass-rate baseline confirms safe -all cutover; (iii) per-ESP per-tenant retire-discipline coordination at terminal-qualifier-cutover-time — the include:-token for a retired ESP must be removed in the same DNS-zone commit batch as the per-publisher -all-cutover; (iv) per-tenant per-customer-domain commercial-honesty caveat — the per-ESP include:-token publication grants the ESP per-tenant authorization to send as the customer-domain envelope identifier, but does NOT grant per-tenant per-customer-domain DKIM-alignment — both legs must independently pass before the per-message DMARC verdict resolves to dmarc=pass under the published terminal-qualifier discipline. Read the transactional- email spoke alongside this SPF- qualifier reference when authoring the per-customer-domain SPF record that incorporates one or more transactional-ESP include:-tokens, when retiring an ESP and removing its include:-token, or when diagnosing spf=permerror aggregate-row clusters tied to per-ESP-cascade overflow before the terminal-qualifier disposition- token THIS page documents can evaluate at the receiver.
• DMARC for Google Workspace — the GOOGLE-WORKSPACE-TENANT-PER-CUSTOM- DOMAIN-SPF-INCLUDE-_SPF.GOOGLE.COM-CASCADE- AS-CANONICAL-PER-TENANT-SPF-QUALIFIER- CONSUMER companion to this SPF qualifier reference. Where THIS page documents the four SPF qualifier semantics (+ pass / - fail / ~ softfail / ? neutral per RFC 7208 §4.6.2), the per-mechanism-prefix qualifier- evaluation algorithm, the terminal- qualifier -all vs ~all selection discipline, and the per-publisher per-domain qualifier- choice strategy for SPF-aligned-pass-rate floor preservation, the Workspace-tenant spoke documents the per-Workspace-tenant per-custom-domain SPF deployment topology where the per-tenant SPF record canonically publishes v=spf1 include:_spf.google.com ~all — the per-Workspace-tenant qualifier selection THIS page's qualifier-evaluation reference decodes. The per-Workspace- tenant per-custom-domain SPF terminal- qualifier choice IS the per-tenant per- custom-domain canonical consumer of the SPF qualifier-discipline floor THIS page architectures at four Workspace-tenant- SPF-deployment-vs-SPF-qualifier-discipline coupling dimensions: (i) per-Workspace- tenant terminal-qualifier ~all vs -all selection as Workspace-tenant DMARC-ramp- cadence-aligned discipline — the per- Workspace-tenant per-custom-domain ~all default published during the p=none monitoring-window coordinates with the Workspace-tenant DMARC-ramp cadence to -all at the p=reject commitment boundary the qualifier-discipline reference THIS page documents; (ii) per-Workspace- tenant include:_spf.google.com cascade as canonical per-tenant per- custom-domain SPF-authorisation-chain — the Workspace-tenant per-custom-domain SPF record's include:_spf.google.com mechanism delegates per-tenant per-source- IP authorisation to Google's managed per- tenant per-custom-domain SPF cascade (which transitively includes Google's per-tenant per-source-IP authorisation sub-cascades), so the per-Workspace-tenant per-source-IP authorisation surface IS managed by Google's per-tenant per-custom- domain SPF infrastructure the per-tenant operator delegates control to via the include: mechanism; (iii) per- Workspace-tenant per-custom-domain SPF 10-DNS-lookup budget audit discipline as Workspace-tenant DMARC-aligned-pass-rate floor preservation — the per-Workspace- tenant per-custom-domain SPF record-audit discipline against the RFC 7208 §4.6.4 10-DNS-lookup ceiling preserves the per- Workspace-tenant per-custom-domain SPF- aligned-pass-rate floor the per-Workspace- tenant per-custom-domain DMARC-aligned- pass-rate floor depends on at the receiver-side DMARC evaluation boundary; and (iv) per-Workspace-tenant per-custom- domain qualifier-discipline-floor as Workspace-tenant per-source-IP exfiltration- attack-surface closure — the per- Workspace-tenant per-custom-domain -all terminal-qualifier publication at the p=reject commitment boundary closes the per- Workspace-tenant per-source-IP attacker- IP-spoofing attack-surface the per- Workspace-tenant per-custom-domain SPF record-publication discipline THIS page documents structurally defends against. Read THIS page when AUTHORING the per- publisher per-domain SPF qualifier- selection discipline at the canonical qualifier-evaluation reference layer; read the Workspace-tenant DMARC deployment spoke when AUDITING the per- Workspace-tenant per-custom-domain SPF qualifier-discipline floor against the SPF qualifier reference THIS page documents at the per-Workspace-tenant per-custom-domain SPF record-publication boundary.
• DKIM selectors explained — the PER-PUBLISHER-PER-DOMAIN-SPF- QUALIFIER-SEMANTICS-AS-ENVELOPE-LAYER- AUTHENTICATION-LEG-PARALLEL-TO-PER-PUBLISHER- PER-SELECTOR-DKIM-APPLICATION-LAYER- AUTHENTICATION-LEG companion to THIS per- publisher per-domain SPF qualifier-semantics reference. Where THIS page documents the per-publisher per-domain SPF qualifier- semantics (the +/~/ -/? per-mechanism per-publisher per-domain authoritative-pass- vs-soft-fail-vs-hard-fail-vs-neutral qualifier publication discipline, the per- publisher per-domain default-qualifier convention, the per-receiver per-message SPF- result-code consequences of each qualifier, the per-Workspace-tenant per-custom-domain SPF qualifier-discipline floor), the DKIM- selectors-explained spoke documents the per- publisher per-selector DKIM-selector publication discipline at FOUR per-SPF- qualifier-vs-DKIM-selector publication coupling dimensions: (i) per- publisher per-domain SPF -all hard-fail qualifier publication AS envelope-layer authoritative- rejection primitive structurally parallel to per-publisher per-selector DKIM cryptographic-validation hard-fail primitive — the per-publisher per- domain SPF -all hard-fail qualifier publication IS the per-publisher per-domain envelope-layer authoritative- rejection primitive at the per-receiver per- message envelope-MAIL-FROM authorization evaluation boundary; the per-publisher per- selector DKIM-Signature cryptographic- validation hard-fail (per-message DKIM cryptographic-signature verification failure AND per-publisher per-selector key- publication present at <selector>._domainkey.<d-domain>) IS the per-publisher per-selector application-layer cryptographic-binding hard-fail primitive at the per-receiver per- message DKIM-leg-evaluation boundary; the two primitives are structurally parallel per- publisher per-domain envelope-layer + application-layer hard-fail authentication- leg publication-coordination disciplines; (ii) per-publisher per-domain SPF ~all soft-fail qualifier publication AS envelope-layer per-receiver per-message deferral-window-publication primitive structurally parallel to per- publisher per-domain partial-DKIM-coverage publication discipline — the per- publisher per-domain SPF ~all soft-fail qualifier publication is the per- publisher per-domain envelope-layer per- receiver per-message deferral-window- publication primitive (per-receiver per- message disposition typically defers to per- DMARC composite-verdict instead of envelope- layer authoritative rejection); the per- publisher per-domain partial-DKIM-coverage publication discipline (per-publisher per- stream selector coverage gaps, per-publisher per-third-party-SaaS-sender selector publication coordination gaps) is the per- publisher per-domain application-layer per- receiver per-message disposition-deferral publication primitive; the two are structurally parallel per-publisher per- domain envelope-layer + application-layer soft-fail publication-coordination disciplines; (iii) per-publisher per-domain SPF + DKIM composite-publication AS per-publisher per-domain DMARC-aligned- pass dual-authentication-leg-redundancy primitive — the per-publisher per- domain DMARC-aligned-pass verdict requires EITHER per-message per-publisher per-domain SPF-aligned-pass OR per-message per-publisher per-selector DKIM-aligned-pass at the per- receiver per-message DMARC composite-verdict boundary; the per-publisher per-domain SPF qualifier-discipline publication THIS page documents AND the per-publisher per-selector DKIM-selector publication discipline TOGETHER form the per-publisher per-domain dual- authentication-leg-redundancy primitive ensuring per-publisher per-domain DMARC- aligned-pass evidence-stream continuity at the per-receiver per-message authentication- evaluation boundary; (iv) per- publisher per-domain SPF qualifier-discipline publication AS per-publisher per-domain envelope-layer authentication-discipline- floor structurally parallel to per-publisher per-selector DKIM key-rotation cadence application-layer authentication-discipline- floor — the per-publisher per- domain SPF qualifier-discipline-floor publication (per-publisher per-domain -all hard-fail commitment, per- publisher per-domain include:- cascade audit discipline maintaining the envelope-layer authorisation surface) IS the per-publisher per-domain envelope-layer authentication-discipline-floor maintenance primitive; the per-publisher per-selector DKIM key-rotation cadence-floor (per- publisher per-selector at-minimum-quarterly rotation cadence, per-publisher per-selector private-key-custody discipline, per-publisher per-stream selector-segmentation hygiene) IS the per-publisher per-selector application- layer authentication-discipline-floor maintenance primitive; the two are structurally parallel per-publisher per- domain authentication-discipline-floor maintenance disciplines at the per-publisher per-domain envelope-layer + application- layer composite-publication coordination boundary. Read THIS page when AUTHORING per-publisher per-domain SPF qualifier- discipline publication; read the DKIM- selectors-explained spoke when UNDERSTANDING how the per-publisher per-selector DKIM- selector publication discipline IS the per- publisher per-domain application-layer authentication-leg parallel to the per- publisher per-domain SPF qualifier-semantics envelope-layer authentication-leg at the per-publisher per-domain composite- publication-coordination boundary.
• CAA records explained — the structurally parallel DNS-published publication-vocabulary primitive companion to this SPF qualifier-vocabulary reference.
• DMARC forensic reports
• BIMI SVG asset requirements
• DKIM failures explained
• DMARC policy rollout
• TLS-RPT JSON aggregate-report format — the PER-PUBLISHER-PER-POLICY-DOMAIN-TLS-RPT-FAILURE-DETAILS-RESULT-TYPE-PER-FAILURE-CLASS-VOCABULARY-AS-STRUCTURALLY-PARALLEL-TRANSPORT-LAYER-PER-RESULT-CLASS-VERDICT-TAXONOMY-COMPANION-TO-PER-PUBLISHER-PER-DOMAIN-SPF-QUALIFIER-PREFIX-CLASS-VOCABULARY-ENVELOPE-MAIL-FROM-LAYER-PER-RESULT-CLASS-VERDICT-TAXONOMY companion at four per-publisher per-domain SPF-qualifier-prefix-class-vocabulary-vs-TLS-RPT-failure-class-vocabulary coupling dimensions: (i) per-publisher per-policy-domain TLS-RPT JSON aggregate-report failure-details[]/result-type per-failure-class vocabulary (starttls-not-supported / certificate-host-mismatch / certificate-expired / certificate-not-trusted / sts-policy-fetch-error / sts-policy-invalid / sts-webpki-invalid / tlsa-invalid / dnssec-invalid / dane-required / validation-failure) per RFC 8460 §4.3 IS structurally parallel transport-layer per-failure-class verdict-vocabulary taxonomy to per-publisher per-domain SPF qualifier-prefix vocabulary verdict-mapping +(pass) / -(fail) / ~(softfail) / ?(neutral) per RFC 7208 §4.6.2 surfacing as per-receiver per-day policy_evaluated/spf=pass|fail|softfail|neutral per-message-attribution per RFC 7489 §6.6.1 THIS SPF-qualifier-vocabulary page documents the per-publisher per-domain envelope-MAIL-FROM-layer per-result-class verdict-vocabulary publication-discipline of — both per-publisher per-domain per-leg per-result-class verdict-vocabulary publication-discipline references coordinate at the per-publisher per-domain composite envelope-MAIL-FROM-and-transport-layer per-result-class verdict-vocabulary publication-discipline coordination boundary; (ii) per-publisher per-policy-domain TLS-RPT JSON aggregate-report-format summary/total-successful-session-count/total-failure-session-count per-day per-policy-domain composite-success-rate evidence-stream IS structurally parallel transport-layer per-day per-policy-domain composite-success-rate evidence-stream to per-publisher per-domain SPF per-day per-source-IP per-record per-qualifier-prefix per-receiver per-message verdict-distribution evidence-stream surfacing in per-receiver per-day DMARC RUA auth_results/spf/result attribution per RFC 7489 §7.2 the SPF-qualifier-vocabulary primer THIS page documents the per-publisher per-domain envelope-MAIL-FROM-layer per-qualifier-prefix evidence-stream publication-discipline of feeds; (iii) per-publisher per-policy-domain TLS-RPT JSON aggregate-report-format policies[]/policy-type=sts/policy-type=tlsa/policy-type=no-policy-found per-policy attribution taxonomy IS structurally parallel transport-layer per-policy attribution per-result-class vocabulary to per-publisher per-domain SPF qualifier-prefix per-result-class verdict-vocabulary the per-publisher per-domain SPF-qualifier-vocabulary primer THIS page documents the per-publisher per-domain envelope-MAIL-FROM-layer per-result-class per-qualifier-prefix publication-discipline of — both per-publisher per-domain operator-side per-leg per-result-class per-attribution-class vocabulary publication-discipline references are per-publisher per-domain per-leg evidence-attribution decision primitives at the per-publisher per-domain composite envelope-MAIL-FROM-and-transport-layer per-leg per-attribution-class vocabulary publication-discipline coordination boundary; (iv) per-publisher per-policy-domain TLS-RPT JSON aggregate-report-format publication-discipline drift (malformed JSON / missing failure-details[] attribution / non-conformant result-type vocabulary / mis-labeled policy-type attribution) directly opens per-publisher per-domain transport-layer-aggregate-observability per-result-class per-failure-class evidence-stream blackout-window structurally parallel to per-publisher per-domain SPF qualifier-prefix publication-discipline drift (+all permissive-mis-publication / missing terminal-qualifier / mis-ordered qualifier-prefix-vs-mechanism producing per-receiver per-day per-source-IP spf=permerror verdict-attribution per RFC 7208 §8.7) opening per-publisher per-domain envelope-MAIL-FROM-layer per-qualifier-prefix-verdict-vocabulary-floor regression the per-publisher per-domain SPF-qualifier-vocabulary primer THIS page documents the per-publisher per-domain envelope-MAIL-FROM-layer per-qualifier-prefix per-result-class verdict-vocabulary publication-discipline of catalogues against — together the per-publisher per-domain SPF qualifier-prefix per-result-class verdict-vocabulary publication-discipline THIS page documents AND the per-publisher per-policy-domain TLS-RPT JSON aggregate-report-format per-failure-class verdict-vocabulary publication-discipline compose the per-publisher per-domain composite envelope-MAIL-FROM-and-transport-layer per-leg per-result-class verdict-vocabulary publication-discipline-floor coordination boundary.
• DMARC deployment checklist — the PER-PUBLISHER-PER-DOMAIN-SPF-QUALIFIER-VOCABULARY-PUBLICATION-DISCIPLINE-AS-LOAD-BEARING-ENVELOPE-MAIL-FROM-LAYER-PER-PHASE-EXIT-CRITERIA-GATE-FOR-DMARC-FOUR-PHASE-OPERATOR-ACTIONABLE-DEPLOYMENT-PROGRESSION companion at four per-publisher per-domain SPF-qualifier-vocabulary-vs-DMARC-deployment-checklist coupling dimensions: (i) per-publisher per-domain SPF terminal-qualifier publication-decision (-all Fail vs ~all SoftFail vs ?all Neutral) per RFC 7208 §4.6.2 THIS page documents the per-publisher per-domain envelope-MAIL-FROM-layer qualifier-vocabulary publication-discipline of IS the load-bearing per-publisher per-domain Phase 1 Discovery prerequisite-floor whose per-publisher per-domain SPF qualifier-publication baseline the per-publisher per-domain DMARC deployment-checklist Phase 1 Discovery action-items reference enumerates as a per-publisher per-domain SPF-leg readiness gate; (ii) per-publisher per-domain SPF qualifier-prefix verdict-mapping (+/-/~/?) per RFC 7208 §4.6.2 surfacing as per-receiver per-day per-source-IP DMARC RUA aggregate-report policy_evaluated/spf=pass|fail|softfail|neutral attribution per RFC 7489 §6.6.1 IS the load-bearing per-publisher per-domain Phase 2 Triage attribution-baselining evidence stream the per-publisher per-domain DMARC deployment-checklist Phase 2 Triage per-phase-exit-criteria readiness-decision-discipline coordinates against as a per-leg pass-rate floor preservation reference; (iii) per-publisher per-domain SPF qualifier-vocabulary strict-vs-permissive ramp-readiness publication-discipline (~all SoftFail as Phase 2 observability-baseline-friendly qualifier IS structurally parallel to per-publisher per-domain DMARC p=none Phase 2 baseline qualifier; -all Fail as Phase 3/4 enforcement-grade qualifier IS structurally parallel to per-publisher per-domain DMARC p=quarantine/p=reject Phase 3/4 enforcement-grade policy-modes) THIS page documents the per-publisher per-domain envelope-MAIL-FROM-layer ramp-readiness publication-discipline of IS the load-bearing per-publisher per-domain envelope-MAIL-FROM-layer ramp-cutover publication-discipline structurally parallel to the per-publisher per-domain DMARC application-layer four-phase deployment progression the per-publisher per-domain DMARC deployment-checklist Phase 3 Quarantine + Phase 4 Reject terminal-stage enforcement-ramp coordinates against; (iv) per-publisher per-domain SPF qualifier-vocabulary publication-discipline drift (+all permissive-mis-publication surfacing as per-day per-receiver per-source-IP spf=pass attribution-distortion or missing terminal-qualifier producing per-receiver per-day per-source-IP spf=permerror attribution per RFC 7208 §8.7 or 10-DNS-lookup-cap exhaustion producing per-receiver per-day per-source-IP spf=permerror attribution per RFC 7208 §4.6.4) directly opens per-publisher per-domain envelope-MAIL-FROM-layer SPF-leg pass-rate floor regression below the per-publisher per-domain DMARC deployment-checklist per-phase-exit-criteria evidence-driven readiness threshold the per-publisher per-domain DMARC deployment-checklist Phase 3 Quarantine + Phase 4 Reject terminal-stage enforcement-ramp publication-discipline THIS DMARC-deployment-checklist spoke documents the operator-actionable per-phase-exit-criteria of structurally depends on at the per-publisher per-domain composite cross-protocol SPF-qualifier-publication-and-DMARC-deployment-ramp coordination boundary.
• DKIM cryptography basics — the asymmetric public-key signature primitive (RFC 6376 plus RFC 8301 crypto-requirements update plus RFC 8463 Ed25519 alternative) underlying the DKIM leg of every per-publisher per-domain DMARC composite authentication portfolio THIS SPF-qualifier-vocabulary primer feeds. Where SPF qualifies envelope-MAIL-FROM authorisation cryptographically-free (the +/-/~/? prefix-vocabulary this page documents requires no per-publisher key material), DKIM requires per-publisher per-selector public/private key infrastructure published as base64 TXT records at selector._domainkey.<domain>. The cross-leg authentication-stack complement covering RSA-2048 vs Ed25519 key-strength tradeoffs, SHA-256 body and header hashing, and the 255-byte TXT-segment splitting (RFC 1035 §3.3.14) RSA-2048 publication requires — the per-publisher per-domain DKIM-leg cryptographic publication-discipline reference whose per-receiver per-day per-source-IP auth_results/dkim attribution per RFC 7489 §7.2 composes against the per-publisher per-domain SPF-leg qualifier-vocabulary publication-discipline THIS page documents at the per-publisher per-domain composite SPF-and-DKIM authentication-stack coordination boundary.
• DKIM troubleshooting — the per-publisher per-selector DKIM-verdict-class triage reference companion at four per-publisher per-domain SPF-qualifier-vocabulary-vs-DKIM-verdict-triage coupling dimensions: (i) per-publisher per-domain SPF terminal-qualifier -all strict-fail vs ~all softfail per RFC 7208 §4.6.2 publication-decision drives per-receiver per-message spf=fail / spf=softfail envelope-MAIL-FROM-layer verdict-class IS structurally parallel application-layer per-publisher per-selector DKIM verdict-class taxonomy publication-decision (dkim=fail / dkim=permerror / dkim=temperror per RFC 8601 §2.7.1 verdict-class spectrum the DKIM-troubleshooting reference catalogues) — both per-publisher per-domain authentication-leg verdict-class triage references coordinate at the per-publisher per-domain composite SPF-and-DKIM authentication-leg verdict-class triage boundary; (ii) per-publisher per-domain SPF qualifier-vocabulary publication-discipline drift (mis-qualified +include: vs unqualified include: default-Pass, premature -all publication causing per-receiver per-message spf=fail verdict-class cascading into DMARC composite-aligned-pass-rate floor regression) IS structurally parallel envelope-MAIL-FROM-layer authentication-leg publication-discipline drift to per-publisher per-selector DKIM-Signature emission-discipline drift surfacing in per-receiver per-message dkim=fail-body-hash-mismatch / dkim=fail-signature-mismatch verdict-class whose per-publisher per-selector root-cause triage the DKIM-troubleshooting body-hash-mismatch + signature-mismatch symptom-flows document the per-publisher per-selector verdict-class triage of; (iii) per-publisher per-domain SPF pass-but-DMARC-fail verdict-class root-cause attribution (per-publisher per-domain SPF authentication-leg pass-discipline coordinated with mis-aligned RFC 5321 MAIL-FROM domain vs RFC 5322 From-header organisational-domain alignment-evaluator failure per RFC 7489 §3.1.1) IS structurally parallel per-publisher per-selector DKIM pass-but-DMARC-fail verdict-class root-cause attribution (per-publisher per-selector DKIM-Signature pass-discipline coordinated with mis-aligned DKIM-Signature d= tag vs RFC 5322 From-header organisational-domain alignment-evaluator failure per RFC 7489 §3.1.1) whose per-publisher per-selector root-cause triage the DKIM-troubleshooting pass-DMARC-fail symptom-flow documents the per-publisher per-selector DKIM-Signature-alignment-evaluator triage-procedure of — both per-publisher per-domain authentication-leg pass-but-DMARC-fail verdict-class triage references jointly compose the per-publisher per-domain composite SPF-and-DKIM alignment-evaluator triage boundary; (iv) per-publisher per-domain SPF permerror verdict-class (per-publisher per-domain SPF mechanism-evaluator hard-failure from byte-grammar publication drift or 10-DNS-lookup-budget exhaustion per RFC 7208 §4.6.4) IS structurally parallel envelope-MAIL-FROM-layer per-publisher per-domain authentication-leg-evaluator hard-failure verdict-class to per-publisher per-selector DKIM permerror verdict-class per RFC 8601 §2.7.1 (per-publisher per-selector DKIM-Signature-evaluator hard-failure from <selector>._domainkey.<d> TXT-RR byte-grammar publication drift or no-selector-record DNS publication-floor defect) whose per-publisher per-selector root-cause triage the DKIM-troubleshooting permerror symptom-flow documents the per-publisher per-selector verdict-class triage of — together the per-publisher per-domain SPF qualifier-vocabulary publication-discipline THIS page documents AND the per-publisher per-selector DKIM-verdict-class triage decision-tree the DKIM-troubleshooting spoke documents compose the per-publisher per-domain composite SPF-and-DKIM authentication-leg-verdict-class-triage coordination floor.
• MX records explained — the inbound-routing DNS companion to this SPF-qualifier page. The SPF mx mechanism per RFC 7208 §5.4 authorizes every host named in the domain's MX records, so the terminal qualifier this page documents (-all / ~all / ?all) only composes a sound envelope-MAIL-FROM authorization verdict when the underlying MX-RR set is itself correctly published — each mx lookup also consumes one of the RFC 7208 §4.6.4 ten-DNS-lookup budget slots whose exhaustion drives spf=permerror. Read the MX-records spoke when an mx-mechanism qualifier choice depends on the inbound mail-exchanger set the SPF evaluator resolves.
• DMARC reporting pipeline — where the qualifier choice this page documents becomes a measurable outcome. The ~all SoftFail vs -all Fail decision (the single most consequential choice at the end of an SPF record) determines which SPF result code receivers stamp on non-authorized mail, and that result code is exactly what the DMARC aggregate (RUA) row reports back: a ~all record produces spf=softfail rows while a -all record produces spf=fail rows for the same unauthorized source. The reporting-pipeline spoke documents how those per-message verdicts are ingested, parsed, and aggregated per-source-IP — so an operator can read the aggregate output to confirm that tightening ~all to -all actually moved the unauthorized senders into the Fail bucket, and to verify no legitimate source is being caught before committing the stricter qualifier.
• BIMI certificates — the verified-logo payoff downstream of the SPF qualifier decision this page documents. The terminal ~all vs -all choice governs whether the SPF leg reliably contributes a DMARC-aligned pass, and a BIMI logo — vouched for by a Verified Mark Certificate (VMC) — only appears once the domain sustains DMARC enforcement (p=quarantine/p=reject) on a solid aligned-pass rate. Read the BIMI certificates spoke to see how getting the SPF qualifier right is one step on the path to earning the brand indicator and its certificate.
• DMARC for Microsoft 365 — the provider-specific guide where the terminal qualifier decision this page documents gets applied. A Microsoft 365 tenant publishes v=spf1 include:spf.protection.outlook.com ~all by default, and the ~all vs -all choice covered here is exactly what you weigh when hardening that record for enforcement. Read the M365 guide to set the qualifier in the context of a full Exchange Online SPF/DKIM/DMARC deployment.
• MTA-STS explained — the transport-layer policy that complements the envelope-layer qualifier decision on this page. An SPF -all hard-fail tells receivers which sources to reject at the message layer, while MTA-STS tells sending MTAs to deliver your inbound mail only over enforced TLS — both operator-published policies that harden a different layer of the same domain; read the MTA-STS primer to add the transport leg to your enforcement posture.
• DANE explained (the DNSSEC-anchored transport-security alternative) — your qualifier choice (~all softfail vs -all hardfail) governs the message-layer SPF verdict, but DANE (RFC 7672 + RFC 6698) governs whether mail reaches your MX over an authenticated, un-strippable TLS channel in the first place. Where MTA-STS serves its policy over HTTPS, DANE pins the receiving MX's certificate through DNSSEC-signed TLSA records — the DNSSEC-based counterpart transport leg. Read it to choose the transport-security mechanism that complements the envelope-layer qualifier discipline this page covers.
• MTA-STS policy syntax — just as your ~all vs -all qualifier is the publisher-chosen dial for the message-layer SPF verdict, the MTA-STS policy file's mode field (testing vs enforce) is the publisher-chosen dial for transport-layer TLS enforcement. This reference dissects that policy file's version / mode / mx / max_age grammar — the HTTPS-served counterpart to the DNSSEC-anchored DANE leg referenced above.
• 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.

12. Audit your SPF record qualifier now

The fastest way to confirm your SPF records terminal qualifier is correct for your deployment stage:

1. Look up your current SPF record. Use dig +short TXT example.com or the Domain Security Checker to see what qualifier currently terminates your record.
2. Identify your deployment stage. New deployment with incomplete sender inventory → ~all + DMARC p=none. Confirmed inventory + ready for enforcement → -all + DMARC p=quarantine or p=reject. Null-sender domain → v=spf1 -all.
3. Flag the four anti-patterns: +all (authorises everything, replace immediately), ?all (provides no enforcement, replace with -all or ~all), missing terminal (implicit Neutral, add an explicit qualified all), and ~all + DMARC p=reject (incoherent, switch to -all).
4. Inspect a real outbound message with the Email Header Analyzer to confirm the Authentication-Results header reports the expected spf=pass for legitimate senders.