DMARC Analyzer

TL;DR

• Three policy modes defined by RFC 7489 section 6.3: p=none (monitoring only, no enforcement), p=quarantine (route failing mail to spam folder), p=reject (refuse failing mail at SMTP RCPT TO).
• Canonical progression: p=none → p=quarantine → p=reject. Never skip quarantine - the spam folder is a recoverable failure mode that surfaces problems without dropping mail.
• p=none is NOT defensive. It gathers reports but takes no enforcement action. Spoofed mail flows normally to recipient inboxes. Use ONLY during the initial Discovery phase (typically the first 2 to 4 weeks of a DMARC deployment).
• p=reject is the steady-state target. Only mode that fully prevents domain spoofing, only mode that satisfies BIMI requirements, only mode recommended by CISA BOD 18-01 for U.S. federal agencies, only mode that defeats business email compromise via brand impersonation.
• pct= sampling applies the named policy to a percentage of failing mail and downgrades the rest one stage. Being removed in the draft-ietf-dmarc-dmarcbis successor draft.
• sp= and np= set subdomain and non-existent-subdomain policies independently of the apex p= tag. Publish sp=reject and np=reject from day one to block spoofing from non-sending subdomains immediately.

1. Overview: what is a DMARC policy mode?

A DMARC policy mode is the value assigned to the mandatory p= tag in the _dmarc.example.com TXT record. The policy mode is the single most important DMARC deployment decision: it tells receiving mail servers what to do when a message claiming to be from your domain fails DMARC evaluation (fails either SPF alignment OR DKIM alignment OR both).

RFC 7489 section 6.3 defines exactly three policy values:

• p=none - the Domain Owner requests no specific action from receivers regarding DMARC failures. This is monitoring mode. Receivers send aggregate reports describing observed DMARC outcomes but do not change message disposition based on DMARC failure. Mail flows normally regardless of DMARC pass / fail status.
• p=quarantine - the Domain Owner requests that DMARC-failing messages be treated as suspicious. The standard receiver interpretation is to deliver to the recipient's spam or junk folder rather than the inbox. The message reaches the recipient and can be rescued from spam, but its visibility is degraded.
• p=reject - the Domain Owner requests that DMARC-failing messages be refused outright. The standard receiver interpretation is to issue an SMTP 5xx response at the RCPT TO stage so the message is bounced back to the sending system before any delivery attempt is made. The message never reaches the recipient mailbox.

The three modes form the canonical Discovery to Quarantine to Reject deployment progression. Each mode has explicit semantics, explicit receiver behaviour, and explicit use cases. The next three sections cover each mode in detail.

2. p=none in detail (monitoring mode)

2.1 Semantics

Per RFC 7489 section 6.3: "The Domain Owner requests no specific action be taken regarding delivery of messages."

p=none is the only DMARC policy mode that does NOT change message disposition. Mail flows normally regardless of DMARC outcome. The only effect of publishing p=none is that receivers send aggregate (rua) reports describing the observed mail traffic.

2.2 Example record

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1; adkim=r; aspf=r; pct=100"

2.3 When to use p=none

• Discovery phase only. The first 2 to 4 weeks of a fresh DMARC deployment, while you build the sender inventory by reading aggregate reports.
• Pre-Triage validation. While you are still in Phase 2 alignment fixing and before you advance to p=quarantine.
• Short-term rollback. If a production p=quarantine or p=reject deployment causes user-visible issues, fall back to p=none while you diagnose - mail flow restores immediately.

2.4 When NOT to use p=none

• NOT a permanent state. p=none provides no defensive value: attackers can spoof your domain freely, and recipient mailboxes will accept the spoofed mail. Many organisations publish p=none "to set up DMARC" and then never advance - this is a deployment anti-pattern. Steady-state production domains belong at p=quarantine or p=reject.
• NOT a BIMI prerequisite. BIMI requires p=quarantine or p=reject; p=none domains are not eligible for the BIMI brand-logo benefit at major receivers.
• NOT compliant with major frameworks. CISA BOD 18-01, M3AAWG, and NIST SP 800-177 Rev. 1 all recommend p=reject (or at minimum p=quarantine) for production domains.

2.5 What receivers do under p=none

• Disposition: deliver normally to inbox (no DMARC-driven action).
• Aggregate reports: sent daily to the rua= mailbox listed in the record.
• Forensic reports: sent per-failure to the ruf= mailbox if configured (most major receivers do not send forensic reports).
• SMTP response code: normal 250 OK at RCPT TO and DATA stages - DMARC failure does not change the SMTP outcome.

3. p=quarantine in detail (spam-folder enforcement)

3.1 Semantics

Per RFC 7489 section 6.3: "The Domain Owner wishes to have email that fails the DMARC mechanism check be treated by Mail Receivers as suspicious."

The exact disposition is at the receiver's discretion, but the universally-adopted convention is to deliver the message to the recipient's spam or junk folder. The message reaches the recipient's mailbox but its visibility is degraded.

3.2 Example record

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; fo=1; adkim=r; aspf=r; pct=100"

3.3 When to use p=quarantine

• Safety-net stage between the Triage phase (alignment fixing) and the Enforcement phase (p=reject) of a deployment. Typical duration: 2 to 4 weeks at pct=100.
• Ramp visibility. Optionally start at pct=10 and ramp to pct=25, pct=50, pct=100 over 4 to 8 weeks to limit exposure during the quarantine window (see Section 7).
• Final defensive tier for organisations that cannot reach a fully-aligned sender estate. p=quarantine is the maximum enforcement compatible with a few stubbornly-misaligned legitimate senders, because the spam folder is recoverable while SMTP reject is not.

3.4 When NOT to use p=quarantine

• NOT a permanent destination. Quarantine is a safety-net stage. The spam folder is a worse user experience than reject + bounce because there is no automatic feedback to the sending system that the message was not delivered. Always advance to p=reject when exit criteria are satisfied.
• NOT a Phase 1 starting point. Skipping p=none Discovery and starting at p=quarantine misses the chance to inventory senders without enforcement risk - legitimate senders that were quietly misaligned will hit the spam folder before you have data to diagnose them.

3.5 What receivers do under p=quarantine

• Disposition: spam or junk folder (receiver discretion; universally adopted convention).
• Aggregate reports: sent daily to the rua= mailbox.
• Forensic reports: sent per-failure to ruf= if configured.
• SMTP response code: normal 250 OK at RCPT TO and DATA stages - the receiver accepts the message and then routes it to spam post-delivery.
• Recipient visibility: message reaches the recipient's spam folder; the recipient can rescue it manually. No automatic feedback to the sender that the message landed in spam.

4. p=reject in detail (SMTP-level enforcement)

4.1 Semantics

Per RFC 7489 section 6.3: "The Domain Owner wishes for Mail Receivers to reject email that fails the DMARC mechanism check."

The receiver issues an SMTP 5xx response code at the RCPT TO stage, refusing to accept the message for delivery. The sending mail server receives the rejection in real time and bounces the message back to the original sender with a permanent failure notification.

4.2 Example record

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc-reports@example.com; fo=1; adkim=r; aspf=r"

4.3 When to use p=reject

• Steady-state production policy. Once Phase 3 quarantine exit criteria are satisfied, advance to p=reject and stay there indefinitely. p=reject is the canonical end state of every well-executed DMARC rollout.
• BIMI deployment. BIMI requires p=quarantine or p=reject; p=reject is strongly preferred by every major BIMI-supporting receiver (Gmail, Yahoo, Apple iCloud Mail, AOL).
• Regulatory compliance. CISA Binding Operational Directive 18-01 mandates p=reject for U.S. federal civilian executive branch agencies. The European Banking Authority, the UK NCSC, and the Australian ACSC all recommend p=reject as the production target.
• Brand impersonation defence. Business email compromise (BEC) and brand impersonation attacks are blocked at the SMTP layer under p=reject - the spoofed mail never reaches recipient mailboxes, so no human can be tricked by it.

4.4 When NOT to use p=reject

• Not before Phase 3 exit criteria. Advancing to p=reject before the quarantine exit criteria are satisfied means legitimate senders still failing alignment will hit hard SMTP bounces and the messages will be lost. The cost of one extra week at quarantine is small; the cost of advancing prematurely is dropped legitimate mail.
• Not without an aggregate-report monitoring pipeline. p=reject without active monitoring of aggregate reports means you will not notice when a previously-aligned sender breaks alignment (rotated DKIM key without updating selector, moved IP range without updating SPF). p=reject demands a running monitoring discipline.

4.5 What receivers do under p=reject

• Disposition: SMTP RCPT TO rejection with 5xx response code (most receivers emit 550 5.7.1 with a DMARC-specific reason phrase).
• Aggregate reports: sent daily to the rua= mailbox.
• Forensic reports: sent per-failure to ruf= if configured.
• SMTP response code: 550 5.7.1 or similar at RCPT TO. The sending mail server receives the rejection synchronously.
• Bounce notification: the sending mail server generates a DSN (delivery status notification) and sends it back to the original sender, providing automatic feedback that the message failed.
• Recipient visibility: zero - the message never reaches the recipient mailbox.

5. Side-by-side comparison

The same observable behaviour, the same security posture, and the same operational consequence, laid out side-by-side across the three modes.

6. Receiver behaviour: Gmail, Outlook, Yahoo, Apple iCloud

RFC 7489 section 6.3 defines the Domain-Owner-requested action but leaves the final disposition to the receiver. In practice every major receiver honours the canonical interpretation:

6.1 Gmail (Google Workspace and consumer)

• p=none - deliver to inbox; emit Authentication-Results: dmarc=fail (p=NONE) header for DMARC-failing mail.
• p=quarantine - deliver to the Spam label; emit Authentication-Results: dmarc=fail (p=QUARANTINE). Subject prefix not modified by Gmail.
• p=reject - SMTP 550-5.7.26 rejection at RCPT TO with the reason phrase "This message does not have authentication information or fails to pass authentication checks."
• Gmail also enforces from February 2024 onward that bulk senders (5000+ messages per day to Gmail addresses) must publish at least p=none with a valid rua= tag.

6.2 Microsoft 365 / Outlook.com

• p=none - deliver to inbox or junk based on other anti-spam signals; emit Authentication-Results: dmarc=fail action=none.
• p=quarantine - route to Junk Email folder; emit Authentication-Results: dmarc=fail action=oreject in some configurations (Microsoft historically used a non-canonical action code).
• p=reject - SMTP 550 5.7.509 rejection in newer configurations; some legacy tenants downgrade to oreject (route to Junk) depending on anti-spoof policy settings. Operators publishing p=reject should verify actual enforcement by inspecting aggregate reports from Microsoft.

6.3 Yahoo Mail / AOL

• p=none - deliver to inbox; emit Authentication-Results: dmarc=fail (p=NONE).
• p=quarantine - deliver to Bulk folder.
• p=reject - SMTP 553 5.7.1 rejection at RCPT TO. Yahoo enforces consistently and is one of the strictest DMARC enforcers since their 2014 policy breakage that drove the industry-wide DMARC adoption push.

6.4 Apple iCloud Mail / @me.com / @mac.com

• p=none - deliver to inbox.
• p=quarantine - route to Junk.
• p=reject - SMTP 5xx rejection at RCPT TO. iCloud Mail enforces the canonical DMARC behaviour consistently.

6.5 Smaller receivers and corporate filters

Corporate Exchange installations, custom MTAs, Proofpoint, Mimecast, Cisco IronPort, Barracuda, SonicWall, and similar enterprise filters all consume the DMARC policy but apply it with site-local interpretation. Some receivers quarantine even under p=none if other anti-spam signals are negative; others under-enforce p=reject if the site administrator has relaxed the anti-spoof policy. Aggregate reports from these receivers are the only authoritative source of truth for your domain's actual enforcement experience.

7. pct= sampling tag interaction

7.1 Semantics

The pct= tag (RFC 7489 section 6.3, "pct" definition) tells receivers what percentage of failing mail to apply the named policy to. The remainder is treated as the next less-strict policy.

• p=quarantine; pct=10 - 10 percent of failing mail is quarantined; 90 percent is treated as p=none (delivered to inbox, reported only).
• p=reject; pct=10 - 10 percent of failing mail is rejected; 90 percent is treated as p=quarantine (routed to spam).
• p=none; pct=X - no effect. pct= only modulates enforcement, and p=none has no enforcement to sample.

7.2 Typical ramp pattern

Operators historically ramp the pct= value as a confidence-building mechanism during the Quarantine and Reject phases:

Week 0:  p=quarantine; pct=10
Week 1:  p=quarantine; pct=25
Week 2:  p=quarantine; pct=50
Week 3:  p=quarantine; pct=100
Week 4:  p=reject; pct=10
Week 5:  p=reject; pct=25
Week 6:  p=reject; pct=50
Week 7:  p=reject; pct=100  <-- steady state

7.3 dmarcbis removal of pct=

The in-progress draft-ietf-dmarc-dmarcbis removes the pct= tag entirely. The rationale is that the sampling semantics are confusing (operators routinely interpret pct=10 as "10 percent of all mail" instead of "10 percent of failing mail"), several large receivers (Microsoft notably) inconsistently honour it, and the staged ramp use case is better served by simply staying longer at the lower-strict policy.

For new deployments starting in 2025 or later, consider skipping the pct= ramp:

Week 0:  p=quarantine     <-- pct=100 implicit, no sampling
Week 4:  p=reject         <-- only after the quarantine exit criteria are satisfied

7.4 What pct= does NOT do

• Does NOT sample reporting. Aggregate reports cover all DMARC outcomes regardless of pct=; only the enforcement disposition is sampled.
• Does NOT randomly downgrade per-message. Receivers may implement per-message sampling (random) or per-source sampling (consistent per source IP) or per-day sampling - the RFC does not mandate a sampling granularity. Different receivers behave differently.

8. sp= and np= subdomain policies

8.1 sp= (subdomain policy, RFC 7489 section 6.3)

The sp= tag sets the policy for all subdomains under the apex. If sp= is omitted, the apex p= tag applies to subdomains automatically.

Common usage during a phased rollout: publish the apex with p=none during Discovery but sp=reject from day one to block spoofing from non-sending subdomains immediately, then ramp the apex p= through quarantine to reject on its own schedule.

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; sp=reject; rua=mailto:dmarc-reports@example.com"

8.2 np= (non-existent subdomain policy, RFC 9091)

The np= tag from RFC 9091 sets the policy specifically for non-existent subdomains (NXDOMAIN). Independent of sp=; takes precedence over sp= for NXDOMAIN subdomains when both are present.

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; sp=quarantine; np=reject; rua=mailto:dmarc-reports@example.com"

np=reject is a free defensive win: NXDOMAIN subdomains never send legitimate mail by definition, so any mail claiming to come from nonexistent.example.com is by definition an attacker - rejecting it has zero legitimate-mail risk.

8.3 Per-subdomain DMARC records

When a subdomain has its own DMARC rollout pace distinct from the apex, publish a per-subdomain DMARC record at _dmarc.sub.example.com with its own p= value. Per-subdomain records take precedence over both sp= and the inherited apex p=.

_dmarc.example.com.            IN  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.com"
_dmarc.marketing.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

Here the apex example.com and most subdomains use p=reject, while the marketing.example.com subdomain (still in its Quarantine phase) uses p=quarantine.

9. Choosing the right mode for your scenario

9.1 Brand-new domain, no mail flow yet

Publish p=reject; sp=reject; np=reject on day one. The domain has no legitimate senders to break and the strictest policy prevents any attacker from establishing spoofing as a baseline.

9.2 Established domain, never deployed DMARC

Standard four-phase rollout: p=none Discovery (2 to 4 weeks) -> p=quarantine Phase 3 (2 to 4 weeks) -> p=reject steady state. Always publish rua= from day one. Consider publishing sp=reject; np=reject from day one (apex p= ramps independently).

9.3 Established domain, already at p=none for months

Advance immediately. p=none provides no defensive value; staying at p=none indefinitely is the most common DMARC anti-pattern. If you have aggregate reports from the existing p=none deployment, you already have most of the sender inventory needed for the Quarantine advance. If you do not have aggregate report ingestion in place, set that up first (this DMARC Analyzer instance is one option), then advance.

9.4 Parked / non-sending domain

Publish p=reject; sp=reject; np=reject immediately. There is no legitimate mail flow to break, and the strict policy prevents attackers from using the parked domain for phishing.

9.5 Subsidiary or acquired domain

Treat the acquired domain as a fresh deployment. Do not merge the rollout calendar with the parent domain - each domain advances on its own exit criteria. If the acquired domain sends low-volume mail (or no mail), you may short-circuit by going straight to p=reject after a 2-week Discovery phase.

9.6 Domain with a stubbornly-misaligned legacy sender

If one legitimate sender cannot be aligned and moving it off your domain is not possible, the maximum enforcement compatible with that sender is p=quarantine. Document the misaligned sender as an explicit accepted exception, monitor aggregate reports for any second misaligned sender appearing, and revisit the migration plan annually. Do NOT accept indefinite p=none as the alternative - even p=quarantine with one accepted exception provides significantly more protection than p=none.

9.7 Domain with active BIMI deployment

BIMI requires p=quarantine or p=reject. p=reject is strongly preferred by every major BIMI-supporting receiver - it is the only policy that fully proves the domain controls the From: header it advertises via BIMI.

10. Common mistakes

• Treating p=none as a defensive policy. p=none provides ZERO spoofing protection. Attackers can spoof your domain freely under p=none. The only operational role of p=none is the initial Discovery phase. Domains that stay at p=none for months or years are advertising "we deployed DMARC" without actually deploying DMARC.
• Jumping from p=none straight to p=reject. Skipping the Quarantine safety-net stage means legitimate senders still failing alignment hit hard SMTP bounces and the messages are dropped. This is the single most common cause of self-inflicted DMARC outages. Always pass through p=quarantine first.
• Forgetting sp= and np=. The apex p= tag only protects the apex. Without sp=reject attackers can spoof from sub-subdomains like billing.example.com. Without np=reject attackers can spoof from non-existent subdomains.
• Misinterpreting pct=. pct=10 does NOT mean "apply DMARC to 10 percent of all mail". It means "apply the named policy to 10 percent of FAILING mail and downgrade the rest one stage". The semantic confusion is one of the reasons pct= is being removed in dmarcbis.
• Removing pct= from a p=reject record too early. Some operators publish p=reject; pct=10 and ramp toward 100 over weeks, but accidentally drop pct= mid-ramp - this jumps enforcement from 10 percent to the default 100 percent overnight. If you are using pct=, drop it only when you reach pct=100.
• Lowering DNS TTL only on the apex. Lower the TTL on every per-subdomain DMARC record AND the apex during rollout. A subdomain record with an 86400 TTL means a 24-hour wait to roll back if something breaks.
• Publishing p=reject without an aggregate-report monitoring pipeline. p=reject without active monitoring is fragile - a future DKIM key rotation that fails to update the published selector will hard-fail every outbound message until the operator notices through user complaints. Aggregate reports are the primary signal during steady-state p=reject; monitor them.

11. Frequently asked questions

What are the three DMARC policy modes?

DMARC defines three policy values for the p= tag in the _dmarc TXT record. p=none requests no enforcement: receivers report DMARC outcomes via aggregate (rua) reports but take no action on failing mail. p=quarantine requests that receivers route DMARC-failing mail to the spam or junk folder. p=reject requests that receivers refuse DMARC-failing mail at the SMTP RCPT TO stage so the message is bounced before delivery. The three modes are defined in RFC 7489 section 6.3 and form the canonical Discovery to Quarantine to Reject deployment progression.

What is the difference between p=none and p=quarantine?

p=none is monitoring mode with no enforcement action. p=quarantine is the first enforcement stage: DMARC-failing mail lands in the spam folder, so spoofed mail is contained but recoverable. The transition from p=none to p=quarantine is the moment your sender inventory must be complete - every legitimate sender must produce DMARC-aligned mail before this advance.

What is the difference between p=quarantine and p=reject?

p=quarantine is recoverable: DMARC-failing mail lands in the spam folder. p=reject is non-recoverable: the receiver refuses the message at SMTP RCPT TO with a 5xx error so the message is bounced back to the sender with no delivery attempt. Reject is the only mode that fully prevents spoofed mail from reaching mailboxes.

When should I use p=none?

Use p=none ONLY during the initial Discovery phase of a DMARC deployment, typically the first 2 to 4 weeks. p=none gathers aggregate reports without taking enforcement action, letting you inventory every legitimate sender. p=none is NOT a defensive policy: spoofed mail flows normally to recipient inboxes under p=none, so attackers can impersonate your domain without obstruction.

When should I use p=quarantine?

Use p=quarantine as a 2 to 4 week safety-net stage between Triage and Enforcement. At p=quarantine, DMARC-failing mail lands in the spam folder, so any legitimate sender still misaligned becomes visible as user complaints about missed mail rather than silent SMTP bounces.

When should I use p=reject?

Use p=reject as the steady-state policy for any domain that sends mail. p=reject fully prevents domain spoofing, satisfies BIMI requirements, and is the only mode recommended by CISA Binding Operational Directive 18-01 for U.S. federal agencies.

What does pct= do under each policy mode?

The pct= tag samples enforcement: receivers apply the named policy to a percentage of failing mail and downgrade the rest one stage. Under p=quarantine pct=10, 10 percent of failing mail is quarantined and 90 percent is treated as p=none. Under p=reject pct=10, 10 percent of failing mail is rejected and 90 percent is treated as p=quarantine. pct= has no effect under p=none and is being removed in draft-ietf-dmarc-dmarcbis.

How do sp= and np= interact with the apex p= tag?

sp= sets the policy for all subdomains under the apex regardless of whether they send mail. If sp= is omitted, the apex p= tag applies to subdomains. np= (RFC 9091) sets the policy for non-existent subdomains specifically. Common configuration: publish the apex with p=none during Discovery but sp=reject from day one to block spoofing from non-sending subdomains immediately.

12. Related guides

• DMARC policy rollout - the JOURNEY companion to this page. Covers the Week 0 to Week 26 timeline, the pct= sampling ramp, and the operational sequencing of the three policy modes during deployment. Read this when you need to understand WHEN to advance between modes.
• DNS propagation — the publisher-side TTL-bounded publish-and-verify cycle that rate-limits every p= tag transition — the DNS-INFRASTRUCTURE-PUBLISHER-SIDE-RAMP- RATE-LIMITER companion to this policy-mode reference and to the policy-rollout journey entry above. Where THIS page documents the OPERATOR CHOICE between p=none / p=quarantine / p=reject dispositions and the sp= / np= / pct= modifiers, and the policy-rollout entry above documents the Week 0 to Week 26 timeline for ADVANCING between those modes, the dns_propagation spoke documents the PUBLISHER-SIDE TTL-BOUNDED PUBLISH-AND-VERIFY CYCLE that physically gates EVERY p=-tag transition between authoring intent and global receiver-side enforcement realisation. Four structurally-distinct DMARC-policy-propagation operational classes the spoke covers that THIS policy-mode reference intentionally elides: (i) DMARC TXT-record first-publish propagation window — when an operator publishes the _dmarc.<domain> TXT record for the first time (typically at v=DMARC1; p=none; rua=mailto:...), the record does NOT instantly become visible to every receiver-side DMARC filter worldwide; instead, the record propagates through the caching-resolver hierarchy at a rate gated by the TTL value (typically 300s / 3600s / 86400s — the 86400s case producing a 24-hour propagation tail). Operators who publish a new _dmarc TXT and immediately send a test message often see dmarc=none (the receiver's DMARC filter sees no DMARC policy) — a diagnostic that resolves only after the TTL-bounded propagation cycle completes; (ii) p=-tag ramp-advancement propagation tail — when an operator ramps from p=none → p=quarantine → p=reject per the policy-rollout spoke's Week 0-26 timeline, EACH ramp advancement republishes the _dmarc TXT with a new p= value and receiver-side resolvers continue to consult the cached prior version until the TTL expires. A publisher advancing p=quarantine → p=reject at the timeline's Week 24 milestone cannot rely on the new strict disposition being honoured globally until the TTL-bounded propagation cycle completes — the spoke documents the recommended pre-ramp TTL floor reduction (lower _dmarc TTL to 300s 24 hours BEFORE a ramp transition); (iii) pct= sampling-ramp propagation interaction — when an operator uses the pct= sampling modifier per RFC 7489 §6.6.4 (ramping pct=25 → 50 → 75 → 100 at the quarantine/reject tiers), each pct= increment is a separate TXT-record-republish event, each of which triggers its own TTL-bounded propagation window. The propagation-cycle structure means a pct= ramp completes EFFECTIVELY 24-48 hours after the configured publish time rather than instantaneously; (iv) _dmarc-record-deprecation propagation tail — when an operator decommissions a domain's DMARC policy (or downgrades from p=reject back to p=none during a regression- recovery scenario), receiver-side resolvers continue to honour the cached prior version until the TTL expires, meaning downgrade-decisions do NOT take effect globally until the TTL-bounded propagation cycle completes. Required reading once an operator advances p= per the rollout-spoke timeline and reports "the ramp isn't taking effect" or "different receivers see different policy dispositions for the same test message".
• DMARC deployment checklist - the OPERATOR QUICK-REFERENCE companion. Per-phase checkboxes, exit criteria, decision matrix. Read this when you need to know WHAT to do at each step.
• DMARC record tags explained - every tag in the DMARC DNS record (v, p, sp, np, pct, rua, ruf, adkim, aspf, fo, rf, ri).
• DMARC alignment explained - identifier alignment (RFC 7489 section 3.1 and section 6.6.2): strict vs relaxed, the organisational domain, the Public Suffix List, and why DKIM passing is not the same as DMARC-aligned.
• DKIM alignment with DMARC — the POLICY-ENFORCEMENT-DKIM-IDENTIFIER- ALIGNMENT-PREREQUISITE companion documenting the DKIM-side identifier-alignment computation (RFC 7489 §3.1.1, adkim=r vs adkim=s, the Public Suffix List organizational-domain extraction algorithm, the multiple-signature "any aligns wins" rule, the M365 onmicrosoft.com gotcha, the Workspace gappssmtp.com gotcha, the SPF-vs-DKIM asymmetry under forwarding, subdomain semantics edge cases) that EVERY policy-mode disposition decision documented on THIS page consumes as its DKIM-side input before the receiver's publisher-requested p= tag can translate into an actual junk-folder or 5xx SMTP-refusal outcome. Where THIS page documents the OPERATOR CHOICE between p=none (observe-only), p=quarantine (junk-folder disposition), and p=reject (envelope-stage 5xx rejection) — along with the sp= / np= / pct= modifiers — the DKIM- alignment-with-DMARC spoke is the DKIM-IDENTIFIER-ALIGNMENT-COMPUTATION companion documenting the precise byte-level algorithm the receiver applies BEFORE this page's policy-mode disposition is reached. The four-axis POLICY-MODE-VS-DKIM-ALIGNMENT comparison exposes the structurally-distinct PREREQUISITE-DEPENDENCY roles: (i) every policy disposition documented on this page depends on a DKIM-aligned signature being computable at the receiver's DMARC filter — the receiver computes identifier alignment by extracting the d= signing domain from each valid DKIM-Signature header, comparing it to the From: header organisational domain (per the Public Suffix List), and treating ANY aligned d= as a DKIM-pass-aligned input to the policy-mode decision; if no d= aligns AND SPF is not aligned either, the receiver consumes the publisher's p= tag and applies the requested disposition; (ii) publisher-side DKIM-alignment misconfiguration is the single biggest cause of legitimate-traffic p=reject bounces during policy- rollout — publishers signing with a third-party domain's d= (the Workspace gappssmtp.com or Microsoft 365 onmicrosoft.com defaults) get DKIM-pass-but-DMARC-unaligned outcomes that pass DKIM in isolation but fail DMARC alignment, producing rejected legitimate traffic the moment p=quarantine or p=reject is enabled; the DKIM-alignment-with-DMARC spoke documents the byte-level d=-correction procedure that MUST be completed before this page's policy advancement is safe; (iii) the adkim=r relaxed- alignment-mode default — under which a signing d= of mail.example.com aligns with a From: user@example.com via PSL- organisational-domain extraction — is the choice that makes p=reject deployable at scale; switching to adkim=s strict mode (which requires byte-identical d= vs From: domain) breaks every common third- party sender that signs with a subdomain d=; the spoke documents the operational consequences of choosing strict-vs-relaxed alignment for both adkim and the policy-mode decision; (iv) under SMTP-forwarding scenarios the SPF-side check fails (envelope MAIL FROM rewritten by the forwarder) but the DKIM signature survives intact — meaning that forwarded legitimate traffic can ONLY pass DMARC via a DKIM-aligned signature; publishers running p=reject who rely solely on SPF-aligned traffic (and not also on a properly-aligned DKIM signature) will reject all forwarded legitimate mail at the moment p=reject is enabled; the DKIM-alignment-with-DMARC spoke documents the SPF-vs-DKIM-under-forwarding asymmetry that this page's policy-mode decision must account for before enforcement-tier advancement. Read the DKIM-alignment-with- DMARC spoke BEFORE advancing past p=none on this page, to verify that every legitimate sending stream emits a DKIM-aligned d= signature under the chosen adkim= mode — the single most important prerequisite for safe p=quarantine / p=reject advancement.
• DMARC aggregate (rua) reports - the primary monitoring signal under every policy mode. How to read the XML, what each field means.
• DMARC forensic (ruf) reports - the per-message diagnostic sibling. Few receivers emit forensic reports but those that do are invaluable during triage.
• DMARC troubleshooting - the cross-cutting diagnostic reference for DMARC failures.
• DMARC monitoring - operational discipline that sustains steady-state p=reject: monthly review, sender registry maintenance, alert thresholds.
• DMARC reporting pipeline - end-to-end rua + ruf ingestion, storage, deduplication, retention, and alerting reference.
• BIMI explained — the DMARC-POLICY-MODE-AS-BIMI-DISPLAY- ELIGIBILITY-GATE companion to this DMARC policy-mode reference. Where THIS page documents the three RFC 7489 §6.3 canonical policy-mode dispositions (p=none / p=quarantine / p=reject) and the operator decision tree for progressing between them, the BIMI-explained pillar is the DOWNSTREAM-CONSUMER-OF-DMARC-ENFORCEMENT companion documenting the four operationally-distinct policy-mode-BIMI- readiness dimensions every operator encounters when the policy-mode decision documented on this page determines BIMI display eligibility at the receiver UI: (i) p=none is NOT BIMI-eligible at any major BIMI-aware mailbox provider (Gmail, Yahoo Mail, AOL, Apple iCloud Mail) — the receiver- side BIMI evaluation explicitly REQUIRES enforcement to elevate the publisher's domain to "verified identity" — the BIMI-explained pillar documents the per-receiver policy-mode eligibility contract that gates p=none publishers from brand-indicator display until they progress to enforcement, making the policy-mode-advance decision documented on this page operationally- rewarded with brand-display visibility; (ii) p=quarantine with pct=100 is BIMI- eligible at Gmail and Apple iCloud Mail — Yahoo Mail and AOL apply STRICTER eligibility requiring p=reject universally — making the pct=100 sustained 30-day metric documented on this page the operationally-load- bearing prerequisite for partial- BIMI-display at the largest mailbox- provider cohort — the BIMI- explained pillar documents the per- receiver pct= threshold differential that determines partial- vs-complete BIMI-display coverage across the BIMI-aware receiver population; (iii) p=reject is universally BIMI-eligible across Gmail + Yahoo + AOL + Apple iCloud Mail — making the p=reject rollout-gate criteria documented on this page the operationally-load- bearing prerequisite for COMPLETE BIMI-display coverage across the BIMI-aware receiver population — the BIMI-explained pillar documents why many publishers progress to p=reject specifically for BIMI display rather than threat-model considerations alone, elevating the policy-mode decision documented on this page from "DMARC enforcement milestone" to "brand-indicator display unlock"; and (iv) the sp=-tag subdomain-policy MUST also enforce (or be absent so the policy inherits from p=) for BIMI display eligibility on subdomain mail — operators publishing p=reject sp=none as risk-management discipline FORFEIT BIMI display on subdomain mail even though their apex organizational domain is BIMI- eligible — the BIMI- explained pillar documents the sp=-tag subdomain- eligibility differential that operators MUST coordinate with the per-policy-tag decision-tree documented on this page when deploying BIMI across an organizational-domain estate with multiple subdomains. Read the BIMI- explained pillar AFTER reaching p=quarantine pct=100 or p=reject via this policy-mode reference — the BIMI pillar is the AUTHORITATIVE downstream-consumer reference for the brand-indicator display reward the policy-mode advance documented on this page operationally unlocks at the BIMI-aware receiver population.
• MX records explained — the POLICY-ENFORCEMENT-EVALUATION-LOCATION- AT-MX-PUBLISHED-RECEIVER-BOUNDARY companion documenting the authoritative MX record (RFC 5321 §5.1 + RFC 7505 null-MX) that NAMES the SMTP-receive endpoint at which the DMARC policy-disposition decision documented on this page is actually computed and applied. Where THIS page documents the OPERATOR CHOICE between p=none (observe-only), p=quarantine (junk-folder disposition), and p=reject (envelope-stage 5xx rejection) — along with the sp= / np= / pct= modifiers — the MX-records spoke is the ENFORCEMENT-EXECUTION-LOCATION companion documenting WHERE in the SMTP-receive infrastructure the chosen disposition is actually realized. The four-axis POLICY-MODE- VS-MX-RECEIVER-ENFORCEMENT comparison exposes the structurally-distinct DISPOSITION-EXECUTION roles: (i) every DMARC policy disposition documented on this page is computed by a DMARC-aware filter at the recipient's MX-published receiver, NOT by the publisher — the publisher's p=reject tag is a REQUEST to the receiver, and the receiver must (a) be a DMARC-aware filter and (b) be the host the MX record actually delegates to for the request to translate into action; (ii) p=reject produces a 5xx SMTP refusal at the receiver's MX-published host BEFORE the message body is accepted into the receiver's mail store — the receiver's filter at the MX-published host evaluates the message envelope, computes identifier-alignment, applies the publisher's p=reject request, and returns a 5xx response code that causes the sending MTA to generate a bounce; this entire decision happens inside the MX-resolved receiver process; (iii) p=quarantine produces a junk-folder disposition AFTER the message is accepted at the MX-published receiver and routed to the recipient's mailbox — the MX-resolved receiver accepts the message, then the receiver-side delivery agent (often the same process or a downstream MDA) decides between Inbox and Junk based on the publisher's p=quarantine request combined with the receiver's local spam-policy heuristics; (iv) recipient domains whose MX is delegated to a non-DMARC- aware filter cannot enforce the publisher's p=reject request at all — the publisher's policy-mode tag is observed and reported back in aggregate / forensic reports, but the disposition is whatever the non-DMARC-aware receiver decided to do (usually Inbox-with-no-flag); this gap between REQUESTED disposition and APPLIED disposition is the single biggest invisible-to-the- publisher policy-enforcement variable in the whole DMARC ecosystem. Read the MX-records spoke when investigating why p=reject-aligned messages nonetheless reach a specific recipient's Inbox, and when scoping the recipient-side receiver-infrastructure-dependency that the policy-mode choice documented on this page silently relies on for any enforcement to occur.
• How attackers bypass weak DMARC - the threat model that motivates the Quarantine to Reject progression. Read this when stakeholders question why p=none is not sufficient.
• DKIM replay attacks explained — the P-EQUALS-REJECT-POLICY-MODE-DOES- NOT-DEFEAT-DKIM-REPLAY companion to this RFC 7489 §6.3 policy-mode decision-tree reference. Where THIS page documents the publisher-side p=none / p=quarantine / p=reject tag whose enforcement decision determines the receiver-side disposition for messages that FAIL DMARC alignment, the DKIM-replay-attacks spoke documents the structurally-distinct attack-class where the attacker captures a single legitimately-signed message per RFC 6376 §8.6 and re-sends it to arbitrary additional recipients — the replayed message carries a cryptographically-valid DKIM signature aligned with the publisher's domain, so the receiver-side DMARC evaluator emits dmarc=pass and the publisher's policy-mode choice this page documents has NO ENFORCEMENT EFFECT on the replayed message. The P-EQUALS- REJECT-POLICY-MODE-DOES-NOT-DEFEAT-DKIM- REPLAY cross-reference establishes FOUR structurally-distinct policy-mode-vs- replay-attack-limitation dimensions: (i) p=none-mode-does-not-defeat-DKIM- replay-but-monitoring-stream-captures- anomalous-recipient-pattern-evidence dimension — under p=none THIS page documents the publisher receives aggregate reports but applies no enforcement; for DKIM-replay attempts the aggregate-report stream captures per-source-IP volume spikes at unusual per-recipient distributions that the operator can correlate with the legitimately-signed-message campaign the attacker is amplifying, providing an early-warning detection signal even though the policy-mode produces no enforcement action; (ii) p=quarantine- mode-does-not-defeat-DKIM-replay-because- replayed-message-DKIM-passes dimension — under p=quarantine THIS page documents the receiver routes DMARC- failing messages to the spam folder; the DKIM-replayed message DKIM-passes and DMARC-passes, so the policy-mode routes the message to the INBOX regardless of the operator's anti- spam intent — the replay-defense burden falls entirely on the SHORT- KEY-LIFETIME and PER-MESSAGE- EXPIRATION-TAG operator-discipline the DKIM-replay-attacks spoke documents; (iii) p=reject-mode- does-not-defeat-DKIM-replay-because- cryptographic-validity-survives- envelope-rewrite dimension — under p=reject THIS page documents the receiver issues a 5xx SMTP rejection for DMARC-failing messages; the DKIM- replayed message's cryptographic signature survives the attacker's envelope-rewrite (the attacker re- wraps the captured signed-message in a new envelope to arbitrary additional recipients), so the receiver-side DKIM verifier still verifies the signature, DMARC still passes, and p=reject's hard-reject enforcement is BYPASSED — the most common operator-side misconception ("we're at p=reject so we're safe from impersonation") is the canonical Myth #6 the DMARC-myths-and- misconceptions cluster debunks; (iv) policy-mode-orthogonal-replay- defense-via-DKIM-x-tag-expiration-and- short-key-lifetime-and-RFC-9103- replay-attack-mitigation dimension — the DKIM-replay-defense operator-discipline is STRUCTURALLY ORTHOGONAL to the policy-mode decision THIS page documents: the publisher must additionally publish the RFC 9103 / RFC 6376 §3.5 x=<timestamp> expiration tag bounding the signature's per-message validity window AND adopt a short DKIM-key- rotation cadence (90 days or shorter) the DKIM-key-rotation cluster documents — neither countermeasure is encoded in any policy-mode tag THIS page covers. Read this DKIM-replay-attacks spoke alongside THIS policy-mode reference when authoring stakeholder communications about the ENFORCEMENT-BOUNDARY of the publisher's policy-mode choice — the policy-mode tag THIS page documents enforces only the DMARC- FAILING-MESSAGE disposition; the DKIM-replayed message class is STRUCTURALLY OUTSIDE the policy- mode enforcement boundary.
• DKIM cryptography basics — the PER-PUBLISHER-DKIM- CRYPTOGRAPHIC-TRUST-ANCHOR-PUBLICATION- DISCIPLINE-AS-LOAD-BEARING-UPSTREAM- CRYPTOGRAPHIC-PRE-REQUISITE-FOR-EVERY- p=quarantine-OR-p=reject-DMARC-POLICY-MODE- ENFORCEMENT-COMMITMENT companion to this RFC 7489 §6.3 policy-mode decision-tree reference. Where THIS page documents the per-publisher p=none / p=quarantine / p=reject policy-mode-progression decision-tree whose enforcement-mode commitment prerequisites a per-publisher per-receiver per-day DKIM-aligned-pass-rate floor, the DKIM-cryptography-basics spoke is the per-publisher per-selector cryptographic- trust-anchor publication-discipline operator-reference documenting the per- publisher per-selector RSA-key-pair generation, RFC 8301 RSA-2048-bit key- strength floor, and per-selector public- key TXT-record publication-grammar compliance at FOUR per-publisher cryptographic-discipline-vs-policy-mode- progression coupling dimensions: (i) per-publisher RFC 8301 RSA-2048- bit key-strength floor as load-bearing upstream cryptographic-input for per- publisher per-receiver per-day DKIM- aligned-pass-rate floor — per- publisher RSA-1024-bit-or-weaker keys cause per-receiver per-message DKIM- verification rejection at cryptographically- modern receivers (Gmail / Outlook / Yahoo enforce ≥1024-bit per RFC 8301 §3.1; emerging receivers enforce ≥2048-bit); per-publisher operator commitment to p=quarantine / p=reject REQUIRES per-publisher per-selector key- strength meeting the per-receiver per- receiver-organisation per-publisher per- message DKIM-verification floor; (ii) per-publisher per-selector cryptographic-trust-anchor rotation-cadence as load-bearing operator-discipline for per-publisher policy-mode-progression sustainability — per-publisher per-selector key-rotation operator- discipline (RFC 6376 §3.6.1 overlap-window pattern) directly bounds the per-publisher per-selector compromise-window and the per-publisher per-selector verification- failure-rate during rotation events; a per-publisher operator on p=reject with degraded per-selector rotation- discipline absorbs the per-receiver per- message rejection cost of every rotation- event verification-failure as legitimate- message-loss; (iii) per-publisher per-selector cryptographic-trust-anchor publication-discipline as DMARC-aggregate- report DKIM-evaluation-result decode reference — per-publisher operator pre-progression diagnostic of per-publisher per-receiver per-day per-row dkim=fail / dkim=permerror evidence requires the per-publisher per-selector cryptographic-trust-anchor publication- discipline reference the DKIM-cryptography- basics spoke documents (per-selector public-key absence, per-selector key-too- small, per-selector key-revoked, per- selector TXT-record byte-grammar defect); (iv) per-publisher per-selector cryptographic-key-custody-isolation operator-discipline as per-publisher per-policy-mode-progression operational- readiness invariant — per- publisher operator advancement from p=quarantine to p=reject commits the per- publisher operator to the per-selector cryptographic-key-custody discipline the DKIM-cryptography-basics spoke documents (per-selector private-key storage with HSM-or-equivalent custody-discipline, per- selector key-access logging, per- selector rotation-key custody-handover protocol) — a per-selector private-key exfiltration event under p=reject materializes as per-attacker per-message signed-from-outside-the-publisher payload that the per-receiver evaluator credentials as per-publisher-authentic.
• DMARC multi-domain strategy — the PER-ORGANIZATIONAL-DOMAIN-POLICY-TAG- MATRIX companion to this RFC 7489 §6.3 policy-mode decision-tree reference. Where THIS page documents the SINGLE-DOMAIN choice between p=none, p=quarantine, and p=reject (plus the sp= subdomain-policy, np= non-existent-subdomain- policy, and pct= sampling- percentage modifiers that refine each), the multi-domain-strategy spoke documents the PER-DOMAIN POLICY-TAG MATRIX an operator managing multiple organizational domains must MAINTAIN as the cardinality of the decision-tree extends from a single publisher's apex-domain into the FIVE structurally-distinct multi-domain operator cohorts: (i) MULTI-BRAND ESTATES where each brand-domain runs its own customer-mail operation at potentially different deployment-maturity points (brand-A at p=reject after 18 months of rollout, brand-B at p=quarantine in the middle of its own rollout, brand-C at p=none still inventorying senders) — each brand-domain's policy-tag choice MUST be made independently per the evidence ITS aggregate-report stream surfaces, not per the most-advanced sibling-brand's policy; (ii) ACQUISITION DOMAINS recently acquired through M&A whose pre-acquisition DMARC posture is UNKNOWN and whose initial policy MUST start at p=none with aggregate- reporting enabled to surface the acquisition's third-party senders before any policy advance; (iii) PARKED DOMAINS the operator owns but does not send mail from where the correct multi-domain-strategy choice is to publish p=reject; sp=reject; adkim=s; aspf=s with NO active senders (so any observed traffic is unambiguous spoofing) — DIFFERENT from the primary-domain choice; (iv) SEND-ONLY DOMAINS the operator uses for outbound transactional mail (mailer.example.com, bounce.example.com) where the policy choice ratchets faster than the receive- also primary domain because the sender inventory is bounded to a small known ESP set; (v) RECEIVE-ONLY DOMAINS the operator uses only for inbound mail (legal@example.com mail-only domain) where the policy choice is structurally irrelevant to inbound-DMARC enforcement but the operator still publishes p=reject as a hygiene marker. Read the multi-domain-strategy spoke when the policy-mode decision-tree on THIS page produces conflicting answers for different domains in the estate, or when an organizational-restructure event (merger, divestiture, brand consolidation) forces a re-evaluation of the entire policy-tag matrix across the multi-domain portfolio rather than just the primary apex domain.
• DKIM failure verdicts explained — the ROLLOUT-GATE companion to this policy-mode decision tree. Where this page documents the operator CHOICE between p=none, p=quarantine, and p=reject (and the sp= / np= / pct= modifiers that refine each), the DKIM-failure-verdicts spoke is the per-RFC-6376-§3.9 + RFC-8601-§2.7.1 reference catalogue for the seven auth_results/dkim/result verdict values (none, neutral, pass, fail, policy, temperror, permerror) whose ZERO-fail invariant on the authorised-sender roster is the operational PRE-CONDITION for every rollout-step advance documented on THIS page. Concretely: advancing from p=none to p=quarantine is operationally safe ONLY when every authorised-sender source on the aggregate-report stream is producing auth_results/dkim/result=pass (cryptographic baseline) AND policy_evaluated/dkim=pass (alignment baseline) — a residual fail / policy / permerror verdict from an unfixed authorised sender means the rollout advance will quarantine legitimate mail. Read the verdict-decode catalogue when this page's section 3 (rollout sequencing p=none → p=quarantine → p=reject) needs to translate the rollout-gate "zero DKIM-fail verdicts from authorised senders" pre-condition into per-verdict remediation actions before clicking the rollout-advance button — each verdict class (none demands signer-side DKIM deployment, fail demands one of the 12+ canonical DKIM-failure-sub-cause remediations, policy demands weak-key rotation or canonicalization-policy alignment, permerror demands signer-side key-parsing or DKIM-Signature header-syntax fix, temperror demands DNS infrastructure investigation only if persistent across many report intervals) maps to a specific operator action that must complete BEFORE the rollout advance is safe.
• Phishing protection - the business-outcome companion to the attacker-bypass threat model. Where the bypass page enumerates HOW attackers slip past weak DMARC, this page enumerates the seven canonical phishing attack patterns (look-alike-domain spoofing, exact-domain spoofing, display-name spoofing, hijacked legitimate-domain abuse, subdomain abuse on unprotected child labels, vendor- compromise spear-phishing, business-email- compromise wire-fraud) and maps each directly to the policy-mode value that denies it: p=reject closes exact-domain spoofing (pattern 2), apex+ sp=reject closes subdomain abuse (pattern 5), and the np=reject RFC 9091 tag closes never-existed-subdomain abuse (pattern 5 variant). Read this page when stakeholders ask "which phishing pattern does each policy mode prevent" — the answer is in the policy-mode-to-pattern mapping table on the phishing page.
• Email spoofing explained — the THREAT-TECHNIQUE FOUNDATION companion to this policy-mode decision-tree. Where this page documents the operator CHOICE between p=none / p=quarantine / p=reject (and the sp= / np= / pct= modifiers that refine each), the email-spoofing pillar documents the SEVEN CANONICAL THREAT-TECHNIQUES each policy-mode choice closes (or fails to close): (1) direct domain From: forgery — defeated by p=quarantine minimum at apex, closed reliably only at p=reject; (2) envelope MAIL FROM spoofing per RFC 5321 — closed at every policy mode via SPF alignment-fail when aspf=s; (3) display-name spoofing — NOT defeated by ANY DMARC policy-mode because the social- engineering layer is orthogonal to the cryptographic-authentication layer DMARC enforces; (4) lookalike-domain registration — NOT defeated by ANY policy-mode on the operator's OWN domain (a separately registered cornpany.com publishes its OWN p=reject that doesn't protect the legitimate company.com); (5) IDN homograph attacks (Unicode confusables per UTS #39) — same limitation; (6) cousin-domain registration — same limitation; (7) subdomain takeover via abandoned DNS — defeated by sp=reject when the takeover targets an existing subdomain, by np=reject per RFC 9091 when the takeover targets a never-existed subdomain. The email-spoofing pillar makes the policy-mode-to-threat-technique mapping EXPLICIT at section 6 ("How DMARC defends against spoofing") and section 7 ("What DMARC does NOT prevent") — critical operator knowledge when advocating for the p=reject milestone documented on this page. Read the email-spoofing pillar when stakeholders ask "which spoofing techniques does the policy-mode advance from p=quarantine to p=reject CLOSE that p=quarantine still leaves open" — the threat-technique-to-policy-mode mapping is the canonical operator vocabulary for framing that escalation case.
• Business Email Compromise (BEC) — the FINANCIAL-IMPACT JUSTIFICATION companion to this policy-mode decision-tree. Where this page documents the operator CHOICE between p=none / p=quarantine / p=reject (and the sp= / np= / pct= modifiers), the BEC spoke documents the FINANCIAL-IMPACT THREAT SCENARIO each policy-mode choice closes (or fails to close): (a) CEO fraud (executive- impersonation wire transfers averaging $130K per incident per FBI IC3 2022) — closed reliably ONLY at p=reject on the apex domain because p=quarantine still allows the spoofed message to surface in the recipient's Junk folder where curious executives still routinely retrieve and actively respond; (b) invoice fraud ($26B+ FBI IC3 cumulative 2013-2022) — closed at p=reject via same domain spoofing-blocking but ALSO requires sp=reject for attacker-pivot via never-used finance sub-domains and lookalike-domain countermeasures outside DMARC scope; (c) payroll diversion (HR-impersonation rerouting direct-deposit) — same policy-mode efficacy profile as CEO fraud; (d) vendor email compromise (VEC, hijacked legitimate vendor mailbox spoofing invoice-fraud) — NOT defeated by ANY DMARC policy-mode because the source is a HIJACKED LEGITIMATE mailbox publishing valid DMARC-pass mail; defense pivots to behavioural-detection and out-of-band verification on the recipient organisation's side. The BEC spoke makes the policy-mode-to-financial- outcome mapping EXPLICIT — critical operator knowledge when building the executive case for the p=quarantine → p=reject advance documented on this page. The BEC threat scenario is the canonical "WHY" answer when finance / legal / executive stakeholders ask "is the operational risk of advancing worth it" — the answer is the FBI IC3 dollar figures the BEC spoke catalogues. Read the BEC spoke when budgeting the rollout or building the executive case for the operational investment in the policy-mode advance documented here.
• Email deliverability fundamentals — the POLICY-ENFORCEMENT-TIER-AS- DELIVERABILITY-KPI-CAUSAL-DRIVER companion to this DMARC policy-modes page. The deliverability spoke is the business-outcome quantification layer that connects every per-domain p=none / p=quarantine / p=reject enforcement-tier decision THIS page documents to the downstream KPI signal the publisher's marketing-operations / transactional- email-operations / customer- communications dashboard tracks at FOUR deliverability-KPI-vs-policy- mode causal-driver dimensions: (i) p=none deployment → DMARC- verdict positive-sender-reputation signal earned, inbox-placement-rate DOES NOT improve from p=reject enforcement-tier signal absence, because the receiver-side deliverability-engine treats p=none as observational-monitoring rather than enforcement-commitment — the deliverability spoke documents the deliverability-KPI baseline for the p=none monitoring- only enforcement-tier: the publisher earns the FOUNDATIONAL positive-sender-reputation signal for emitting valid SPF + DKIM verdicts, but the receiver-side inbox-placement engines treat p=none as observational rather than enforcement-commitment, so the INCREMENTAL inbox-placement- rate LIFT achievable through DMARC-as-deliverability-signal does NOT materialise until the publisher advances to p=quarantine + p=reject; (ii) p=quarantine deployment → bounce-rate increases for mis- aligned sender streams, inbox- placement-rate begins to LIFT as receivers begin treating p=quarantine as enforcement- commitment for OTHER unauthorised senders impersonating the publisher — the deliverability spoke documents how the p=quarantine deployment- tier transition causes observable bounce-rate increases in the publisher's bounce- pipeline for sender streams the operator had not yet identified as mis-aligned (transactional ESP signing with wrong d=, SaaS- platform sender signing with platform d= rather than customer d=, forwarder rewrites invalidating SPF) — the operator's response is the ALIGNMENT-AUDIT diagnostic workflow before advancing to p=reject; concurrently receivers begin treating the publisher's p=quarantine as enforcement-commitment for OTHER unauthorised senders impersonating the publisher, which begins LIFTING the publisher's legitimate-mail inbox-placement-rate above the p=none baseline; (iii) p=reject deployment → bounce-rate stabilises at post-alignment-audit floor, inbox-placement-rate LIFTS to steady-state ceiling, deferral- rate decreases as receivers treat publisher's full- enforcement posture as a load-bearing positive sender-reputation signal — the deliverability spoke documents how the p=reject full-enforcement deployment- tier transition causes the publisher's bounce-rate to stabilise at the post- alignment-audit floor (only legitimately mis-aligned mail bounces, because every intentional sender stream has been aligned during the p=quarantine phase) while the inbox-placement-rate LIFTS to its steady-state ceiling and the deferral- rate decreases as receivers treat the publisher's full- enforcement posture as the strongest possible positive sender-reputation signal short of arriving via a receiver-side allow-listed TIP relationship; (iv) pct= ramp during p=quarantine and p=reject deployment → the deliverability spoke documents the per-percent- ramp deliverability-KPI monitoring workflow that controls bounce-rate excursion within the publisher's incident- response tolerance — the deliverability spoke documents the operational runbook for monitoring the bounce-rate / deferral- rate / complaint-rate / inbox-placement-rate KPI time-series across the pct= ramp documented on THIS page (pct=10 → pct=25 → pct=50 → pct=100), and provides the per-percent- ramp deliverability-KPI threshold matrix (acceptable bounce-rate delta per pct= increment, acceptable deferral-rate delta, acceptable complaint-rate delta) that the publisher's enforcement-tier ramp commitment is bounded by. Read the deliverability spoke WITH this DMARC policy-modes page when scheduling the enforcement-tier ramp OR when triaging a deliverability-KPI excursion observed during the ramp — the policy-modes page is the protocol-level enforcement-tier reference, and the deliverability spoke is the business-outcome causal-driver companion that determines whether an enforcement-tier advance is BUSINESS- SAFE at any given time.
• BIMI Verified Mark Certificates (VMC and CMC) — the commercial-milestone companion to the policy-mode progression on this page - the VMC eligibility gate is structurally coupled to the policy-mode value documented here: the BIMI rendering pipeline at Gmail / Apple Mail / Yahoo / Fastmail / Outlook will NOT honour a BIMI record (and will NOT display the brand logo in the inbox) unless the publishing domain's DMARC record is at p=quarantine or p=reject at the apex AND (for subdomain logos) sp=quarantine or sp=reject on the same record — meaning the policy-mode progression documented on this page from p=none through p=quarantine to p=reject is the structural gating-prerequisite for the VMC commercial- acquisition workflow. Operators reading this page to understand the policy-mode semantics need the BIMI-certificates spoke as the COMMERCIAL-MILESTONE companion documenting what they can monetise once the policy-mode progression completes: which of the two issuing CAs (DigiCert vs Entrust) accepts which trademark evidence pack (registered trademark for VMC vs unregistered mark for CMC), the 12-month VMC renewal cadence, the byte-level PEM-bundle file format the BIMI record's a= URL must serve, the mailbox-provider-specific rendering coverage (VMC supported by Gmail + Apple Mail + Yahoo + Fastmail + Outlook; CMC currently only honoured by Gmail), and the canonical deployment- failure-pattern taxonomy (logo-not-rendering even with valid VMC, mailbox-provider- specific quirks, rendering-suppression cases triggered by DMARC enforcement gaps). Read this spoke when the policy-mode progression on this page raises the stakeholder question "what is the next milestone after we reach p=reject" — the answer is the VMC commercial-acquisition workflow the BIMI-certificates spoke documents. Distinct from the help_bimi_explained.php pillar (which is the BIMI-PROTOCOL-WALKTHROUGH primer) — this is the BIMI-CERTIFICATE-ACQUISITION-AND-RENEWAL PROCEDURE that the BIMI protocol presupposes but does not itself document, gated structurally on the policy-mode progression this page covers.
• BIMI SVG Tiny PS file-format requirements - the BIMI rendering pipeline at Gmail / Apple Mail / Yahoo / Fastmail / Outlook has TWO gates that must BOTH be passed before the brand logo appears in the inbox: the FIRST gate is the DMARC policy-mode value documented on this page (must be at p=quarantine or p=reject at the apex, AND for subdomain logos sp=quarantine or sp=reject on the same record); the SECOND gate is the SVG-Tiny-PS file-format compliance of the actual logo asset the BIMI record's l= URL serves. The BIMI-certificates entry above covers the COMMERCIAL-TRADEMARK- ATTESTATION arm of the BIMI deployment gated on this page's policy-mode progression; the BIMI-SVG-requirements spoke covers the TECHNICAL-FILE-FORMAT arm of the same deployment, ALSO gated on this page's policy-mode progression. Even a tenant that has reached p=reject AND completed VMC issuance will still fail to render the logo if the SVG asset violates Tiny PS profile constraints: scripts, animations, external resources, embedded metadata, non-square aspect ratio, or missing baseProfile="tiny-ps" attribute each individually suppress the logo rendering at the mailbox-provider side. Operators reading this page to understand the policy-mode semantics need the BIMI-SVG-requirements spoke as the TECHNICAL-FILE-FORMAT companion that pairs with the BIMI-certificates entry above to cover BOTH non-policy gates the BIMI rendering pipeline imposes downstream of the policy-mode progression on this page: which SVG features are allowed and which are forbidden under the Tiny PS 1.2 profile, the square-aspect-ratio viewBox="0 0 SIZE SIZE" requirement, the baseProfile="tiny-ps" document-element attribute, the ~32 KB unminified / ~8 KB minified file- size operational target, the application/svg+xml / image/svg+xml MIME-type- serving requirements from the URL the BIMI record's l= tag points to, and the canonical validation tools (BIMI Group's SVG validator, Cloudflare's BIMI inspector, Mailhardener's BIMI lookup tool). Read this spoke alongside the BIMI-certificates entry above when stakeholders ask "what is the complete BIMI checklist after we reach p=reject" — the answer is the TWO-ARM PAIR of VMC commercial- acquisition (certificates spoke) plus SVG-Tiny-PS technical-authoring (svg-requirements spoke) both gated on this page's policy-mode progression.
• DMARC myths and misconceptions - the canonical reference for "I heard DMARC breaks mailing lists" and related folklore.
• SPF explained - the IP-authorisation primitive that DMARC evaluates via SPF alignment.
• SPF mechanisms explained — the PUBLISHER-SIDE-DMARC-POLICY-TIER- ADVANCEMENT-DEPENDS-ON-AGGREGATE-PER- MECHANISM-SPF-PASS-RATE companion to this policy-mode reference. Where THIS page documents the operational policy-tier progression ladder (p=none monitoring → p=quarantine partial enforcement → p=reject full enforcement) and the gating decisions between tiers, the SPF-mechanisms-explained spoke is the BYTE-GRAMMAR REFERENCE documenting the eight RFC 7208 §5 per- mechanism evaluation primitives whose AGGREGATE per-mechanism pass-rate is the load-bearing input the publisher consults before every tier advancement. The POLICY- TIER-DEPENDS-ON-PER-MECHANISM-PASS-RATE cross-reference establishes FIVE structurally- distinct per-mechanism dependencies that gate the policy-mode progression: (i) ip4: / ip6: literal-IP mechanism pass-rate — the SAFEST mechanisms per RFC 7208 §5.6 (deterministic, no DNS lookup, zero void-lookup risk) and the FIRST mechanism category whose ≥99% pass- rate is a prerequisite for advancing from p=none to p=quarantine; (ii) include: cross-domain mechanism cascade pass-rate — the MOST FRAGILE mechanism category because include: introduces cross-domain dependencies on third-party SPF records whose owner can change them without notice; the SPF-mechanisms spoke documents how each include: contributes to the cumulative 10-DNS- lookup budget per RFC 7208 §4.6.4, and publisher discipline around include:-pass-rate auditing is the prerequisite for advancing from p=quarantine to p=reject; (iii) a: / mx: dynamic-resolution mechanism pass-rate — RFC 7208 §5.3 / §5.4 mechanisms that resolve to the domain's A or MX RRs at evaluation time; these are STABLE-IN-AGGREGATE but OPERATIONALLY-FRAGILE because a temporary DNS outage at the publisher's MX hosts produces transient SPF-fail bursts that appear in the RUA stream as alignment- failure spikes; the SPF-mechanisms spoke documents the per-mechanism evaluation algorithm whose understanding the publisher must internalise before accepting that transient bursts are NOT evidence of a policy-tier-blocking problem; (iv) deprecated ptr: mechanism — the SPF-mechanisms spoke documents the RFC 7208 §5.5 deprecation status of ptr: and the receiver-side DNS-lookup-budget cost (~5 of 10 budget); publishers with legacy ptr: records in their SPF chain CANNOT responsibly advance to p=reject because every PTR-mechanism resolution adds a permerror risk that breaks the SPF-leg of the DMARC evaluation; (v) terminating all qualifier — the SPF-mechanisms spoke documents the four qualifier prefixes (+all, -all, ~all, ?all) whose semantic difference is the operational LOCK-IN decision the publisher makes at the moment of advancing from p=quarantine to p=reject (the canonical guidance is to pair p=reject with -all for full commitment; ~all with p=reject is a contradiction the SPF-mechanisms spoke documents as a common operator mistake). Pair this page (the policy-tier progression ladder reference) with the SPF-mechanisms spoke (the per-mechanism byte-grammar reference) when authoring a per- organisational-domain tier-advancement decision — the spoke documents the canonical per-mechanism evaluation primitives whose aggregate pass-rate the publisher must verify is stable before any tier advancement.
• SPF qualifiers explained - the PUBLISHER-SIDE-DMARC-POLICY-TIER- ADVANCEMENT-DEPENDS-ON-AGGREGATE-PER- QUALIFIER-SPF-RESULT-CODE-DISTRIBUTION companion to this policy-mode reference. Where THIS page documents the operational policy-tier progression ladder (p=none monitoring → p=quarantine partial enforcement → p=reject full enforcement) and the per-tier ramp-exit criteria the publisher's RUA evidence stream must satisfy, the dedicated SPF-qualifiers spoke documents the STRUCTURALLY-LOAD-BEARING publisher-side qualifier-prefix choice whose four coordination dimensions determine the per-tier ramp-exit criteria's per-mail-source SPF-leg contribution profile: (i) terminating -all (HardFail) commits the publisher to the strongest receiver-side spf=fail verdict for unmatched IPs, which is the operationally- required terminal state at p=reject because the receiver-side rejection is the load-bearing operational control - the per-tier ramp from p=quarantine to p=reject typically pairs with publisher migration from ~all to -all at the SPF record's terminating mechanism; the SPF- qualifiers spoke documents the HardFail- commitment-as-p=reject-ramp-exit-criterion coordination contract; (ii) terminating ~all (SoftFail, RFC 7208 §10.1 operator-default during DMARC rollout) is the appropriate qualifier-prefix at p=none monitoring tier and early p=quarantine tier because it produces a non-rejecting spf=softfail verdict that permits the publisher to observe full traffic-stream evidence in the RUA stream without inducing receiver-side rejection of legitimate-but-unrecognised mail sources - the policy-tier ramp from p=none to p=quarantine commonly proceeds WITHOUT requiring SPF- qualifier change from ~all; the SPF-qualifiers spoke documents the SoftFail-during-rollout publisher-discipline and the per-tier qualifier-prefix appropriate choice matrix; (iii) publisher publishing ?all (Neutral) or +all (Pass) at the SPF record's terminating mechanism produces an evidence- stream-confounding RUA stream where the spf=neutral or spf=pass verdicts include BOTH legitimate-publisher-authorised traffic AND attacker-spoofed traffic indistinguishably - the publisher's policy-tier ramp from p=none upward CANNOT advance safely because the RUA stream's per-source spf-result distribution loses the publisher-vs-attacker discrimination signal that the ramp-exit criteria depend on; the SPF-qualifiers spoke documents the ?all/+all- defeat-of-policy-ramp-evidence operator- mistake-class and the publisher-side audit discipline for verifying the SPF record's terminating-qualifier appropriateness before each policy-tier advancement; and (iv) per-mechanism qualifier prefixes (not just the terminating all) modulate the receiver-side spf-result distribution per-source-IP - publisher publishing ~include:thirdparty.example.com commits SoftFail for third-party-include- routed traffic while +include:firstparty.example.com (omitted-qualifier shorthand) commits Pass for first-party-include-routed traffic - the policy-tier ramp's per-mail-source ramp-exit criterion must be evaluated per-mechanism-qualifier-segmented rather than aggregated across the entire SPF record; the SPF-qualifiers spoke documents the per-mechanism qualifier prefix discipline and the operator- decision framework for choosing per- mechanism qualifier prefixes that align the publisher's per-mail-source spf- result-code contribution with the per-policy-tier ramp-exit criteria this page documents.
• SPF DNS-TXT-record byte syntax — the POLICY-MODE-RAMP-AT-PUBLISHER- DEPENDS-ON-BYTE-LEVEL-SPF-RECORD- CORRECTNESS companion to this policy-mode reference. Where THIS page documents the operational policy-tier progression ladder (p=none monitoring → p=quarantine partial enforcement → p=reject full enforcement) and the gating decisions between tiers, the SPF-DNS-syntax spoke is the BYTE-GRAMMAR REFERENCE documenting the RFC 7208 §3 SPF-record byte-syntax whose byte-precise authoring is the load-bearing prerequisite the publisher must verify is correct BEFORE ANY ramp exit criterion can be evaluated. The POLICY-MODE-RAMP-DEPENDS-ON-BYTE-LEVEL-SPF- CORRECTNESS cross-reference establishes FOUR structurally-distinct byte-grammar dimensions whose correctness gates the policy-mode progression: (i) v=spf1 version-prefix byte-correctness — RFC 7208 §4.5 mandates the literal six-byte v=spf1 token as the very first bytes of the TXT record (case-insensitive but otherwise byte-exact); operators publishing common typos (v=spf 1 with embedded space, v=SPF1 uppercase, bare spf1 missing the v= tag prefix) trigger receiver-side SPF parsers to skip the record entirely or return permerror, which inverts the p=none monitoring intent into 100%-permerror RUA noise — the publisher cannot baseline a legitimate-sender pass-rate before advancing to p=quarantine if the record never authenticates in the first place; (ii) qualifier-prefix byte-discipline (-all / ~all / ?all / +all) — RFC 7208 §4.6 / §4.7 mandates exactly one of four single-byte qualifiers immediately preceding the terminating all mechanism; the per-byte qualifier choice is the operational LOCK-IN decision at p=quarantine → p=reject advancement (the canonical pairing is -all with p=reject for full commitment; ~all with p=reject is a contradiction; +all or ?all undermine p=reject entirely by producing spf=pass for any sender, which makes the policy-tier advancement operationally meaningless); (iii) per-mechanism token whitespace/comma byte-discipline — RFC 7208 §4.6.1 mandates mechanisms are separated by exactly ONE space and tokens are byte-contiguous (no embedded spaces inside ip4:1.2.3.4, no comma separators, no trailing slashes); operators publishing ip4: 1.2.3.4 (with embedded space) or include: example.com (with embedded space) or ip4:1.2.3.4/ (with trailing slash) trigger permerror at receiver-side evaluation, producing the same RUA noise pattern as the version-prefix error class and blocking ramp progress at every tier; (iv) 255-byte TXT-string fragmentation discipline at p=quarantine → p=reject flatten-cycle — RFC 1035 §3.3.14 constrains each TXT-record string to a maximum of 255 bytes; publishers crossing the threshold during the flatten cycle (a common operational step in the p=quarantine → p=reject ramp when consolidating nested includes into a single SPF record) MUST split the record into multiple consecutive quoted strings per RFC 7208 §3.3, and the post-flatten byte-budget must remain within the receiver-side SPF parser's per-string parsing tolerance — operators publishing a single 256-byte string trigger DNS-resolver truncation or per-parser handling divergence, which produces the spf=permerror burst that inverts the p=reject ramp's anti-spoofing intent into a self-inflicted deliverability outage. Pair this page (the policy-tier progression ladder reference) with the SPF-DNS-syntax spoke (the canonical RFC 7208 §3 byte-grammar reference) when authoring a per-organisational-domain tier-advancement plan — the spoke documents the byte-precise SPF-record syntax whose correctness the publisher must verify is intact at every ramp exit criterion before any tier advancement is operationally safe.
• DKIM explained - the cryptographic-signing primitive that DMARC evaluates via DKIM alignment.
• DKIM for Microsoft 365 — the M365-TENANT-DKIM-PASS-VERDICT- AS-PER-POLICY-MODE-ENFORCEMENT-INPUT companion to this DMARC policy-modes pillar. Where THIS page documents the DMARC p= tag value space (p=none / p=quarantine / p=reject), the per-policy- mode enforcement-decision semantics the receiver-side DMARC evaluator applies, the per-policy-mode pct=N ramp consumption pattern, and the per-policy-mode receiver-side application-layer disposition contract — i.e. the POLICY-MODE-DECISION-TREE side of the DMARC enforcement pipeline — the M365-DKIM spoke is the M365- TENANT-DKIM-PASS-VERDICT-PROVIDER companion documenting the M365-tenant- specific DKIM deployment topology whose cryptographic-signature-verification outcome (the dkim=pass verdict at the Friendly-From-header alignment boundary) becomes the LOAD-BEARING per-policy-mode enforcement input the receiver-side DMARC evaluator consumes when applying the policy-mode decision THIS page documents. Concretely, the spoke documents FOUR M365-DKIM-verdict-vs- DMARC-policy-mode-consumption dimensions: (i) M365-tenant- EOP-managed dual-selector selector1._domainkey / selector2._domainkey CNAME-delegated DKIM signing produces the per-message DKIM signature whose cryptographic verification at the receiver-side delivers the dkim=pass verdict the DMARC evaluator consumes as ONE of the TWO authentication inputs (alongside SPF) under the policy-mode decision THIS page documents — the M365-tenant DKIM-Signature header carrying d=<tenant-domain> + s=selector1|selector2 becomes the SECOND alignment-pathway that drives the DMARC pass/fail verdict consumed by the per-policy-mode enforcement decision THIS page documents; (ii) M365 dual- selector rotation cadence is operationally INVISIBLE to the per- policy-mode enforcement contract — Microsoft auto-rotates between selector1 and selector2 on a managed cadence (typically several months), and the per-policy-mode enforcement decision THIS page documents at the receiver-side DMARC evaluator STRUCTURALLY consumes either selector's dkim=pass verdict identically — the M365-tenant operator does NOT need to coordinate per-policy-mode ramp tier advancements with the Microsoft-managed selector-rotation midpoint, structurally decoupling the M365-DKIM rotation cadence from the per-policy-mode pct=N ramp tier advancement contract; (iii) M365-tenant-specific dkim= permerror / dkim=temperror failure modes (CNAME-published-but-Microsoft- managed-target-TXT-not-yet-provisioned, customer-DNS-provider-stripping-CNAME- query, M365-tenant-rename-de-couples- existing-selector-CNAMEs) introduce STRUCTURAL FAILURE PATTERNS that the per-policy-mode enforcement decision THIS page documents amplifies under p=quarantine / p=reject — whereas p=none tolerates these failure modes by emitting RUA reports without applying enforcement, p=quarantine moves the impacted M365-tenant-outbound mail to Junk and p=reject STRUCTURALLY DROPS the mail, making the M365-DKIM-deployment-correctness- invariant the spoke documents a LOAD- BEARING prerequisite for safe advancement through the per-policy-mode ramp tiers THIS page documents; and (iv) the M365-tenant terminal p=reject posture creates a STRUCTURAL CROSS-CONSUMPTION DEPENDENCY between the M365-DKIM-deployment- correctness invariant the spoke documents and the per-policy-mode enforcement contract THIS page documents — the M365-tenant operator advancing to the terminal p=reject tier THIS page documents requires ALL M365-tenant- outbound mail streams to carry a cryptographically-valid Friendly-From- header-aligned DKIM signature (per-the-M365-deployment-topology the spoke documents); if a subset of M365-tenant-outbound mail streams emits without DKIM signing (e.g., a misconfigured connector, a SHARED- TENANT-DKIM rotation midpoint window, a legitimately-aligned but DKIM- unsigned partner-relayed stream), terminal p=reject drops the impacted stream at the receiver- side enforcement boundary. Read the DKIM-for-Microsoft-365 spoke alongside this DMARC policy-modes pillar when the M365-tenant operator is planning per-policy-mode ramp tier advancement — the M365-DKIM-deployment-correctness invariant the spoke documents is the LOAD-BEARING per-policy-mode enforcement-input prerequisite whose operational integrity the per-policy- mode ramp tier advancement contract THIS page documents depends on.
• DKIM for Google Workspace — the WORKSPACE-TENANT-DKIM-PASS- VERDICT-AS-PER-POLICY-MODE-ENFORCEMENT- INPUT companion to this DMARC policy- modes pillar. Where THIS page documents the DMARC p= tag value space (p=none / p=quarantine / p=reject), the per-policy- mode enforcement-decision semantics the receiver-side DMARC evaluator applies, the per-policy-mode pct=N ramp consumption pattern, and the per-policy-mode receiver-side application-layer disposition contract — i.e. the POLICY-MODE-DECISION-TREE side of the DMARC enforcement pipeline — the Workspace-DKIM spoke is the WORKSPACE-TENANT-DKIM-PASS-VERDICT- PROVIDER companion documenting the Workspace-tenant-specific DKIM deployment topology whose cryptographic- signature-verification outcome (the dkim=pass verdict at the Friendly-From- header alignment boundary) becomes the LOAD-BEARING per-policy-mode enforcement input the receiver-side DMARC evaluator consumes when applying the policy-mode decision THIS page documents. Concretely, the spoke documents FOUR Workspace-DKIM-verdict-vs-DMARC-policy- mode-consumption dimensions: (i) Workspace-tenant-Admin- Console-managed single-selector google._domainkey (or operator-chosen custom selector) TXT- published DKIM signing produces the per-message DKIM signature whose cryptographic verification at the receiver-side delivers the dkim=pass verdict the DMARC evaluator consumes as ONE of the TWO authentication inputs (alongside SPF) under the policy-mode decision THIS page documents — the Workspace-tenant DKIM-Signature header carrying d=<workspace-tenant-domain>; s=google (or operator-custom selector) becomes the SECOND alignment- pathway that drives the DMARC pass/fail verdict consumed by the per-policy-mode enforcement decision THIS page documents; (ii) Workspace operator-controlled single-selector manual rotation cadence is operationally VISIBLE to the per-policy-mode enforcement contract during the per- rotation overlap-window — unlike the Microsoft-managed M365 dual- selector auto-rotation cadence (which the per-policy-mode enforcement contract STRUCTURALLY consumes identically regardless of which selector is active), the Workspace operator-controlled single-selector rotation introduces a per-rotation overlap-window during which both the old-selector TXT record and the new- selector TXT record must be published simultaneously at the Workspace customer-vanity-domain DNS zone — if the operator advances the rotation midpoint BEFORE the overlap-window receiver-side cache TTL has elapsed, receivers still cache the old-selector public key, causing dkim=fail on the new-selector-signed mail and per-policy-mode-amplified enforcement under p=quarantine / p=reject; (iii) Workspace-tenant-specific dkim= permerror / dkim=fail failure modes (Workspace Admin Console generates new key but operator forgets to publish TXT record at customer-vanity-domain DNS zone, registrar-side TXT-record split-string concatenation breaks the 2048-bit public key, per-rotation overlap-window not coordinated with Workspace-side selector-rotation midpoint) introduce STRUCTURAL FAILURE PATTERNS that the per-policy-mode enforcement decision THIS page documents amplifies under p=quarantine / p=reject — whereas p=none tolerates these failure modes by emitting RUA reports without applying enforcement, p=quarantine moves the impacted Workspace-tenant-outbound mail to Junk and p=reject STRUCTURALLY DROPS the mail, making the Workspace-DKIM-deployment- correctness invariant the spoke documents a LOAD-BEARING prerequisite for safe advancement through the per- policy-mode ramp tiers THIS page documents; and (iv) the Workspace-tenant terminal p=reject posture creates a STRUCTURAL CROSS-CONSUMPTION DEPENDENCY between the Workspace- DKIM-deployment-correctness invariant the spoke documents and the per- policy-mode enforcement contract THIS page documents — the Workspace-tenant operator advancing to the terminal p=reject tier THIS page documents requires ALL Workspace-tenant-outbound mail streams to carry a cryptographically-valid Friendly-From-header-aligned DKIM signature (per-the-Workspace- deployment-topology the spoke documents); if a subset of Workspace- tenant-outbound mail streams emits without DKIM signing (e.g., a misconfigured Workspace gateway, legacy mail-relay rule emitting without Workspace-DKIM-routing, a legitimately-aligned but DKIM-unsigned third-party-sender authorized through SPF only), terminal p=reject drops the impacted stream at the receiver-side enforcement boundary. Read the DKIM-for-Google-Workspace spoke alongside this DMARC policy- modes pillar when the Workspace- tenant operator is planning per- policy-mode ramp tier advancement — the Workspace-DKIM-deployment- correctness invariant the spoke documents is the LOAD-BEARING per- policy-mode enforcement-input prerequisite whose operational integrity the per-policy-mode ramp tier advancement contract THIS page documents depends on.
• Why SPF alone is insufficient - the six structural limitations of an SPF-only posture (forwarder break per RFC 7208 §11.4, no header-From coverage, no integrity protection of the message body, no policy contract, no aggregate-feedback loop, the 10-DNS-lookup ceiling per RFC 7208 §4.6.4) that JUSTIFY every policy mode this page documents existing in the first place. Where this page is the WHAT and HOW of p=none / p=quarantine / p=reject, the SPF-insufficiency spoke is the WHY — p=none exists because operators need to instrument the SPF-DKIM-coverage gap before closing it; p=quarantine exists because the SPF-alone posture leaves the header-From-spoof attack surface wide open and the operator needs a partial-enforcement gate to start diverting spoofed mail without breaking legitimate forwarding; p=reject exists because the SPF forwarder-break problem cannot be closed without DKIM alignment AND a published rejection contract that receivers execute. Read this spoke when an operator asks "why can't I just publish SPF and skip DMARC" or "why does p=none alone provide zero spoof-defence" — the SPF-insufficiency spoke walks the six structural gaps and the DMARC-binding remedy in a single 13-section reference, mapping each gap directly to the policy-mode that closes it on this page.
• DMARC for Google Workspace - per-MUA deployment guide; receiver behaviour under each policy mode.
• DMARC for Microsoft 365 - per-MUA deployment guide; Microsoft-specific oreject and action=quarantine behaviour.
• DMARC for Hybrid Exchange (on-prem + Microsoft 365) - the HYBRID-COEXISTENCE-PHASE-AWARE- POLICY-MODE-ADVANCEMENT companion to this p=none vs p=quarantine vs p=reject head-to-head comparison. Where THIS page documents the per-mode enforcement floor for BIMI eligibility and CISA BOD 18-01 compliance, the hybrid- coexistence spoke is the HYBRID- TOPOLOGY-ADVANCEMENT-COORDINATION REFERENCE documenting that hybrid Exchange / Exchange Online coexistence introduces TWO outbound boundaries (on-prem outbound through the HCW- configured send connector + EXO cloud- egress through Exchange Online Protection) whose p=none to p=quarantine to p=reject policy-mode advancement MUST be coordinated in lockstep: premature p=quarantine advancement before the on-prem outbound boundary reaches the KPI 1 pass-rate threshold produces silent quarantine of legitimate on-prem-originated mail (PowerShell-scripted monitoring alerts, DUI scanner notifications, line-of- business application-relay traffic); premature p=quarantine advancement before the EXO cloud-egress boundary reaches the threshold produces silent quarantine of EXO-originated mail (Outlook desktop clients, mobile OWA, per-mailbox-rule auto-forwards). The hybrid-coexistence spoke documents the phase-aware coordination discipline every hybrid operator must apply BEFORE advancing through the policy- mode progression THIS page compares.
• DMARC for transactional email - per-ESP deployment guide (SendGrid, Mailgun, SES, Postmark, SparkPost).
• DMARC for SaaS senders — heterogeneous-policy-mode-distribution across the multi-tenant platform's customer fleet - the per-deployment deep dive on the SaaS-multi-tenant-platform operator persona whose fleet of customer domains SIMULTANEOUSLY occupies ALL THREE policy modes documented on this page. Where THIS page is the canonical pillar reference documenting what each of the three p= values (none, quarantine, reject) does at the receiver-execution layer and what the per-mode operator-workflow looks like during the canonical p=none→p=quarantine→p=reject rollout, the SaaS-senders spoke is the MULTI-TENANT-PLATFORM-OPERATOR-VIEW of that same policy-mode reference — the SaaS platform does NOT see a single domain transitioning through the three modes in temporal sequence; the SaaS platform sees a HETEROGENEOUS DISTRIBUTION across its tenant fleet at every instant in time (some customers at p=none in the monitoring phase, some customers at p=quarantine in the soft- enforce phase, some customers at p=reject in production enforcement, ALL simultaneously). This creates a structurally-distinct operator challenge the single-domain rollout reference on THIS page does not address: the SaaS platform must support per-tenant DKIM-key isolation so a p=reject-enforcement tenant's signing failures do not trigger cross-tenant blocking on the same shared virtual-MTA pool; the SaaS platform must coordinate per-tenant aggregate-report attribution from the receiver-emitted RUA stream that multiplexes all tenants' results into a single SaaS-platform-level reporting endpoint; and the SaaS platform must implement per-tenant rollout-phase tracking so the customer- success workflow can advise each customer on their NEXT policy-mode advancement independently of every other tenant. Read the SaaS-senders spoke when an operator working at a SaaS platform asks "how do I roll out DMARC across hundreds or thousands of customer domains in different policy modes simultaneously" or when an operator working at a customer asks "how does my SaaS provider's infrastructure interact with my p=quarantine or p=reject policy mode" — the SaaS-senders spoke documents the multi-tenant-platform-side of the single-tenant policy-mode workflow this page documents at the receiver-execution layer.
• DMARC for Shared Hosting — shared-IP-reputation-bounded policy-mode selection on Plesk / DirectAdmin / ISPConfig / generic-no-control-panel platforms — the SHARED-HOSTING-POLICY-MODE-CONSTRAINT companion to this policy-modes pillar for the SMB operator population whose p= selection is bounded by shared-IP-reputation drag. Where THIS page documents each p= value at the receiver-execution layer for any operator regardless of sending infrastructure, the shared-hosting spoke documents the per-mode SELECTION CONSTRAINTS the shared-IP-pool operator persona faces: p=none is the practical starting floor for any tenant on a co-tenant-shared IP because the operator does not control which other tenants on the same /24 are sending unauthenticated mail that pollutes the IP's reputation signal; p=quarantine is the practical ceiling for many shared-hosting tenants because premature p=reject ramps couple the operator's own legitimate mail to the co-tenant-pool's authentication-failure rate (a co-tenant's misconfigured SPF causes the operator's own mail to land in the quarantine bucket via shared-IP-reputation cross-contamination at major receivers); the pct= sampling tag is more useful on shared-hosting than on dedicated-IP because per-tenant sample-rate observation isolates the shared-IP-pool contribution to the DMARC-fail rate from the per-tenant authoring-error contribution; sp= + np= subdomain hardening is uniquely valuable on shared-hosting because the parked / unused-subdomain attack surface is the primary BEC-staging vector for the shared-IP-pool tenant population. Read the shared-hosting spoke when selecting the p= value for a domain hosted on a control-panel-tier shared platform (cPanel / Plesk / DirectAdmin / ISPConfig) or a generic-no-control-panel shared host — the spoke is the authoritative reference for the per-mode SELECTION CONSTRAINTS the shared-IP-pool operator persona faces that a dedicated-IP-pool operator does not.
• Email authentication glossary - definitions of every term used on this page.
• Email security & privacy glossary — the DMARC-POLICY-MODE-CHOICE-RESOLVES- BACK-TO-SECURITY-AND-PRIVACY-VOCABULARY- DEFINITIONS companion to this DMARC policy- mode protocol-mechanic reference. Where THIS page documents the three DMARC policy modes at the protocol-mechanic level (RFC 7489 §6.3: p=none reporting- only monitoring without any receiver-side enforcement action, p=quarantine receiver-side message routing to junk- folder or quarantine for review, p=reject receiver-side message rejection at SMTP-time or post-DATA bounce; the per-mode receiver-side decision tree against the policy_evaluated.disposition field; the sp= subdomain- policy override; the pct= partial-application percentage during staged rollouts), 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 2048 of this page) documenting the canonical single-sentence definitions for FOUR security-and-privacy terms-of-art whose OPERATIONAL-MEANING the DMARC policy- mode mechanism THIS page documents directly engages with: (i) monitoring- without-enforcement-discipline — the glossary's canonical definition of monitoring-without-enforcement as the publisher-side-observability-discipline- producing-rollout-blocker-detection-data- without-collateral-deliverability-impact is what the p=none policy mode on THIS page encodes: receivers evaluate DMARC, emit aggregate-report rows, but DO NOT apply disposition.quarantine or disposition.reject — the foundational observability surface for the sender-inventory discovery phase of every DMARC rollout; (ii) quarantine- as-junk-folder-mitigation — the glossary's canonical definition of quarantine as the receiver-side routing of message to junk-folder / quarantine review queue rather than inbox or SMTP-bounce is what the p=quarantine policy mode on THIS page encodes: a mid-rollout threshold where receivers reduce inbox placement for misaligned mail without full rejection — preserving recoverability if a legitimate sender was missed during the p=none monitoring phase; (iii) 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 p=reject policy mode on THIS page encodes: receivers respond with SMTP 5xx rejection or bounce-after-DATA, providing the canonical production-ready DMARC posture against the BEC / exact-domain- spoofing / replay-attack threat classes; (iv) graduated-policy-rollout- staging-discipline — the glossary's canonical definition of graduated-rollout-staging-discipline as the canonical-multi-phase-progression- from-monitoring-to-enforcement-with-pct- ramps-and-sp-subdomain-coverage-decisions is what the canonical p=none → p=quarantine → p=reject progression on THIS page encodes: paired with pct=<N> percentage- ramp and sp=<policy> subdomain-coverage tags, the policy- mode mechanism becomes the foundational DMARC rollout-staging primitive. Read the email-security-and-privacy-glossary spoke alongside this DMARC policy-mode reference when designing the DMARC- rollout-staging documentation that must correlate per-mode-choice on the publisher-side record authoring with the per-threat-class defense coverage + per-rollout-stage deliverability- risk profile at the receiver-side DMARC evaluation — the glossary is the canonical security-and-privacy- vocabulary substrate; THIS page is the canonical DMARC-policy-mode protocol- mechanic reference whose per-mode choice determines the per-threat-class defense profile + per-rollout-stage deliverability-risk profile the glossary's vocabulary catalogues.
• CAA records explained - the PUBLISHER-SIDE-DNS-PUBLISHED- POLICY-ASSERTION-PARALLEL companion reference. Where THIS page documents the DMARC p= policy-mode spectrum (p=none monitoring / p=quarantine / p=reject) as a publisher- side DNS-published TXT-record policy assertion that EXTERNAL EVALUATORS (DMARC-validating receivers) enforce on the publisher's behalf at message evaluation time, the CAA-records spoke documents the STRUCTURALLY-PARALLEL publisher-side DNS-published RR-type-257 policy-assertion pattern that EXTERNAL EVALUATORS (CAs about to issue a certificate) enforce on the publisher's behalf at certificate-issuance time. Both RFC-specified mechanisms share the same RFC-design pattern: PUBLISHER PUBLISHES a DNS RR encoding a policy assertion in the publisher's domain zone (DMARC at _dmarc.<domain> TXT record / CAA at <domain> RR-type-257 record), an EXTERNAL EVALUATOR (DMARC-validating receiver / certificate- issuing CA) MUST FETCH AND RESPECT the policy assertion at decision time (RFC 7489 §6.6.3 for DMARC / RFC 8659 §4 for CAA), and the publisher's policy REPLACES THE EVALUATOR'S DEFAULT WITH AN EXPLICIT PUBLISHER-CHOSEN ENFORCEMENT CONTRACT (DMARC: explicit p=quarantine / p=reject replaces the receiver's default "deliver to inbox" / CAA: explicit issue "digicert.com" replaces the CA's default "issue if domain ownership validates"). The TWO mechanisms additionally share a CRITICAL- ENFORCEMENT-FLAG pattern (DMARC p=reject / CAA flags=128 critical bit) where the publisher ELEVATES the policy from advisory to mandatory-rejection-on-failure, and a REPORTING-CONTACT pattern (DMARC rua= aggregate report / CAA iodef= incident contact) where the publisher receives observability signal from external evaluators about policy-decision events. Read the CAA-records spoke alongside this page when authoring the PUBLISHER-SIDE-DNS-PUBLISHED-POLICY- ASSERTION section of an organisation's comprehensive RFC-published-policy deployment plan — the DMARC p=quarantine / p=reject ramp documented on this page is ONE EXEMPLAR of the broader RFC-published-policy design pattern that CAA also exemplifies; an organisation tightening its DMARC p= policy mode is also almost-always-correctly tightening its CAA records as part of the broader publisher-side-DNS-published-policy- assertion hardening posture. The two policy mechanisms operate at different protocol layers (DMARC at message- evaluation / CAA at certificate-issuance) but enforce the same publisher-side intent: the publisher REPLACES the external evaluator's permissive default with an explicit publisher-chosen enforcement contract that defends the publisher's domain identity against unauthorised use.
• DKIM selectors explained - the PER-SELECTOR-DKIM-PASS-RATE-FLOOR- AS-LOAD-BEARING-UPSTREAM-INPUT-TO-DMARC- POLICY-MODE-RAMP-ADVANCEMENT companion to this DMARC policy-mode-ramp reference. Where THIS page documents the per- publisher per-domain DMARC policy-mode ramp advancement cadence (p=none monitoring phase → p=quarantine partial enforcement phase with pct= ramp → p=reject full enforcement phase), the DKIM-selectors spoke documents the per-publisher per- domain per-selector DKIM-signing-key namespace discipline — the canonical <selector>._domainkey.<domain> TXT-record per-selector namespace partition, the per-ESP per-publisher selector allocation policy (selector1 / selector2 for M365, google for Workspace, s1 / s2 for SendGrid, k1 for Mailgun), the per-selector overlap-window rotation cadence, the per-selector revocation- via-empty-p= primitive — whose per- publisher per-domain per-selector DKIM- aligned-pass-rate floor is the per- message receiver-side authentication outcome each per-publisher per-domain DMARC policy-mode ramp advancement decision STRUCTURALLY DEPENDS on. Pair THIS DMARC policy-mode-ramp reference WITH the DKIM-selectors spoke when AUTHORING the per-publisher per-domain ramp-advancement readiness gate that ADVANCES p=none → p=quarantine → p=reject — the per-selector DKIM-aligned-pass-rate floor sustained across the monitoring phase is the operationally-grounded readiness signal every per-publisher per-domain ramp advancement decision requires BEFORE committing the per-domain p=quarantine or p=reject policy-mode transition this page documents.
• DMARC for cPanel - the PER-CPANEL-TENANT-PER-DOMAIN-DMARC- POLICY-MODE-RAMP-ADVANCEMENT-WORKFLOW companion to this DMARC policy-mode-ramp reference. Where THIS page documents the canonical per-publisher per-domain DMARC policy-mode ramp advancement cadence (p=none monitoring phase → p=quarantine partial enforcement phase with pct= ramp → p=reject full enforcement phase), the cPanel deployment guide documents the control-panel- operator-facing instantiation of the ramp-advancement workflow against the WHM/cPanel Email Deliverability UI — the per-cPanel-tenant per-domain DMARC TXT publication at _dmarc.<tenant-domain> emitted by the control-panel UI, the per-tenant per-domain DMARC p= tag value selection workflow (initial p=none publication via the control-panel UI's default DMARC record scaffold, per-tenant per-domain pct= partial enforcement ramp via control-panel UI tag edits, per-tenant per-domain p=reject commitment via control-panel UI tag edits), and the per-cPanel-server per- tenant per-domain DMARC-aligned-pass- rate visibility surfaced through the Email Deliverability UI's per-tenant per-domain authentication status panel. Pair THIS DMARC policy-mode-ramp reference WITH the cPanel deployment guide when AUTHORING per-cPanel-tenant per-domain ramp-advancement runbooks whose per-tenant per-domain p=none → p=quarantine → p=reject phase advancement decisions must traverse the WHM/cPanel Email Deliverability control-panel UI's operator-facing workflow surface.
• Domain Security Checker - live DNS lookups for SPF, DKIM, DMARC, MTA-STS, CAA, BIMI, and DNSSEC against any domain - check your current DMARC policy mode.
• Email Header Analyzer - paste a raw email header to see the Authentication-Results DMARC outcome inline.
• DNS Record Generator - interactive wizard for building DMARC records with the right p= + sp= + np= + pct= + rua= tags for each phase.
• SPF for Microsoft 365 — the per-M365-tenant per-domain v=spf1 include:spf.protection.outlook.com -all publication discipline this spoke documents produces the per-receiver per-day per-source-IP per-message first-hop SPF-aligned-pass evidence whose floor is the empirical readiness gate for advancing the per-publisher per-domain DMARC policy-tier ramp p=none → p=quarantine → p=reject THIS page catalogues. Read the M365 SPF spoke as the per-tenant envelope- MAIL-FROM authorization-publication input materially producing the per- receiver SPF-aligned-pass-rate floor that gates each per-publisher per- domain policy-tier advancement decision the policy-modes catalogue documents.
• TLS-RPT report format - the PER-PUBLISHER-PER-DOMAIN-DMARC- POLICY-TIER-RAMP-ADVANCEMENT-PARALLEL- TRANSPORT-LAYER-OBSERVABILITY-GATE companion to this DMARC policy-modes catalogue. Where THIS page documents the three RFC 7489 §6.3 p= tag values (p=none, p=quarantine, p=reject) and the per- receiver per-message disposition action each value instructs for DMARC-failed mail, the TLS-RPT report-format spoke documents the STRUCTURALLY-PARALLEL per-receiver per-publisher per-day RFC 8460 §4 JSON aggregate-report byte- grammar whose per-failure result-type enum (starttls-not-supported, certificate-host-mismatch, certificate-expired, sts-policy-fetch-error, sts-webpki-invalid) provides the transport-layer evidence every per-publisher per-domain policy- tier ramp-advancement decision the policy-modes catalogue documents structurally requires. Pair this policy-modes catalogue with the TLS-RPT-report-format spoke at FOUR per-publisher per-domain DMARC-policy- mode-to-TLS-RPT-JSON-consumer dimensions: (i) per-publisher per-domain per-receiver per-day JSON- report ingestion as transport-layer ramp-gate empirical input parallel to the per-domain DMARC aggregate-XML stream - the per-publisher per-domain _smtp._tls.<domain> published rua=mailto: endpoint receives per-day JSON aggregate-reports from every receiver processing the per-domain egress under MTA-STS or DANE policy, and the report- format spoke's byte-grammar reference enables per-receiver per-day per-policy- evaluation parsing without which the per-publisher per-domain policy-tier ramp-advancement decision lacks the parallel transport-layer evidence every defensible p=quarantine → p=reject advancement requires; (ii) per-failure result-type enumeration as per-publisher per-domain per-receiver per-day silent-failure attribution catalogue at each policy-tier boundary - the spoke's per- failure result-type enum lets per-publisher per-domain operators distinguish receiver-side starttls-not-supported (peer receiver lacks STARTTLS) from per-publisher sts-policy-fetch-error (per-publisher mta-sts.<domain> policy file unreachable from peer receiver), per-publisher certificate-host-mismatch (per-publisher mta-sts.txt mx: allow-list specifies MX hostnames whose presented certificates fail SNI matching), per- publisher sts-webpki-invalid (per-publisher receive MX presents a certificate from an untrusted root chain or expired intermediate) without which every transport-failure attribution collapses to a single opaque "STARTTLS failed" signal and the per-publisher per-domain policy-tier ramp-advancement decision lacks the per-failure-class transport-layer evidence the defensible advancement requires; (iii) per-publisher per-domain per-receiver per-day summary.total-successful-session-count / total-failure-session-count as MTA-STS-mode-progression-readiness empirical input PARALLEL to per-domain DMARC policy-tier ramp-advancement readiness - the spoke's per- day per-MX-host successful-vs-failed STARTTLS session-count aggregation is the LOAD-BEARING empirical-readiness gate the per-publisher per-domain operator uses to advance the per- domain MTA-STS policy mode from testing to enforce alongside the per-domain DMARC policy mode from p=quarantine to p=reject - the two ramp progressions must advance in lock-step so the transport-layer silent-failure regression budget never out-strips the message-layer enforcement budget; and (iv) per-failure sending-mta-ip / receiving-mx-hostname / failure-reason-code as per-publisher per-domain per-receiver per-day cross-receiver consistency- deviation incident-triage primitive at each policy-tier boundary - when one receiver shows sustained certificate-host-mismatch on a specific sending-mta-ip while peer receivers show clean STARTTLS during a per-publisher per-domain p=quarantine → p=reject ramp-advancement review, the per-failure attribution lets per-publisher per-domain operators attribute the failure to a specific receiving-MX-hostname vs a per-publisher certificate misconfiguration that would silently amplify the message-layer enforcement regression budget the policy-tier advancement consumes. Pair THIS policy-modes catalogue with the TLS-RPT-report- format spoke when designing the per- publisher per-domain DMARC policy-tier ramp-advancement readiness-gate discipline that fuses the per-domain DMARC RUA-XML message-layer evidence stream with the per-domain TLS-RPT- JSON transport-layer evidence stream into the unified per-publisher per- domain authentication-and-encryption- posture observability surface every defensible p=none → p=quarantine → p=reject ramp-advancement STRUCTURALLY DEPENDS on for per- publisher per-domain end-to-end ramp- advancement defensibility.
• MTA-STS for Google Workspace — the WORKSPACE-TENANT-PER-CUSTOM-DOMAIN- PER-DMARC-POLICY-MODE-RAMP-AS-PARALLEL- PER-TENANT-MTA-STS-THREE-MODE-RAMP companion to this DMARC policy-mode ramp-progression reference. Where THIS page documents the per-publisher per- domain application-layer DMARC three- mode policy state-machine (p=none monitoring → p=quarantine partial- enforcement → p=reject full-enforcement), the MTA-STS-for- Google-Workspace spoke documents the per-Workspace-tenant per-custom-domain transport-layer MTA-STS three-mode ramp companion at four per-tenant cross-layer three-mode coordination dimensions: (i) per-Workspace- tenant per-custom-domain transport- layer mode: none baseline parallels application-layer p=none monitoring baseline — Workspace tenants publishing initial MTA-STS publish mode: none as no-effect baseline + per-tenant TLS-RPT v=TLSRPTv1; rua=mailto: to receive per-receiver per-day JSON- aggregate evidence; this transport- layer baseline runs parallel to per- tenant application-layer p=none + rua=mailto: baseline producing per-tenant per-day DMARC aggregate-XML evidence; (ii) per-Workspace-tenant per- custom-domain transport-layer mode: testing partial- enforcement parallels application-layer p=quarantine pct=<n> partial-enforcement — Workspace tenants advance per-custom-domain MTA- STS to mode: testing where sending MTAs report per-tenant TLS- failures to the per-tenant TLS-RPT endpoint but do NOT structurally reject delivery; this transport-layer staging commitment runs parallel to per-tenant application-layer p=quarantine pct=10/25/50/100 staging-ramp commitment where receivers report per- message DMARC verdicts to per-tenant RUA endpoint while applying staged quarantine disposition; both stages are per-tenant per-day evidence-driven commit-gate progression; (iii) per-Workspace-tenant per- custom-domain transport-layer mode: enforce terminal- enforcement parallels application- layer p=reject terminal- enforcement — Workspace tenants advance per-custom-domain MTA-STS to mode: enforce where sending MTAs REJECT delivery to MX hostnames not matching the publisher-pinned mx: allow-list and refuse cleartext-delivery fallback; this transport-layer terminal commitment runs parallel to per-tenant application- layer p=reject terminal commitment where receivers reject per- message DMARC-fail mail at SMTP delivery time; per-tenant cross-layer terminal-enforcement coordination ensures publisher-side defense-in-depth commitment lands coherently on both layers simultaneously; and (iv) per-Workspace-tenant per- custom-domain per-stage ramp-readiness gate observable through complementary evidence streams — Workspace tenants gate per-tenant per-stage ramp-advancement on per-receiver per- day per-source-IP DMARC-aligned-pass- rate convergence (application-layer evidence stream) AND per-receiver per- day per-MX-host TLS-handshake success- rate convergence (transport-layer evidence stream); per-tenant per-stage cross-layer ramp-readiness gate coordination is the canonical per- Workspace-tenant defense-in-depth deployment discipline the per-tenant operator program executes. Read the Workspace-MTA-STS deployment spoke alongside this DMARC policy-mode ramp-progression reference when coordinating per-Workspace-tenant per- custom-domain cross-layer three-mode ramp-progression across the application- layer DMARC enforcement boundary and transport-layer MTA-STS enforcement boundary.
• DKIM troubleshooting — the PER-MESSAGE-DKIM-FAILURE-MODE- DIAGNOSTIC-LADDER-AS-PER-PUBLISHER-PER- DOMAIN-DMARC-POLICY-MODE-PROGRESSION- PREREQUISITE-DISCIPLINE-FLOOR companion to this DMARC-policy-modes reference. Where THIS page documents the per-publisher per- domain DMARC policy-mode catalogue (p=none monitor-only / p=quarantine partial- enforcement at pct=1/10/25/50/100 ramp- cadence / p=reject terminal-enforcement) + the per-publisher per-domain per-policy- mode operational semantics + the per- publisher per-domain per-mode ramp- progression discipline-floor, the DKIM- troubleshooting spoke is the per-message DKIM-failure-mode diagnostic-ladder reference per-publisher operators consult BEFORE committing per-publisher per-domain DMARC policy-mode progression at FOUR per- policy-mode DKIM-discipline-floor prerequisite dimensions: (i) per- publisher per-domain DMARC p=none monitor- only mode prerequisite per-publisher per- domain DKIM-failure-mode baseline-survey discipline — per-publisher operators initiating per-publisher per- domain DMARC p=none monitor-only publication as the per-publisher per-domain policy- ramp Phase 1 survey-window concurrently survey per-publisher per-domain DKIM- failure-mode baseline state (per-selector publication audit + per-canonicalization- mode survey + per-key-size + per-rotation- cadence baseline) because the per-publisher per-domain p=none monitor-only window produces per-publisher per-domain per- receiver-side aggregate-report evidence streams the per-publisher per-domain DKIM- failure-mode baseline-survey discipline decodes the per-publisher per-domain per- message DKIM verification posture from; (ii) per-publisher per-domain DMARC p=quarantine partial-enforcement mode prerequisite per-publisher per-domain DKIM-failure-mode discipline-floor- readiness — per-publisher operators committing per-publisher per-domain DMARC p=quarantine partial-enforcement publication (pct=1, 10, 25, 50, 100 progressive ramp) MUST have per-publisher per-domain DKIM- failure-mode discipline-floor readiness in place because per-publisher per-domain p= quarantine partial-enforcement commits the per-publisher per-domain to per-receiver- side per-message quarantine dispositions for per-publisher per-domain per-message DKIM-fail-AND-SPF-fail per-message combinations — per-publisher per-domain operators in this state MUST have per- publisher per-domain DKIM-failure-mode discipline-floor that minimises per- publisher per-domain per-message legitimate- mail DKIM-verification-failure rate to prevent per-publisher per-domain per- receiver-side per-message legitimate-mail quarantine-disposition spike; (iii) per-publisher per-domain DMARC p=reject terminal-enforcement mode prerequisite per-publisher per-domain DKIM-failure-mode terminal-discipline- floor + per-publisher per-domain DKIM- signed-mail-flow universality — per-publisher operators committing per- publisher per-domain DMARC p=reject terminal-enforcement publication (the per- publisher per-domain DMARC policy-ramp terminal commitment) MUST have per- publisher per-domain DKIM-failure-mode terminal-discipline-floor PLUS per- publisher per-domain DKIM-signed-mail-flow universality (every per-publisher per- domain per-tenant-SaaS-platform per-source- IP per-message stream carries per-message DKIM-signature) because per-publisher per- domain p=reject terminal-enforcement commits the per-publisher per-domain to per-receiver-side per-message reject dispositions for per-publisher per-domain per-message DKIM-fail-AND-SPF-fail per- message combinations — per-publisher per- domain per-message DKIM verification failures at terminal-enforcement scope directly translate per-publisher per- domain to per-receiver-side per-message legitimate-mail-reject dispositions; (iv) per-publisher per-domain DMARC policy-mode rollback discipline coordinated with per-publisher per-domain DKIM- failure-mode rollback discipline — when per-publisher per-domain operators detect per-publisher per-domain deliverability KPI degradation post per- publisher per-domain DMARC policy-mode ramp-progression, the per-publisher per- domain rollback discipline applies BOTH to the per-publisher per-domain DMARC publication (downshift p= or downshift pct=) AND verifies per-publisher per- domain DKIM-failure-mode discipline-floor stability across the rollback window — the per-publisher per-domain DKIM- troubleshooting per-failure-mode diagnostic-discipline reference is the per-publisher per-domain operational cross-reference per-publisher per-domain operators consult during per-policy-mode rollback coordination. Read the DKIM- troubleshooting spoke alongside this DMARC-policy-modes reference when AUTHORING per-publisher per-domain DMARC policy-mode ramp-progression runbooks that integrate per-publisher per-domain DKIM-failure-mode discipline-floor readiness verification, when AUDITING per-publisher per-domain DKIM-signing posture BEFORE committing to per- publisher per-domain DMARC p=quarantine or p=reject ramp-progression milestones, when EXECUTING per-publisher per-domain per-mode-progression DKIM-failure-mode- rate baseline-survey discipline at the per-publisher per-domain p=none monitor- only window, or when ESTABLISHING per- publisher per-domain joint per-policy- mode-rollback discipline coordinating per- publisher per-domain DMARC mode downshift with per-publisher per-domain DKIM- failure-mode discipline-floor stability verification.
• RFC 7489 - DMARC - the DMARC specification itself.
• RFC 9091 - DMARC np= tag - the non-existent-subdomain policy tag extension.
• draft-ietf-dmarc-dmarcbis - the in-progress DMARC successor that removes pct= and modernises the spec.
• SPF forwarding issues — the canonical operator-side SPF-forwarding-issue remediation reference whose per-forwarder envelope-rewrite-induced spf=fail-with- aligned=false defect-class is amplified by the per-publisher terminal DMARC policy-mode state THIS three-state-ladder reference documents at four policy-mode-to- SPF-forwarding-failure-severity resolution dimensions: (i) p=none-as-monitor-only policy mode is the canonical load-bearing per-publisher diagnostic-observability-window baseline — under p=none forwarding- induced spf=fail rows surface in the per-receiver per- source-IP rua-aggregate-XML evidence stream WITHOUT receiver- side dispositional action, giving the publisher a baseline- observability window to enumerate the per-forwarder envelope-rewrite defect-classes the SPF-forwarding- issues reference catalogues BEFORE the terminal-state policy- mode advancement amplifies the per-row-rejection severity; (ii) p=quarantine-as-pct=- ramp policy mode is the canonical load-bearing per-publisher gradient-coverage rollout window for the per-forwarder remediation sequence — under p=quarantine; pct=N the per-publisher pct=-ramp proportion converts the per-row per-forwarder spf=fail-with- aligned=false rate into a per-receiver per-source-IP Junk- folder quarantine action at pct=-bounded coverage, giving the publisher the per-rollout-stage empirical-evidence stream the SPF-forwarding-issues remediation playbook needs to drive the per-forwarder include-token- addition / SRS-enablement / ARC- Sealer-trust-list-publication cutover; (iii) p=reject; pct=100-as- terminal-state policy mode is the canonical load-bearing per- publisher 100%-coverage deliverability-failure amplifier — under terminal-state p=reject; pct=100 every per-forwarder envelope- rewrite-induced spf=fail-with- aligned=false row converts deterministically into a per- receiver SMTP-5xx rejection, the per-publisher deliverability consequence the SPF-forwarding- issues reference IS the load-bearing remediation playbook for; and (iv) the sp=-subdomain- policy-tag coordination discipline is the canonical load-bearing per-publisher subdomain-mail-stream-coverage amplifier — per-publisher per-subdomain mail-streams (alumni-newsletter news.example.com + bounce-handler bounces.example.com + per-acquired-subsidiary subsidiary.example.com) each emit forwarding-vulnerable outbound mail whose per-row spf=fail-with- aligned=false rejection severity is determined by the per- publisher sp=quarantine vs sp=reject tag-value choice the policy-mode reference documents the per-subdomain coordination discipline for. Read the SPF-forwarding-issues spoke ALONGSIDE this DMARC- policy-modes reference whenever the publisher scopes a per- publisher per-rollout-stage forwarder-remediation coordination plan — the per- publisher terminal-state policy- mode advancement THIS three- state-ladder reference documents IS the load-bearing per-row rejection-severity amplifier the per-forwarder envelope-rewrite + SRS + ARC-rescue remediation playbook the SPF-forwarding- issues reference documents is the load-bearing publisher-side per-stage downstream remediation consumer of.
• MTA-STS explained — the transport-layer SMTP-TLS-policy-enforcement complement to per-policy-mode progression — the LOAD-BEARING transport-layer SMTP-TLS-policy-enforcement complement to the three-state policy-mode ladder (none → quarantine → reject) THIS page documents. Where THIS page documents the per-publisher message- layer DMARC-policy-mode progression whose per-stage rejection-severity amplifies receiver-side enforcement of authentication verdicts, the MTA-STS pillar documents the per- publisher per-MX-host transport-layer SMTP-TLS-policy publication discipline (RFC 8461 mode=testing → mode=enforce progression mirroring the DMARC p=none → p=quarantine → p=reject ladder) whose per-stage TLS-stripping- refusal rate amplifies receiver-side enforcement of transport-confidentiality. Both ladders share the same staged- observability-before-enforcement publication-discipline pattern (testing / monitoring stage produces aggregate feedback BEFORE enforcement commitment), and an operator advancing DMARC from p=quarantine to p=reject without also publishing MTA-STS mode=enforce leaves the cross-layer in-transit TLS- stripping-AND-MITM-downgrade attacker- bypass class ungated even when the application-layer DMARC reject-state commits the maximum receiver-side message-rejection severity. Read the MTA-STS pillar alongside this DMARC policy-modes reference whenever the per-publisher policy-mode progression plan extends to a complete cross- layer enforcement-state coordination plan.
• MTA-STS policy file syntax (RFC 8461 §3.2 byte-by-byte) — the PER-PUBLISHER-PER-DOMAIN-mta-sts.txt- POLICY-FILE-BYTE-FORMAT-AS-LOAD-BEARING- TRANSPORT-LAYER-PARALLEL-MODE-LADDER companion to this DMARC application- layer policy-mode progression reference. Where THIS page documents the per- publisher per-domain DMARC application- layer policy-mode progression (p=none observation → p=quarantine intermediate enforcement → p=reject terminal enforcement) governing the per- publisher per-domain message-rejection- severity ratchet, the MTA-STS-policy- syntax spoke documents the byte-by-byte publication discipline of the per- publisher per-domain https://mta-sts.<d>/.well- known/mta-sts.txt policy-file whose per-publisher per-domain transport- layer enforcement-state ladder STRUCTURALLY MIRRORS the DMARC application-layer enforcement-state ladder THIS page documents at FOUR per-publisher per- domain parallel-mode-ladder coupling dimensions: (i) per-publisher per-domain MTA-STS mode: none AS PARALLEL-CONTROL-STATE to DMARC p=none observation baseline — the per-publisher per-domain MTA-STS mode: none state is the structurally-parallel transport-layer baseline-control-state to the DMARC p=none baseline- observation-state THIS page documents at the application-layer; both ladders share the staged-observability-before- enforcement publication-discipline; (ii) per-publisher per-domain MTA-STS mode: testing AS PARALLEL- INTERMEDIATE-STATE to DMARC p=quarantine intermediate enforcement — the per-publisher per-domain MTA-STS mode: testing state produces per-MX-host TLS-handshake- failure aggregate evidence (via the coordinated TLS-RPT JSON-report channel) without enforcing per-receiver TLS- stripping-refusal; structurally-parallel to the DMARC p=quarantine intermediate-enforcement state THIS page documents (which produces quarantine- disposition aggregate evidence without terminal rejection); (iii) per- publisher per-domain MTA-STS mode: enforce AS PARALLEL- TERMINAL-STATE to DMARC p=reject terminal enforcement — the per-publisher per-domain MTA-STS mode: enforce state commits the maximum receiver-side TLS-stripping-refusal severity at the transport-layer, structurally-parallel to the DMARC p=reject terminal enforcement state THIS page documents at the application-layer; an operator advancing DMARC to p=reject without also advancing MTA-STS to mode: enforce leaves the cross-layer TLS-stripping-AND-MITM- downgrade attacker-bypass class ungated; (iv) per-publisher per-domain MTA-STS max_age: retention- window AS PARALLEL-COMMITMENT-CADENCE to DMARC p=quarantine / p=reject commitment-cadence — the MTA-STS max_age: field commits per-receiver caching of the published transport-layer policy for the declared duration (typically 604800 = 7 days for testing, 1209600 = 14 days for enforce); structurally-parallel to the DMARC publisher-side commitment cadence the per-publisher policy-mode ladder progression THIS page documents operationally maintains. Read the MTA- STS-policy-syntax spoke ALONGSIDE this DMARC policy-modes reference whenever the per-publisher policy-mode progression plan extends to the byte-format reference operators need when authoring the transport-layer policy-file at the per- publisher per-domain MTA-STS HTTPS endpoint.
• TLS-RPT DNS record syntax (RFC 8460 §3 byte-by-byte) — where THIS page documents the per-publisher per-domain DMARC policy-mode progression ladder (p=none observation → p=quarantine intermediate enforcement → p=reject terminal enforcement) governing the per- publisher per-domain APPLICATION- LAYER message-rejection-severity ratchet, the TLS-RPT-record-syntax spoke documents the byte-by-byte publication discipline of the per-publisher per-domain _smtp._tls.<d-domain> TXT-record whose JSON- report aggregate-evidence stream is the LOAD-BEARING TRANSPORT- LAYER observability primitive operationally coordinated with the per-publisher policy-mode progression ladder THIS page documents. FOUR structurally-distinct DMARC- POLICY-MODE-LADDER-TO-TLS-RPT- PUBLICATION coupling dimensions the TLS-RPT-record-syntax spoke operationally documents: (i) per-publisher per-domain TLS-RPT TXT-RR publication discipline as load-bearing prerequisite for the per-publisher per-domain DMARC p=none observation-state observability baseline — before the per-publisher per-domain DMARC policy-mode ratchet begins at p=none with its observation-only application- layer evidence-stream, the per-publisher per-domain TLS-RPT TXT-RR publication discipline must be in place to produce the structurally-parallel transport- layer observation-only evidence- stream — both protocols share the staged-observability-before- enforcement publication-discipline pattern THIS page operationalises; (ii) per-publisher per- domain TLS-RPT JSON-report evidence-stream as load-bearing transport-layer observability coordinated with the DMARC p=quarantine intermediate-enforcement state observability discipline — when the per-publisher per- domain DMARC policy-mode advances to p=quarantine, the per-publisher per-domain application-layer aggregate-XML evidence-stream surfaces per- source-IP quarantine-disposition rows; the per-publisher per- domain TLS-RPT JSON-report evidence-stream is the structurally- parallel transport-layer observability primitive whose per-publisher per-MX-host per- failure-class evidence stream must be reviewed in synchronization with the application-layer evidence-stream review the per- publisher policy-mode ladder progression demands; (iii) per-publisher per-domain TLS-RPT TXT-RR publication discipline as load-bearing prerequisite for the per-publisher per-domain DMARC p=reject terminal- enforcement state confidence- floor — advancing the per-publisher per-domain DMARC policy-mode to p=reject requires the per- publisher per-domain confidence floor that the per-source-IP application-layer authentication- evidence-stream is comprehensive; the per-publisher per-domain TLS-RPT JSON-report evidence- stream the TLS-RPT-record-syntax spoke documents the publication of is the load-bearing transport- layer evidence-stream whose cross-receiver per-MX-host per- failure-class observability surface complements the per-source-IP per-disposition application-layer observability surface to compose the per-publisher per-domain cross-OSI-layer confidence floor; (iv) per-publisher per- domain TLS-RPT policy-mode parallel (TLS-RPT JSON-report rua-only observation-state without MTA-STS enforce-mode) as load-bearing structural-parallel to the DMARC per-publisher per-domain p=none observation- state at the transport layer — both protocols share the staged-observability-before- enforcement discipline; per- publisher per-domain p=none + per-MX-host MTA-STS mode: testing + per-publisher per- domain TLS-RPT publication compose the cross-OSI-layer observation-only baseline before per-publisher per-domain p=quarantine / p=reject + per-MX- host MTA-STS mode: enforce compose the cross-OSI- layer enforcement-state. Read the TLS-RPT-record-syntax spoke ALONGSIDE this DMARC policy-modes reference whenever the per- publisher per-domain policy-mode progression plan extends to a cross-OSI-layer observability + enforcement framework — the TLS-RPT-record-syntax publication- discipline IS the load-bearing transport-layer observability primitive whose JSON-report aggregate-evidence stream is the structural-parallel transport- layer evidence-stream coordinated with the application-layer aggregate-XML evidence-stream the per-publisher per-domain policy-mode ladder progression THIS page documents materially depends on at the per-publisher per-domain cross-OSI-layer confidence-floor boundary.
• ARC (Authenticated Received Chain) — the PER-FORWARDER-HOP-CRYPTOGRAPHIC- CHAIN-OF-CUSTODY-PRESERVATION-MECHANISM companion to this DMARC-policy-modes operator reference. Where THIS page documents the per-publisher per-domain p=none → p=quarantine → p=reject enforcement-mode ramp progression (RFC 7489 §6.3, the pct= partial-deployment tag, the receiver-side per-mode-row disposition catalogue), the ARC- explained spoke is the per-forwarder- hop chain-of-custody-preservation companion documenting FOUR ARC-rescue coordination dimensions whose per- forwarder-path satisfaction gates whether forwarded per-publisher per- domain messages can survive the per-publisher per-domain policy-mode ramp without false-positive forwarder- path quarantine-or-reject disposition: (i) per-forwarder-hop ARC-Set authoring discipline at the forwarder- side MTA preserves the original message per-receiver authentication verdicts across the rewrite boundary — the RFC 8617 §4 ARC-Set (ARC-Authentication-Results + ARC-Message-Signature + ARC-Seal) authored at each forwarder hop captures the forwarder's per-message authentication decision and seals the chain against tampering; the ARC spoke documents the per-forwarder-hop ARC-Set authoring discipline whose per-publisher per-domain transit through forwarder paths preserves the per-receiver dkim=pass / spf=pass verdict that the per-publisher per-domain p=quarantine / p=reject enforcement mode this page documents depends on for true-positive disposition; (ii) per-receiver ARC-validator trust posture determines whether ARC-rescued forwarder-path verdicts contribute to the receiver-side DMARC-pass at per-publisher per- domain p=reject mode — Gmail's per-receiver ARC-validator trust posture (the per-receiver per-ARC-signer whitelist that allows the ARC-Authentication-Results verdict to be consumed as if it were the receiver-side Authentication-Results evaluation) materially varies across Gmail, M365, Yahoo, iCloud, and Apple Mail — the ARC spoke documents the per-receiver per-ARC-signer trust-posture catalogue whose per-receiver variance the per- publisher per-domain policy-mode rollout must account for; (iii) per- publisher per-domain ARC-rescue enforcement variance at p=quarantine vs p=reject determines the per-publisher per-domain forwarder-path-survival rate — when a per-publisher per-domain operator advances from p=quarantine to p=reject, the forwarder- path traffic whose ARC-rescue depended on per-receiver ARC-validator trust at p=quarantine falls into the per-receiver per-ARC-validator- not-trusted reject disposition; the ARC spoke documents the per- publisher per-domain ARC-rescue rate baseline observability that gates the per-publisher per-domain ramp advancement decision; (iv) per- publisher policy-mode-ramp ARC- rescue diagnostic visibility at the per-publisher per-domain per-day per-receiver per-forwarder- path RUA aggregate-XML evidence stream determines the per-publisher per-domain ramp-progression confidence — the per-day per-receiver per-forwarder-path per-policy-mode ARC-rescued-row vs ARC-not-rescued-row disposition breakdown surfaces in the aggregate- XML evidence stream as the per- publisher per-domain ramp-progression confidence baseline; the ARC spoke documents the per-publisher per- domain ARC-rescue diagnostic visibility operationally consumed at each ramp- progression decision point. Read the ARC spoke ALONGSIDE this DMARC- policy-modes reference whenever the per-publisher per-domain operator scopes a per-publisher per-domain policy-mode rollout for traffic that traverses mailing-list / per-account forwarder paths — the per-publisher per-domain policy-mode ramp progression THIS page documents IS the per-receiver per-message enforcement contract whose per- forwarder-path satisfaction the ARC- rescue mechanism the ARC spoke documents preserves the per-message cryptographic chain-of-custody for.
• DKIM DNS record syntax (RFC 6376 §3.6.2) — the byte-level encoding-layer reference for the public-key TXT record at <selector>._domainkey.<domain>. Before ramping from p=none through p=quarantine to p=reject, every publisher-controlled selector must publish a syntactically-valid DKIM TXT record so receiver-side verification produces dkim=pass AND the downstream DMARC alignment check the policy-mode-enforced action gates the receiver-side disposition decision on can complete. This DNS-syntax reference covers the v=DKIM1 prefix, the p= base64 public-key payload, the k= / h= / t= / s= tags, TXT-chunking past the 255-octet character-string limit, key revocation via empty p=, and the seven most common syntax mistakes that block a clean policy-mode rollout from p=none through p=reject.
• SPF 10-DNS-lookup limit (RFC 7208 §4.6.4) - the PER-POLICY-MODE-RAMP-PRE-CONDITIONED- ON-PER-PUBLISHER-SPF-PERMERROR-FREE- BASELINE companion to this DMARC policy- modes reference. Where THIS page documents the per-publisher per-domain three-mode policy state machine (p=none observation, p=quarantine partial enforcement, p=reject terminal enforcement) plus the per-publisher per-domain pct= sampling modifier and the per-publisher per-subdomain sp= / np= policy delegation tags, the SPF-lookup-limit spoke is the per-publisher per-domain cumulative- mechanism lookup-budget ARITHMETIC REFERENCE documenting the RFC 7208 §4.6.4 10-lookup hard ceiling whose violation flips the receiver-side SPF verdict to permerror on EVERY message regardless of the connecting IP — and permerror at the SPF leg cascades into dmarc=fail at p=reject on every DMARC- honouring receiver. The POLICY-MODES-VS- SPF-LOOKUP-LIMIT cross-reference establishes the per-publisher per-domain SPF-baseline-stability prerequisite that each policy-mode ramp transition structurally requires: (i) per- publisher pre-p=none baseline gate — the per-publisher per- domain SPF record must be at or under the 10-lookup ceiling BEFORE the first p=none publication, otherwise the receiver-side spf=permerror cascade contaminates the entire Phase-1 observation-window aggregate-report baseline and makes the per-publisher per-source-IP authentication-pass-rate KPI uninterpretable; (ii) per-publisher pre-p=quarantine ramp gate — the per-publisher per-domain SPF-baseline clearance must be re-verified before the p=none → p=quarantine ramp commits because the per-publisher per-source-IP dmarc=fail rate the operator uses to decide the ramp-commit threshold is dominated by spf=permerror rows when the lookup ceiling is crossed; (iii) per-publisher pre- p=reject terminal-enforcement gate — at p=reject terminal-enforcement, any per-publisher per-domain SPF-record edit that crosses the 10-lookup ceiling produces an immediate per-publisher per-message hard- bounce cascade on EVERY DMARC-honouring receiver because spf=permerror + p=reject yields dmarc=fail + 550 SMTP-time rejection at the receiving MX. Read THIS page when AUTHORING the per-publisher per- domain three-mode policy state machine progression; read the SPF-lookup-limit spoke when AUDITING the per-publisher per- domain SPF-baseline stability that each policy-mode ramp-commit step structurally requires BEFORE the next mode tightens.
• SPF permerror vs temperror — the PER-POLICY-MODE-RAMP-PRE- CONDITIONED-ON-PER-PUBLISHER-PER-DOMAIN- SPF-RESULT-CODE-STABILITY-VS-TRANSIENT- DNS-NOISE-DISCRIMINATION companion to this DMARC policy-modes reference, forming the natural cliff → cause-discrimination pair with the immediately-preceding SPF-lookup- limit entry (SPF-lookup-limit catalogues the 10-lookup permerror cliff arithmetic; SPF-permerror-vs-temperror catalogues the operational TERMINAL-vs-TRANSIENT discrimination an operator MUST perform when reading per-receiver per-day per- source-IP aggregate-XML row/auth_results/spf/result=permerror vs row/auth_results/spf/result=temperror evidence-stream rows). Where THIS page documents the per-publisher per-domain three-mode policy state machine (p=none observation, p=quarantine partial enforcement, p=reject terminal enforcement) plus the per-publisher per- domain pct= sampling modifier and per-publisher per-subdomain sp= / np= policy delegation tags, the SPF-permerror-vs- temperror spoke is the per-publisher per- domain SPF-result-code-stability DIAGNOSTIC REFERENCE documenting the terminal-vs-transient SPF-failure-class discrimination whose per-receiver per- mailbox-provider per-day distribution determines whether per-publisher per- domain action is REQUIRED (permerror class) or NOT-REQUIRED (temperror class) BEFORE the next policy-mode ramp commit. The POLICY-MODES-VS-SPF-PERMERROR-TEMPERROR cross-reference establishes the per- publisher per-domain SPF-result-code- stability discipline that each policy-mode ramp transition structurally requires at FOUR per-policy-mode-vs-SPF-failure-class coupling dimensions: (i) per- publisher pre-p=none baseline per-receiver per-mailbox-provider per-day permerror-vs-temperror disambiguation gate — the per-publisher per- domain Phase-1 publication-baseline REQUIRES per-receiver per-mailbox-provider per-day aggregate-XML row/auth_results/spf/result=permerror attribution streams to be discriminated FROM result=temperror attribution streams BEFORE per-publisher per-domain corrective-action publication is triggered; per-receiver per-day per- source-IP permerror evidence triggers per- publisher per-domain SPF record-syntax validation + per-publisher per-domain cumulative-mechanism 10-lookup arithmetic re-audit, while per-receiver per-day temperror evidence triggers NO per- publisher per-domain action (transient DNS-resolver downstream-of-publisher noise clears on retry); (ii) per- publisher pre-p=quarantine ramp per-receiver per-mailbox-provider per-day permerror-rate floor and temperror-rate ceiling per RFC 7489 §6.6.1 — the per-publisher per- domain Phase-3 pct=-ramp commit (pct=10 → pct=25 → pct=50 → pct=75 → pct=100) REQUIRES per-publisher per-domain Phase-2 per-receiver per-mailbox-provider per-day aggregate-XML permerror-rate to be at-or- under per-publisher per-domain permerror- rate floor (typically <0.1% of per-day per-source-IP authenticated message volume) BEFORE per-publisher per-domain Phase-3 pct=-ramp progression is initiated, while per-receiver per- mailbox-provider per-day temperror-rate is tolerated up to a per-publisher per- domain noise-ceiling (typically <1.0% of per-day per-source-IP authenticated message volume) because temperror is transient DNS-resolver-upstream-of- publisher infrastructure noise that self-heals on per-receiver per-mailbox- provider DNS-resolver retry; (iii) per-publisher per-domain Phase-3 per-receiver per-mailbox-provider per-day permerror-vs-temperror policy-disposition- coupling under RFC 7489 §6.6.1 SPF-fail cascade semantics — at per- publisher per-domain p=quarantine and p=reject, per-receiver per-mailbox-provider treats per-message per-source-IP SPF permerror as DMARC-SPF-fail (cascading into per- publisher per-domain dmarc=fail when no DKIM- aligned-pass leg survives) while per- message per-source-IP SPF temperror generally results in per-receiver per-mailbox-provider deferred-retry semantics (per RFC 7208 §2.6.7 §8.5) without cascading into immediate DMARC-fail attribution — the per-publisher per-domain operational consequence is permerror class triggers per-receiver per-mailbox-provider per- message reject/quarantine disposition while temperror class triggers per- receiver per-mailbox-provider per-message deferred-retry (typically queue-and-retry with exponential backoff); (iv) per-publisher per-domain Phase-2 per-receiver per-mailbox-provider per-day permerror-rate-floor cross-attribution to per-publisher per-domain include:-chain depth-budget re-audit prerequisite for Phase-4 p=quarantine commit — the per-publisher per-domain Phase-4 p=quarantine ramp commit REQUIRES per-publisher per-domain Phase-2 per-receiver per-mailbox-provider per-day aggregate-XML permerror-rate floor clearance (per-publisher per-domain Phase-2 permerror evidence-stream <0.1% of per-day per-source-IP authenticated message volume across the per-publisher per-domain RUA observation window), otherwise per-publisher per-domain include:-chain depth-budget re-audit MUST PRECEDE per-publisher per- domain Phase-4 p=quarantine commit because per-receiver per-mailbox- provider per-day permerror evidence at p=quarantine cascades into per-publisher per-domain composite- aligned-pass-rate floor erosion gating per-mailbox-provider per-publisher per- domain reputation-floor signal-stream which 2024 Gmail/Yahoo/Microsoft Bulk- Sender-Requirements mandate at the per- publisher per-domain composite- authentication-leg coordination boundary.
• TLS-RPT explained — the PER-RECEIVER-PER-SESSION- TRANSPORT-LAYER-ENCRYPTION-FAILURE- TELEMETRY-AS-LOAD-BEARING-PEER-LAYER- POLICY-RAMP-STATE-MACHINE-COMPANION companion to this DMARC three-mode policy-modes state-machine reference. Where THIS page documents the per- publisher per-domain DMARC three-mode policy state machine progression (p=none observability baseline → p=quarantine spam-folder enforcement → p=reject SMTP-time rejection enforcement) at the application layer, the TLS-RPT- explained spoke is the per-publisher per-domain per-receiver per-session transport-layer-encryption failure- mode telemetry whose paired-with- MTA-STS three-mode publication discipline (MTA-STS mode=none → MTA-STS mode=testing → MTA-STS mode=enforce) is the load-bearing peer-layer policy-ramp state-machine progression at the transport layer at FOUR per-policy- mode-to-TLS-RPT-publication coupling dimensions: (i) per-publisher per-domain p=none-with-rua-mailto application-layer-observability- baseline mirrors per-publisher per- domain TLS-RPT-with-MTA-STS- mode=testing-publication transport-layer-observability- baseline — the DMARC p=none with rua-mailto publication step is the per-publisher per-domain application-layer DMARC- aggregated-verdict observability- baseline establishment step, the TLS-RPT publication paired with MTA-STS mode=testing publication is the per-publisher per-domain transport-layer per- receiver per-session per-MX hop encryption-failure observability- baseline establishment step, and the per-publisher per-domain operator runs BOTH layers in parallel during Phase 2 to gather per-layer baseline before ramping either layer's enforcement; (ii) per- publisher per-domain p=quarantine ramp-step commit gates parallel to MTA-STS mode=enforce ramp-step commit — the DMARC p=quarantine ramp-step commit decision reads the per- publisher per-domain DMARC-aligned- pass-rate stability AND the per- publisher per-domain TLS-RPT failure- details rate stability the TLS-RPT- explained spoke documents BEFORE committing the application-layer ramp-step tightening, because per- receiver per-session transport- encryption-failure regression (e.g. starttls-not-supported or validation-failure spikes in the TLS-RPT failure-details stream) is an upstream cause- candidate for per-message DKIM-fail rate regressions that would block the per-publisher per-domain p=quarantine ramp-step commit; (iii) per-publisher per-domain p=reject-with-MTA-STS- mode=enforce-with-TLS-RPT- publication terminal-enforcement cross-layer state — the per-publisher per-domain DMARC p=reject terminal- enforcement state composes with MTA-STS mode=enforce terminal-enforcement state to ship the per-publisher per-domain complete cross-layer authentication- and-encryption enforcement posture, and TLS-RPT publication is the per- publisher per-domain operator-side ongoing-observability publication discipline that produces the per- session per-MX hop transport- encryption-failure-rate stability signal the per-publisher per-domain operator reads to detect terminal- state regression at the transport layer; (iv) per-publisher per-domain Bulk-Sender-Requirements- 2024 cross-layer deliverability- floor composition — the per-publisher per-domain Feb-2024 Gmail/Yahoo Bulk Sender Requirements deliverability-floor composition explicitly requires the per-publisher per-domain DMARC p=reject application- layer terminal-enforcement state AND per-publisher per-domain MTA-STS-and- TLS-RPT transport-layer publication discipline as paired cross-layer publication components of the complete per-publisher per-domain cross-layer authentication-and- encryption deliverability posture. Read THIS page when AUTHORING the per-publisher per-domain three-mode application-layer policy state machine progression; read the TLS- RPT-explained spoke when AUTHORING the per-publisher per-domain peer- layer transport-encryption failure- telemetry publication discipline whose paired-with-MTA-STS three- mode publication progression structurally mirrors the DMARC three-mode policy progression THIS page documents at the application layer.
• include: vs ip4: vs a: vs mx — the PER-PUBLISHER-PER-DOMAIN-SPF- MECHANISM-DECISION-VIEW-AS-LOAD-BEARING- PEER-PROTOCOL-LAYER-UPSTREAM-AUTHENTICATION- DETERMINANT companion to this DMARC three- mode policy-progression reference. Where THIS page documents the per-publisher per- domain DMARC three-mode policy progression at the per-message application-layer enforcement boundary (the p=none monitor-only disposition, the p=quarantine Junk-folder routing disposition, the p=reject receiver-side reject disposition), the include-vs-ip4-vs-a-vs-mx spoke is the peer per-publisher per-domain SPF-mechanism- decision-view whose per-mechanism-choice publication discipline is the LOAD-BEARING upstream determinant of the per-message envelope-MAIL-FROM SPF evaluation outcome (per-message permerror from include: 10-lookup-limit breach, per-message temperror from a:/mx: DNS- resolution failure, per-message pass from well-composed include:/ ip4:/a:/ mx: mechanism set) that feeds the per-publisher per-domain DMARC three- mode policy-disposition THIS page documents at FOUR per-policy-progression coupling dimensions: (i) peer per- publisher per-domain authentication- discipline-vs-enforcement-discipline parallelism — the per- publisher per-domain DMARC three-mode policy-disposition THIS page documents at the per-message application-layer enforcement boundary pairs operationally with the per-publisher per-domain SPF- mechanism-choice publication discipline the include-vs-ip4-vs-a-vs-mx spoke documents at the per-domain envelope-MAIL- FROM authentication-publication layer — the per-publisher per-domain DMARC disposition decision presupposes a per- publisher per-domain SPF-mechanism-choice publication discipline that emits the per- message authentication-evaluation outcome the per-publisher per-domain DMARC disposition rule then enforces; (ii) upstream SPF-mechanism-choice as determinant of downstream DMARC-policy- disposition emission — the per-publisher per-domain DMARC p=quarantine / p=reject enforcement disposition THIS page documents operationally depends on the per-publisher per-domain SPF-mechanism-choice publication discipline the include-vs- ip4-vs-a-vs-mx spoke documents — a per- publisher per-domain SPF-record carrying include: mechanisms with cumulative 10-lookup-limit breach emits per-message spf=permerror, a per-publisher per-domain SPF-record relying on a:/mx: with DNS-resolution failure emits per- message spf=temperror, and either failure-mode propagates to per- message policy_evaluated.spf=fail feeding the per-publisher per-domain DMARC disposition rule that this page documents the per-mode rationale for; (iii) per-publisher per-domain cross-protocol-pillar policy-progression coordination — the per- publisher per-domain DMARC three-mode policy-progression THIS page documents at the application-layer enforcement- boundary pairs operationally with the per- publisher per-domain SPF-mechanism-choice publication-discipline-evolution progression the include-vs-ip4-vs-a-vs- mx spoke documents (per-publisher per- domain SPF-mechanism-choice evolution from permissive +all/ ?all defaults to restrictive ~all/-all defaults as the per-publisher per-domain SPF-mechanism-choice publication discipline matures), and the per-publisher per-domain cross-protocol-pillar enforcement- progression coordination (DMARC three-mode progression operationally synchronized with SPF mechanism-choice-discipline maturation) is the load-bearing per- publisher per-domain enforcement- progression rhythm every per-publisher per-domain DMARC-deployment programme coordinates at the per-publisher per- domain cross-protocol-pillar enforcement- composition boundary; (iv) per- publisher per-domain p=reject deployment-readiness as function of SPF- mechanism-choice publication-discipline stability — the per- publisher per-domain DMARC p=reject enforcement disposition THIS page documents at the per-message application-layer enforcement boundary operationally requires the per- publisher per-domain SPF-mechanism-choice publication discipline the include-vs- ip4-vs-a-vs-mx spoke documents to be operationally stable (no per-message spf=permerror emission from cumulative include: 10- lookup-limit breach, no per-message spf=temperror emission from a:/mx: unreliable DNS-resolution dependency, no per-message spf=softfail emission from ~all mechanism-default-induced ambiguity) — per-publisher per-domain p=reject deployment readiness operationally hinges on the per-publisher per-domain SPF-mechanism-choice publication discipline maturity the include-vs-ip4- vs-a-vs-mx spoke documents the per- mechanism-choice rationale of. Read THIS page when STAGING per-publisher per- domain DMARC three-mode policy progression; read the include-vs-ip4-vs- a-vs-mx spoke when CHOOSING the per- publisher per-domain SPF-mechanism publication approach (include:, ip4:, a:, or mx:) whose per-mechanism-choice publication discipline is the LOAD-BEARING upstream determinant of the per-message SPF- evaluation outcome feeding the per- publisher per-domain DMARC three-mode policy-disposition THIS page documents at the per-message application-layer enforcement boundary.
• DKIM-Signature header tag anatomy — the per-message DKIM-Signature header per-tag anatomy as load-bearing upstream authentication-determinant of per-message DKIM-leg DMARC-alignment evaluation companion to this DMARC three-mode policy progression reference. Where THIS page documents the per-publisher per-domain DMARC three-mode policy progression (p=none / p=quarantine / p=reject) and the adkim / aspf strict-vs-relaxed alignment-mode choice, the DKIM-Signature-anatomy spoke documents the per-message header byte- grammar whose per-tag publication- discipline is the LOAD-BEARING upstream authentication-primitive every per-message DKIM-leg DMARC-alignment evaluation STRUCTURALLY DEPENDS on for the per- receiver dispositional verdict that the three-mode policy-disposition machine consumes. Four DKIM-SIGNATURE-HEADER- ANATOMY-VS-DMARC-POLICY-MODE-DISPOSITION cross-correlation axes the signature- anatomy spoke documents: (i) per- message DKIM-Signature d=<domain> tag value STRUCTURALLY DETERMINES the per-message DKIM-leg DMARC-aligned-pass evaluation under the chosen adkim=r or adkim=s alignment-mode — the per-message d= tag value MUST match the per-message From: header organizational domain under adkim=r (relaxed, permitting subdomain match) OR exact-match under adkim=s (strict, exact domain only); the per-publisher per-domain adkim mode choice THIS page documents STRUCTURALLY DETERMINES the per-message DKIM-leg DMARC-aligned-pass verdict that feeds the per-disposition policy-mode evaluation; (ii) per-message DKIM- Signature bh= body-hash tag COMPUTATION-DISCIPLINE STRUCTURALLY GATES the per-message DKIM-aligned-pass at the p=quarantine + pct= sampling-window evaluation boundary — the per-message bh= tag carries the SHA-256 hash of the canonicalized message body; per-message body-hash mismatch under c=simple mode produces per- receiver dkim=fail verdicts that propagate to per-row policy_evaluated.dkim=fail and engage the p=quarantine dispositional-enforcement boundary; (iii) per-message DKIM-Signature s=<selector> selector tag VALUE STRUCTURALLY GATES the p=reject terminal enforcement state's per-receiver verifier- side public-key fetch operation — the per-message s= tag identifies the per-publisher per-selector public-key TXT-RR the receiver-side verifier fetches; per-publisher per- selector TXT-RR publication regression at <selector>._domainkey.<d-value> produces per-receiver dkim=permerror verdicts that under p=reject terminal-state enforcement propagate to 550-SMTP-time rejection identically to spoofed-mail rejection; (iv) per-message DKIM- Signature a=<algorithm> algorithm tag VALUE STRUCTURALLY DETERMINES the per-receiver verifier- coverage divergence at the p=quarantine → p=reject ramp-tightening boundary — the per-message a= tag identifies the per- message signature algorithm (rsa-sha256 per RFC 8301 / ed25519-sha256 per RFC 8463); per-publisher per-domain dual-algorithm signing posture (RSA-2048 + Ed25519) STRUCTURALLY GATES safe p=reject commit because per- receiver verifier-coverage divergence cannot be rolled back from p=reject once the per- publisher per-domain terminal-state enforcement boundary crosses. Read THIS page when STAGING per-publisher per-domain DMARC three-mode policy-progression; read the DKIM-Signature-anatomy spoke when AUDITING the per-message header byte- grammar per-tag publication discipline whose d= tag value, body- hash computation, selector tag publication, and algorithm choice are the LOAD-BEARING upstream authentication- determinants of the per-message DKIM-leg DMARC-aligned-pass evaluation outcome feeding the per-publisher per-domain DMARC three-mode policy-disposition THIS page documents at the per-message application-layer enforcement boundary.
• DKIM canonicalization — the canonicalization-mode-choice spoke documents the per-publisher per-domain RFC 6376 §3.4 c=-tag choice between c=simple/simple (byte-exact header + body) and c=relaxed/relaxed (header-name case-folded + whitespace-collapsed + trailing-CRLF-normalised body) whose per-message DKIM body-hash stability across legitimate intermediary whitespace normalisation, MIME re-encoding, and signature-preserving relays is the LOAD-BEARING upstream determinant of the per-message DKIM-verify-pass verdict feeding every per-publisher per-domain p=quarantine or p=reject dispositional commitment THIS page documents. Four canonicalization-choice-vs-policy-mode coupling axes the canonicalization spoke documents: (i) per-publisher per-domain c=simple/simple canonicalization mode produces brittle per-message DKIM body-hash stability STRUCTURALLY GATING safe p=quarantine advancement readiness — the simple body canonicalization byte-exact hash computation fails under per-relay trailing whitespace insertion, line-ending normalisation (CRLF↔LF), and the ubiquitous "ensure single trailing CRLF" MTA discipline — the per-message dkim=fail verdict propagates to per-row policy_evaluated.dkim=fail and engages the p=quarantine dispositional- enforcement boundary even for cryptographically-legitimate publisher- signed mail; (ii) per-publisher per-domain c=relaxed/relaxed canonicalization mode is the operationally-load-bearing default whose per-message DKIM body-hash stability under legitimate intermediary whitespace normalisation is the per-publisher per-domain DKIM-aligned-pass-rate floor prerequisite for safe p=quarantine → p=reject ramp advancement — the relaxed header canonicalization (case-fold header names, collapse internal whitespace, strip trailing whitespace) + relaxed body canonicalization (collapse internal whitespace, strip trailing whitespace per line, ignore trailing empty lines) together create the per-message DKIM body-hash stability the receiver-side verifier requires to emit dkim=pass for publisher-signed mail traversing legitimate per-receiver whitespace-normalising relay paths; (iii) per-publisher per-domain canonicalization-choice consistency across ALL signing MTAs in the publisher's outbound-egress fleet is the LOAD-BEARING upstream operator-discipline whose divergence produces the dkim=fail-but-cryptographically- legitimate per-message verdict-class that retroactively retracts the per-publisher per-domain DKIM-aligned-pass-rate floor below the safe-ramp-advancement threshold — heterogeneous canonicalization-mode deployment across multiple per-publisher signing-MTA cohorts (e.g., on-prem Exchange signing with c=simple/simple while transactional ESP cohorts sign with c=relaxed/relaxed) produces per-receiver per-source-IP DKIM-aligned- pass-rate variance that mismeasures the per-publisher per-domain DKIM-aligned- pass-rate floor at ramp-advancement- decision time; (iv) per-publisher per-domain canonicalization-mode publication divergence between the per-message DKIM-Signature header c=-tag value and the receiver- side verifier's canonicalization re-computation is the LOAD-BEARING per-receiver dkim=permerror root-cause class that under p=reject terminal-state enforcement propagates to 550 SMTP-time rejection identically to spoofed-mail rejection — per-publisher canonicalization-mode publication-discipline regression converts cryptographically- legitimate publisher-signed mail into p=reject-bounce evidence indistinguishable from spoofing at the per-receiver per-publisher per-day aggregate-report row level. Read THIS page when STAGING per-publisher per-domain DMARC three-mode policy-progression; read the canonicalization spoke when AUDITING the per-publisher per-domain c=-tag canonicalization-mode choice whose per-message DKIM body-hash stability under legitimate intermediary whitespace normalisation is the LOAD-BEARING upstream determinant of the per-message DKIM-verify- pass verdict feeding the per-publisher per-domain DMARC three-mode policy- disposition THIS page documents at the per-message application-layer enforcement 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) whose DMARC layer THIS three-mode policy- disposition reference is the terminal- enforcement chapter of, at four cross- protocol policy-mode-as-ecosystem-terminal- enforcement coupling dimensions: (i) per-publisher per-domain p=none monitoring-only mode as the ecosystem-framework Phase-1 publication- discipline gate establishing the per- publisher per-domain RUA-aggregate-evidence stream BEFORE per-publisher per-domain SPF + DKIM publication-completeness has been validated — the ecosystem framework explicitly documents p=none as the per-publisher per-domain no-enforcement publication-discipline that activates the per-receiver per-day per- source-IP per-row RUA-XML observability stream the operator consumes to validate per-publisher per-domain SPF + DKIM publication-completeness BEFORE advancing to per-publisher per-domain quarantine / reject enforcement; (ii) per- publisher per-domain p=quarantine pct=N partial-enforcement-with- sampling mode as the ecosystem-framework Phase-2 publication-discipline gate validating per-receiver per-day per- source-IP per-row composite SPF-or-DKIM- aligned-pass-rate floor BEFORE per- publisher per-domain terminal-state publication — the ecosystem framework documents per-publisher per- domain pct=-tag sampling- floor + per-receiver per-day Spam-folder- landing-rate evidence the operator consumes during the per-publisher per- domain quarantine-tier publication- discipline window; (iii) per- publisher per-domain p=reject pct=100 terminal-state mode as the ecosystem-framework Phase-3 publication- discipline gate the operator advances to AFTER per-publisher per-domain composite- ecosystem publication-completeness (SPF + DKIM + ARC + per-egress-MTA fleet- coverage) per-receiver per-day RUA-row evidence floor has been reached — the ecosystem framework documents the per-publisher per-domain SPF + DKIM + ARC publication-discipline floor the per- publisher per-domain operator MUST satisfy BEFORE advancing to the per-publisher per- domain terminal-state enforcement-tier; (iv) per-publisher per-domain DMARC policy-mode-tier ramp-progression STRUCTURALLY CONSUMES the per-publisher per-domain SPF + DKIM + ARC publication- completeness evidence the ecosystem framework's per-receiver per-day per- source-IP per-row RUA-XML evidence stream materially surfaces — the per- publisher per-domain operator's per-tier ramp-advancement-readiness gate is empirically validated through the per- receiver per-day per-source-IP per-row SPF-aligned-pass-rate + DKIM-aligned-pass- rate + ARC-rescue-coverage-floor evidence the ecosystem framework's RUA-aggregate- report stream produces. Read the email- authentication-ecosystem pillar alongside this DMARC policy-modes reference when the per-publisher per-domain operator is positioning the per-publisher per-domain DMARC three-mode policy-tier ramp within the broader per-publisher per-domain four- protocol authentication-publication discipline, when coordinating per-publisher per-domain DMARC policy-mode advancement with per-publisher per-domain SPF + DKIM + ARC publication-completeness gates, or when authoring per-publisher per-domain per-protocol authentication-publication runbooks that must coordinate per-publisher per-domain DMARC three-mode policy-tier ramp with the broader per-publisher per- domain authentication-publication ecosystem.
• SPF for Google Workspace — the per-Workspace-tenant per-custom- domain envelope-MAIL-FROM-layer SPF publication-discipline companion to this DMARC three-mode policy-tier ramp reference. Where THIS page documents the per-publisher per-domain RFC 7489 §6.3 DMARC three-mode policy-tier (p=none → p=quarantine → p=reject) ramp progression, the SPF-for-Google-Workspace spoke documents the structurally parallel per- Workspace-tenant per-custom-domain envelope-MAIL-FROM-layer SPF publication (v=spf1 include:_spf.google.com -all canonical baseline, per-tenant per- custom-domain Gmail-egress include:_spf.google.com macro expansion, per-tenant per-third- party-sender SPF-flattening discipline against the RFC 7208 §4.6.4 ten-DNS- lookup ceiling). Four per-Workspace- tenant per-custom-domain DMARC-policy- ramp coupling dimensions matter at the per-tenant per-custom-domain policy-tier advancement boundary: (i) per-Workspace- tenant per-custom-domain p=none-tier SPF-aligned-pass- rate observability baseline — the per- tenant per-custom-domain v=spf1 include:_spf.google.com -all publication the SPF-for-Google-Workspace spoke documents establishes the per- tenant SPF-aligned-pass-rate floor every per-tenant per-custom-domain p=none observability period THIS page documents measures against BEFORE per-tenant p=quarantine advancement; (ii) per-Workspace-tenant per-custom-domain p=quarantine-tier per- receiver-side SPF-aligned-pass-rate floor — per-tenant per-custom-domain p=quarantine requires sustained per-tenant SPF-aligned-pass- rate ≥ 95% (Google Workspace egress baseline) measured over the per-tenant per-custom-domain p=none observability period; the per-tenant SPF publication-discipline the SPF-for-Google-Workspace spoke documents IS the load-bearing per-tenant per-custom-domain envelope-layer authentication-leg every per-tenant per- custom-domain p=quarantine ramp advancement THIS page documents depends on; (iii) per-Workspace-tenant per- custom-domain p=reject-tier per-receiver- side DMARC-aligned-pass composite-verdict — per-tenant per-custom-domain p=reject requires per-tenant per-message DMARC-aligned-pass composite- verdict (DKIM-aligned-pass OR SPF- aligned-pass) per RFC 7489 §3.1; the per- tenant SPF-aligned-pass leg the SPF-for- Google-Workspace spoke documents IS the per-tenant envelope-layer composite- verdict-attribution input every per- tenant per-custom-domain p=reject-tier per-receiver- side accept/quarantine/reject decision THIS page documents depends on; (iv) per- Workspace-tenant per-custom-domain DMARC policy-ramp completion as per-publisher per-domain composite envelope-and- application-layer authentication- publication-portfolio-floor compliance — the per-tenant per-custom-domain DMARC three-mode policy-tier ramp completion THIS page documents IS the per-tenant per-custom-domain composite authentication- publication-portfolio-floor compliance primitive, and the per-tenant SPF envelope-MAIL-FROM-layer publication- discipline the SPF-for-Google-Workspace spoke documents IS the per-tenant per- custom-domain envelope-layer publication- portfolio component every per-tenant per- custom-domain composite publication-and- policy-ramp discipline depends on at the per-publisher per-domain publication-portfolio coordination floor. Read THIS page when AUTHORING the per- publisher per-domain DMARC three-mode policy-tier ramp progression discipline; read the SPF-for-Google-Workspace spoke when AUTHORING the per-Workspace-tenant per-custom-domain envelope-MAIL-FROM- layer SPF publication that per-tenant per-custom-domain DMARC policy-ramp advancement THIS page documents depends on as the per-tenant envelope-layer authentication-leg input variable.
• DANE explained — the per-publisher per-MX DANE TLSA transport-layer enforcement-mode- ramp companion at four cross-layer enforcement-mode-ramp coupling dimensions.
• MTA-STS for Microsoft 365 — the PER-M365-TENANT-PER-CUSTOM- DOMAIN-MTA-STS-TRANSPORT-LAYER-MODE-RAMP- AS-STRUCTURALLY-PARALLEL-DMARC-APPLICATION- LAYER-POLICY-MODE-RAMP companion to this DMARC policy-modes reference. Where THIS page documents the per-publisher per-domain DMARC p= policy-mode-ramp publication discipline (the canonical p=none → p=quarantine pct=N → p=reject pct=100 progression with per-cohort pct= ramp gating), the M365 MTA-STS spoke is the PER-M365-TENANT TRANSPORT-LAYER MODE-RAMP reference the per-M365-tenant operator consults when ramping the parallel transport-layer receive-side STARTTLS- enforce contract. Four cross-layer per- M365-tenant mode-ramp coordination dimensions: (i) PER-M365-TENANT-MTA-STS- MODE-TESTING-VS-DMARC-P-NONE (per-M365- tenant mode: testing publication is parallel to per-publisher per-domain DMARC p=none monitoring-mode — both are observation- only publication postures that emit observability data without enforcing receiver-side disposition); (ii) PER-M365- TENANT-MTA-STS-MODE-ENFORCE-VS-DMARC-P- REJECT (per-M365-tenant mode: enforce is parallel to per-publisher per-domain DMARC p=reject pct=100 — both are terminal enforcement-mode publications gating receiver-side disposition cascade); (iii) PER-M365-TENANT-MTA-STS-POLICY-ID- ROTATION-VS-DMARC-PCT-RAMP (per-M365- tenant MTA-STS policy-id field cache-invalidation rotation cadence is parallel to per-publisher per-domain DMARC pct=N per-cohort ramp publication cadence — both gate per- receiver per-day per-cohort behavior changes); (iv) PER-M365-TENANT-MTA-STS- ENFORCE-FAILURE-VS-DMARC-P-REJECT-RECEIVER- SIDE-CASCADE (per-M365-tenant MTA-STS enforce-mode receive-side STARTTLS-handshake failure cascades to per-message hard-bounce — structurally parallel to per- publisher per-domain DMARC p=reject receive-side per- message policy_evaluated/disposition=reject cascade — both are terminal mode- publication failure-disposition primitives the per-receiver per-day disposition stream surfaces). Read the M365 MTA-STS spoke alongside this DMARC policy-modes guide when AUTHORING the per-M365-tenant per- custom-domain composite cross-layer application-layer-DMARC-and-transport-layer- MTA-STS mode-ramp coordination discipline, when PLANNING the per-M365-tenant per- custom-domain ramp sequencing (whether to enforce MTA-STS before or alongside DMARC p=reject), or when INVESTIGATING per-M365-tenant per-custom- domain composite cross-layer deliverability regressions correlating with either mode- ramp publication.
• DKIM key rotation
• DKIM best practices
• Reverse DNS / PTR records for mail servers
• MTA-STS vs DANE for SMTP — a terminal p=reject policy closes the message-layer direct-domain spoofing surface, but it does nothing for the transport hop: an active attacker can still strip STARTTLS or substitute the MX to intercept mail in clear text. MTA-STS and DANE are the two transport-layer enforcement disciplines that close that gap. Read the head-to-head comparison to choose the HTTPS-PKI-anchored (MTA-STS) or DNSSEC-anchored (DANE) transport-security leg that complements the enforcement ramp this page documents.
• Microsoft SNDS + JMRP monitoring — DMARC reporting shows who fails authentication; Microsoft SNDS + JMRP shows how Outlook.com's filter and its users judge the mail that passes — the per-IP reputation signal aggregate reports cannot see.

13. Check your current DMARC policy mode now

DMARC Analyzer's free Domain Security Checker performs live DMARC + SPF + DKIM + MTA-STS + BIMI lookups against any domain. Use it to confirm your current DMARC policy mode (the value of the p= tag in your published _dmarc TXT record), the subdomain policy (sp=) and non-existent subdomain policy (np=) if set, and the sampling tag (pct=) if present. The DNS Record Generator builds syntactically-correct DMARC records with the right p= + sp= + np= + rua= tags for any phase of the rollout. Imported DMARC aggregate reports (via includes/DmarcParser.php) drive the per-source-IP pass and fail dashboard that powers your sender registry under every policy mode.

Check my current DMARC policy mode Sign up — Free plan