DMARC Analyzer

TL;DR

• DMARC policy rollout is the phased migration of the p= tag through three states: p=none (monitor) -> p=quarantine (route to spam) -> p=reject (refuse at SMTP). Defined in RFC 7489 §6.3.
• The rollout is OPERATIONAL guidance, not an RFC-defined ramp. Receivers act on whatever p= value is currently published — you control the cadence by editing the DNS record between phases.
• Typical timeline: 3-6 months end-to-end. 2-4 weeks at p=none to discover senders; 4-8 weeks fixing alignment; 2-4 weeks at p=quarantine; pct= ramp 5 -> 25 -> 50 -> 100 over 4-8 weeks; then p=reject.
• The pct= tag applies the published policy to a percentage of failing mail — use it to ramp enforcement gradually within a stage rather than between stages. Note: pct= is deprecated in dmarcbis.
• Never jump straight from p=none to p=reject. Quarantine first — the spam folder is a recoverable failure mode; SMTP reject is not.
• Aggregate (rua) reports are the single most important signal during rollout. Publish rua=mailto: on day one and read the reports weekly.
• The sp= and np= tags can advance AHEAD of p= because non-sending subdomains are easier to lock down than the apex.

1. What is DMARC policy rollout?

DMARC policy rollout is the phased migration of the p= tag through DMARC's three policy states. The p= tag tells receiving mail servers what action to take when a message fails DMARC evaluation — either because SPF and DKIM both failed alignment, or because neither produced a verifiable result for the From: header domain. RFC 7489 §6.3 defines three valid values:

• p=none — request no action; the message is delivered normally and the receiver only reports the DMARC outcome via aggregate (rua) reports.
• p=quarantine — request that the message be flagged as suspicious; most receivers route it to the spam folder.
• p=reject — request that the message be refused at the SMTP RCPT TO stage so the sending MTA receives a bounce.

The rollout is the OPERATIONAL JOURNEY through those three states. The DMARC RFCs do not specify a ramp — they describe what receivers SHOULD do when they observe each value. The sender controls progression by editing the _dmarc DNS TXT record. Moving from p=none to p=quarantine means publishing a new TXT record value; receivers pick up the change as the TTL expires (typically within an hour).

Rollout exists because DMARC is unforgiving. Every sending source that fails alignment at p=reject stops delivering — every SaaS sender without custom-domain DKIM, every on-prem MTA with a stale SPF include, every automated job that ships from a third-party domain. You cannot discover those failures without the diagnostic phase that p=none provides; you cannot tolerate them under p=reject; the rollout bridges the gap.

The full DMARC ecosystem context is in the DMARC primer; the tag-by-tag reference is the DMARC records deep dive; the identifier-alignment concept that determines pass/fail in the first place is the DMARC alignment page. This page focuses on the rollout sequence itself.

2. The three DMARC policy states

The keystone reference for this page: every rollout decision is a choice between these three values and the operational consequences of each.

p=none is sometimes called monitoring mode. It is not the final state of any production DMARC deployment — leaving an active sending domain at p=none indefinitely means publishing a DMARC record that documents WHO IS SPOOFING YOU without actually stopping them. However, p=none with active aggregate-report monitoring is dramatically better than no DMARC record at all because it gives you the visibility needed to plan a rollout.

p=quarantine is the operational middle ground. The receiver still accepts the message but flags it as suspicious — typically routing to the spam folder. Recipients can recover missed legitimate mail from spam during the quarantine phase, which is exactly the failure mode you want during rollout: visible enough to surface alignment problems, recoverable enough that a missed transactional mail is not a service incident.

p=reject is the goal state. Mail that fails DMARC is refused at RCPT TO, before the message body is accepted, so the sending MTA receives a hard SMTP bounce. No spam-folder fallback exists. This is the only state that actually prevents DMARC-failing mail from reaching the recipient — everything else is partial enforcement.

3. The phased rollout sequence

The standard rollout has five phases. Each phase has an entry condition, a published DMARC record, an observation window, and an exit condition. Do not advance phases on a fixed schedule — advance when the exit conditions are met. A larger sending estate takes longer.

Phase 1 — Discovery (p=none, 2 to 4 weeks)

Published record (apex): v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. Receivers send daily aggregate reports describing which IPs sent mail claiming to be from your domain, what SPF / DKIM results applied, and whether alignment passed. The goal of Phase 1 is INVENTORY: enumerate every legitimate sender and every spoofing source.

Exit when: every sending IP in the aggregate reports is identified as either legitimate (with a remediation plan if currently misaligned) or known-malicious (will be addressed by the rollout itself).

Phase 2 — Alignment Fix-up (still p=none, 4 to 8 weeks)

For every legitimate-but-misaligned sender from Phase 1, fix the alignment. Common remediation work:

• Enable custom-domain DKIM at every SaaS sender (SendGrid, Mailgun, Postmark, Marketo, HubSpot, ServiceNow). Without this the SaaS signs mail with its own domain and DKIM never aligns with your From:.
• Update SPF to include legitimate senders that produce SPF-aligned mail (custom bounce domains).
• Migrate stale third-party DMARC delegation (subdomain CNAME pointing to a vendor's DMARC reporting service).
• Identify shadow IT — Acme Logging, a one-off survey tool, a forgotten e-commerce platform — and either align them or decommission them.

Exit when: aggregate reports show ≥99% of legitimate mail volume passing DMARC. The remaining ≤1% is acceptable known-failing (typically forwarders) or acceptable spoofing.

Phase 3 — Initial Enforcement (p=quarantine; pct=5, 1 to 2 weeks)

Published record: v=DMARC1; p=quarantine; pct=5; rua=mailto:dmarc-reports@example.com. Receivers quarantine 5% of DMARC-failing mail; the remaining 95% is treated as p=none. The small sample surfaces any blocked legitimate flows that Phase 2 missed — typically a low-volume sender that did not appear in the previous aggregate-report window.

Exit when: 1-2 weeks of aggregate reports with no unexpected blocked legitimate flows.

Phase 4 — Ramping Enforcement (p=quarantine with pct= ramp, 4 to 8 weeks)

Ramp pct= through 25, 50, 100 in 1-2 week increments. Each ramp expands the sample subject to quarantine; each ramp is independently verifiable via the rua reports. The full pct= ramp typically takes 4-8 weeks because each step needs an observation window long enough to surface weekly-cadence senders (a payroll mailer that runs every Wednesday or a quarterly report).

Exit when: pct=100 is published, 1-2 weeks of clean aggregate reports.

Phase 5 — Full Enforcement (p=reject, indefinite)

Published record: v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com. The pct= tag is omitted (or set to pct=100 explicitly). This is the permanent operational state. Aggregate reports continue to arrive — DMARC monitoring is forever, not a one-off project. New SaaS deployments, marketing-tool changes, or partner integrations can re-introduce misalignment, and rua reports are the detection mechanism.

4. The pct= tag for gradual enforcement

The pct= tag specifies the percentage of mail subjected to the published policy. RFC 7489 §6.6.4 defines this as a sampling mechanism for gradual rollout. The default is pct=100 if the tag is omitted.

The receiver semantics: when DMARC fails on a message and pct<100, the receiver applies p= to a random subset of pct-percent of failing messages. The remaining 100-pct-percent are downgraded to the next-lower policy:

• p=quarantine; pct=25 — 25% of failing mail is quarantined; the other 75% is treated as p=none.
• p=reject; pct=10 — 10% of failing mail is rejected; the other 90% is treated as p=quarantine.

The standard ramp inside a single policy state:

; Week 0 — initial enforcement at 5%
v=DMARC1; p=quarantine; pct=5;  rua=mailto:dmarc-reports@example.com

; Week 1 — ramp to 25% after clean rua reports
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com

; Week 2 — ramp to 50%
v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@example.com

; Week 4 — ramp to 100% (pct= tag omitted)
v=DMARC1; p=quarantine;         rua=mailto:dmarc-reports@example.com

Important dmarcbis note: the in-progress draft-ietf-dmarc-dmarcbis deprecates the pct= tag. The rationale is that pct= is rarely used correctly — operators commonly publish low pct values for months without ever ramping, leaving most mail enforcement-free, and gradual enforcement is better achieved through the phased approach (p=none -> p=quarantine -> p=reject) rather than within-stage pct ramping.

Practical guidance: pct= still works at every major receiver as of 2026 and will continue to work for the foreseeable future. Use it where it helps (the early quarantine phase), but do not rely on a long-running pct ramp as a substitute for advancing through the policy states. If you are starting a fresh rollout today, plan for a rollout that does not depend on pct= existing in five years.

5. Subdomain policy timing: sp= and np=

The p= tag applies to the organizational (apex) domain. RFC 7489 §6.3 defines sp= for subdomain policy override; RFC 9091 §2 adds np= for non-existent subdomain policy. The two subdomain tags are independent of the apex rollout and can advance ahead of it.

The policy waterfall (per RFC 9091 §2):

1. For mail claiming a non-existent subdomain From: domain — np= applies if present; otherwise falls through to sp=; otherwise to p=.
2. For mail claiming an existing subdomain From: domain — sp= applies if present; otherwise p=.
3. For mail claiming the apex From: domain — p= applies. sp= and np= are ignored.

Why subdomain policy advances ahead of the apex: the apex domain is the hardest part of the rollout because it carries the highest-volume legitimate sending estate (marketing, transactional, support, partner integrations). Subdomains often have a much narrower role — and many subdomains have NO legitimate sender at all (parked subdomains, internal-only subdomains, or naming patterns that exist only as DNS records for other services). Those subdomains can move to p=reject on day one without risk.

A typical published record during rollout:

; Apex still at p=none for sender discovery, but every
; subdomain that should never send mail is locked
; down at quarantine/reject from the start.

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

Reads as: the apex (example.com) is in monitoring; existing subdomains (mail.example.com, smtp.example.com, etc.) are quarantined if they fail DMARC; non-existent subdomains (random.example.com, a.example.com) are rejected — closing the NXDOMAIN-spoofing surface that some phishing campaigns exploit.

6. Worked rollout timeline (Week 0 to Week 26)

A realistic six-month rollout for a mid-size organization with 5 to 15 legitimate sending sources. Adjust the dates based on your sending-estate complexity — larger organizations often need 9-12 months end-to-end.

Week 0 — Publish initial record

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

Apex at p=none for discovery; np=reject from day one because non-existent subdomains have no legitimate sender by definition. Set up a mailbox for the rua reports — typically a forwarding address routed to a parser (DMARC Analyzer's aggregate-report ingestion pipeline; see includes/DmarcParser.php).

Weeks 1 to 3 — Read the aggregate reports

Daily aggregate reports arrive from Google, Microsoft, Yahoo, and other major receivers. The reports describe alignment outcomes per sending IP. Build the inventory: SaaS senders, on-prem MTAs, marketing platforms, partner forwarders, and spoofing sources.

Weeks 4 to 10 — Fix legitimate-sender alignment

Work through each misaligned legitimate sender. Typical fixes: enable custom-domain DKIM at SaaS senders, update SPF, retire shadow-IT senders. Re-check aggregate reports weekly to confirm each fix landed.

Week 11 — Advance to quarantine (pct=5)

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

Now 5% of failing apex mail is routed to spam. The small sample surfaces any sender that Weeks 4-10 missed. Read rua reports daily for the first week, then weekly.

Weeks 12 to 16 — Ramp pct=

• Week 12: pct=25
• Week 14: pct=50
• Week 16: pct=100 (or omit the tag)

Weeks 17 to 22 — Stabilize at p=quarantine; pct=100

Two to four weeks at full quarantine enforcement, ideally spanning at least one weekly-cadence sender cycle (e.g., a payroll mailer that runs every Wednesday) and one monthly-cadence sender cycle (e.g., a monthly customer newsletter).

Week 23 — Advance to p=reject (pct=5)

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

Reject 5% of failing apex mail. Now the failure mode is non-recoverable (SMTP bounce) — keep a close eye on the rua reports and any support tickets about bounced mail.

Weeks 24 to 26 — Ramp pct= to 100

• Week 24: pct=25
• Week 25: pct=50
• Week 26: pct=100 (or omit the tag)

Week 26+ — Operational steady state

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

DMARC reaches the goal state. Aggregate-report monitoring continues forever — new senders (a new SaaS tool, a new partner) can break alignment at any time and rua reports are the detection signal.

7. Rollout best practices

1. Publish rua= on day one. The aggregate-report stream is the single most important rollout diagnostic. Without rua, you are advancing policy stages blind.
2. Always go through quarantine. Never jump from p=none to p=reject. The quarantine phase is the recoverable failure mode that surfaces problems without dropping mail.
3. Lock down non-sending subdomains first. Publish np=reject from day one; publish sp=quarantine as soon as you have inventoried subdomain senders. Subdomains are the easy half of the rollout.
4. Time observation windows around cadence. A weekly payroll mailer does not appear in a Monday-to-Friday observation window. Ensure each ramp step spans at least one weekly cycle and ideally one monthly cycle for the longest ramps.
5. Use a low TTL on the _dmarc record. 300-3600 seconds. This lets you roll back quickly if a ramp step blocks legitimate mail.
6. Maintain a rollback record. Keep the previous DMARC TXT value ready to re-publish if the next ramp step breaks something. Rollback is just a DNS edit — but you do not want to compose the rollback record during an incident.
7. Communicate the rollout internally. Marketing, HR/payroll, support, and partner-integration teams all need to know that DMARC is rolling out and what the symptoms of misalignment look like (spam-folder placement, bounce messages).
8. Document every sender. Build a spreadsheet of every legitimate sending source: tool name, owner, SPF include or DKIM selector, current alignment status, remediation owner. This is the artifact you will reference for years.
9. Monitor after p=reject ships. DMARC monitoring is forever. Schedule a monthly review of aggregate reports indefinitely.
10. Read forensic (ruf) reports if you have them. ruf reports include the From: header of failing mail; they accelerate debugging when an aggregate report shows a strange sending IP. Most receivers do not send ruf reports, but Google does (and others do partially).

8. Common rollout mistakes

1. Jumping straight from p=none to p=reject. The single most common cause of self-inflicted email outages. Quarantine first.
2. Leaving p=none forever. A DMARC record at p=none with no rollout plan publishes the fact that you have DMARC monitoring without actually protecting your domain. After 12-24 months at p=none, the rollout has stalled — fix it.
3. Ignoring rua reports. Publishing rua= without reading the reports is monitoring theatre. The reports are the signal — without consuming them, you are advancing policy stages blind.
4. Ramping pct= without an observation window. A pct= ramp from 5 to 100 in one day is no rollout at all. Each step needs at least a week to surface previously-unseen senders.
5. Forgetting third-party senders. Marketing tools, transactional-email APIs, ticketing systems, and partner notifications all need DKIM alignment. The aggregate reports will surface them — read the reports.
6. Publishing duplicate DMARC TXT records. RFC 7489 §6.6.3 requires exactly one DMARC TXT record per domain. A second record (often left over from a vendor trial) invalidates the entire policy at receivers.
7. Missing sp= on a parent domain with active subdomain senders. Without sp=, every subdomain inherits the apex p=. If the apex is p=reject and a subdomain has a separate sending estate that is not yet aligned, the subdomain traffic breaks.
8. Using a single high TTL. A 24-hour TTL on the _dmarc record means rollback takes 24 hours. Use 300-3600 seconds for the entire rollout, only increasing the TTL after p=reject stabilizes.
9. Skipping the np= tag. np=reject closes the NXDOMAIN-subdomain spoofing surface at zero risk. There is no legitimate mail that requires sending from a non-existent subdomain. Publish np=reject on day one.
10. Stopping aggregate-report monitoring after p=reject ships. Rollout is a project; monitoring is permanent. A new SaaS deployment three months after p=reject can reintroduce misalignment — the rua reports are the detection signal.

9. Rollout troubleshooting

Legitimate mail is being quarantined or rejected

Identify the source from the aggregate reports — every quarantine/reject decision is logged with the sending IP. Look up the IP, identify the sender, and confirm whether the sender supports custom-domain DKIM. If yes, enable it. If no, consider whether the sender can be migrated to a DMARC-aware alternative or whether the relevant mail flow should use a different From: domain.

Aggregate reports stopped arriving

Verify the rua= mailbox is accepting mail (the rua mailbox itself must align with DMARC if it is on the same domain — a chicken-and-egg problem during rollout that is best solved by hosting the rua mailbox at a different domain or by publishing a cross-domain authorisation record per RFC 7489 §7.1). Confirm the rua= mail is not being spam-filtered by the mailbox provider.

The pct= ramp surfaced a new misaligned sender

Roll back to the previous pct= value (DNS edit, propagates within TTL). Add the new sender to the inventory. Fix alignment. Re-attempt the ramp step after a clean observation window.

A subdomain breaks after publishing sp=quarantine

The subdomain has senders the apex rollout did not inventory. Either publish a subdomain-specific DMARC record (_dmarc.subdomain.example.com with its own p=) and run an independent rollout for that subdomain, or roll back sp= and inventory the subdomain senders before advancing.

Forwarded mail is failing DMARC at p=reject

SPF alignment routinely breaks during forwarding (envelope rewrite). The fix is to ensure DKIM alignment is solid — DKIM survives forwarding when the message body is not modified. If both SPF and DKIM fail under forwarding, the forwarder should adopt ARC (RFC 8617) to preserve authentication results across the hop.

A short-lived spike in DMARC failures appeared

Usually a new third-party tool was configured to send mail from your domain without alignment. Identify it from the aggregate reports (a new sending IP that was not in last week's report), confirm it is legitimate, and align it.

Receivers ignore the published policy

DMARC enforcement is at receiver discretion — some smaller receivers partially implement DMARC. The major consumer mailbox providers (Google, Microsoft, Yahoo) enforce DMARC reliably. Smaller corporate gateways and some ISP mailers vary. This is not a misconfiguration — it is the reality of DMARC deployment at receivers.

10. Frequently Asked Questions

What is the DMARC policy rollout?

The DMARC policy rollout is the phased migration of the p= tag from p=none (monitoring mode, no enforcement) through p=quarantine (route unaligned mail to the spam folder) to p=reject (refuse unaligned mail at the SMTP level). RFC 7489 §6.3 defines the three policy states; the rollout sequence itself is operational guidance because the receiver acts on whatever p= value is currently published — there is no built-in ramp. Operators advance one stage at a time, monitoring aggregate (rua) reports between stages to confirm no legitimate mail flows are being blocked.

How long should a DMARC rollout take?

A typical DMARC rollout takes three to six months end-to-end. The general cadence: 2-4 weeks at p=none to discover every legitimate sender via aggregate reports; 4-8 weeks fixing alignment for each discovered sender (SaaS DKIM enabling, SPF cleanup, third-party DMARC delegation); 2-4 weeks at p=quarantine; pct= gradual ramping from 5 -> 25 -> 50 -> 100 over 4-8 weeks; then p=reject. Larger organizations with diverse sending estates (HR, marketing, transactional, third-party SaaS, partner portals) typically need the upper end of the range.

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

p=none requests no action — receivers report alignment results via aggregate (rua) reports but deliver mail normally regardless of DMARC outcome. p=quarantine requests that DMARC-failing mail be routed to the spam folder (the exact action is at the receiver's discretion; most route to spam, some apply additional spam-score weighting). p=reject requests that DMARC-failing mail be refused at the SMTP RCPT TO stage, before the message body is accepted, so the sending MTA receives a bounce. p=reject is the only state that actually prevents DMARC-failing mail from reaching the recipient.

What does the pct= tag do during rollout?

pct= specifies the percentage of mail subjected to the published policy. pct=100 (the default) applies p= to 100% of DMARC-failing mail. pct=25 with p=quarantine applies quarantine to 25% of failing mail and downgrades the remaining 75% to p=none behaviour. RFC 7489 §6.6.4 defines this as a sampling mechanism for gradual rollout: ramp pct= from 1 -> 10 -> 25 -> 50 -> 100 between policy changes so you discover blocked legitimate flows on a small sample before the full rollout. Note: dmarcbis (the in-progress successor draft) deprecates pct= — read the dmarcbis transition notes before relying on pct= for a brand-new rollout.

Should I jump straight from p=none to p=reject?

No. Jumping straight from p=none to p=reject is the single most common cause of self-inflicted email outages during DMARC rollout. p=none gathers DMARC-failure data via aggregate reports but takes no action on failing mail. Moving directly to p=reject means every legitimate sender that was failing alignment under p=none (and was NOT noticed because mail still delivered) now hits a hard SMTP reject. Pass through p=quarantine first — the spam folder is a recoverable failure mode that surfaces problems without dropping mail.

How do I know when it is safe to move from p=quarantine to p=reject?

Three signals: (1) Two to four consecutive weeks of aggregate (rua) reports showing zero DMARC-failing mail from legitimate sources — every aligned source pass-rate at or near 100%, every misaligned source identified and either fixed or accepted as known-failing. (2) No support tickets about missed mail (transactional, password reset, partner notification) that would indicate legitimate mail was hitting quarantine. (3) The pct= sampling ramp at p=quarantine reached pct=100 with no new failure modes appearing. If all three are true, advance to p=reject.

What is the difference between p=, sp=, and np=?

p= sets the policy for the organizational domain (the apex). sp= overrides p= for ALL subdomains. np= (added in RFC 9091) overrides p= for non-existent subdomains specifically — protecting parked subdomains from spoofing without affecting any defined subdomains. During rollout, the sp= and np= tags are often advanced AHEAD of p= because subdomains are easier to control than the apex (a non-sending subdomain can move to p=reject on day one without risk). The RFC 9091 waterfall: np= wins for NXDOMAIN subdomains, sp= wins for existing subdomains, p= wins for the apex.

11. Related guides

• DMARC deployment checklist (operator quick-reference) — the concise per-phase action list that complements this deep dive. Covers the prerequisites checklist, per-phase action items, per-phase exit criteria, a decision matrix for common rollout scenarios, and an FAQ. Most operators keep both pages open in adjacent browser tabs during a real rollout: this page explains the WHY and the underlying mechanisms, the checklist explains the WHAT and WHEN in the order the operator works through them.
• DMARC reporting pipeline — the STAGED-ROLLOUT-AS-RUA-INGESTION- PIPELINE-CONSUMER companion documenting the end-to-end aggregate-report transport- and-ingestion pipeline whose per-day per-source-IP per-disposition row-stream is the EVIDENCE INPUT against which every phase-advance decision documented on this rollout deep dive is gated. Where THIS page documents the Week 0 → Week 26 staged rollout cadence (p=none monitoring → p=quarantine pct=1 → pct=5 → pct=10 → pct=25 → pct=50 → pct=100 → p=reject pct=1 → … → p=reject pct=100), the operator decision rules that govern each phase advance (per-source-IP unauthenticated- volume below the pre-publication-baseline floor, per-organisational-sub-domain alignment-pass rate above the deliverability-safety threshold, zero unexplained quarantine-rate spikes during the dwell-window), the per-phase exit criteria, and the rollback triggers, the reporting-pipeline spoke documents the INGESTION INFRASTRUCTURE that surfaces every one of those decision-gate signals: the receiver-side report-generator that runs on a per-day cadence at every major mailbox provider, the DNS resolution of the publisher's rua= URI to the operator's inbound mailbox or HTTPS-webhook endpoint, the MIME-attached SMTP / HTTPS delivery of the gzip-or-zip compressed RUA XML payload, the operator- side mailbox-poller or webhook-handler that retrieves the inbound report, the MIME-part extraction step, the gzip / zip / tar.gz decompression step, the RUA XML schema-validation step, and the row-by-row ingestion into the analyzer's dmarc_records table that produces the per-(source-IP, day, disposition, alignment-pass / alignment-fail) tuple the operator joins against the rollout-decision rules on this page. Without a fully-functioning RUA ingestion pipeline, EVERY phase advance documented on this page becomes BLIND: an operator cannot tell whether Week 1's p=none-baseline-collection actually captured the long-tail legitimate-but-misconfigured senders the baseline is supposed to expose (mailing-list relays whose ARC chain rescues alignment after the first forwarder, niche transactional-mail SaaS whose include: chain is broken, on-prem-only relays whose new MX configuration the operator forgot to add to the SPF record), whether Week 4's p=quarantine pct=5 advance produced any quarantine-rate-spike on the organisational-sub-domain hierarchy, or whether the Week 18 p=reject pct=50 advance triggered the rollback condition (sustained-three-day deliverability-rate drop below the safety floor). The reporting-pipeline spoke is therefore the OBSERVATION-INFRASTRUCTURE PREREQUISITE for the rollout cadence documented on this page — the rollout is gated on per-phase RUA-row inspection, the pipeline is the carrier that delivers those rows from the receiver-side verifier to the operator-side decision loop. Read the reporting-pipeline spoke alongside this rollout deep dive when scoping the rollout-observability posture the rollout cadence depends on — the pipeline must be FULLY-FUNCTIONING before Week 0 begins, and any pipeline-ingestion failure mode (mailbox bouncing, MIME extraction failing, gzip decompression failing, XML schema-validation failing, row-ingestion DB error) is itself a rollback trigger documented in this rollout reference. Closes the DMARC-pillar-broader ↔ DMARC-reporting- pipeline bridge whereby the per-phase rollout-decision-gate signal this page defines is the END-CONSUMER of every ingestion-pipeline mechanic the pipeline spoke documents.
• DNS propagation explained (TTLs, resolver caching, and the Week-boundary timing dependency) — the operational reference for the invisible-but-critical timing layer that every phase advance in this rollout deep dive silently depends on. Every Week-N → Week-N+M boundary in this rollout assumes the previously-published DMARC record has propagated to every recursive resolver that will evaluate the next phase's mail — but DNS propagation is not a wave: it is the gradual aging-out of cached records across millions of recursive resolvers, governed by the per-record TTL (RFC 1035 §3.2.1 + RFC 2181 §8) plus the resolver's own minimum and maximum cache caps. Operators who publish a Week 0 p=none record with the provider-default TTL of 14 400 seconds (4 hours) — or worse, 86 400 seconds (24 hours) — then advance to p=quarantine on Week 4 morning will see receivers reject mail against the cached p=none record for hours after the change goes live at the authoritative nameservers, and will get conflicting aggregate-report rows for several days as different receivers' caches age out at different rates. The DNS propagation reference documents: the per-record TTL mechanics and the authoritative-vs-recursive-vs-stub-client chain of caches, the recommended 300-second (5-minute) TTL for active rollouts vs the 3600-second (1-hour) TTL for steady-state production records, the lower the TTL one full TTL period BEFORE you change the record rule that makes every phase advance feel instantaneous, the operator verification workflow using dig / kdig against the authoritative nameservers + multiple geographically diverse recursive resolvers (1.1.1.1 / 8.8.8.8 / 9.9.9.9) to confirm the new record has actually replaced the old one end-to-end, and the emergency-rollback case for short TTLs when an inadvertent p=reject advance breaks legitimate mail. Read this BEFORE the rollout's Week 0 record publication — choosing the right TTL on day one is the single highest-leverage prerequisite decision in the whole rollout playbook.
• DMARC policy modes: p=none vs p=quarantine vs p=reject (comparative deep dive) — the head-to-head comparative reference for the three policy values defined by RFC 7489 §6.3. Where this page walks the policy values through a phased rollout timeline (Week 0 → Week 26), the policy-modes page treats the three values as the comparative subject: per-mode semantics, side-by-side comparison table across 11 dimensions, receiver behaviour at the major mailbox providers, the pct= sampling tag interaction (including the dmarcbis removal), how sp= and np= subdomain policies interact with the apex p=, scenario-based decision matrix, and FAQ. Read it when stakeholders ask "what is the difference between p=quarantine and p=reject?" or "why is p=none not sufficient?" — questions this rollout deep dive answers in passing but the policy-modes page answers head-on.
• Multi-Domain DMARC Strategy (portfolio operator reference) — the portfolio-strategy companion to this single-domain rollout deep dive. Where this page walks one record through one rollout, the multi-domain guide walks the portfolio: domain inventory + six-category taxonomy (production sending / marketing subdomain / parked / acquired-company / brand-defensive / delegated), the organizational domain rule (RFC 7489 §3.2 + Public Suffix List), the sp= + np= (RFC 9091) subdomain hardening pair, central RUA reporting consolidation, the acquired-company 6-step integration playbook, and the canonical null-SPF + p=reject + null-MX (RFC 7505) parked-domain hardening pattern. Read this page first, then the multi-domain guide to scale the rollout across acquired companies, ccTLD registrations, marketing subdomains, and brand-defensive parked properties.
• DMARC for Shared Hosting — shared-IP-reputation-bounded ramp-rhythm on Plesk / DirectAdmin / ISPConfig / generic-no-control-panel platforms — the SHARED-HOSTING-RAMP-RHYTHM-CONSTRAINT companion to this phased rollout playbook for the SMB operator population whose Week 0 → Week 26 ramp is structurally slower than the dedicated-IP-pool tenant the canonical timeline this page documents is calibrated for. Where THIS page walks one record through the Week 0 p=none → Week 4 p=quarantine → Week 26 p=reject canonical ramp targeting a tenant with full sending- infrastructure control, the shared-hosting spoke documents the per-phase RAMP-RHYTHM CONSTRAINTS the shared-IP-pool operator persona must respect: Phase 1 (p=none) observation window is structurally longer because shared-IP co-tenant churn introduces month-over-month DMARC-fail-rate noise that masks the operator's own authoring-stability signal (a 4-week dedicated-IP baseline is a 12-week shared-IP baseline); Phase 2 (p=quarantine) ramp is paced by the slowest-changing per-tenant DKIM rotation event in the shared-IP pool (because cross-tenant DKIM-signing-drift registers in the operator's RUA as unrelated-source-IP DMARC-fail rows that the operator must distinguish from their own infrastructure churn); Phase 3 (p=reject) gate is COUPLED to the shared-IP pool's collective bounce rate ceiling at major receivers (Gmail, Yahoo, Outlook each treat shared-IP-pool bounce-rate as a per-IP reputation signal, and a co-tenant's surge breaks the operator's own delivery during a p=reject ramp); pct= sampling on shared-hosting is operationally valuable as a per-tenant ramp-throttle independent of the per-receiver evaluation of the shared-IP pool's collective reputation. Read the shared-hosting spoke when planning a DMARC rollout 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-phase RAMP-RHYTHM CONSTRAINTS the shared-IP-pool operator persona must respect that a dedicated-IP-pool operator does not.
• DMARC for cPanel & Shared Hosting — the CPANEL-TENANT-RAMP-MILESTONE-LADDER- WITH-WHM-RESELLER-AND-EMAIL-DELIVERABILITY- UI-MEDIATED-PHASE-TRANSITION-INSTRUMENTATION companion reference. Where THIS page documents the universal Week 0 p=none → Week 4 p=quarantine; pct=5 → Week 12 pct=25 → Week 16 pct=100 → Week 20 p=reject; pct=25 → Week 26 p=reject; pct=100 canonical ramp sequence in receiver-side enforcement-tier-progression terms, the DMARC-for-cPanel deployment spoke documents the CPANEL-SPECIFIC OPERATIONAL EXECUTION of the SAME ramp sequence across FIVE cPanel-UI-mediated phase- transition checkpoints that map the receiver-side timeline onto cPanel- tenant operator-actionable steps: (1) Phase 1 Week 0 baseline observation is executed via cPanel UI → Email Deliverability → Manage → "Install the Suggested Record" (which auto-publishes the p=none DMARC TXT record AND configures the rua=mailto: mailbox); (2) Phase 2 Week 4 sender-inventory completion is executed via WHM → Email Deliverability → "Diagnostics" run across every cPanel-tenant-protected-domain account to surface every Exim-relay source_ip the cPanel server emits from (and every websitewelcome.com-cohabitant IP the SPF cascade authorises); (3) Phase 2 Week 8 SPF + DKIM fixes execute via cPanel UI → Email Deliverability → Manage → "Repair" (which re-publishes the default._domainkey DKIM TXT record AND the cPanel-default SPF cascade); (4) Phase 3 Week 12 p=quarantine; pct=5 ramp instrumentation requires WHM → Tweak Settings → "Email DKIM" verification across every tenant-domain (because cPanel's EXIM_DKIM toggle is per-tenant and a single unsigned-tenant-domain breaks the Phase-3-advancement gate at ~99% legitimate-mail policy_evaluated=pass); (5) Phase 4 Week 26 p=reject; pct=100 enforcement is operator- gated on the WHM-reseller-tier coordination protocol (because the WHM-level "Reseller Account" boundary introduces a SECOND tier of envelope- rewriting whose Phase-4 advancement gate is per-reseller not per-tenant — the operator must coordinate across every reseller account before issuing the final p=reject; pct=100 TXT-record update). Read the DMARC-for-cPanel spoke when ramping a cPanel-tenant-protected domain through the canonical Week 0 → Week 26 timeline THIS page documents — the spoke is the authoritative reference for the per-phase cPanel-UI-mediated operator-actionable steps that map the receiver-side enforcement-tier ladder onto cPanel's WHM + Email Deliverability UI surface.
• DMARC record tags explained — every tag in the DMARC DNS record (v, p, sp, np, pct, rua, ruf, adkim, aspf, fo, rf, ri) with syntax, defaults, and interaction rules.
• DMARC alignment explained — identifier alignment (the SPF/DKIM-domain-matches-From: rule) that determines DMARC pass/fail. The rollout assumes you understand alignment.
• DKIM alignment with DMARC — the POLICY-ROLLOUT-PHASE-EXIT-CRITERION- DEPENDS-ON-AGGREGATE-DKIM-ALIGNMENT-PASS- RATE companion to this rollout playbook. Where THIS page documents the Week-by-week rollout cadence (Week 0 RUA-baseline → Week 2 SPF/DKIM remediation → Week 4 p=quarantine ramp → Week 8 pct=25 → Week 12 pct=50 → Week 16 pct=75 → Week 20 p=reject commitment → Week 26 retrospective), the DKIM-alignment spoke is the BYTE-LEVEL EVALUATION REFERENCE documenting the receiver-side decision rule whose aggregate pass-rate the publisher MUST measure from RUA aggregate-report data at every phase exit. The POLICY-ROLLOUT-PHASE-EXIT- REQUIRES-DKIM-ALIGNMENT-FLOOR cross- reference establishes FOUR structurally- distinct per-phase DKIM-alignment-floor dimensions whose verification gates the rollout progression: (i) Week 0 baseline measurement — per-sender DKIM-alignment pass-rate discovery from RUA aggregate-report data — before any policy change, the publisher MUST measure the per-sender DKIM-alignment pass-rate from the first 2-4 weeks of RUA data with p=none; the DKIM-alignment spoke documents the per-sender aggregate- report row structure (the identifier.header_from domain + the auth_result.dkim.domain + auth_result.dkim.result triple) whose per-domain match evaluation determines the alignment verdict — without baseline DKIM-alignment rates per-sender, the publisher cannot identify which senders are at risk of delivery degradation when policy tightens; (ii) Week 4 p=quarantine ramp entry — DKIM-alignment-pass-rate ≥98% as prerequisite — the spoke documents the operationally-canonical ≥98% per-sender DKIM-alignment-pass-rate floor required before advancing from p=none to p=quarantine; senders consistently below the floor are flagged for remediation (DKIM-CNAME delegation gaps, third-party signer d=-divergence, on-prem hybrid signing- ordering defects) before policy tightening; the rollout pauses at p=none until the per-sender floor is reached; (iii) Week 8-16 pct=N ramp exit criteria — per-percentage DKIM-alignment- verdict-floor verification — during the pct=25/50/75 ramp, the spoke's RFC 7489 §3.1.1 evaluation rule continues to apply to the percentage of messages selected by the pct sample; the publisher MUST observe per-percentage DKIM-alignment-floor stability (≥98% across the sampled subset, not just the whole stream) before advancing pct; the spoke documents the aggregate-report row evaluation the publisher applies at each pct=N exit checkpoint; (iv) Week 20 p=reject commitment — per-organizational-domain DKIM- alignment-floor across ENTIRE portfolio of authorized senders — at p=reject entry, the spoke's DKIM-alignment-pass-rate floor becomes operationally LOAD-BEARING for deliverability: any sender below ≥99% DKIM-alignment will produce visible delivery degradation; the rollout's Week 20 commitment requires verified portfolio-wide alignment floor verification per the spoke's evaluation rule applied at portfolio scope. Read the DKIM-alignment-with-DMARC spoke alongside the rollout playbook at every phase-exit checkpoint — the spoke documents the receiver-side decision rule whose aggregate pass-rate the publisher must verify is stable before any phase advancement is operationally safe.
• DMARC for Office 365 hybrid — the dual-transport-path rollout deep dive for Exchange-on-prem + Exchange-Online coexistence — the per-deployment procedural deep dive on the Exchange-hybrid-coexistence rollout-topology that materially-alters the Week 0 → Week 26 cadence this page documents for single-path operators. Where THIS page documents the single-path rollout sequence (Week 0 p=none → Week 4 TTL-lowering + sender-inventory → Week 8 SPF + DKIM fixes → Week 12 p=quarantine; pct=5 → Week 16 pct=25 → Week 20 p=quarantine; pct=100 → Week 26 p=reject), the hybrid-deployment spoke documents the DUAL-TRANSPORT-PATH variation of the same rollout sequence for operators with concurrent Exchange-on-prem + Exchange-Online mailbox populations. The hybrid topology introduces three structurally-distinct rollout constraints the single-path cadence documented on this page does not address: (a) the SPF-authorisation prerequisite is DOUBLED — the on-prem Exchange edge MTA's outbound IPs PLUS the EOP outbound IPs must BOTH appear in the SPF record before any p=quarantine or p=reject advance, because mail can leave through either path during coexistence and a missing authorisation on either path causes unaligned-SPF + DMARC-fail at the receiver for ALL senders on the missing path; (b) the DKIM-signing configuration is DUAL — on-prem mail typically signs with the operator's public domain via an Exchange Edge Transport rule (operator-managed key), while EOP signs with the CNAME-delegated Microsoft-managed key — both must pass DKIM-verification AND both must align with the From: header per RFC 7489 §3.1.1 before any policy advance, because a broken-DKIM-on-one-path failure produces aligned-SPF-but-unaligned- DKIM mail on that path that the DMARC verdict-evaluation will still pass (DMARC is "either-passes"), but which the operator should fix before advancing because the path's DMARC-pass margin is then dependent on SPF authorisation alone; (c) the DMARC-aggregate-report attribution is DUAL — a single receiver-emitted RUA report contains row groups for both the on-prem edge IP block AND the EOP IP block for the same sending domain, and the operator must READ BOTH row-groups during the Week 4 sender-inventory phase to confirm the rollout is healthy on BOTH paths — single-path operators only have one row-group per sender; hybrid operators must add path attribution to their sender-inventory model. Read the hybrid-deployment spoke when an operator with concurrent Exchange-on-prem + Exchange-Online mailbox populations executes this page's rollout cadence — the spoke is the authoritative reference for the dual-transport-path topology variation of the single-path cadence this page documents at the canonical Week 0 → Week 26 timeline level.
• Phishing protection — the business case for advancing to p=reject — the stakeholder-facing companion to this technical rollout deep dive. Every phase advance documented here (Week 0 p=none → Week 12 p=quarantine; pct=5 → Week 20 p=quarantine; pct=100 → Week 26 p=reject) is ultimately justified by the anti-phishing protection each policy value provides at the receiver. Where this page documents WHAT to do at each phase and WHEN to advance, the phishing page documents WHY each phase advance is worth the operational risk: the seven canonical phishing attack patterns (look-alike-domain spoofing, exact- domain spoofing, display-name spoofing, hijacked legitimate-domain abuse, subdomain abuse, vendor-compromise spear-phishing, business-email- compromise wire-fraud), the policy-mode-to-pattern mapping that shows which patterns each advance closes, and the financial-impact data (FBI IC3 $50B+ BEC losses 2013-2022) that justifies the rollout to skeptical finance / legal / executive stakeholders. Read this page when budgeting the rollout or building the executive case for the operational investment.
• Email spoofing explained — the THREAT-TECHNIQUE foundation whose seven canonical spoofing techniques justify each cadence advance documented on this page — the THREAT-TECHNIQUE FOUNDATION companion to this rollout-cadence deep dive. Where this page documents the WEEK 0 → WEEK 26 timeline (Week 0 p=none → Week 12 p=quarantine; pct=5 → Week 20 p=quarantine; pct=100 → Week 26 p=reject) and the OPERATIONAL discipline each phase requires (rua-ingestion review, sender registry maintenance, rollback gates, complaint-rate budgets), the email-spoofing pillar documents the UPSTREAM JUSTIFICATION for advancing through that cadence: the seven canonical threat-techniques (direct domain spoofing, envelope MAIL FROM spoofing, display-name spoofing, lookalike-domain registration, IDN homograph attacks per UTS #39, cousin-domain registration, subdomain takeover via abandoned DNS), the specific cadence-phase that closes each (only Week 26 p=reject reliably closes direct domain From: forgery; only apex+ sp=reject by Week 26 closes subdomain abuse; np=reject per RFC 9091 closes never-existed- subdomain abuse), and the MITRE ATT&CK T1566 / T1583.001 / T1036 mappings the rollout cadence is ultimately measured against. The email-spoofing pillar makes the cadence-phase-to-threat-technique closure mapping EXPLICIT at section 6 ("How DMARC defends against spoofing") — critical operator knowledge when justifying the cadence-phase budget to skeptical stakeholders ("why advance from p=quarantine; pct=100 to p=reject if the cadence is already blocking SOME spoofing?"). Read the email-spoofing pillar once you have the cadence-timeline anchored on this page and need the THREAT-TECHNIQUE taxonomy reference for which forgery patterns each phase advance actually closes versus which require the FINAL Week 26 p=reject milestone — the threat-technique deep dive is the canonical operator vocabulary for framing the each-cadence-phase ROI argument the deliverability and BEC spokes complement with the deliverability-outcome and financial-impact framing.
• How attackers bypass DMARC — the POLICY-ROLLOUT-ATTACKER-RESIDUAL companion to this phased-rollout playbook. Where THIS page documents the OPERATIONAL CADENCE for advancing from p=none through p=quarantine; pct= ramping to p=reject at 100% (the Week 0 → Week 26 timeline, per-phase observation-window criteria, per-receiver propagation verification, pct=N sampling-tag micro-ramp discipline, rollback-trigger thresholds), the attacker-bypass spoke documents the POST-ENFORCEMENT ATTACKER RESIDUAL SURFACE that remains AFTER the operator completes the full ramp and reaches steady-state p=reject at 100%. The POST-ENFORCEMENT residual is STRUCTURALLY-DIFFERENT from the DURING-ROLLOUT failure surface this page catalogues — during rollout the operator is racing to close legitimate-sender misconfigurations before each phase advance, post-rollout the operator is managing the SET-DIFFERENCE between "what p=reject closes" and "what attackers still do" that no phase advance can address: (i) display- name spoofing against the post-p=reject operator (the attack alignment cannot see, no Week-N advance closes), (ii) lookalike- domain registration (typosquat / homograph / TLD-swap against the operator's organisational-domain — the attacker authors its own valid DMARC on the lookalike, the operator's p=reject has no jurisdiction), (iii) third-party-vendor compromise where the attacker takes over an ESP-tenant the operator legitimised in Phase 2 (the compromised ESP retains valid d= alignment under the operator's domain), (iv) DKIM- replay attacks where the attacker rebroadcasts a legitimately-signed message the operator authored (the signature still verifies; DMARC at p=reject accepts because alignment passes), (v) ARC trust-chain abuse via forwarders the operator's MTA trusts, (vi) compromised-internal-relay legitimate-d=-signing when the attacker has gained access to the operator's own SMTP-AUTH infrastructure, (vii) partner-supply-chain compromise where the upstream-vendor's compromised infrastructure signs with the partner's legitimately-aligned d= and forwards into the operator's communication graph, (viii) Reply-To substitution + conversation-hijacking, (ix) Punycode / IDN homograph on the From-header. The attacker-bypass spoke documents WHICH residual classes the Phase 5 steady-state monitoring cadence on this page must include as DETECT-NOT-PREVENT controls — every residual class has a corresponding RUA- stream or out-of-band signal the post-rollout operator monitors for (lookalike-domain registrations via threat-intel feeds, third-party-vendor anomalous-sending-pattern alarms, DKIM- replay forensics via duplicate-signature detection in RUA streams, internal-relay anomaly detection via sender-IP-vs- legitimate-IP-pool diff). Read the attacker-bypass spoke when the operator reaches Phase 5 steady-state — the spoke is the load-bearing post-enforcement-residual reference that defines the Phase 5 monitoring scope beyond the cadence advance documented on this page.
• Email deliverability — the cluster-spanning operational reference for the inbox-placement outcome that justifies the rollout cadence — the operational deep dive on the receiver-side deliverability outcome every cadence gate documented on this page is ultimately measured against. Where this page documents the Week 0 p=none → Week 12 p=quarantine; pct=5 → Week 20 p=quarantine; pct=100 → Week 26 p=reject CADENCE (what to do at each phase, when to advance, and which rollback gates to instrument), the deliverability spoke documents the OUTCOME the cadence pursues: inbox placement at Gmail, Outlook.com, Yahoo Mail, iCloud, and every other receiver that enforces the Gmail / Yahoo Bulk Sender Requirements (February 2024) gating bulk-sender inbox placement on DMARC-enforcement compliance. Specifically: Gmail Bulk Sender Requirements require p=quarantine minimum for senders shipping ≥5,000 messages per day to gmail.com inboxes, Yahoo Sender Best Practices similarly require DMARC enforcement at the apex, and Outlook.com bulk-sender guidance counts DMARC enforcement toward the four reputation sub-scores at M365 inbound. The rollout cadence on this page is timed specifically to let the deliverability outcome stabilise at each gate BEFORE advancing — the four-week pct=5 dwell window exists precisely so the operator can observe the deliverability impact in postmaster- tool dashboards and decide whether the legitimate-mail collateral damage rate is within the deliverability-budget tolerance. Where the cadence companion on this page is the TIMELINE for advancing, the deliverability spoke is the BUSINESS-OUTCOME reference covering the full deliverability framework (delivery funnel, authentication layer, sender reputation, list hygiene, postmaster tools, SMTP bounce taxonomy, placement models) that the cadence gates manipulate. Read the deliverability spoke when instrumenting per-gate deliverability observability ("which Postmaster Tools signals indicate the cadence advance was deliverability-safe", "what is the complaint-rate budget for the pct=100 advance", "how do I diagnose unexpected inbox-placement regression after a cadence step") — the spoke is the authoritative cluster-spanning operational reference for the deliverability outcome the rollout cadence is engineered to preserve.
• DMARC explained — the central DMARC primer covering the broader DMARC ecosystem, aggregate-report XML schema, and mailing-list / forwarding interactions.
• Business Email Compromise (BEC) — the financial-impact threat scenario that justifies advancing through the rollout cadence — the operational deep dive on the financial-impact threat scenario every cadence gate documented on this page is ultimately measured against. Where this page documents the Week 0 p=none → Week 12 p=quarantine; pct=5 → Week 20 p=quarantine; pct=100 → Week 26 p=reject CADENCE (what to do at each phase, when to advance, and which rollback gates to instrument), the BEC spoke documents the FINANCIAL- IMPACT THREAT SCENARIO the cadence ultimately defends against — the operationally-canonical financial- impact justification for the entire rollout investment. Specifically: the FBI IC3 data on Business Email Compromise losses (cumulative $50B+ 2013-2022 with $2.7B-$2.9B annual run rate 2019-2023) is the executive case for advancing the rollout cadence through every gate to p=reject — Week 0 p=none alone provides observability but ZERO BEC defense, Week 12 p=quarantine; pct=5 provides partial BEC defense (5 percent of spoofed mail diverted to spam folder), Week 26 p=reject finally closes the apex-domain-spoofing BEC variant (one of the six canonical BEC variants the spoke catalogues). Where the cadence companion on this page is the TIMELINE for advancing, the BEC spoke is the FINANCIAL- IMPACT REFERENCE covering the six canonical BEC variants (CEO fraud, vendor-invoice fraud, payroll-redirect, attorney impersonation, W-2 / data theft, account-compromise BEC), the five-stage BEC kill chain (recon → setup → pretexting → execution → laundering), the precise DMARC gap (DMARC closes exact-domain spoofing but NOT look-alike-domain BEC), and the full defense-in-depth control stack (DMARC enforcement + wire-transfer verification + look-alike-domain monitoring + employee training). Read the BEC spoke when building the executive / finance / legal case for why the rollout cadence is worth the operational risk — the spoke is the authoritative financial-impact reference that justifies the rollout investment at every gate.
• SPF explained — Sender Policy Framework (RFC 7208). Most rollout-blocking alignment failures originate in SPF.
• Why SPF alone is insufficient — the POLICY-ROLLOUT-EXPLAINS-WHY- DMARC-RAMP-EXISTS-AS-PRE-WEEK-0- MOTIVATION-LAYER companion to this DMARC policy rollout playbook. Where THIS page documents the time-axis migration from p=none monitoring-mode through p=quarantine + pct=-sampled ramp to p=reject at 100% enforcement (Week 0 → Week 26 typical cadence), the why-SPF-alone-is- insufficient spoke is the FOUNDATIONAL why-DMARC-exists reference whose 4-class SPF-insufficiency catalogue is the PRE-Week-0 motivation layer the operator team needs to justify the rollout investment to leadership and to align cross-functional stakeholders (security, IT operations, marketing, customer- success) on WHY the phased ramp is structurally necessary. The POLICY- ROLLOUT-EXPLAINS-WHY-DMARC-RAMP-EXISTS- AS-PRE-WEEK-0-MOTIVATION-LAYER cross- reference establishes FOUR structurally- distinct why-not-just-SPF rationale dimensions: (i) SPF-alone-leaves- RFC5322-From-spoofing-OPEN justifies- DMARC-rollout dimension — SPF per RFC 7208 produces a verdict for the RFC5321.MailFrom envelope domain ONLY; the RFC5322.From header (what mail clients display to end-users) is NEVER authenticated by SPF alone; this gap leaves brand impersonation OPEN regardless of how strict the operator's SPF -all qualifier is — the why-SPF-alone-is-insufficient spoke documents WHY closing this gap requires the DMARC alignment-evaluation layer the rollout ramp deploys; the rollout ramp's p=reject end-state is the structural closure of the RFC5322.From-spoofing attack class SPF alone CANNOT address; (ii) SPF-pass-rate-collapse-via-forwarders- without-DKIM-leg-justifies-DMARC-ramp dimension — SPF pass-rate collapses through forwarders (mailing- list-managers / .forward / corporate- gateway) producing legitimate-mail spf=fail at receivers; the rollout ramp's Week 0 → Week 12 monitoring-mode discovery phase surfaces these forwarder-induced SPF failures via DMARC aggregate reports (per RFC 7489 §A.2 RUA channel); the why-SPF-alone- is-insufficient spoke documents WHY DMARC's SPF-OR-DKIM alignment per RFC 7489 §3.1 is the structural rescue for forwarded mail — the DKIM leg survives forwarders that SPF collapses through; the rollout ramp's gate-criteria (DKIM pass-rate ≥ 95% across all monitored senders) is the structural commitment to the DKIM-as-second-leg complement the why-SPF-alone-is-insufficient spoke explains; (iii) SPF-lookup-budget- exhaustion-in-multi-tenant-publishing- justifies-DKIM-second-leg-via-DMARC dimension — SPF RFC 7208 §4.6.4 imposes a 10-DNS-lookup budget across the entire include: mechanism cascade; multi-tenant publishers (SaaS + ESP + transactional- provider + analytics-pixel-sender) routinely exceed this budget, producing spf=permerror verdicts that collapse the SPF authentication contract entirely; the rollout ramp's Week 0 discovery phase surfaces these permerror outcomes per source-IP via the per-sender baseline measurement discipline; the why-SPF-alone-is- insufficient spoke documents WHY DKIM has no equivalent lookup-budget — one DNS-TXT lookup per signature — and WHY the rollout ramp's gate-criteria treat DKIM as the structurally-more-robust leg in multi-tenant publishing contexts where SPF lookup-budget exhausts; (iv) SPF-lacks-enforcement-policy- primitive-justifies-DMARC-p-tag-as- publisher-controlled-rejection dimension — SPF qualifier (-all / ~all / ?all / +all) influences receiver-side reputation heuristics but does NOT provide a normative-enforcement-mode contract; receivers may quarantine, reject, or ignore spf=fail verdicts per their own policy at their own discretion; DMARC RFC 7489 §6.3 p= tag (p=none / p=quarantine / p=reject) is the publisher- controlled normative-enforcement-policy primitive that gives the publisher DIRECT control over receiver-side rejection — the rollout ramp's TIME- AXIS migration from p=none through p=quarantine to p=reject is the structural progression in publisher-controlled rejection authority that SPF alone cannot provide; the why-SPF-alone-is- insufficient spoke documents WHY the DMARC publisher-controlled enforcement- policy primitive is structurally load-bearing and WHY the rollout ramp exists to time-shift the publisher through the trust-building progression. Pair this page (the Week 0 → Week 26 DMARC policy-rollout time-axis playbook) with the why-SPF-alone-is-insufficient spoke (the foundational why-DMARC- exists reference) when an operator team authors the pre-Week-0 stakeholder- alignment narrative and needs to apply the same four-class why-not-just-SPF rationale discipline as the structural motivation layer that justifies the rollout investment to leadership and cross-functional stakeholders.
• SPF for Google Workspace — the WORKSPACE-PHASED-RAMP-SPF-PREREQUISITE companion for Workspace-tenant operators executing this DMARC rollout playbook — the WORKSPACE-PHASED-RAMP-SPF-PREREQUISITE companion to this DMARC policy rollout playbook. Where THIS page documents the TIME-AXIS migration from p=none through p=quarantine to p=reject with the relaxed-to- strict alignment migration, the SPF-for-Google-Workspace spoke is the Workspace-tenant-SPECIFIC SPF-authoring prerequisite reference that determines whether the rollout's PHASE-EXIT GATES (Week 4 advance from p=none to p=quarantine requires SPF-aligned-pass population at ≥99% of legitimate outbound; Week 8 advance from p=quarantine to p=reject requires the same floor sustained for 30 days; Week 12+ steady-state p=reject requires the floor maintained indefinitely) are even reachable for a Workspace-tenant operator. The spoke documents the Workspace-tenant authoring decisions that determine the SPF-aligned-pass population: the load-bearing include:_spf.google.com baseline token (one include slot, covering Gmail-outbound MTAs and Workspace's google-managed outbound IP space), the ~all-vs--all qualifier-selection decision tree (Workspace ships SPF guidance for both depending on Workspace-hybrid topology presence), the on-prem-Postfix / on-prem-Exim hybrid co-existence pattern (on-prem outbound hostnames must be added as explicit ip4: or a: tokens because they are NOT covered by the google-managed _spf.google.com include), the secondary-SaaS-sender pattern (MailChimp / SendGrid / HubSpot / Mailgun-via-Workspace senders need their own include tokens added alongside the Workspace baseline), and the Workspace SMTP-relay-from-outside- Workspace coverage gap (Workspace SMTP-relay from outside the Workspace-managed IP envelope is NOT covered by _spf.google.com). Read the SPF-for-Workspace spoke when the operator running THIS rollout is on Google Workspace — the spoke is the authoritative per-platform SPF-authoring prerequisite reference that establishes whether the rollout's PHASE-EXIT GATES are achievable on a Workspace tenant, and a misconfigured Workspace SPF record can block the entire rollout from advancing past p=none indefinitely.
• SPF for Microsoft 365 — the M365-TENANT-PHASED-RAMP-SPF- PREREQUISITE-WITH-SPF-PROTECTION-OUTLOOK- INCLUDE-CASCADE-LOOKUP-COST-MANAGEMENT companion to this DMARC policy rollout playbook. Where THIS page documents the TIME-AXIS migration from p=none through p=quarantine to p=reject with the relaxed-to- strict alignment migration, the SPF-for-Microsoft-365 spoke is the M365-tenant-SPECIFIC SPF-authoring prerequisite reference that determines whether the rollout's PHASE-EXIT GATES (Week 4 advance from p=none to p=quarantine requires SPF-aligned-pass population at ≥99% of legitimate outbound; Week 8 advance from p=quarantine to p=reject requires the same floor sustained for 30 days; Week 12+ steady-state p=reject requires the floor maintained indefinitely) are even reachable for a Microsoft-365-tenant operator. The spoke documents the M365-tenant authoring decisions that determine the SPF-aligned-pass population: the load-bearing include:spf.protection.outlook.com baseline token (a single include slot whose sub-include cascade — spf-a.outlook.com / spf-b.outlook.com / spfd.protection.outlook.com — recursively consumes 4-6 of the 10 available lookup slots, leaving thin headroom for secondary ESPs co-habiting with M365), the ~all-vs--all qualifier-selection decision tree (M365 deployment guidance for both depending on hybrid-Exchange topology presence), the on-prem Exchange hybrid co-existence pattern (on-prem Exchange outbound hostnames must be added as explicit ip4: or a:mail.<org>.<tld> tokens because they are NOT covered by the Microsoft-managed spf.protection.outlook.com include), the secondary-SaaS-sender pattern (SendGrid / Mailgun / Amazon SES / Mailchimp / HubSpot / Marketo senders need their own include tokens added alongside the M365 baseline — and the cascade-overflow class diagnosed in the sibling SPF-PermError-vs-TempError entry is the dominant failure mode this layering produces), and the M365 Direct-Send / SMTP-AUTH-relay-from-outside-M365 coverage gap (Direct-Send originating from outside the M365-tenant outbound IP envelope is NOT covered by spf.protection.outlook.com). Read the SPF-for-Microsoft-365 spoke when the operator running THIS rollout is on Microsoft 365 / Exchange Online — the spoke is the authoritative per-platform SPF-authoring prerequisite reference that establishes whether the rollout's PHASE-EXIT GATES are achievable on an M365 tenant, and a misconfigured M365 SPF record (cascade overflow, missing secondary-ESP includes, wrong qualifier selection) can block the entire rollout from advancing past p=none indefinitely.
• DKIM explained — DomainKeys Identified Mail (RFC 6376). Custom-domain DKIM is the single most important Phase 2 remediation.
• DKIM DNS TXT-record byte syntax (RFC 6376 §3.6.1 tag-list grammar) — the PER-SELECTOR-PUBLISHER-SIDE-TXT-RECORD- AUTHORING-AS-LOAD-BEARING-PHASE-2-BASELINE- OBSERVABILITY-PREREQUISITE companion to this DMARC policy-rollout reference. Where THIS page documents the rollout phase sequence (p=none → p=quarantine → p=reject), the per-phase pct=-ramp schedule, and the per-phase exit-criteria gates the publisher advances through, the DKIM-DNS-syntax spoke documents the PUBLISHER-SIDE TXT-RECORD BYTE-LEVEL AUTHORING REFERENCE whose per-tag byte-correct publication is the LOAD-BEARING UPSTREAM PRECONDITION every per-phase exit- criteria gate THIS rollout page documents structurally depends on. The PER-DKIM-TXT- RECORD-TAG-VS-ROLLOUT-PHASE cross-reference establishes FOUR structurally-distinct per- publisher-side-DKIM-TXT-record-tag-to- rollout-phase coupling dimensions: (i) byte-correct v=DKIM1 version-prefix + p= base64- encoded public-key-material publication as Phase 2 baseline-observability prerequisite — the Phase 2 baseline-observability stage this rollout schedules consumes per-receiver per-forwarder per-selector aggregate-report rows showing dkim=pass verdicts; selectors lacking the byte-correct v=DKIM1 version-prefix or publishing an empty p= tag at steady-state produce dkim=permerror (key syntax) at every receiver per §6.1.2, denying Phase 2 the per-selector baseline-observability evidence the Phase 3 ramp-exit-criteria floor depends on; the DKIM-DNS-syntax spoke documents the canonical publisher-side authoring rule whose violation forecloses Phase 2 baseline-observability; (ii) RFC 8301 §3 RSA-2048 minimum p= public-key-strength publication as Phase 3 per-percentage-ramp- exit-criteria floor — every per- percentage Phase 3 ramp advancement (pct=10 → pct=25 → pct=50 → pct=75 → pct=100) consumes per-receiver per- forwarder rolling DKIM-aligned-pass-rate evidence; selectors still publishing pre- 2018 1024-bit RSA p= public- key material collapse to dkim=fail (insufficient key strength) at modern Microsoft / Google / Yahoo receivers, denying each per-percentage Phase 3 ramp exit the DKIM-aligned-pass-rate floor the next advancement requires; the DKIM-DNS-syntax spoke documents the RFC 8301 §3 RSA-2048 floor as the canonical publisher- side publication discipline whose pre-Phase- 3 enforcement is the load-bearing per- percentage Phase 3 ramp-exit-criteria prerequisite; (iii) multi-string TXT chunking discipline per RFC 1035 §3.3.14 as Phase 2 per-selector publication- correctness prerequisite for 2048-bit RSA p= public-key publication — selectors publishing 2048-bit RSA p= public-key material exceeding the 255-octet per-TXT-character- string boundary WITHOUT correct multi-string chunking produce dkim=permerror (key syntax) at every receiver, denying Phase 2 the per-selector baseline-observability evidence every downstream Phase 3 / Phase 4 / Phase 5 gate this rollout sequences depends on; the DKIM-DNS-syntax spoke documents the multi- string chunking discipline as the canonical publisher-side publication discipline whose violation forecloses every downstream phase- gate; (iv) STRICT prohibition of stale t=y testing-flag past the 24-72h burn-in window as Phase 1 → Phase 2 burn-in-cleanup gate prerequisite — selectors with the t=y testing flag still published after the burn-in window cause every receiver to SILENTLY treat per-row dkim=pass verdicts as none for DMARC- alignment evaluation purposes per RFC 6376 §3.6.1, producing the DECEPTIVELY-SILENT Phase 2 baseline-observability defect where the aggregate-report auth_results/dkim/ result=pass elements appear valid in the XML but the downstream policy_evaluated/dkim=fail alignment evaluations dominate the per- receiver per-row distribution — denying Phase 3 the DKIM-aligned-pass-rate floor evidence; the DKIM-DNS-syntax spoke documents the t=y burn-in cap as the canonical publisher-side authoring discipline whose pre-Phase-2 cleanup is the load-bearing Phase 1 → Phase 2 burn-in-cleanup gate prerequisite. Read THIS DMARC policy-rollout reference WITH the DKIM-DNS-syntax spoke when the per-selector DKIM-TXT-record authoring step arrives at the publisher's queue ahead of each phase exit: the rollout page documents the PER-PHASE EXIT-CRITERIA SCHEDULE, the DKIM-DNS-syntax spoke documents the PER-TAG PUBLISHER-SIDE TXT-RECORD AUTHORING discipline every per-phase exit- criteria gate structurally depends on.
• DKIM-Signature header anatomy — the PER-MESSAGE-SIGNED-HEADER BYTE-SHAPE COMPANION documenting the RFC 6376 §3.5 DKIM-Signature header anatomy whose tag- by-tag correctness is a LOAD-BEARING Phase 2 / Phase 3 rollout prerequisite BEFORE the policy ramp documented on THIS page can safely advance to p=quarantine or p=reject. Where THIS page documents the FIVE-PHASE rollout journey (Phase 1 publish p=none + rua=, Phase 2 fix custom-domain DKIM + ESP DKIM-signing cohabitation, Phase 3 inventory closure + SPF-cascade-overflow remediation, Phase 4 ramp p=quarantine + pct=10 → pct=100, Phase 5 advance to p=reject + post- reject monitoring), the DKIM-Signatures- explained spoke documents the FOUR PER- MESSAGE TAG-AUTHORING DIMENSIONS the DKIM-signing infrastructure published in Phase 2 must produce on every outbound message before the policy ramp can consume DKIM-aligned verdicts as the primary alignment authority: (i) v= / a= / b= / bh= cryptographic envelope — the version, algorithm, signature, and body-hash tags whose per-message correctness determines whether the receiver's verification engine produces a dkim=pass vs dkim=fail verdict in Authentication-Results, with the per-tag receiver-side rejection conditions operators must understand before assuming a DKIM-pass row in the RUA stream is cryptographically valid; (ii) d= + i= identifier-binding tags — the d= signing-domain and i= AUID identifier whose per-tag relationship to the visible From: header determines whether the DKIM verdict ALIGNS under the DMARC alignment computation, which is precisely what Phase 3 inventory closure aims to validate is correct before the operator advances the policy ramp; (iii) s= selector-binding tag — the s= selector sublabel whose per-message published value determines which DKIM-key-publication record under <s>._domainkey.<d> the receiver fetches for verification, with operator-side per-ESP selector- rotation discipline materially affecting whether Phase 4's pct=10 → pct=100 ramp observes the expected DKIM-aligned-row percentage; (iv) h= signed-header + l= body-length + c= canonicalization tags — the per-message envelope- scope tags whose per-tag correctness determines whether forwarder-induced header reordering, body-modification, or canonicalization-mismatch breaks the DKIM verdict in transit, which is the single most common Phase 5 post-reject false-positive root cause the operator traces back to a per-tag mismatch in the DKIM-Signature header. Read the DKIM- Signatures-explained spoke during Phase 2 / Phase 3 of the rollout BEFORE advancing past p=none: the per-tag byte-shape reference is what the operator's inventory-closure pass validates is correct on every outbound sender, and which Phase 4-5 ramp decisions consume as the empirical evidence the DKIM-aligned-row trend in the RUA stream is materially sound.
• DKIM best practices — key-cryptography & signing-hygiene discipline that determines whether your DMARC rollout survives p=reject — the operator-facing best-practices reference for the DKIM deployment-and-maintenance discipline the DMARC rollout documented on THIS page structurally depends on. Where the DMARC rollout is the TIME-AXIS migration from p=none through p=quarantine to p=reject with the relaxed-to-strict alignment migration, the DKIM best-practices spoke is the STANDING-DISCIPLINE reference that determines whether your DKIM-pass rate stays at the operationally-critical 99%+ floor the rollout requires to safely publish p=reject: the RSA-2048-minimum key-size discipline (after the 2024 Gmail / Yahoo RSA-1024 deprecation), the 6-month selector-rotation cadence with overlap-window dual-signing (the single most common rollout-blocking failure is a botched key-rotation that breaks DKIM-pass during the rollout window), the explicit avoidance of the l= body-length tag that defeats body-hash-ceiling attacks, the relaxed/relaxed canonicalization choice for forwarder-survivability, the per-provider key-inventory discipline ensuring every SaaS sender + ESP + MTA in your sender inventory has its own documented DKIM keypair under the d=<org-domain> umbrella, and the breach-response key-revocation protocol for the post-p=reject world where a compromised DKIM key becomes an immediate operational incident (private-key impersonation lets an attacker publish DMARC-aligned spoof traffic that bypasses your enforce policy). Read this BEFORE you advance past Phase 2 — alignment failures attributable to DKIM hygiene are the most-cited reason rollouts stall at p=quarantine rather than progressing to p=reject.
• BIMI explained — Brand Indicators for Message Identification. BIMI requires DMARC at p=quarantine or p=reject, so the rollout is the prerequisite for BIMI deployment.
• BIMI Verified Mark Certificates (VMC and CMC) — the POLICY-ROLLOUT-GATE-FOR-VMC- PROCUREMENT companion reference. Where THIS page documents the rollout PHASES (Phase 0 monitor / Phase 1 p=quarantine pct=10/25/50/100 progressive ramp / Phase 2 p=reject final lock / sp= + np= tag coverage for unused subdomains) operators must walk through to reach steady-state DMARC enforcement, the BIMI-VMC-certificates spoke documents the DOWNSTREAM-INVESTMENT-DECISION-GATE that determines whether the operator's rollout progression IS or IS NOT worth pairing with the $1,500-$3,000-per-year VMC spend: VMC issuance from DigiCert or Entrust will REJECT the application before validation if the DNS-published DMARC record is at p=none or p=quarantine pct<100 — Phase 1 mid-ramp (pct=25 / pct=50) is an explicit fail-the-CA-pre-check state — and will REVOKE the issued cert if the operator subsequently relaxes the DMARC enforcement record back below the BIMI-display threshold. The implication: the operator's rollout calendar this page documents is the single GATING prerequisite calendar for VMC procurement, and the rollout's Phase 1 completion checkpoint (every legitimate mail-stream consistently aligning at p=quarantine pct=100 for 14+ consecutive days) IS the VMC-application-can-begin checkpoint. Read the BIMI-VMC-certificates spoke alongside this page when scoping a BIMI rollout — the certificate-procurement calendar (3-6 weeks CA validation + annual renewal cycle + revocation risk on policy-relaxation) MUST be planned backwards from the rollout-phase completion calendar this page documents.
• BIMI SVG Tiny PS logo requirements — the POLICY-ROLLOUT-PHASE-1-COMPLETION- AS-PARALLEL-PREREQUISITE-FOR-SVG-ASSET- AUTHORING-AND-PUBLICATION-DISCIPLINE companion reference. Where THIS page documents the canonical DMARC policy- rollout calendar (Phase 0 monitor / Phase 1 p=quarantine pct=10/25/50/100 ramp / Phase 2 p=reject pct=10/25/50/100 ramp / Phase 3 p=reject pct=100 steady-state with sp= + np= subdomain coverage), the BIMI-SVG-Tiny-PS spoke documents the STRUCTURALLY-PARALLEL publisher-side SVG-asset-authoring-and-publication discipline that runs alongside the DMARC policy-rollout calendar, across four cross-prerequisite deployment-calendar dimensions: (i) the Phase 1 completion checkpoint (every legitimate mail-stream consistently aligning at p=quarantine pct=100 for 14+ consecutive days) is the VMC-application-can-begin checkpoint (per the BIMI-VMC sibling-entry above), and the parallel publisher-side asset- authoring track this BIMI-SVG-Tiny-PS spoke documents (commissioning a designer to produce a BIMI Working Group-conformant SVG-Tiny-PS variant of the brand logo, running the asset through the BIMI Group SVG validator, hosting the asset behind a stable publisher-controlled HTTPS endpoint) MUST be sequenced to complete BEFORE the VMC application step, (ii) the Phase 2 p=reject transition is the BIMI-display-eligibility window opens checkpoint at the MUA layer — operators in p=reject pct=100 steady-state with a procured VMC and a validator-conformant SVG-Tiny-PS asset and a stable HTTPS publication endpoint SATISFY the four-cornered display- eligibility prerequisite that Gmail / Apple Mail / Yahoo / Fastmail / Outlook BIMI evaluators require, (iii) SVG-asset rotation discipline (corporate rebrand, logo refresh, regulatory mark update) interacts with the DMARC policy- record stability discipline this page documents — an SVG-asset rotation requires a new VMC issuance which requires DMARC enforcement to be MAINTAINED at the p=quarantine pct=100 or p=reject level the original VMC was issued under, and (iv) per- subdomain BIMI publication (_bimi.<subdomain> records for distinct sub-brand deployments) interacts with the sp= subdomain-policy tag coverage discipline this page documents in the Phase 3 steady-state — each per-subdomain BIMI-display ramp requires its OWN parallel SVG-asset authoring + VMC procurement + DMARC subdomain- enforcement track. Read the BIMI-SVG- Tiny-PS spoke alongside this DMARC policy-rollout reference when planning a BIMI rollout — the publisher-side SVG-asset authoring-and-publication calendar the BIMI-SVG-Tiny-PS spoke documents MUST be sequenced in parallel to the DMARC policy-rollout calendar THIS page documents, with both prerequisite tracks converging at the VMC-application-can-begin checkpoint and the BIMI-display-eligibility- window-opens checkpoint.
• MTA-STS explained — SMTP MTA Strict Transport Security (RFC 8461). Companion transport-security deployment, often shipped alongside the final DMARC reject phase.
• MTA-STS vs DANE for SMTP — the DMARC-POLICY-ROLLOUT-PARALLEL- TRANSPORT-LAYER-DECISION-TREE-AS- ENFORCEMENT-RAMP-COMPANION-PHASE companion to this DMARC policy-rollout deep-dive reference. Where THIS page documents the canonical four-phase DMARC p= rollout (Phase 1 p=none observation, Phase 2 p=quarantine pct=10/25/50/100 ramp, Phase 3 p=reject pct=10/25/50/100 ramp, Phase 4 p=reject pct=100 steady-state with sp/np-tag publication) as the APPLICATION-LAYER MESSAGE- IDENTIFIER-AUTHENTICATION-POLICY rollout, and the adjacent MTA-STS-explained spoke documents the transport-layer companion rollout that ships alongside the final DMARC-reject phase, the MTA-STS-vs-DANE spoke is the OPERATOR-DECISION-TREE companion documenting the head-to-head DNSSEC-anchored-DANE vs HTTPS-PKI- anchored-MTA-STS transport-security choice whose answer determines WHICH transport-layer enforcement technology (or both) runs in parallel to the DMARC ramp this page documents. Four DMARC- ROLLOUT-VS-TRANSPORT-DECISION-DIMENSION cross-correlation axes the spoke documents: (i) DNSSEC-readiness determines the parallel-transport-track technology choice — operators whose domain zones are ALREADY DNSSEC- signed can deploy DANE in parallel to the DMARC ramp with minimal additional infrastructure; operators whose zones are NOT DNSSEC-signed face a choice between deferring DANE to a separate future deployment project vs adopting MTA-STS (no DNSSEC dependency) as the parallel-transport-track companion to the DMARC ramp — the spoke documents the per-domain DNSSEC-readiness assessment that determines which transport-layer technology can plausibly ship on the same operator-side deployment calendar as the DMARC rollout; (ii) per-phase evidence-stream complementarity — the spoke documents the canonical Week 0 baseline-parallel-deployment pattern where MTA-STS-testing / DANE-publishing runs alongside DMARC- none-observation, with TLS-RPT JSON aggregates feeding the transport-layer evidence stream and DMARC RUA XML aggregates feeding the application- layer evidence stream — the two streams triangulate operationally during the rollout's observation phases; (iii) per-phase failure-mode attribution under parallel deployment — when the DMARC ramp's Phase 3 advance produces unexplained deliverability degradation, the MTA-STS-vs-DANE spoke documents the attribution methodology that distinguishes application-layer DMARC- misalignment failure modes from transport-layer MTA-STS-policy- misauthored OR DANE-TLSA-rotation- timing failure modes — critical operator knowledge during the parallel-rollout's most enforcement- sensitive phases; (iv) per-phase enforcement-flip-timing coordination — the spoke documents the canonical operator-decision-tree for whether the transport-layer flip (MTA-STS mode:enforce OR DANE-active publication) precedes, follows, or coincides with the DMARC p=reject flip — different operators choose different sequencing patterns based on their deliverability- risk-appetite and the spoke catalogues each pattern's operational trade-offs. Pair this DMARC-policy-rollout reference (the application-layer ramp playbook) with the MTA-STS-vs-DANE spoke (the transport-layer technology-choice decision-tree) when authoring the per-domain full-stack rollout calendar — the spoke is the canonical decision- reference whose answer determines the parallel-transport-track technology that runs alongside the DMARC ramp documented on this page.
• MTA-STS for Google Workspace — the WORKSPACE-TENANT-MTA-STS-DEPLOYMENT- AS-TRANSPORT-LAYER-COMPANION-ROLLOUT-PHASE- RUNNING-IN-PARALLEL-TO-THE-DMARC-POLICY- RAMP companion to this DMARC policy-rollout reference. Where THIS page documents the canonical four-phase DMARC p= rollout (the p=none baseline + monitoring phase, the p=quarantine pct=10/25/50/100 ramp, the p=reject pct=10/25/50/100 ramp, the p=reject pct=100 steady-state with sp/np-tag publication for subdomain coverage) — i.e. the APPLICATION- LAYER MESSAGE-IDENTIFIER-AUTHENTICATION- POLICY rollout side of the operator-side deployment calendar — the MTA-STS-for- Google-Workspace spoke is the WORKSPACE- TENANT-SPECIFIC TRANSPORT-LAYER ROLLOUT COMPANION documenting the parallel-phased MTA-STS deployment that operators on Workspace-hosted domains run alongside the DMARC ramp this page documents: (i) the MTA-STS mode:testing baseline phase is the transport-layer analog of DMARC's p=none baseline phase — both publish the policy without enforcement, both collect receiver-side feedback (TLS-RPT JSON aggregates for MTA-STS-testing, RUA aggregate reports for DMARC-none), both let the operator validate the deployment surface before flipping to enforcement; operators on Workspace commonly ship MTA-STS-testing in parallel with DMARC-none so the two evidence streams converge during the same observation window; (ii) the MTA-STS mode:enforce flip is the transport-layer analog of the DMARC p=reject flip — both transition from observation-only to enforcement-with-real-consequences, both require receiver-side cooperation, both produce deliverability cliffs if misconfigured; operators on Workspace commonly time the MTA-STS-enforce flip AFTER the DMARC-reject flip (sequential rollout) or alongside it (parallel rollout) — both patterns are operationally defensible and the Workspace spoke documents the operator- choice trade-offs; (iii) the Workspace-tenant MTA-STS publication at https://mta-sts.<workspace-domain> /.well-known/mta-sts.txt with mx: aspmx.l.google.com + mx: alt1.aspmx.l.google.com + ... runs the same max_age: cache-validity-bound publication discipline as the DMARC ri= reporting-interval discipline this page documents — both publications bound the receiver-side cache horizon within which a misconfiguration produces observable damage, both require operator discipline to rotate / extend / shrink within the operationally-safe window; (iv) the Workspace MTA-STS rollout's failure modes are reported in TLS-RPT JSON aggregates while the DMARC rollout's failure modes are reported in RUA aggregate reports — operationally complementary forensic evidence streams for the same Workspace- tenant mail-stream during the rollout period; an operator reconciling TLS-RPT certificate-host- mismatch events against per-message DMARC-fail RUA records during the same week can triangulate whether deliverability degradation traces to transport-layer mis-publication (MTA-STS-side) or application-layer mis-publication (DMARC-side). Read the MTA-STS-for-Google-Workspace spoke alongside this DMARC policy-rollout reference when planning a Workspace- hosted domain's full email-security deployment calendar — the Workspace- tenant-specific MTA-STS publication topology the spoke documents is the load-bearing transport-layer-rollout companion to the DMARC p= ramp this page documents, and the two phases benefit from coordinated deployment scheduling on the same observation calendar.
• TLS-RPT explained — SMTP TLS Reporting (RFC 8460).
• TLS-RPT report format (RFC 8460 §4 JSON schema) — the POLICY-ROLLOUT-RAMP-GATE-TLS- RPT-AGGREGATE-EVIDENCE-PER-PHASE- PARALLEL-OBSERVABILITY-FEED companion to this DMARC-policy-rollout phased- deployment reference. Where THIS page documents the four-phase DMARC policy- ramp (Phase 1 p=none observation; Phase 2 p=quarantine pct=N stepped ramp from 1% through 100%; Phase 3 p=reject pct=N stepped ramp; Phase 4 p=reject steady-state) AND the rollout-playbook documents the PARALLEL MTA-STS mode: testing → mode:enforce transport-layer ramp that runs alongside the DMARC application- layer ramp, the TLS-RPT-report- format spoke documents the PER-PHASE TRANSPORT-LAYER OBSERVABILITY- EVIDENCE PAYLOAD byte-schema the rollout-playbook's MTA-STS-ramp- phase-gates consume. FOUR structurally-distinct POLICY- ROLLOUT-PHASE-VS-TLS-RPT-JSON-RAMP- GATE-EVIDENCE operational classes the spoke enumerates that THIS DMARC-application-layer-ramp reference cross-references but does not byte-schema enumerate: (i) MTA-STS mode:testing observation-phase ramp-gate evidence from per-receiver per-day policies[].policy.policy-mode = testing JSON rows — the per-receiver per-day record of the MTA-STS policy mode that was evaluated at the receiving MTA, which the operator audits to confirm receivers are pulling the published mode:testing policy file before advancing to mode:enforce; (ii) per-receiver per-day STARTTLS- success-rate ramp-gate evidence from summary.total-successful-session- count / total-session-count ratio — the per-receiver per- day transport-encryption-success rate that the rollout-playbook's MTA-STS- ramp phase-gates use as the empirical condition for advancing from mode:testing to mode:enforce (analogous to the application-layer DMARC- aligned-pass-rate phase-gate this page documents at the p=none → p=quarantine ramp- boundary); (iii) per-receiver per-day failure-class-attribution ramp-gate evidence from failure-details[].result-type enumeration breakdown — the per-class transport-failure attribution (starttls-not-supported, certificate- host-mismatch, certificate-not-trusted, validation-failure, tls-error, dane- invalid) that the rollout-playbook's per-phase observation-window retrospective consumes to determine whether any specific receiver-class is producing systematic failures that must be remediated before advancing the MTA-STS ramp; (iv) cross- protocol pipeline-reuse parallels the DMARC-RUA ingestion stack for TLS-RPT JSON payloads — the operator's seven-stage DMARC-RUA pipeline (Stage 1 IMAP / Microsoft Graph ingestion; Stage 2 format- detection-and-extraction; Stage 3 RUA XML parsing OR TLS-RPT JSON parsing; Stage 4 normalisation; Stage 5 deduplication; Stage 6 analysis-and- join-against-failure-catalogues; Stage 7 alerting) reuses Stages 1-4 + 6-7 identically for TLS-RPT JSON payloads, so the rollout-playbook's per-phase observation-and-analysis discipline operates on a UNIFIED feed of application-layer DMARC RUA evidence (this page) AND transport-layer TLS-RPT JSON evidence (the TLS-RPT- report-format spoke) without architectural change. Read the TLS-RPT-report-format spoke alongside this DMARC-policy-rollout reference when constructing the cross-protocol rollout calendar whose per-phase observation-window evidence consumes application-layer DMARC-aligned-pass- rate KPIs (this page) AND transport- layer STARTTLS-success-rate KPIs (the TLS-RPT-report-format spoke) as twin ramp-gate-evidence sources the operator's phase-advancement decision depends on.
• CAA records explained — Certification Authority Authorization (RFC 8659).
• DMARC monitoring — the PER-PHASE-GATING-KPI-AND-DRIFT-DETECTION-COMPANION spoke to this DMARC-policy-rollout phased-deployment reference. Where THIS page documents the FOUR-PHASE rollout sequence and per-phase observation calendar (Phase 1: p=none baseline establishment with rua= aggregate-report collection over a 30-day observation window; Phase 2: p=quarantine with pct=10 partial- enforcement ramp and per-cohort alignment-pass-rate plateau-stability observation; Phase 3: p=quarantine with pct=100 full-quarantine- enforcement and per-third-party-sender alignment-gap-closure verification; Phase 4: p=reject with full-reject- enforcement and steady-state monitoring), the DMARC-monitoring deployment spoke documents the CONTINUOUS-OBSERVABILITY INFRASTRUCTURE an operator deploys ALONGSIDE the rollout sequence to produce the EMPIRICAL EVIDENCE each phase-gate requires. The monitoring spoke documents the per-phase KPI thresholds that gate phase-advancement (e.g. DKIM-aligned-pass-rate ≥ 98% sustained over 7 rolling days as the typical Phase- 3 → 4 threshold, SPF-aligned-pass-rate ≥ 95% as the typical Phase-2 → 3 threshold, zero-unattributed-source_ip-spikes-over- 14-days as the typical Phase-1 → 2 cohort-inventory completeness criterion), the per-third-party-sender attribution- and-remediation workflow for closing per-cohort alignment gaps surfaced during the per-phase observation window, and the per-source_ip-anomaly-detection rules that distinguish legitimate third-party-sender alignment-drift from external-attacker-bypass-attempt spikes during the rollout. The monitoring spoke documents the per-phase ALERT-ROUTING rules that fire when a previously- cleared per-cohort alignment-pass-rate regresses during a later rollout phase (a DKIM-selector-rotation-misconfiguration regression that breaks alignment for a previously-aligned ESP cohort, an envelope-MAIL-FROM-rewriter-onboarding that breaks SPF-alignment at an intermediate-forwarder boundary, a new-third-party-ESP-onboarding-without- DKIM-aligned-publication regression), and the per-phase ROLLBACK-PLAYBOOK an operator runs when a phase-advancement produces an unexpected per-cohort deliverability cliff. Read the monitoring spoke alongside this page when designing the observability infrastructure that supports the per-phase rollout sequence documented here — the rollout-phase sequence described here is the OPERATIONAL DECISION POINT the monitoring spoke produces the EMPIRICAL INPUT for, and the monitoring spoke is the canonical reference for WHICH per-phase KPIs gate which phase-advancement decisions, WHICH per-cohort regression signals fire which alert-routing rules, and WHICH per-phase rollback playbooks the operator runs when an advancement misfires.
• SPF forwarding issues — the DMARC-POLICY-RAMP-LOAD-BEARING- FORWARDING-BREAK-OBSERVABILITY-CONSUMER companion reference. Where THIS page documents the DMARC policy-mode ramp sequence (Phase 1 p=none monitoring → Phase 2 p=quarantine pct=10..100 → Phase 3 p=reject pct=10..100) and the per-phase KPI gates, per-cohort regression signals, alert-routing rules, and rollback playbooks the operator runs, the spf_forwarding_issues spoke is the SPF-FORWARDING-BREAK CATALOGUE canonical reference documenting the RFC 7208 §10.4 forwarding-failure mechanism + per-forwarder-population per-recipient SPF-fail-rate distribution (vacation auto-forwarders at Gmail/Outlook/Apple; recipient-side mailbox-rule forwarders; mailing-list intermediaries Mailman/Sympa/Discourse; per-customer enterprise forwarding appliances Mimecast/Proofpoint; SRS- vs-non-SRS intermediary class boundary) every DMARC-ramp phase-advancement decision structurally consumes. FOUR structurally-distinct DMARC-POLICY- RAMP-FORWARDING-BREAK dimensions the forwarding-issues spoke defines that this DMARC-policy-rollout page structurally consumes: (i) per- forwarder per-recipient SPF-fail-rate AS THE RAMP-PROGRESSION GATE between Phase 1 p=none and Phase 2 p=quarantine — the spf_forwarding_issues spoke documents the per-receiver per- forwarder SPF-fail rate as the operator-side gating signal that DKIM-aligned-pass-on-forwarded-path baseline has been established BEFORE the p=quarantine Phase 2 publication — without the DKIM half of the DMARC disjunction carrying the per-receiver alignment-pass load on forwarded mail, p=quarantine publication routes legitimate forwarded mail to the recipient's spam folder at cohort-level rates the spf_forwarding_issues spoke quantifies (>10% per-forwarder SPF-fail-rate at Gmail/Outlook vacation auto-forwarders is common); Phase 1 → Phase 2 advancement REQUIRES the per- forwarder per-recipient DKIM-aligned- pass-rate-on-forwarded-path baseline the forwarding-issues spoke documents; (ii) per-forwarder per-recipient SPF-fail-rate AS THE PHASE-2-RAMP pct=10..100 progression gate — the spf_forwarding_issues spoke documents the per-receiver per- forwarder SPF-fail-rate at pct=10 baseline as the canonical observability signal that gates the pct= ramp progression (10 → 25 → 50 → 100); the DMARC-policy-rollout operator increments pct= only after per- forwarder per-recipient SPF-fail-rate with co-occurring DKIM-aligned-pass- rate-on-forwarded-path baseline has stabilised below an operator-defined threshold for the prior pct= cohort population; (iii) per- forwarder per-recipient SPF-fail-rate AS THE LATE-RAMP p=reject deliverability-risk reconciliation signal — the spf_forwarding_issues spoke documents the legitimate forwarded-mail population at p=reject publication; when the per-forwarder per-recipient SPF-fail-rate AND DKIM- unaligned-fail-rate co-occur (the DKIM half also breaks on forwarding because the forwarder body-modifies the message — mailing-list footer insertion / Subject prefix mutation / header rewriting), the p=reject publication IMMEDIATELY routes the legitimate forwarded mail to the receiver's reject-disposition the spf_forwarding_issues spoke characterises by forwarder-population class; the operator's Phase 3 ramp- risk assessment depends on this baseline; (iv) per-forwarder per-recipient SPF-fail-rate AS THE ROLLBACK-TRIGGER threshold for the per-phase rollback playbook — the spf_forwarding_issues spoke documents the per-receiver per- forwarder SPF-fail-rate-with-DKIM- also-fail co-occurrence rate (forwarder body-modifies + breaks DKIM body-hash AND envelope-MAIL- FROM is not SRS-rewritten so SPF- check fails); this co-occurrence rate is the canonical rollback- trigger threshold for the per-phase rollback playbook THIS page documents — when the co-occurrence rate spikes above the operator-defined rollback threshold during a ramp-advancement window, the operator rolls back the ramp to the prior phase (Phase 2 pct=N back to Phase 2 pct=N/2; Phase 3 pct=N back to Phase 2 pct=100) per the rollback playbook the policy-rollout page documents at the operator-side decision level. Read the spf_forwarding_issues spoke alongside this DMARC-policy-rollout page when authoring the per-phase ramp- progression KPI definitions — the forwarding-break catalogue is the load-bearing per-forwarder per- receiver SPF-fail-rate baseline reference every DMARC-ramp advancement decision THIS page documents structurally consumes for legitimate-forwarded-mail-population deliverability-risk framing.
• SPF qualifiers explained — the STAGED-ROLLOUT-PAIRED-PROGRESSION companion reference documenting the SPF-qualifier ramp that operationally PAIRS with the DMARC policy-mode ramp this page documents. Where THIS page documents the per-phase DMARC policy- mode advancement sequence (Phase 1 p=none monitoring / Phase 2 p=quarantine pct=10 sampling / Phase 3 p=quarantine pct=50 / Phase 4 p=quarantine pct=100 / Phase 5 p=reject pct=10 / Phase 6 p=reject pct=50 / Phase 7 p=reject pct=100), the SPF-qualifiers spoke documents the STRUCTURALLY-PARALLEL SPF-qualifier ramp the operator SHOULD execute in OPERATIONAL LOCKSTEP with the DMARC policy-mode ramp documented here. The per-phase pairing is: Phase 1-2 DMARC-monitoring is the SAFE PHASE to run with SPF ~all SoftFail because the operator is still discovering the latent authorised-sender inventory and a misconfigured -all Fail could inadvertently reject legitimate mail from a forgotten-but-legitimate sender that the DMARC aggregate reports have not yet surfaced; Phase 3-4 DMARC-partial-quarantine is the ENRICHMENT PHASE where the operator has completed the per-cohort authorised-sender inventory via the DMARC aggregate report stream and can TIGHTEN SPF to -all Fail IF the aggregate-report-derived sender-inventory has stabilised (sender-inventory-stability is the per-phase gate for the SPF tightening, not the DMARC-policy-mode advancement); Phase 5-7 DMARC-full- reject SHOULD ALWAYS be paired with SPF -all Fail because a publisher running p=reject DMARC AND ~all SPF SoftFail is OPERATIONALLY INCONSISTENT — the DMARC stance asserts "reject unauthenticated messages" while the SPF stance simultaneously asserts "merely soft-fail the same unauthenticated messages" (the receiver-side enforcement is dominated by the strictest publisher assertion, but the publisher-side intent ambiguity is itself a deployment- defect signal). The qualifier spoke also documents the THIRD ROLLOUT- PAIRED ARTEFACT operators sometimes miss: the ?all Neutral qualifier as an OBSERVABILITY-ONLY intermediate between ~all SoftFail and -all Fail that some operators use during the initial Phase 1 sender-inventory- discovery period to receive maximum SPF observability signal without triggering ANY receiver-side enforcement (the receiver-side equivalent of "log everything, enforce nothing"). Read the qualifier spoke alongside this page when authoring the SPF SECTION of the per-phase rollout playbook — the DMARC-policy-mode advancement sequence is the LOAD-BEARING NARRATIVE this page documents, but the SPF- qualifier ramp is the OPERATIONALLY- PAIRED narrative that runs in lockstep with it and gates the same per-phase deliverability- regression risk.
• DMARC for SaaS senders — the per-publisher SaaS-sender- inventory-as-load-bearing-rollout- stage-gate-criterion companion to this DMARC policy-rollout reference. Where THIS page documents the per-publisher p=none → p=quarantine → p=reject ramp + per-publisher pct= percentage-ramp cadence as the operator-side scheduling-discipline applied to the DMARC TXT record over the 6-12 week rollout window, the SaaS-senders spoke documents the per-publisher per-SaaS- sender-onboarding inventory whose completeness is the LOAD-BEARING rollout-stage-gate criterion every per- stage advancement consumes: (i) per-publisher Phase 1 (SPF + DKIM publication gate) — BEFORE the per-publisher _dmarc publication at p=none, every per-SaaS- sender used by the per-publisher must be enrolled in the per-customer-CNAME- delegated DKIM-signing onboarding workflow at the per-SaaS-platform, AND every per-SaaS-platform per-customer include: token must be in the per-publisher SPF cascade under the RFC 7208 §4.6.4 10-DNS-lookup cap; (ii) per-publisher Phase 2 (p=none baseline observability gate) — the per-publisher rua- aggregate-XML evidence must catalogue EVERY per-SaaS-sender's per-customer- signed mail producing dkim=pass + dkim-aligned=true BEFORE any per-publisher p=quarantine advancement — the SaaS-senders spoke documents the per-SaaS-sender per-customer DKIM- alignment-onboarding workflow this Phase-2-gate-criterion consumes; (iii) per-publisher Phase 3 (p=quarantine pct=ramp gate) — the per-publisher pct= percentage-ramp from 1% → 10% → 25% → 50% → 100% gates the deliverability-regression risk of ANY per-SaaS-sender misalignment, so the per-publisher per-SaaS-sender inventory completeness the SaaS-senders spoke catalogues is the load-bearing per-stage-gate- criterion at every per-publisher pct-ramp checkpoint; (iv) per-publisher Phase 5 (p=reject pct=100 terminal-state closure gate) — the per-publisher terminal-state p=reject; pct=100 publication REQUIRES every per-SaaS- sender per-customer-signed mail to produce DKIM-aligned-pass OR per- publisher SPF-aligned-pass — the per- publisher per-SaaS-sender inventory completeness the SaaS-senders spoke catalogues is the LOAD-BEARING terminal-state precondition this rollout-cadence contract closes against. Read the SaaS-senders spoke alongside this rollout-cadence reference at every per-publisher per- stage-gate checkpoint — the per- publisher per-SaaS-sender inventory the SaaS-senders spoke catalogues is the load-bearing per-stage-advancement gate criterion the rollout-cadence contract THIS page documents consumes.
• DMARC forensic / failure reports — the per-publisher per-stage AFRF forensic-evidence as granular per- message feedback complement to rua- aggregate per-row feedback companion to this DMARC policy-rollout reference. Where THIS page documents the per-publisher p=none → p=quarantine → p=reject ramp + per-publisher pct= percentage-ramp cadence as the operator-side scheduling-discipline that consumes per-receiver rua-aggregate-XML evidence as the per-stage GO/NO-GO gate-keeping signal, the forensic- reports spoke documents the structurally-distinct PER-MESSAGE AFRF (Abuse Feedback Report Format, RFC 6591) forensic-evidence-capture publication-discipline whose per- message granular per-row reproduction is the load-bearing per-stage diagnostic complement to the rua aggregate per- row evidence-stream this rollout- cadence reference consumes. Four PER-ROLLOUT-STAGE-VS-AFRF-FORENSIC- EVIDENCE coupling dimensions the forensic-reports spoke documents that THIS page's per-stage gate-keeping algorithm consumes: (i) per- publisher Phase 2 (p=none baseline- observability gate) AFRF-as-per- message-diagnostic-complement — when per-publisher Phase 2 rua- aggregate-XML evidence shows anomalous per-source-IP DMARC-fail clustering the rollout-cadence reference's per-stage gate-keeping algorithm cannot resolve from per- row aggregate counts alone, the per- publisher ruf=mailto:<mailbox> + fo=1 AFRF capture is the canonical per-message diagnostic primitive resolving the per-source-IP per-message reproduction; (ii) per-publisher Phase 3 (p=quarantine pct=ramp gate) AFRF- as-per-message-misalignment-attribution evidence — when per- publisher Phase 3 per-pct-checkpoint rua-aggregate-XML evidence shows unexpected DMARC-aligned-fail rate spikes the rollout-cadence reference's gate-keeping algorithm flags as ramp- regression, the per-publisher AFRF stream gives per-message auth_results + identifiers + delivery_result per-message attribution distinguishing per-mailing-list-forwarder / per-account-forwarding-rewrite / per-SRS-rewriter / per-ESP-replay per-message root-cause classes; (iii) per-publisher Phase 4 (p=reject pct=ramp gate) AFRF-as- per-message-spoofing-detection evidence — when per- publisher Phase 4 rua-aggregate-XML evidence shows per-source-IP DMARC-fail clustering at unknown- source-IP-topologies, the per- publisher AFRF stream is the load- bearing per-message spoofing- detection evidence the rollout- cadence reference's gate-keeping algorithm consumes for per-stage spoofing-rate-vs-legitimate-mail discrimination; (iv) per- publisher Phase 5 (p=reject pct=100 terminal-state closure gate) AFRF- as-per-message-rejection-attribution evidence — when per- publisher Phase 5 terminal-state rua-aggregate-XML evidence shows per-receiver per-message disposition=reject events the rollout-cadence reference's gate-keeping algorithm flags for legitimate-vs-spoofed attribution, the per-publisher AFRF stream is the per-message evidence pipeline distinguishing per-message legitimate-mail rejection (the rollback-trigger signal) from per-message spoofing- rejection (the terminal-state- validation signal). Read the forensic-reports spoke alongside this rollout-cadence reference at every per-stage gate-keeping checkpoint — the per-publisher AFRF stream is the load-bearing per- message diagnostic complement to the rua aggregate per-row evidence-stream the rollout-cadence reference's per- stage gate-keeping algorithm consumes.
• DMARC for transactional email — the PER-TRANSACTIONAL-ESP-PER- CUSTOMER-STREAM-DMARC-ALIGNED-PASS- RATE-OBSERVABILITY-AS-LOAD-BEARING- PER-STAGE-GATE-KEEPING-INPUT-TO- POLICY-ROLLOUT-CADENCE-ALGORITHM- COMPANION-AT-FOUR-PER-ESP-STREAM-VS- PER-ROLLOUT-STAGE-COORDINATION- DIMENSIONS companion to this DMARC- policy-rollout reference. Where THIS page documents the canonical per- publisher per-domain DMARC policy- rollout cadence algorithm (the per- publisher per-domain p=none → p=quarantine → p=reject policy-stage progression + the per-stage pct=10/25/50/75/100 ramp-enforcement transition + the per-stage rua- aggregate-XML per-source-IP DMARC- aligned-pass-rate observability gate- keeping discipline), the transactional- email spoke is the per-publisher per- transactional-ESP-stream DMARC alignment-coordination discipline reference whose per-ESP-stream per- source-IP DMARC-aligned-pass-rate evidence-stream IS the LOAD-BEARING per-stage observability-input the per-publisher per-domain policy- rollout cadence algorithm THIS page documents consumes at four per-ESP- stream-vs-per-rollout-stage coordination dimensions: (i) per-transactional-ESP-stream DMARC-aligned-pass-rate observability as Phase 2 baseline-observability gate- keeping input — Phase 2 of the rollout-cadence ladder (p=none + rua=mailto: testing-mode + 30-90 day observability-baseline) gate-keeps on per-publisher per-source-IP DMARC- aligned-pass-rate observation; the per-transactional-ESP-stream evidence- stream the transactional-email spoke documents IS the LOAD-BEARING per- ESP-stream cohort of the per-source-IP DMARC-aligned-pass-rate baseline- observability input the Phase 2 gate- keeping algorithm consumes; (ii) per-transactional-ESP-stream per-source-IP DMARC-aligned-pass-rate attribution as Phase 3 pct=-ramp gate- keeping input — Phase 3 of the rollout-cadence ladder (pct=10 → pct=25 → pct=50 → pct=75 → pct=100 ramp-enforcement transition) gate- keeps on per-source-IP per-step DMARC-aligned-pass-rate-regression- detection at the per-pct=-step ramp boundary; the per-transactional- ESP-stream evidence-stream the transactional-email spoke documents IS the LOAD-BEARING per-ESP-stream cohort of the per-source-IP per-step regression-detection input the Phase 3 gate-keeping algorithm consumes — per-publisher per-rollout-team decisions to ADVANCE the per-domain pct= tag or HOLD-AT-CURRENT-STEP / REVERT-TO-PRIOR-STEP gate-keep on the per-ESP-stream DMARC-aligned-pass- rate evidence-stream the transactional- email spoke documents; (iii) per-transactional-ESP-stream per-customer-stream per-message forensic-investigation root-cause- attribution as Phase 3-4-5 ongoing observability-discipline gate-keeping input — Phase 3-4-5 of the rollout-cadence ladder (ongoing rua-stream aggregate-XML observability + ongoing ruf-stream forensic-report per-message evidence-capture + per- source-IP forensic-investigation root-cause-attribution discipline) gate-keep on per-publisher per-source- IP per-message DMARC-fail-class attribution; the per-transactional- ESP-stream per-customer-stream per- message forensic-investigation root- cause-class catalogue the transactional-email spoke documents IS the LOAD-BEARING per-ESP-stream cohort of the per-message forensic- investigation root-cause-attribution input the Phase 3-4-5 ongoing observability-discipline gate-keeping algorithm consumes; (iv) per- transactional-ESP-stream sp=<subdomain-policy>- tag-vs-per-publisher per-domain p=<policy>-tag subdomain-policy-rollout coordination — per-publisher per-domain rollout- cadence transitions encounter per- transactional-ESP-stream subdomain- usage patterns (e.g. m.<tenant-domain> / email.<tenant-domain> / news.<tenant-domain> dedicated transactional subdomains) whose per-subdomain DMARC-aligned- pass-rate-attribution evidence the per-publisher sp=<subdomain-policy>- tag publication-discipline gate-keeps on at the per-publisher per-subdomain policy-rollout cadence boundary — the per-transactional-ESP-stream per- subdomain attribution discipline the transactional-email spoke documents IS the LOAD-BEARING per-subdomain cohort of the sp=<subdomain-policy> rollout-cadence gate-keeping input the per-publisher per-subdomain rollout-cadence algorithm consumes. Read the transactional-email spoke ALONGSIDE this DMARC-policy-rollout reference whenever a per-publisher per-domain rollout-cadence per-stage gate-keeping question intersects per-transactional-ESP-stream observability — THIS page gives the canonical per-publisher per-domain rollout-cadence gate-keeping algorithm, the transactional-email spoke gives the per-publisher per- transactional-ESP-stream alignment- coordination evidence-stream the per-publisher per-domain rollout- cadence gate-keeping algorithm's per- stage observability-input ladder bottoms out on at the per-publisher per-ESP-stream per-source-IP DMARC- aligned-pass-rate-attribution boundary.
• ARC (Authenticated Received Chain) explained — the PER-FORWARDER-HOP-AUTHENTICATION- PRESERVATION-CHAIN-AS-LOAD-BEARING-PER- PUBLISHER-PER-POLICY-ROLLOUT-STAGE-pct=- RAMP-CONFIDENCE-INPUT companion to this DMARC policy-rollout reference. Where THIS page documents the per-publisher per-domain Phase 2 p=none → Phase 3 p=quarantine + pct=1 → pct=5 → pct=10 → pct=25 → pct=50 → pct=100 ramp-cadence gate-keeping algorithm (per-stage rua aggregate-XML DMARC-aligned-pass-rate observability + per-stage forensic- investigation gate-keeping + per-stage per-source-IP attribution discipline + sp=-tag-vs-p=-tag subdomain-policy coordination), the ARC-explained spoke is the canonical RFC 8617 per-forwarder- hop authentication-preservation primitive documenting the ARC-Seal + ARC-Message- Signature + ARC-Authentication-Results per-hop chain mechanism that ITSELF IS the load-bearing per-publisher per-domain per-pct=-stage alignment-survival input the per-publisher per-domain rollout- cadence gate-keeping algorithm consumes at four per-rollout-stage-to-ARC-chain- evidence coupling dimensions: (i) per-publisher per-domain Phase 2 observability-baseline rua aggregate-XML as load-bearing per-forwarder-hop ARC- chain-pass-rate-observability baseline — every per-publisher per-domain Phase 2 rua aggregate-XML stream the policy-rollout gate-keeping algorithm THIS page documents consumes captures per-source-IP per-message DMARC-aligned-pass-rate evidence; the per-publisher per-domain per-forwarder- hop ARC-chain pass-rate (per-hop arc=pass evaluation evidence in rua aggregate-XML auth_results body) IS the load-bearing per-Trusted-ARC-Sealer-list-receiver-side configuration-dependent per-forwarder-hop alignment-survival baseline the ARC- explained spoke documents the per-hop chain-mechanism of; (ii) per- publisher per-domain Phase 3 pct=-ramp- advancement-confidence as load-bearing per-forwarder-hop ARC-trusted-sealer- coverage-rate-driven advancement-input primitive — every per-publisher per-domain Phase 3 per-pct=-stage advancement decision the rollout-cadence gate-keeping algorithm THIS page documents executes consumes per-stage per-forwarder-hop ARC-trusted-sealer- coverage-rate evidence; the per-publisher per-domain per-forwarder-hop ARC-trusted- sealer-coverage-rate (Gmail-as-canonical- ARC-trusted-sealer + per-receiver Exchange Online Trusted-ARC-Sealers list + ProtonMail / Yahoo / O365 per-receiver- side ARC-trusted-sealer configuration) IS the load-bearing per-publisher per- domain per-pct=-stage advancement- confidence input the per-publisher per- domain rollout-cadence gate-keeping algorithm consumes for advancing the per-pct= percentage at each gate-keeping ladder bottom; (iii) per- publisher per-domain Phase 3-4-5 forensic- investigation gate-keeping as load- bearing per-forwarder-hop ARC-Authentication- Results per-hop AAR-evidence-vocabulary primitive — every per-publisher per-domain Phase 3-4-5 forensic- investigation gate-keeping event the rollout-cadence algorithm THIS page documents triggers consumes per-message per-forwarder-hop ARC-Authentication- Results AAR-header evidence-vocabulary (per-hop i= instance-tag + per-hop cv=pass|fail|none chain-validation-result + per-hop d= signing-domain + per-hop s= selector); the per-publisher per-domain per-forwarder-hop AAR-evidence-row vocabulary IS the load-bearing per- message per-hop authentication-result- attribution primitive the per-publisher per-domain forensic-investigation gate- keeping algorithm consumes for per- message per-hop alignment-loss-root- cause-attribution at the rollout-cadence gate-keeping boundary; (iv) per- publisher per-domain sp=-tag-vs-p=-tag- subdomain-policy as load-bearing per- forwarder-hop ARC-chain-evaluation-scope per-subdomain-boundary coordination discipline — every per-publisher per-domain sp=-tag-vs-p=-tag-subdomain- policy decision the rollout-cadence algorithm THIS page documents executes consumes per-forwarder-hop ARC-chain- evaluation-scope per-subdomain-boundary coverage evidence; the per-publisher per-domain per-forwarder-hop ARC-chain- evaluation per-subdomain-boundary coverage discipline IS the load-bearing per-publisher per-domain per-pct=-stage sp=-tag-vs-p=-tag-subdomain-policy coordination input the per-publisher per-domain rollout-cadence gate-keeping algorithm consumes for per-subdomain- boundary per-stage cadence-gate-keeping. Read the ARC-explained spoke ALONGSIDE this DMARC policy-rollout reference whenever a per-publisher per-domain per-pct=-stage advancement-confidence decision the per-publisher per-domain rollout-cadence gate-keeping algorithm executes hinges on per-forwarder-hop ARC-trusted-sealer-coverage-rate or per- forwarder-hop ARC-Authentication-Results AAR-evidence-vocabulary attribution — THIS page gives the per-publisher per-domain per-pct=-stage gate-keeping algorithm, the ARC-explained spoke gives the canonical per-forwarder-hop ARC-chain primitive every per-stage rua aggregate- XML observability baseline + per-pct=- ramp advancement-confidence + per-stage forensic-investigation gate-keeping consumes as the load-bearing per- forwarder-hop authentication-preservation primitive.
• SPF mechanism comparison: include vs ip4 vs a vs mx — the RFC-7208-§5-PER-MECHANISM- EVALUATION-CATALOGUE-AS-LOAD-BEARING- PHASE-1-PUBLICATION-BASELINE- PREREQUISITE companion to this five- phase DMARC-policy-rollout workflow reference. Where THIS page documents the per-publisher five-phase deployment workflow (Phase-1 publication-baseline → Phase-2 p=none observability-baseline → Phase-3 pct=-ramp → Phase-4 p=quarantine cutover → Phase-5 p=reject terminal-state), the include_vs_ip4_vs_a_vs_mx spoke documents the per-RFC-7208-§5- mechanism-choice catalogue at FOUR per-mechanism-choice-vs-DMARC- policy-rollout-coupling dimensions: (i) per-publisher per- mechanism-correct SPF-record AUTHORING AS LOAD-BEARING Phase-1 publication-baseline PREREQUISITE — Phase-1 of the rollout publishes the canonical per-publisher authentication-record-set (SPF + DKIM + DMARC TXT records); the include_vs_ip4_vs_a_vs_mx spoke documents the per-RFC-7208-§5- mechanism-choice catalogue whose per-mechanism-correct authoring IS the load-bearing Phase-1 SPF- record-publication prerequisite every downstream per-pct=-ramp gate THIS page architects depends on; (ii) per-publisher per-mechanism-driven per-source- IP SPF-ALIGNED-PASS RATE FLOOR AS LOAD-BEARING Phase-3 pct=- ramp-advancement gate-keeping INPUT — every per-pct=- ramp-stage advancement consumes the publisher's per-source-IP SPF-aligned-pass-rate floor; the include_vs_ip4_vs_a_vs_mx spoke documents the per-mechanism evaluation semantics whose per- mechanism choice determines the per-source-IP SPF-aligned-pass- rate observed at receivers and emitted in rua aggregate-XML; per- mechanism mis-authoring at Phase- 1 (e.g., over-restrictive ip4: CIDR omitting legitimate egress IPs, missing include: token for a stacked ESP, deprecated ptr: mechanism per RFC 7208 §5.5) directly degrades the per-pct=-ramp-advancement SPF-aligned-pass-rate floor THIS page documents as the canonical gate-keeping input; (iii) per-publisher per- mechanism RFC-7208-§4.6.4-TEN- DNS-LOOKUP-CEILING-OVERFLOW AS LOAD-BEARING Phase-2-to-Phase-3 p=none-to-pct=-ramp blocker — per-publisher per-mechanism cascading (multiple include: tokens for stacked ESPs + per-egress a:/mx: mechanisms) routinely overflows the RFC 7208 §4.6.4 ten-DNS- lookup-ceiling producing spf=permerror verdicts at receivers; the include_vs_ip4_vs_a_vs_mx spoke documents the per-mechanism- cutover remediation disciplines (flattening include: tokens to ip4: literals, per-stream envelope- domain isolation, per-ESP subdomain delegation) every Phase-2-to-Phase-3 rollout stage operator applies before advancing the pct=-ramp; (iv) per-publisher per- mechanism per-AFRF-row RUF forensic-evidence DECODE AS LOAD-BEARING Phase-4-to-Phase-5 p=quarantine-to-p=reject cutover forensic-investigation REFERENCE — Phase-4 p=quarantine and Phase-5 p=reject cutovers consume per- AFRF-row forensic evidence attributing per-message SPF- evaluation outcomes to per- mechanism evaluation semantics; the include_vs_ip4_vs_a_vs_mx spoke documents the per-RFC- 7208-§5-mechanism-catalogue evaluation semantics whose per- mechanism decoding IS the canonical Phase-4-to-Phase-5 forensic-investigation reference every per-AFRF-row per-mechanism-attributed SPF- evaluation outcome decoding depends on. Read the include_ vs_ip4_vs_a_vs_mx spoke alongside this five-phase DMARC-policy-rollout workflow reference whenever the per- publisher operator scopes a Phase-1 publication-baseline authoring + Phase-2 p=none observability-baseline + Phase-3 pct=-ramp-advancement + Phase-4-to-Phase-5 cutover plan — the per-RFC-7208-§5- mechanism-catalogue the spoke documents IS the canonical UPSTREAM SPF-record-publication primitive every five-phase rollout THIS page architects structurally depends on.
• Email Header Analyzer — paste any email's headers and see SPF, DKIM, DMARC results plus the alignment evaluation. Use during rollout to debug specific failing messages reported by users.
• Domain Security Checker — live DNS lookups for DMARC, SPF, DKIM. Confirms the published record matches the intended rollout stage.
• DMARC troubleshooting — the SYMPTOM-DRIVEN ROLLOUT-FAILURE- DIAGNOSIS companion to THIS rollout-cadence contract. Where THIS page documents the per-stage p=none → p=quarantine → p=reject publication cadence as the OPERATOR-SIDE SCHEDULING-DISCIPLINE applied to the DMARC TXT record over the 6-12 week rollout window, the troubleshooting spoke documents the SYMPTOM-DRIVEN debugging playbook the operator MUST exercise at every per-stage gate-keeping checkpoint to convert the rua-stream evidence accumulated under the prior stage into the GO / NO-GO decision for flipping to the next stage. Four ROLLOUT- STAGE-VS-TROUBLESHOOTING-PLAYBOOK axes the troubleshooting spoke documents that THIS page is the rollout-cadence scheduler for: (1) p=none monitoring- stage gate — the troubleshooting spoke's "DMARC verdict = fail despite SPF = pass + DKIM = pass" symptom-catalogue traces the per-source-IP DMARC-fail-rate distribution accumulated in the rua stream during the p=none stage to the per-source-IP root-cause attribution (alignment-mode mismatch / DKIM signing- domain divergence / SPF mailfrom-domain divergence / unsigned legitimate-tenant / shadow-IT discovery) the operator MUST resolve BEFORE this page's stage gate flips to p=quarantine; (2) p=quarantine partial- enforcement-stage gate — the troubleshooting spoke's "spam-folder complaint from legitimate user" symptom- catalogue traces the per-message Authentication-Results audit through the receiver-side quarantine-decision path (sa-pass with dmarc=fail / sa-fail with dmarc=fail / mailing-list-rewrite drift / forwarder-induced From-domain rewrite cascade) the operator MUST close BEFORE this page's stage gate flips to p=reject; (3) per- stage pct= ramp diagnostic — the troubleshooting spoke's "verdict distribution flatlines despite pct= increase" symptom traces the per-stage rua-stream verdict-rate regression to the pct=-sampled receiver-side enforcement behaviour (RFC 7489 §6.6.4 sampling drift / receiver-side pct= interpretation divergence across Microsoft / Google / Yahoo / Mail.ru / Comcast) at every stage's incremental ramp this page schedules; (4) sp= + per-subdomain rollout coordination — the troubleshooting spoke's "subdomain unexpectedly p=reject-rejected" symptom-catalogue traces the sp=-tag-vs-p=-tag inheritance interaction the operator MUST understand BEFORE this page schedules an sp=quarantine or sp=reject publication. Read THIS page when SCHEDULING the next rollout stage; read the troubleshooting spoke when DIAGNOSING the rua-stream evidence at every stage's gate-keeping checkpoint.
• DMARC myths and misconceptions — the PER-ROLLOUT-STAGE-DEPLOYMENT-CADENCE- AS-LOAD-BEARING-REBUTTAL-DISCIPLINE-AGAINST- EVERY-DMARC-DEPLOYMENT-MYTH-COUNTERED-BY-THIS- CATALOGUE companion to THIS rollout-cadence contract. Where THIS page documents the p=none → p=quarantine → p=reject publication cadence as the OPERATOR-SIDE SCHEDULING-DISCIPLINE applied to the DMARC TXT record over the 6-12 week rollout window, the myths-and-misconceptions spoke is the OPERATOR- SIDE rebuttal catalogue documenting how the most damaging DMARC-deployment myths collapse against the per-rollout-stage cadence-evidence THIS page establishes at FOUR per-rollout-stage- to-deployment-myth dimensions: (i) "Skip p=none and publish p=reject on day one" myth — rebutted against THIS page's p=none monitoring-stage gate; the myths spoke documents how skipping the per-source-IP discovery window cuts off the rua-stream evidence accumulation required to find shadow-IT senders / unsigned legitimate tenants / alignment-mode-mismatched ESPs BEFORE enforcement strips their mail — every "go-straight-to-reject" anecdote the myths spoke rebuts depends on the monitoring-stage evidence THIS page schedules; (ii) "p=quarantine is a permanent stopping point" myth — rebutted against THIS page's intermediate- stage scheduling contract; the myths spoke documents how operators get stuck at p=quarantine indefinitely because they lack the per-stage pct= ramp discipline THIS page prescribes — the permanent-quarantine misconception collapses against the 6-12 week stage- progression evidence THIS page schedules; (iii) "pct=100 + p=reject on day one is safe because the rua-stream looks clean" myth — rebutted against THIS page's per-stage pct= ramp diagnostic; the myths spoke documents how rua-stream "cleanliness" at p=none is a per-source-IP receiver-side pct= sampling artifact, NOT a steady-state DMARC-pass verdict, and only the per-stage pct= ramp THIS page schedules converts the sampled evidence to a gate-keeping GO/NO-GO signal for the next stage; (iv) "Subdomains inherit p= automatically without sp=" myth — rebutted against THIS page's sp= + per-subdomain rollout coordination scheduling; the myths spoke documents how sp=-tag inheritance behaviour diverges across Microsoft / Google / Yahoo / Mail.ru / Comcast receiver implementations and how operators must explicitly schedule the sp= publication separately from p= publication — the "subdomains inherit automatically" misconception collapses against the sp=-aware stage-scheduling discipline THIS page prescribes. Read THIS page when SCHEDULING the rollout; read the myths-and-misconceptions spoke when an operator, executive, or auditor cites a rollout-related DMARC misconception that threatens the per-stage cadence THIS page prescribes.
• DKIM canonicalization — the PER-PUBLISHER-PER-MESSAGE- CANONICALIZATION-ALGORITHM-CHOICE- AS-LOAD-BEARING-PHASE-2-BASELINE- OBSERVABILITY-PREREQUISITE companion to this DMARC policy rollout reference. Where THIS page documents the per-publisher per-domain DMARC rollout per-stage cadence (Phase 1 SPF + DKIM publication-completeness gate, Phase 2 p=none baseline- observability gate consuming per- receiver rua aggregate-XML evidence to validate per-source-IP sender- inventory completeness and per- sender per-message DKIM-aligned- pass-rate floor before advancing, Phase 3 p=quarantine pct=ramp gate consuming per-stage per-day quarantine-rate-distribution evidence, Phase 4 p=reject pct= ramp gate, Phase 5 p=reject pct= 100 terminal-state closure gate + sp= subdomain-coordination schedule + np= non-existent- subdomain coordination schedule), the DKIM-canonicalization spoke is the STRUCTURALLY-UPSTREAM per- publisher per-message canonicalization- algorithm-choice-publication- discipline reference whose RFC 6376 §3.4 simple-vs-relaxed canonicalization- algorithm-pair primitive published in the per-message DKIM-Signature header's c=-tag is a load-bearing Phase 2 baseline- observability prerequisite whose per-receiver per-forwarder-class dkim-pass-rate evidence MUST be evaluated before per-publisher advancement to Phase 3 p=quarantine pct=ramp. The DKIM-canonicalization- vs-DMARC-rollout coupling establishes four specific per- publisher canonicalization-choice- to-rollout-stage-gate dimensions: (i) Phase 2 baseline- observability gate consumes per- publisher per-message canonicalization- choice evidence as load-bearing per-forwarder-class dkim-pass-rate floor — Phase 2 p=none baseline-observability evidence capture establishes the per- receiver per-publisher per-source- IP per-forwarder-class dkim-pass- rate distribution baseline; per- publisher canonicalization-choice published in every per-message DKIM-Signature directly determines the per-forwarder-class dkim-pass- rate floor; a per-publisher per- DKIM-signing-infrastructure c=simple choice produces per- forwarder-class concentrated dkim= fail-rate spike that flags as unsafe-to-advance under Phase 3 readiness criteria THIS page prescribes; per-publisher canonicalization-migration (typically c=simple → c=relaxed/ relaxed) is a load-bearing per- publisher remediation step before Phase 3 advancement; (ii) per-publisher Phase 2 → 3 advancement decision consumes per- receiver per-forwarder-class per- message-class dkim-pass-rate- distribution-stability as load- bearing gate criterion — per-publisher canonicalization- choice consistency across per- DKIM-signing-infrastructure (uniform c=relaxed/relaxed across per-tenant + per-marketing-ESP + per-transactional-ESP + per-corporate- relay signing surfaces) is a load- bearing precondition for per- receiver per-publisher per-source- IP dkim-pass-rate stability — per-publisher canonicalization- drift introduces per-DKIM-signing- infrastructure-cohort variance that violates Phase 3 advancement criteria; (iii) per- publisher Phase 3 pct=ramp per- stage per-day quarantine-rate- distribution evidence captures per-publisher canonicalization- choice fallout — Phase 3 p=quarantine pct=ramp per-stage per-day quarantine-rate- distribution evidence captured in per-receiver per-publisher per- domain rua aggregate-XML <policy_evaluated><disposition>quarantine</disposition> rows directly captures per-publisher per-forwarder-class dkim=fail cohort produced by per-publisher canonicalization-choice mismatch; per-publisher pct=ramp regression attribution routinely surfaces per-publisher canonicalization- choice as a load-bearing root- cause class; (iv) per- publisher Phase 4 p=reject pct= ramp + Phase 5 p=reject pct=100 terminal-state closure gate consumes per-publisher per-mail- class per-forwarder-class dkim- pass-rate-survival evidence as load-bearing per-mail-class rejection-rate baseline — per-publisher Phase 4 + Phase 5 terminal-state closure gate consumes per-publisher per-mail- class per-forwarder-class dkim- pass-rate-survival evidence to validate per-publisher per-mail- class rejection-rate stays below per-publisher operational- tolerance threshold; per-publisher canonicalization-choice that fails to survive per-forwarder-class modification produces per-mail- class rejection-rate spike that blocks terminal-state closure; per-publisher canonicalization- consolidation discipline (uniform c=relaxed/relaxed across per- publisher DKIM-signing infrastructure) is a load-bearing per-publisher Phase 5 terminal-state closure precondition. Read the DKIM- canonicalization spoke alongside this DMARC rollout reference during per-publisher Phase 2 baseline-observability evidence capture (audit per-publisher per- DKIM-signing-infrastructure canonicalization-choice consistency BEFORE drafting Phase 3 advancement readiness assessment), during per-publisher Phase 2 → Phase 3 advancement gate-keeping decision (per- forwarder-class dkim-pass-rate floor evidence requires per- publisher canonicalization-choice validation as load-bearing upstream input), and during per- publisher Phase 3 pct=ramp regression root-cause attribution (per-publisher canonicalization- choice mismatch with per- forwarder-hop modification discipline is a canonical per- stage regression root-cause class).
• TLS-RPT record syntax — the PER-PUBLISHER-PER-STAGE-TRANSPORT- LAYER-COMPLIANCE-OBSERVABILITY- PREREQUISITE companion to this DMARC policy-rollout reference. Where THIS page documents the per-publisher per- domain DMARC policy-rollout phase- progression discipline (Phase 1 publication-baseline, Phase 2 observability-baseline at p=none, Phase 3 p=quarantine + pct=-ramp progression, Phase 4 p=reject terminal-state advancement, Phase 5 per-publisher cross-receiver terminal-state monitoring), the TLS-RPT- record-syntax spoke documents the per- publisher per-domain RFC 8460 §3 TLS-RPT DNS TXT-RR publication discipline whose per-publisher per- stage transport-layer-compliance observability evidence is LOAD-BEARING per-stage gate evidence the per- publisher per-domain DMARC policy- rollout phase-progression decision discipline THIS page documents structurally consumes at FOUR per- publisher per-stage transport-layer- compliance gate coupling dimensions: (i) per-publisher Phase 1 publication-baseline transport-layer- publication-discipline gate consuming per-publisher per-domain TLS-RPT TXT- RR publication evidence as load-bearing per-publisher per-domain transport- layer-observability-baseline prerequisite — per-publisher per-domain DMARC policy-rollout Phase 1 publication-baseline gate requires per- publisher per-domain message-layer DMARC TXT-RR publication discipline (per-domain _dmarc TXT- RR publication) AND per-publisher per- domain transport-layer TLS-RPT TXT-RR publication discipline (per-domain _smtp._tls TXT-RR publication the TLS-RPT-record-syntax spoke documents the per-publisher publication of) AS COMPOSED per- publisher per-domain cross-layer observability-baseline-publication prerequisite — per-publisher per-stage gate the per-publisher per-domain DMARC policy-rollout phase-progression discipline THIS page documents consumes is the per-publisher per-domain TLS-RPT TXT-RR publication discipline THIS TLS- RPT-record-syntax spoke documents as the load-bearing transport-layer- observability publication-baseline prerequisite; (ii) per- publisher Phase 2 observability- baseline transport-layer-evidence- capture gate consuming per-publisher per-domain rua mailbox TLS-RPT JSON- report inbound evidence stream as load-bearing per-publisher per-MX-host per-failure-class transport-layer- compliance baseline — per- publisher per-domain DMARC policy- rollout Phase 2 observability-baseline gate consumes per-receiver per-day per- MX-host per-failure-class TLS-RPT JSON- report evidence at the per-publisher per-domain rua mailbox the TLS-RPT- record-syntax spoke documents the per- publisher publication of as the LOAD- BEARING per-publisher per-MX-host transport-layer-compliance-baseline evidence the per-publisher per-stage gate decision requires; per-publisher per-MX-host SMTP-STARTTLS failure- emergence per RFC 8460 §4.3 failure- class catalogue (starttls-not- supported / certificate- host-mismatch / certificate-expired / certificate-not-trusted / tlsa-invalid / sts-policy-invalid) captured per-day per-MX-host in the per-publisher per-domain rua TLS-RPT JSON-report evidence stream operationally IS the per-publisher per-MX-host transport-layer-compliance- baseline the per-publisher per-stage gate decision the per-publisher per- domain DMARC policy-rollout phase- progression discipline THIS page documents consumes; (iii) per- publisher Phase 3 p=quarantine + pct=-ramp progression consuming per-publisher per-day per- MX-host TLS-pass-rate-distribution- stability as load-bearing per-stage advancement criterion — per- publisher per-domain DMARC policy- rollout Phase 3 pct=-ramp per-stage advancement decision (per- publisher pct=10 → pct=25 → pct=50 → pct=100 per-publisher per-stage progression) requires per- publisher per-day per-MX-host TLS-pass- rate-distribution-stability evidence from the per-publisher per-domain rua TLS-RPT JSON-report evidence stream the TLS-RPT-record-syntax spoke documents the per-publisher publication of — per-publisher per-stage gate advancement the per-publisher per- domain DMARC policy-rollout phase- progression discipline THIS page documents enforces consumes per- publisher per-day per-MX-host TLS-pass- rate distribution as the per-stage transport-layer-compliance prerequisite; (iv) per-publisher Phase 4/5 terminal-state p=reject gate consuming per-publisher per-domain cross-receiver TLS-pass-rate- distribution as load-bearing per- publisher per-domain terminal-state transport-layer-compliance prerequisite per BSR-2024 enforcement boundary — per-publisher per-domain DMARC policy-rollout Phase 4 p=reject terminal-state advancement gate (per- publisher per-domain terminal-state commitment) requires per-publisher per- domain cross-receiver TLS-pass-rate- distribution evidence (per-receiver Gmail / Microsoft 365 / Yahoo / Apple Mail per-publisher per-MX-host TLS- pass-rate aggregate from per-receiver rua-emitted TLS-RPT JSON-report stream the TLS-RPT-record-syntax spoke documents the per-publisher per-domain rua publication of) as the LOAD- BEARING per-publisher per-domain terminal-state transport-layer- compliance prerequisite the per-stage gate decision the per-publisher per- domain DMARC policy-rollout phase- progression discipline THIS page documents requires per BSR-2024 (Gmail + Yahoo Bulk Sender Requirements February 2024) per-publisher cross- receiver TLS-handshake-success-rate floor enforcement boundary. Read the TLS-RPT-record-syntax spoke alongside this DMARC policy-rollout reference when planning per-publisher per-domain DMARC enforcement-ramp whose per-stage gate decision discipline structurally depends on per-publisher per-MX-host transport-layer-compliance evidence the per-publisher per-domain rua TLS-RPT JSON-report capture the TLS-RPT-record- syntax spoke documents the per-publisher per-domain publication of structurally produces, and when investigating per- publisher per-stage regression whose upstream root-cause is per-publisher per-MX-host transport-layer-compliance variance the per-publisher per-domain rua TLS-RPT JSON-report evidence stream the TLS-RPT-record-syntax spoke documents the per-publisher per-domain publication of structurally captures at per-receiver per-day per-MX-host per- failure-class row-level granularity.
• DKIM troubleshooting (symptom-driven diagnostic ladder) — the PER-RAMP-STAGE-DKIM-VERDICT-LADDER- AS-LOAD-BEARING-DIAGNOSTIC-PREREQUISITE companion to this DMARC policy-rollout playbook. Where THIS page documents the canonical phased-enforcement ramp through p=none monitoring → p=quarantine partial- enforcement → p=reject full-enforcement (per-stage pct= ramp gates, sp=-tag subdomain- coordination, per-source-IP root-cause attribution checkpoints), the DKIM- troubleshooting spoke is the OPERATOR-SIDE per-symptom diagnostic ladder whose per- verdict branches are the LOAD-BEARING DIAGNOSTIC PREREQUISITE every per-pct=-ramp- stage advancement decision depends on at FOUR per-ramp-stage-to-DKIM-diagnostic- ladder dimensions: (i) Phase 1 publication-baseline DKIM-verdict ladder traversal as deployment-baseline prerequisite — before the first p=none publication, the operator MUST traverse the DKIM- troubleshooting per-symptom decision tree to confirm the publisher's per-selector TXT-record is publication-healthy (no receiver-side dkim=permerror NXDOMAIN, no dkim=fail body- hash mismatch from canonicalisation-mode misconfiguration, no dkim=policy algorithm-too-weak or key-too-short verdicts); the troubleshooting spoke is the canonical reference for this Phase 1 publication-baseline verification step; (ii) Phase 2 p=none monitoring-baseline DKIM-verdict-rate observability as Phase-3 advancement gate — during the p=none observability window, per-receiver per-source-IP per-day DKIM-aligned-pass-rate aggregate-report evidence drives the Phase-3 advancement decision; the troubleshooting spoke's per- symptom branches are the operator-side diagnostic reference for attributing per-receiver DKIM-aligned-fail rate floor regressions to root causes (legitimate sender selector-mismatch, intermediary body-modification breaking body-hash, third-party signer onboarding gap) BEFORE advancing to p=quarantine; (iii) Phase 3 pct=- ramp per-stage gate-keeping DKIM-aligned- pass-rate floor enforcement — each pct=10 → pct=25 → pct=50 → pct=100 per-stage advancement is gated by per- receiver per-source-IP DKIM-aligned-pass- rate floor enforcement; the troubleshooting spoke documents the per-symptom branches operators traverse when a per-receiver DKIM-aligned-fail surge during a pct=-ramp advancement regresses the per-stage gate-keeping decision and requires per-source-IP root- cause attribution before the per-stage advancement may resume; (iv) Phase 4 p=quarantine → Phase 5 p=reject cutover DKIM-aligned- pass-rate confidence floor — the cutover decision from quarantine partial-enforcement to reject full- enforcement requires sustained DKIM-aligned- pass-rate floor across per-receiver per- source-IP per-day evidence; the troubleshooting spoke is the canonical operator-side per-symptom diagnostic ladder the cutover-readiness assessment consumes when investigating per-receiver per-source-IP DKIM-aligned-fail evidence rows that would produce legitimate-mail rejection at p=reject. Read the DKIM- troubleshooting spoke ALONGSIDE this policy-rollout playbook BEFORE every per-pct=-ramp-stage advancement and BEFORE every per-phase quarantine / reject cutover — the spoke is the canonical application-layer per-symptom diagnostic ladder the ramp-stage advancement decision depends on at the per-receiver per-source- IP per-day DKIM-aligned-pass-rate observability boundary.
• DMARC aggregate reports (RFC 7489 §7.2 XML rua) — the PER-RECEIVER-PER-SOURCE-IP-PER-DAY- RUA-AGGREGATE-XML-EVIDENCE-STREAM-AS-LOAD- BEARING-PER-pct=-RAMP-STAGE-ADVANCEMENT- GATE-KEEPING-INPUT companion to this DMARC policy-rollout playbook. Where THIS page documents the canonical phased-enforcement ramp through p=none monitoring → p=quarantine partial- enforcement → p=reject full- enforcement (per-stage pct= ramp gates, sp=-tag subdomain- coordination, per-source-IP root-cause attribution checkpoints), the DMARC- aggregate-reports spoke is the OPERATOR-SIDE per-receiver per-source-IP per-day RFC 7489 §7.2 XML aggregate-report evidence-stream reference whose record-level vocabulary is the LOAD-BEARING per-stage gate-keeping input every pct=-ramp-stage advancement consumes at FOUR per-ramp- stage-to-aggregate-evidence-coupling dimensions: (i) Phase 2 p=none monitoring-baseline per-receiver per-source-IP DKIM-aligned- pass-rate and SPF-aligned-pass-rate floor establishment via record-level row/policy_evaluated/dkim=pass and row/policy_evaluated/spf=pass evidence-row aggregation — the aggregate-reports spoke documents the per-receiver per-source-IP per-day record- level evidence-row vocabulary operators consume to establish the Phase-2 baseline the Phase-3 advancement decision depends on; (ii) Phase 3 pct=10 → pct=25 → pct=50 → pct=100 per-stage advancement gate-keeping via per-receiver per-source-IP per-day record-level row/policy_evaluated/disposition= evidence-row aggregation — the aggregate-reports spoke documents the per- stage record-level evidence-row vocabulary operators consume to attribute per-source-IP per-day disposition outcomes during the Phase-3 pct=-ramp advancement, and to confirm sustained per-stage alignment-pass-rate floor BEFORE each ramp advancement; (iii) Phase 4 p=quarantine partial- enforcement observability via per-receiver per-source-IP per-day record-level row/policy_evaluated/disposition= quarantine evidence-row aggregation — the aggregate-reports spoke documents the per-receiver per-source-IP per-day quarantine- disposition evidence-row vocabulary operators consume to confirm sustained per-receiver per- source-IP alignment-pass-rate floor during the Phase-4 partial-enforcement window the Phase-5 cutover decision depends on; (iv) Phase 5 p=reject cutover per-receiver per-source-IP per-day post- cutover regression-monitoring via record- level row/policy_evaluated/disposition= reject evidence-row aggregation — the aggregate-reports spoke documents the post-cutover per-receiver per-source-IP per- day reject-disposition evidence-row vocabulary operators consume to detect post-cutover regressions where legitimate-mail rejection emerges at receivers and to drive the per- source-IP root-cause attribution required for rollback or per-source-IP mitigation decisions. Read the DMARC-aggregate-reports spoke ALONGSIDE this policy-rollout playbook BEFORE every per-pct=-ramp-stage advancement and BEFORE every per-phase quarantine / reject cutover — the spoke is the canonical per-receiver per-source-IP per-day RFC 7489 §7.2 XML aggregate-report evidence-stream reference whose record-level vocabulary is the LOAD-BEARING per-stage gate-keeping input every ramp-stage advancement decision depends on at the per- receiver per-source-IP per-day evidence-row observability boundary.
• DMARC for Google Workspace — the WORKSPACE-TENANT-SPECIFIC DEPLOYMENT-WORKFLOW companion to this DMARC policy-rollout playbook. Where THIS page documents the provider- agnostic phased-enforcement ramp through p=none monitoring → p=quarantine partial- enforcement → p=reject full-enforcement, the Workspace deployment spoke is the WORKSPACE-TENANT-SPECIFIC per-phase execution guide at FOUR per- Workspace-tenant-to-phased-ramp coupling dimensions: (i) Phase 2 Workspace-tenant baseline publication via canonical include:_spf.google.com SPF token + Workspace-managed google._domainkey CNAME DKIM signing-key + _dmarc TXT p=none publication + Workspace Admin Console domain- verification + RUA-mailbox configuration — the Workspace spoke documents the Workspace-tenant- specific Phase-2 baseline publication workflow operators execute BEFORE Phase-3 advancement on Workspace tenants; (ii) Phase 3 pct=- ramp Workspace-tenant third-party-sender catalogue coordination — Salesforce / HubSpot / Mailchimp / Marketo / Zendesk / Intercom secondary include: token enrollment within the Workspace tenant's 10-DNS- lookup SPF budget — the Workspace spoke documents the per- Workspace-tenant third-party-sender enrollment discipline required to sustain the Phase-3 pct=- ramp advancement decision; (iii) Phase 4 p=quarantine Workspace- tenant partial-enforcement coordination via Workspace Admin Console policy- update workflow + per-Workspace-tenant quarantine-disposition observability — the Workspace spoke documents the Workspace-tenant-specific Admin Console policy-update workflow operators execute during Phase-4 partial- enforcement on Workspace tenants; (iv) Phase 5 p=reject Workspace-tenant cutover and post- cutover regression-monitoring via Google Postmaster Tools per-receiver per-source-IP per-day reject-disposition observability + RUA-aggregate-XML record-level row/policy_evaluated/disposition=reject evidence-row aggregation — the Workspace spoke documents the post- cutover Workspace-tenant-specific regression-detection workflow operators execute AFTER Phase-5 cutover on Workspace tenants. Read the Workspace deployment spoke ALONGSIDE this policy-rollout playbook when executing the phased ramp on Workspace tenants — the spoke is the canonical Workspace- tenant-specific deployment-workflow reference whose per-phase Workspace- Admin-Console + Postmaster-Tools operational steps are the LOAD-BEARING Workspace-tenant execution discipline every Workspace-tenant phased-ramp advancement decision depends on.
• DMARC for Microsoft 365 — the M365-TENANT-SPECIFIC DEPLOYMENT-WORKFLOW companion to this DMARC policy-rollout playbook. Where THIS page documents the provider- agnostic phased-enforcement ramp through p=none monitoring → p=quarantine partial- enforcement → p=reject full-enforcement, the M365 deployment spoke is the M365-TENANT-SPECIFIC per-phase execution guide at FOUR per- M365-tenant-to-phased-ramp coupling dimensions: (i) Phase 2 M365-tenant baseline publication via canonical include:spf.protection.outlook.com SPF token + Exchange-Online-managed selector1._domainkey + selector2._domainkey CNAME pair pointing at selector1-<domain>-com._domainkey.<tenant>.onmicrosoft.com + _dmarc TXT p=none publication + Microsoft 365 Defender portal DKIM- signing enablement — the M365 spoke documents the M365-tenant-specific Phase-2 baseline publication workflow operators execute BEFORE Phase-3 advancement on M365 tenants; (ii) Phase 3 pct=-ramp M365-tenant third-party-sender catalogue coordination — Salesforce / HubSpot / Mailchimp / Marketo / Zendesk / Intercom secondary include: token enrollment within the M365 tenant's 10-DNS-lookup SPF budget alongside Exchange Online Connectors for hybrid on-premises relay routing — the M365 spoke documents the per-M365-tenant third-party-sender enrollment discipline required to sustain the Phase-3 pct=-ramp advancement decision; (iii) Phase 4 p=quarantine M365-tenant partial-enforcement coordination via Microsoft 365 Defender anti-spoofing policy-update workflow + Exchange Online transport-rule coordination + per-M365-tenant quarantine-disposition observability via Threat Explorer — the M365 spoke documents the M365-tenant-specific Defender policy- update workflow operators execute during Phase-4 partial-enforcement on M365 tenants; (iv) Phase 5 p=reject M365-tenant cutover and post-cutover regression- monitoring via Microsoft Defender for Office 365 Threat Explorer per- receiver per-source-IP per-day reject-disposition observability + RUA-aggregate-XML record-level row/policy_evaluated/disposition=reject evidence-row aggregation — the M365 spoke documents the post-cutover M365-tenant-specific regression- detection workflow operators execute AFTER Phase-5 cutover on M365 tenants. Read the M365 deployment spoke ALONGSIDE this policy-rollout playbook when executing the phased ramp on M365 tenants — the spoke is the canonical M365-tenant-specific deployment-workflow reference whose per-phase Microsoft-365-Defender + Exchange-Online-Admin-Center + Threat-Explorer operational steps are the LOAD-BEARING M365-tenant execution discipline every M365-tenant phased- ramp advancement decision depends on.
• SPF 10-DNS-lookup limit — the canonical publisher-side SPF-hygiene-prerequisite reference documenting how the RFC 7208 §4.6.4 ten-DNS-lookup ceiling (counted recursively across include:, a, mx, ptr, exists:, and redirect= mechanisms during the receiver-side recursive SPF evaluation per RFC 7208 §4.6.4) is the load-bearing publisher-side SPF-hygiene prerequisite every per-publisher phased-rollout ramp THIS page schedules must satisfy BEFORE advancing past the Phase-1 monitor stage — an unresolved ten-lookup exceedance produces spf=permerror across every aggregate- report record, collapsing the policy_evaluated.spf verdict to fail regardless of legitimate mail-stream provenance and making the Phase-2 baseline- observability evidence the rollout ramp's gate-keeping decision discipline depends on STRUCTURALLY UNTRUSTWORTHY (the ~99% legitimate-mail policy_evaluated=pass advancement gate canonical to the rollout ramp cannot be evaluated when SPF is permerroring). Read the SPF-lookup-limit spoke ALONGSIDE this rollout playbook during Phase-1 and Phase-2 — the spoke documents the four canonical publisher-side remediation strategies (envelope-domain split, third-party-include flattening via static IP/CIDR publication, SPF-record macro consolidation, and the redirect=-as-single-lookup- replacement pattern) that restore spf=pass verdicts to the aggregate- report stream BEFORE the Phase-3 pct=-ramp advancement decision boundary is reached.
• MTA-STS policy file syntax — the PER-PUBLISHER-TRANSPORT- SECURITY-MTA-STS-mode=testing→mode= enforce-PROGRESSION-AS-STRUCTURAL- PARALLEL-TO-PER-PUBLISHER-MESSAGE- AUTHENTICATION-p=none→p=quarantine; pct=ramp→p=reject;pct=100- PROGRESSION companion to this DMARC policy rollout playbook. Where THIS page documents the per- publisher message-authentication enforcement-policy progression through the p=none baseline- observability phase, the p=quarantine; pct= gradient-coverage ramp, and the p=reject; pct=100 terminal-state with per-phase aggregate-report-evidence-grounded advancement-gate decision-criteria, the mta_sts_policy_syntax spoke documents the structurally- ISOMORPHIC per-publisher TRANSPORT- SECURITY enforcement-policy progression through the mode: testing baseline- observability phase, the per-mx- pattern selective-enforcement phase, and the mode: enforce terminal-state with per-phase TLS-RPT-evidence-grounded advancement-gate decision-criteria. FOUR structurally-distinct PER-MTA- STS-mode-STATE-VS-PER-DMARC-p=-MODE- STATE STRUCTURAL-PARALLEL dimensions the per-publisher rollout discipline THIS page documents operationally consumes when extended to the transport-security layer the policy-syntax spoke catalogues: (i) per-publisher mode: none AS PER- PUBLISHER MTA-STS-DEPLOYMENT-PRE- PHASE-0-STATE STRUCTURAL-PARALLEL- TO-PER-PUBLISHER-DMARC-RECORD- ABSENCE-PRE-PHASE-0-STATE — both the absence of any per-publisher _dmarc TXT-record AND the explicit mode: none mta-sts.txt publication are the per-publisher pre-deployment baseline-state that produces ZERO per-receiver-side enforcement outcome; both must transition to the baseline-observability phase (p=none + mode: testing) before per-publisher empirical-evidence collection begins; (ii) per- publisher mode: testing AS PER-PUBLISHER MTA-STS-DEPLOYMENT- BASELINE-OBSERVABILITY-PHASE STRUCTURAL-PARALLEL-TO-PER- PUBLISHER-DMARC-p=none- BASELINE-OBSERVABILITY-PHASE — both the per-publisher mode: testing mta-sts.txt publication AND the per-publisher p=none DMARC-record publication produce per-publisher empirical-evidence WITHOUT changing per-receiver-side disposition: every per-receiver MTA-STS-aware sending MTA sends per-publisher per-day per-mx- pattern TLS-RPT JSON aggregate reports against the per-publisher mode: testing baseline, every per-receiver DMARC-aware verification engine sends per- publisher per-day per-row aggregate XML reports against the per- publisher p=none baseline; the per-publisher operator consumes BOTH evidence streams to inform per-publisher per-mx-pattern transport-security readiness AND per-publisher per- source-IP message-authentication readiness; (iii) per- publisher partial-mx-pattern- enforcement-mode-publication-cadence AS PER-PUBLISHER MTA-STS-DEPLOYMENT- GRADIENT-COVERAGE-PHASE STRUCTURAL- PARALLEL-TO-PER-PUBLISHER-DMARC- p=quarantine; pct=<0..99>-GRADIENT- COVERAGE-RAMP-PHASE — the DMARC pct=-ramp gradient-coverage discipline THIS page documents has a structural transport-security parallel: the per-publisher mta-sts.txt can progressively narrow the mx:-field per-mx- pattern enumeration while at mode: testing until the per-mx-pattern per-receiver TLS-RPT-evidence-grounded per- receiver per-day TLS-handshake-rate baseline reaches the per-publisher operator confidence-threshold for mode: enforce advancement; (iv) per- publisher mode: enforce AS PER-PUBLISHER MTA-STS-DEPLOYMENT- TERMINAL-STATE STRUCTURAL-PARALLEL- TO-PER-PUBLISHER-DMARC-p=reject; pct=100-TERMINAL-STATE — both the per-publisher mode: enforce mta-sts.txt publication AND the per-publisher p=reject; pct=100 DMARC-record publication are the per-publisher full-enforcement terminal-state that commits the per-receiver-side enforcement: mode: enforce commits the per-receiver MTA-STS- aware sending MTA to REJECT TLS-handshake-failure or mx- pattern-mismatch destinations WITHOUT fallback to opportunistic- TLS, p=reject; pct=100 commits the per-receiver DMARC- aware verification engine to REJECT every per-message non- aligned-DMARC verdict WITHOUT fallback to quarantine or none; both terminal-state advancement decisions depend on the per- publisher per-phase per-day empirical-evidence stream reaching the operator-confidence-grounded ~99%-coverage-quality threshold the per-phase advancement-gate decision-criteria the policy- rollout playbook THIS page documents enforces. Read the mta_sts_policy_syntax spoke ALONGSIDE this DMARC policy rollout playbook when the per- publisher rollout discipline THIS page documents is extended to the transport-security layer the spoke catalogues — the spoke is the canonical per-publisher TRANSPORT- SECURITY ROLLOUT-DISCIPLINE STRUCTURAL-PARALLEL the per- publisher message-authentication rollout-discipline this page documents extends to at the per- publisher mta-sts.txt-policy-file publication level.
• DKIM for Microsoft 365 — the LOAD-BEARING per-M365-tenant per- custom-domain PER-M365-TENANT-DKIM- PUBLICATION-AS-FOUNDATIONAL- PREREQUISITE-OF-THE-FIVE-PHASE-DMARC- RAMP companion documenting the per- M365-tenant per-custom-domain DKIM publication tutorial (Exchange Online / Microsoft 365 Defender admin-center DKIM enablement, the 2048-bit selector1._domainkey / selector2._domainkey per-tenant CNAME publication, the per- tenant DKIM signing-domain verification) whose per-tenant successful execution is the FOUNDATIONAL PREREQUISITE that MUST complete BEFORE the per-publisher per- domain five-phase DMARC enforcement ramp this page documents can advance past phase 1 (p=none monitoring) — the per-publisher per- domain ramp progression strictly requires the per-publisher per-domain DKIM-aligned-pass-rate floor across the per-publisher per-domain authorized- sender inventory to advance to phase 2 (p=quarantine pct=10), phase 3 (p=quarantine pct=100), phase 4 (p=reject pct=10), phase 5 (p=reject pct=100). For M365-tenant per-publisher per- custom-domain operators, the DKIM-for- M365 spoke documents the EXACT per- tenant per-custom-domain admin-center / PowerShell DKIM-enablement operations that PRODUCE the per-publisher per- domain DKIM-aligned-pass-rate floor the per-publisher per-domain DMARC ramp this page documents progression depends on. Where THIS page documents the per-publisher per-domain RFC 7489 FIVE-PHASE DMARC ENFORCEMENT RAMP DISCIPLINE (the per-publisher per- domain p=none → p=quarantine pct=10 → p=quarantine pct=100 → p=reject pct=10 → p=reject pct=100 phase progression, the per-phase advancement prerequisites, the per-phase rollback criteria, the per-phase observability instrumentation), the DKIM-for-M365 spoke documents the PER-M365-TENANT per-custom-domain FOUNDATIONAL PREREQUISITE — the per-tenant per- custom-domain DKIM publication operations that PRODUCE the per- publisher per-domain DKIM-aligned-pass- rate floor the per-publisher per-domain DMARC ramp progression this page documents structurally depends on. Read THIS page when PLANNING the per- publisher per-domain five-phase DMARC enforcement ramp progression; read the DKIM-for-M365 spoke when PUBLISHING the per-M365-tenant per-custom-domain DKIM records that PRODUCE the per-publisher per-domain DKIM-aligned-pass-rate FLOOR-PREREQUISITE the per-publisher per-domain DMARC ramp progression this page documents structurally depends on.
• DKIM for Google Workspace — the LOAD-BEARING per-Workspace-tenant per-custom-domain PER-WORKSPACE-TENANT- DKIM-PUBLICATION-AS-FOUNDATIONAL- PREREQUISITE-OF-THE-FIVE-PHASE-DMARC- RAMP companion documenting the per- Workspace-tenant per-custom-domain DKIM publication tutorial (the Google Admin console Apps > Google Workspace > Gmail > Authenticate email DKIM enablement flow, the per-tenant 2048-bit google._domainkey.<d> DNS-TXT publication, the per-tenant DKIM signing-domain verification step) whose per-tenant successful execution is the FOUNDATIONAL PREREQUISITE that MUST complete BEFORE the per-publisher per- domain five-phase DMARC enforcement ramp this page documents can advance past phase 1 (p=none monitoring) — the per-publisher per- domain ramp progression strictly requires the per-publisher per-domain DKIM-aligned-pass-rate floor across the per-publisher per-domain authorized- sender inventory to advance to phase 2 (p=quarantine pct=10), phase 3 (p=quarantine pct=100), phase 4 (p=reject pct=10), phase 5 (p=reject pct=100). For Workspace-tenant per-publisher per- custom-domain operators, the DKIM-for- Workspace spoke documents the EXACT per- tenant per-custom-domain Admin-console DKIM-enablement operations that PRODUCE the per-publisher per-domain DKIM- aligned-pass-rate floor the per- publisher per-domain DMARC ramp this page documents progression depends on. Where THIS page documents the per- publisher per-domain RFC 7489 FIVE- PHASE DMARC ENFORCEMENT RAMP DISCIPLINE (the per-publisher per- domain p=none → p=quarantine pct=10 → p=quarantine pct=100 → p=reject pct=10 → p=reject pct=100 phase progression, the per-phase advancement prerequisites, the per-phase rollback criteria, the per-phase observability instrumentation), the DKIM-for- Workspace spoke documents the PER- WORKSPACE-TENANT per-custom-domain FOUNDATIONAL PREREQUISITE — the per- tenant per-custom-domain DKIM publication operations that PRODUCE the per-publisher per-domain DKIM- aligned-pass-rate floor the per- publisher per-domain DMARC ramp progression this page documents structurally depends on. Read THIS page when PLANNING the per-publisher per-domain five-phase DMARC enforcement ramp progression; read the DKIM-for- Workspace spoke when PUBLISHING the per-Workspace-tenant per-custom-domain DKIM records that PRODUCE the per- publisher per-domain DKIM-aligned-pass- rate FLOOR-PREREQUISITE the per- publisher per-domain DMARC ramp progression this page documents structurally depends on.
• Email authentication glossary — the DMARC-POLICY-ROLLOUT-RAMP- VOCABULARY-RESOLVES-TO-CROSS-CLUSTER- EMAIL-AUTHENTICATION-TERMINOLOGY-HUB companion to this DMARC ramp-discipline reference. Where THIS page documents the per-publisher per-domain DMARC policy- rollout ramp progression (the canonical p=none monitoring phase → p=quarantine partial- enforcement phase with pct= incremental rollout → p=reject full-enforcement phase, per-receiver evaluator behaviour at each phase, per- publisher operational discipline at each phase, the sp= subdomain- policy choice coordination), the email- authentication-glossary spoke is the cross-cluster TERMINOLOGY-RESOLUTION reference whose per-term canonical definitions establish the shared vocabulary every DMARC-ramp discussion structurally depends on at FOUR per-term vocabulary-resolution dimensions: (i) per-term DMARC-record tag-set vocabulary resolution — the DMARC-record tag-set vocabulary (p= policy tag, sp= subdomain-policy tag, pct= percentage tag, aspf= SPF-alignment-strictness tag, adkim= DKIM-alignment-strictness tag, rua= aggregate-report URI tag, ruf= forensic-report URI tag, fo= forensic- options tag, rf= report-format tag, ri= report-interval tag) THIS page's per- publisher per-domain ramp reference structurally references at every per- ramp-phase entry is canonically defined in the glossary spoke; the per- publisher per-domain DMARC-record per- tag terminology vocabulary that drives every ramp-progression authoring discussion lives in the glossary's per- tag entry-set; (ii) per-term DMARC-alignment-strictness vocabulary resolution — the DMARC-alignment- strictness vocabulary (organizational domain, public suffix list, aspf= s/ relaxed mode, adkim= s/relaxed mode, RFC5322-From domain, SPF-aligned-pass, DKIM-aligned-pass) THIS page's per- publisher per-domain ramp reference references when describing per-phase per-message alignment-evaluation outcomes is canonically defined in the glossary spoke; the per-message alignment-mode evaluation vocabulary that determines whether a per-message SPF-pass or DKIM-pass becomes a DMARC- aligned-pass at each ramp phase lives in the glossary's per-term alignment- vocabulary entry-set; (iii) per- term DMARC-disposition vocabulary resolution — the DMARC-disposition vocabulary (per-receiver disposition keyword set: none, quarantine, reject; per-message per-source-IP disposition outcome; per-publisher per-domain per- phase enforcement-rate KPI; per-receiver per-day disposition-cohort aggregation) THIS page's per-publisher per-domain ramp reference references when describing per-phase per-receiver evaluator output is canonically defined in the glossary spoke; the per-receiver per-message disposition-outcome vocabulary that drives every per-phase progression decision discussion lives in the glossary's per-term disposition- vocabulary entry-set; (iv) per- term DMARC-aggregate-report vocabulary resolution — the DMARC-aggregate-report vocabulary (rua= mailto/HTTPS RUA-URI, per-receiver per-day-bucket XML report, per-source-IP per-row attribution-key field, per-disposition per-row evaluation-outcome field, per-message DKIM-result per-row evaluation field, per-message SPF-result per-row evaluation field, RFC 7489 §7.2 report schema) THIS page's per-publisher per-domain ramp reference references when describing per-phase aggregate-report consumption and per-phase ramp-progression- confirmation telemetry is canonically defined in the glossary spoke; the per-publisher per-domain aggregate-report-stream decode vocabulary that drives every operator-side per- ramp-phase decision discussion lives in the glossary's per-term aggregate-report- vocabulary entry-set. Read the email- authentication-glossary spoke alongside this DMARC policy-rollout ramp-discipline reference when authoring per-publisher per-domain ramp-progression runbooks and per-tag-coordination documents that need the shared terminology hub.
• MTA-STS for Microsoft 365 Four per-M365-tenant phased-rollout coordination dimensions: (i) per-publisher per-domain DMARC ramp Phase 2 (RUA-observability publication) coordinated with MTA-STS Phase 1 (testing-mode publication) on the same custom-domain — both publication primitives produce per-tenant evidence streams (RUA for application-layer DKIM/SPF/DMARC verdicts, TLS-RPT for transport-layer STARTTLS-handshake failures) the M365 operator must concurrently provision the rua=mailto:/tls-rpt=mailto: aggregation surface for, so a per-tenant operations team typically rolls them up in the same Phase 1/2 deployment window; (ii) per-publisher per-domain DMARC ramp Phase 3 (p=quarantine pct=10/25 partial enforcement) coordinated with MTA-STS Phase 2 (enforce-mode publication) on the same custom-domain — the Phase 3 ramp introduces per-message quarantine actions whose receiver-side disposition outcomes depend on the per-message Authentication-Results header set surviving the per-message transport-layer leg in unmodified form, which the per-M365-tenant MTA-STS enforce-mode publication is the per-publisher hardening primitive against per-attacker STARTTLS-downgrade tampering with, so the Phase 3 application-layer enforcement coordinates with concurrent Phase 2 transport-layer enforcement; (iii) per-publisher per-domain DMARC ramp Phase 5 (terminal p=reject pct=100) coordinated with MTA-STS enforce-mode + DANE-when-available transport-hardening posture — the terminal p=reject application-layer commitment is the operator's permanent declaration that per-message authentication-failures result in receiver-side SMTP 5xx rejection, and the concurrently-published per-M365-tenant MTA-STS enforce-mode + DANE-TLSA publication closes the transport-layer attack-surface that would otherwise allow per-attacker per-message authentication-evidence tampering to bypass the terminal application-layer enforcement; (iv) per-tenant rollback-and-progression playbook coordination across application-layer DMARC and transport-layer MTA-STS — when the per-tenant operator detects a per-customer-domain ramp regression (deliverability KPI degradation, per-receiver feedback-loop spike, per-source-IP RUA anomaly), the rollback discipline applies BOTH to the application-layer ramp (downshift pct= or downshift p=) AND to the transport-layer publication (downshift MTA-STS mode from enforce back to testing while investigating sts-policy-fetch-error patterns) — the per-publisher per-domain operator runs a UNIFIED per-tenant ramp-and-rollback workflow across both publication primitives, not two independent workflows. Read the M365-MTA-STS spoke alongside this DMARC policy-rollout reference when planning the per-M365-tenant per-custom-domain DMARC ramp progression with concurrent transport-layer hardening, when authoring the per-tenant per-phase rollout runbook coordinating both application-layer and transport-layer publication cadences, or when investigating per-tenant per-phase ramp regressions that correlate with per-tenant TLS-RPT sts-policy-fetch-error patterns indicating concurrent transport-layer publication drift.
• Reverse DNS (PTR records) explained — the PER-OUTBOUND-IP-POOL-PTR-RDNS-AS-RAMP- PRECONDITION companion to this DMARC policy- rollout reference. Where THIS page documents the per-publisher per-domain DMARC ramp cadence (Phase 0 TTL discipline → Phase 1 SPF + DKIM prerequisite verification → Phase 2 RUA publication + monitoring inventory → Phase 3 p=none observation window → Phase 4 p=quarantine pct ramp → Phase 5 terminal p=reject pct=100), the reverse-DNS-PTR spoke is the PER-PUBLISHER-PER-DOMAIN- DELIVERABILITY-PRECONDITION REFERENCE every publisher consults during Phase 1 prerequisite verification when auditing the per-outbound- IP-pool PTR record publication that gates per-receiver inbound-MX accept-or-reject decisions BEFORE the per-message DMARC evaluator even fires. Three structurally- distinct PTR-vs-DMARC-ramp coordination dimensions: (i) per-outbound-IP-pool PTR record continuity gates per-receiver deliverability ACCEPTANCE — receivers rejecting per-PTR-absent connections at SMTP 550 before the per-message DMARC evaluator runs masks the per-message DMARC policy enforcement entirely (per-receiver rejected-at-rDNS-lookup mail produces no per-receiver RUA evidence row, so the publisher's Phase 3 / Phase 4 observation window understates the per-receiver deliverability surface); (ii) per-outbound- IP-pool PTR-record forward-confirmed match (the PTR-resolved hostname's forward A/AAAA record must resolve back to the same IP) is the receiver-side validation discipline that distinguishes legitimate publisher- owned IP pools from misconfigured / hostile IP pools — Phase 1 prerequisite verification catalogues this as the same-class deliverability prereq as DKIM signing-key publication; (iii) per-shared-IP-pool PTR-record reputation cohort interaction with per-tenant DMARC ramp produces correlated per-receiver deliverability outcomes — a shared-IP-pool co-tenant's PTR-record misconfiguration produces per-receiver rejected-at-rDNS- lookup events for OTHER co-tenants on the same pool, generating per-tenant deliverability KPI regressions during Phase 3 / Phase 4 ramp progression the publisher must correlate with shared-pool PTR-record audit evidence to attribute correctly.
• RFC 7489 §6.3 — General Record Format — the foundational DMARC tag specification including p=, sp=, pct=.
• RFC 9091 — np tag — adds np= for non-existent subdomain policy.
• draft-ietf-dmarc-dmarcbis — the in-progress DMARC successor draft that deprecates pct= and ruf=.
• DANE TLSA explained (RFC 7672) — the PER-PUBLISHER-DMARC-FIVE-PHASE- ROLLOUT-AS-STRUCTURAL-PARALLEL-TO-PER- PUBLISHER-DANE-TLSA-DEPLOYMENT-PHASE companion to this DMARC policy-rollout reference. Where THIS page documents the per-publisher DMARC five-phase enforcement- mode progression (Phase 0 publication- baseline, Phase 1 p=none observability, Phase 2 p=quarantine; pct=-ramp, Phase 3 p=quarantine; pct=100 enforcement, Phase 4 p=reject; pct=-ramp, Phase 5 p=reject; pct=100 terminal- commitment), the DANE-TLSA-explained spoke is the per-publisher transport-layer deployment-phase progression structural- twin reference documenting the RFC 7672 per-publisher per-MX-host TLSA-RR DNSSEC-anchored certificate-pinning deployment-phase progression at the per- publisher transport-confidentiality commitment-escalation boundary. The PER- PUBLISHER-DMARC-FIVE-PHASE-VS-PER-PUBLISHER- DANE-TLSA-DEPLOYMENT-PHASE cross-reference establishes FOUR structurally-distinct per-publisher phase-coordination dimensions: (i) per-publisher Phase 0 (DMARC publication-baseline) AS STRUCTURAL PARALLEL TO per-publisher DANE Phase 0 (per-MX-host DNSSEC-zone-signing baseline) — both per-publisher commitment-escalation progressions require a per-publisher publication-baseline pre-condition step before per-publisher observability emission starts — the per-publisher DMARC record-publication pre-condition mirrors the per-publisher per-MX-host zone DNSSEC- signing pre-condition; both per-publisher operational disciplines require per- publisher publication-infrastructure validation before progression to per- publisher observability emission; the DANE- TLSA-explained spoke documents the per- publisher per-MX-host DNSSEC-publication baseline whose structural-twin IS the per- publisher DMARC-publication baseline THIS page documents the rollout-phase progression of; (ii) per-publisher Phase 1 (DMARC p=none observability) AS STRUCTURAL PARALLEL TO per-publisher DANE Phase 1 (per-MX-host TLSA-RR publish- monitor mode) — both per-publisher per- receiver-organization observability streams feed per-publisher pre-enforcement operational diagnostics — the per- publisher Phase 1 per-receiver per-day rua-aggregate observability stream mirrors the per-publisher Phase 1 per-receiver-MTA per-day TLS-RPT JSON-aggregate observability stream; both per-publisher observability emissions feed the per-publisher pre- enforcement operational-diagnostics baseline-distribution computation; the DANE- TLSA-explained spoke documents the per- publisher per-MX-host TLS-RPT-coupled Phase 1 observability discipline whose structural-twin IS the per-publisher Phase 1 per-receiver rua-aggregate discipline THIS page documents; (iii) per-publisher Phase 2-3 (DMARC p=quarantine pct=ramp + 100) AS STRUCTURAL PARALLEL TO per-publisher DANE Phase 2 (per-MX-host TLSA-RR enforce-with-fallback) — both per- publisher progressive-enforcement phases require per-publisher per-receiver- organization-cohort progressive-coverage- rollout management — the per- publisher Phase 2 pct=-ramp progressive-coverage-rollout management mirrors the per-publisher DANE Phase 2 per-MX-host pattern-by-pattern progressive- enforcement-coverage rollout; both per- publisher operational disciplines require per-receiver per-day enforcement-coverage- rate monitoring; the DANE-TLSA-explained spoke documents the per-publisher per-MX- host progressive-enforcement-coverage rollout discipline whose structural-twin IS the per-publisher Phase 2-3 DMARC pct=-ramp discipline THIS page documents; (iv) per-publisher Phase 4-5 (DMARC p=reject; pct=- ramp + 100 terminal-commitment) AS STRUCTURAL PARALLEL TO per-publisher DANE Phase 3 (per-MX-host TLSA-RR enforce- strict terminal-commitment) — both per- publisher operational terminal-state commitments represent per-publisher hard- enforcement-mode bindings the per-publisher operations team commits to long-term operational integrity — the per- publisher DMARC p=reject; pct=100 terminal-state commitment mirrors the per- publisher DANE per-MX-host TLSA-RR enforce- strict terminal-commitment; both per- publisher hard-enforcement commitments bind the per-publisher per-receiver- organization delivery-quality lifecycle through per-publisher publication- infrastructure rotation-cadence operational discipline; the DANE-TLSA-explained spoke documents the per-publisher per-MX-host TLSA-RR enforce-strict terminal-commitment discipline whose structural-twin IS the per-publisher Phase 5 DMARC p=reject; pct=100 terminal-commitment THIS page documents the rollout-phase progression of. Read the DANE-TLSA- explained spoke alongside this DMARC policy-rollout reference whenever the operator scopes a per-publisher message- AND-transport-layer-coordinated five-phase deployment plan — the per-publisher per-MX- host DANE-TLSA-RR DNSSEC-anchored deployment- phase progression IS the canonical transport-layer structural-twin of the per-publisher five-phase DMARC enforcement- mode-progression THIS page documents the operational discipline of, and per-publisher message-AND-transport-layer cross-protocol phase-coordination is the per-publisher operational-discipline pattern whose per-phase coordination is the per-publisher cross-protocol deployment-readiness pre- condition for advancement to the next per-publisher commitment-escalation boundary.
• DKIM failures explained — the PER-PHASE-RAMP-ADVANCEMENT-GATING EVIDENCE companion to this DMARC policy-rollout playbook. Where THIS page documents the five-phase enforcement-mode-progression operational discipline (Phase 1 baseline RUA observation at p=none, Phase 2 quarantine pct=10 ramp-entry, Phase 3 quarantine pct=100, Phase 4 reject pct=10, Phase 5 reject pct=100), the DKIM-failures-explained spoke documents the four-class DKIM verdict-failure taxonomy (bodyhash-mismatch, signature-mismatch, permerror, temperror) the operator MUST diagnose down to zero before any per-phase ramp-advancement gate clears. Read THIS page when ARCHITECTING the per-phase ramp cadence; read the DKIM-failures spoke when DIAGNOSING the per-class DKIM-failure rows in the Phase 1 RUA stream that BLOCK Phase 2 ramp-entry until each failure class is attributed to its root cause and remediated.
• SPF DNS record syntax — the PER-PUBLISHER-PER-DOMAIN-SPF- TXT-RR-BYTE-GRAMMAR-PUBLICATION- DISCIPLINE-AS-LOAD-BEARING-PRECONDITION- OF-PER-PUBLISHER-PER-DOMAIN-DMARC- RAMP-STEP-TIGHTENING companion documenting the per-publisher per- domain SPF TXT-RR byte-grammar publication discipline whose per-record per-token byte-correctness IS the load-bearing Phase 1 pre- deployment SPF-authentication-leg- health green-state baseline that EVERY DMARC-ramp-step tightening commit on the five-phase enforcement- mode progression THIS page documents the operational discipline of structurally depends on. Where THIS page documents the per-publisher per- domain DMARC five-phase enforcement- mode progression discipline (Phase 1 p=none monitoring; Phase 2 p=quarantine; pct=-ramp gradual subset enforcement; Phase 3 p=quarantine; pct=100 full quarantine; Phase 4 p=reject; pct=-ramp; Phase 5 p=reject; pct=100 terminal-enforcement state), the SPF-DNS-syntax spoke is the STRUCTURALLY-PAIRED LOAD-BEARING per-publisher per-domain SPF- authentication-leg-health green-state baseline publication discipline at four per-SPF-DNS-syntax-publication- discipline-to-per-DMARC-policy-ramp- step-coupling dimensions: (i) per-publisher-per-domain-SPF- TXT-RR-byte-grammar-defects-collapse- SPF-aligned-pass-rate-floor-below- Phase-2-ramp-entry-gate — per-publisher per-domain SPF TXT-RR byte-grammar publication discipline defects (per-record per-mechanism- token byte-corruption, multiple v=spf1 TXT-RR siblings at the same FQDN violating RFC 7208 §3.2 cardinality, per-record TXT-RR byte-length budget exhaustion, version-prefix-byte sequence defects) produce per-row auth_results.spf.result=permerror verdicts in the Phase 1 monitoring- window RUA stream; per-publisher per- domain SPF-aligned-pass-rate floor collapses below the Phase 2 ramp- entry gate; Phase 2 p=quarantine; pct=-ramp commit MUST NOT proceed until the per-publisher per-domain SPF TXT-RR byte-grammar publication discipline is remediated AND the per-publisher SPF-aligned-pass-rate floor recovers across the Phase 1 monitoring window; (ii) per-publisher- per-domain-SPF-mechanism-choice-as- load-bearing-Phase-1-sender- catalogue-completeness-gate — per-publisher per-domain SPF mechanism-choice authoring discipline (the per-record per-mechanism authoring choice among include: / ip4: / ip6: / a / mx tokens enumerating the per-publisher per-domain authorised sending-IP set) IS THE per-publisher per-domain sender-catalogue-completeness gate at the Phase 1 monitoring window; per- publisher per-domain SPF mechanism- choice incompleteness (missing per-ESP include: statement for an authorised marketing / transactional sender, missing per-region ip4: / ip6: ranges for an authorised hosted-sender IP block) surfaces in the Phase 1 RUA stream as per-row auth_results.spf.result=fail verdicts on per-source-IP rows the per-publisher CANNOT distinguish from unauthorised-third-party / spoofer per-source-IP rows; Phase 2 p=quarantine; pct=-ramp commit MUST NOT proceed until the per-publisher per-domain SPF mechanism-choice authoring is complete and per-row auth_results.spf.result=fail verdicts have been triaged into authorised-but-unaligned vs unauthorised-sender categories; (iii) per-publisher-per-domain-SPF- end-of-record-qualifier-prefix-byte- choice-as-load-bearing-Phase-3-pct=100- quarantine-vs-Phase-4-reject-ramp- coordination-axis — per- publisher per-domain SPF end-of- record qualifier-prefix-byte choice (the ~all SoftFail vs -all Fail vs ?all Neutral end-of- record terminal qualifier) directly interacts with the per-publisher per- domain DMARC enforcement-mode progression at Phase 3 p=quarantine; pct=100 and Phase 4 p=reject; pct= boundaries; per-publisher per-domain SPF ~all SoftFail- terminal qualifier paired with p=quarantine; pct=100 produces per-receiver per-message delivery-placement-policy verdict DEFERRING to receiver-side spam- filter scoring; per-publisher per- domain SPF -all Fail- terminal qualifier paired with p=reject produces per- receiver per-message hard-bounce verdict on EVERY DMARC-honouring receiver; per-publisher per-domain SPF end-of-record qualifier-prefix- byte choice MUST be coordinated with the per-publisher per-domain DMARC ramp-step progression at the Phase 3 → Phase 4 boundary; (iv) per- publisher-per-domain-SPF-RFC-7208- §4.6.4-10-DNS-lookup-budget-vs-per- publisher-per-domain-DMARC-ramp- step-tightening-as-coupled-per- publisher-per-domain-SPF-budget- compliance-gate — per- publisher per-domain SPF mechanism- choice authoring discipline ALSO determines per-publisher per-domain cumulative DNS-lookup cost toward the RFC 7208 §4.6.4 ten-lookup ceiling; per-publisher per-domain SPF lookup-budget overrun at any per- receiver-side per-message SPF evaluation event produces per-message spf=permerror verdict that collapses per-publisher per- domain SPF-aligned-pass-rate floor AND blocks Phase 2 / Phase 3 / Phase 4 ramp-step tightening commits on the five-phase progression. Read THIS page when SEQUENCING the five-phase per-publisher per-domain DMARC enforcement-mode progression discipline; read the SPF-DNS-syntax spoke when AUTHORING per-publisher per-domain SPF TXT-RR byte-grammar publication discipline as the STRUCTURALLY-PAIRED LOAD-BEARING Phase 1 SPF-authentication-leg-health green-state baseline publication discipline whose per-record per-token byte-correctness IS the precondition each per-publisher per-domain DMARC ramp-step tightening commit on the five-phase progression THIS page documents structurally depends on.
• DKIM selectors explained (RFC 6376 §3.1) — the PER-PUBLISHER-PER-SELECTOR-DKIM-KEY- IDENTIFIER-SCHEME companion to this DMARC five-phase policy-rollout reference. Where THIS page documents the per-publisher per- domain DMARC enforcement-progression discipline — Phase 1 pre-deployment DNS hygiene + per-publisher authentication-leg green-state baseline → Phase 2 p=none RUA observation → Phase 3 p=quarantine pct=<N> progressive ramp → Phase 4 p=quarantine pct=100 → Phase 5 p=reject — gated by per-publisher per-domain authentication- leg-health green-state baselines, the DKIM-selectors-explained spoke is the per-publisher per-selector key-identifier- scheme reference documenting the RFC 6376 §3.1 selector._domainkey.<domain> naming convention whose per-selector public-key TXT-RR publication discipline IS the per-Phase-1 DKIM-authentication-leg- health green-state baseline each subsequent DMARC ramp step structurally depends on. The DMARC-POLICY-ROLLOUT-VS-DKIM-SELECTOR- IDENTIFIER-SCHEME cross-reference establishes FOUR structurally-distinct per-publisher per-domain per-selector DKIM-key-publication coupling dimensions: (i) per-publisher per-selector primary-key publication discipline as Phase 1 precondition — the per-publisher MUST publish at least one per-selector public-key TXT-RR at the canonical <selector>._domainkey.<domain> location BEFORE any per-message DKIM-Signature header can produce a receiver-side verification verdict; (ii) per-publisher per-selector rotation-secondary-key publication discipline as Phase 3 precondition — per-publisher key-rotation cadence requires a per-selector secondary key-pair published at a sibling <rotation-selector>._domainkey.<domain> location to enable zero-downtime key rotation BEFORE Phase 3 ramp tightening amplifies per-receiver per-message DKIM failure consequences; (iii) per- publisher per-selector key-revocation marker publication discipline as Phase 4 precondition — deprecated per- selectors MUST be marked via p= empty-value revocation marker (not deleted outright) to allow per-receiver in-flight per-message signature verification against the deprecated selector to fail cleanly with dkim=permerror+ revoked rather than dkim=temperror + ambiguous NXDOMAIN; (iv) per-third-party- sender per-vendor selector inventory discipline as Phase 5 precondition — each per-third-party-sender's per- vendor selector (Mailchimp k1._domainkey, SendGrid s1._domainkey / s2._domainkey, SparkPost scph0<N>._domainkey, per-Workspace-tenant google._domainkey, per-M365- tenant selector1._domainkey / selector2._domainkey) MUST be inventoried and continuously verified as publishing a parseable public-key TXT BEFORE Phase 5 p=reject commits the per-publisher per-domain to receiver-side SMTP-time 550 rejection of DKIM-misaligned mail. Read THIS page when AUTHORING the per-publisher per-domain DMARC five-phase ramp progression; read the DKIM-selectors-explained spoke when AUDITING the per-publisher per-selector DKIM-key publication discipline that gates each ramp-step tightening commit.
• SPF mechanisms explained (RFC 7208 §5) — the PER-PUBLISHER-DMARC-FIVE-PHASE- ENFORCEMENT-PROGRESSION-PRE-CONDITIONED- ON-STABLE-SPF-MECHANISM-EVALUATION companion to this DMARC policy rollout playbook. Where THIS page documents the per-publisher per-domain five-phase ramp progression (p=none observation -> p=quarantine pct=<N> partial enforcement -> p=quarantine pct=100 -> p=reject pct=<N> -> p=reject pct=100 terminal enforcement), the SPF- mechanisms-explained spoke is the per- mechanism left-to-right evaluation-order REFERENCE documenting the RFC 7208 §5 mechanism grammar (ip4, ip6, a, mx, ptr, exists, include, all) plus the per-qualifier semantics (+ pass, - hardfail, ~ softfail, ? neutral) whose receiver-side evaluation discipline yields the SPF result that feeds into the DMARC composition. The DMARC-POLICY- ROLLOUT-VS-SPF-MECHANISM cross-reference establishes the per-publisher per- mechanism evaluation-stability discipline that each ramp-phase tightening commit structurally requires: (i) Phase 0 permerror-clearance prerequisite — every spf=permerror at Phase 1 observation (overrun 10-lookup ceiling, malformed mechanism syntax, recursive include: loop) cascades into dmarc=fail at p=reject on EVERY DMARC- honouring receiver, producing a per- publisher per-message hard-bounce cascade at Phase 5 terminal enforcement; (ii) Phase 0 temperror-clearance prerequisite — every spf=temperror at the SPF leg (timeout against an authoritative nameserver for a nested include: target) produces a non-deterministic per-publisher per- message verdict that flips between dmarc=pass and dmarc=fail across retries; operators must clear the per-publisher temperror baseline at Phase 1 BEFORE the ramp commits to pct= sampling because the non-deterministic verdict undermines the aggregate-report-based ramp-decision cadence; (iii) Phase 1 per- qualifier discipline — every publisher must commit to either -all (hardfail terminal mechanism) or ~all (softfail terminal mechanism) BEFORE Phase 5 p=reject because per-DMARC-receiver-disposition the ~all softfail yields spf=softfail which under p=reject the receiver propagates to dmarc=fail + 550 SMTP-time rejection identically to -all hardfail — but the Phase 3 monitoring window's interpretation of legitimate-mail verdict differs materially between the two terminal-qualifier choices. Read THIS page when AUTHORING the per- publisher per-domain DMARC five-phase ramp progression; read the SPF- mechanisms-explained spoke when AUDITING the per-publisher per-mechanism evaluation-stability baseline that each ramp-step tightening commit structurally requires BEFORE the next phase tightens.
• DKIM cryptography basics — the per-publisher per-selector cryptographic key-strength as load-bearing Phase-1 publisher-side cryptographic-discipline prerequisite for safe Phase-3 / Phase-4 enforcement-ramp advancement companion to this five-phase DMARC policy-rollout progression reference. Where THIS page documents the canonical five-phase DMARC ramp (Phase 1 Discovery at p=none, Phase 2 Triage of misaligned legitimate senders, Phase 3 p=quarantine + pct= sampling, Phase 4 p=quarantine; pct=100, Phase 5 p=reject), the DKIM cryptography-basics spoke documents the per-publisher per-selector cryptographic primitive whose Phase-1 baseline-correctness is the LOAD-BEARING upstream cryptographic- publication prerequisite every Phase-2 triage backlog and every Phase-3 / Phase-4 ramp-step tightening commit STRUCTURALLY DEPENDS on for the per-receiver dkim-aligned- pass coverage rate to be high enough that the per-domain DMARC-pass-rate aggregate baseline supports safe enforcement advancement. Four DKIM-CRYPTOGRAPHIC- DISCIPLINE-VS-DMARC-RAMP-PHASE cross- correlation axes the cryptography-basics spoke documents: (i) per-publisher per-selector RSA-2048 minimum key-length baseline STRUCTURALLY GATES Phase-3 / Phase-4 enforcement-ramp commitment — a per-publisher per-selector sub-1024-bit RSA key produces per-receiver verifier-side dkim=neutral or dkim=permerror verdicts that cumulate into a per-domain DKIM-aligned-pass coverage-rate floor below the Phase-3 ramp-advancement gate (typical 95-99 percent coverage requirement); operators MUST rotate every per-selector RSA-1024 key to RSA-2048 BEFORE Phase 3 (p=quarantine) crosses the per-receiver dispositional- enforcement boundary; (ii) per- publisher per-selector public-key DNS- publication correctness (k=rsa, p= base64-encoded DER, trailing zero-byte preservation, no per-line truncation) STRUCTURALLY GATES per-message DKIM-signature verifiability across receivers — a per-selector TXT-RR publication-discipline regression produces per-receiver verifier-side dkim=permerror verdicts that propagate to per-row policy_evaluated.dkim=fail AND per-domain DMARC-aligned-pass coverage-rate cliff at Phase 1 baseline; operators MUST clear every per-selector publication- regression BEFORE Phase 2 triage commits because the per-permerror baseline is publisher-side, not legitimate-sender-side; (iii) per-publisher per-selector cryptographic-algorithm choice (rsa-sha256 vs ed25519-sha256) STRUCTURALLY DETERMINES the per-receiver verifier-coverage baseline at Phase-3 / Phase-4 boundary — Ed25519-sha256 adoption per RFC 8463 is unevenly supported by 2020s-vintage verifiers, producing per-receiver per-day dkim=neutral verdicts at receivers that have not upgraded to Ed25519-aware verifiers; operators MUST publish dual-algorithm signatures (RSA-2048 + Ed25519) per selector pair BEFORE Phase 4 (p=reject) commits because the per-receiver verifier-coverage divergence cannot be rolled back from p=reject; (iv) per-publisher per-selector key-rotation overlap-window discipline STRUCTURALLY GATES Phase-3 / Phase-4 ramp-rollback safety — a per- publisher per-selector key-rotation without an overlap-window long enough to cover the per-receiver verifier-side per-selector-cache TTL produces a per- day per-selector dkim-pass coverage-rate cliff that operators must distinguish from a legitimate per-sender per-day regression; a per-publisher per-selector rotation-overlap-window discipline of less than 14 days produces a per-day dkim-fail-cliff at Phase 3 (p=quarantine) that triggers the per-receiver quarantine-rate alarm AND requires the operator to roll the per-domain DMARC policy back to p=none while the per- selector cache flushes. Read THIS page when AUTHORING the per-publisher per- domain DMARC five-phase ramp progression; read the DKIM cryptography-basics spoke when AUDITING the per-publisher per- selector cryptographic-publication baseline whose Phase-1 correctness gates every subsequent ramp-phase tightening commit and whose per-rotation overlap- window discipline gates every Phase-3 / Phase-4 ramp-rollback safety contract.
• Email security glossary — the cluster-wide threat-and-defense vocabulary reference whose ~80 per-term DefinedTerm definitions name the SOC / SIEM / SOAR / runbook operations-layer vocabulary the per-publisher per-domain DMARC five-phase ramp progression THIS page documents structurally feeds at the operations-layer ingest boundary. Where THIS page documents the per-publisher per- domain DMARC five-phase enforcement-mode progression discipline (Phase 1 pre- deployment authentication-leg green-state baseline, Phase 2 p=none rua=-monitoring telemetry observation, Phase 3 p=quarantine pct= graduated tightening, Phase 4 p=reject pct=100 enforcement-floor commit, Phase 5 steady-state SOC review cadence), the email-security-glossary spoke is the OPERATIONS-LAYER-VOCABULARY reference documenting the per-receiver SOC / SIEM / SOAR / runbook operations- layer playbook vocabulary the per-message DMARC verdict stream THIS page's ramp progression produces feeds into. Four RAMP-PROGRESSION-TO-OPERATIONS-LAYER- VOCABULARY coupling dimensions the security-glossary spoke documents: (i) SOC / SIEM / SOAR ingest vocabulary as per-receiver operations- layer consumer of the per-publisher per- domain DMARC verdict stream the ramp progression produces — the Security Operations Center (SOC), Security Information and Event Management (SIEM), and Security Orchestration Automation and Response (SOAR) vocabulary the security glossary catalogues is the per-receiver operations-layer ingest catalogue the per- publisher per-domain DMARC verdict stream THIS page's ramp progression produces feeds into via the per-day aggregate- report XML ingest; (ii) NIST SP 800-61 incident- response lifecycle vocabulary as operations-layer playbook for the per- message DMARC-fail verdict triage — the NIST SP 800-61 IR lifecycle vocabulary the security glossary catalogues (Preparation, Detection & Analysis, Containment / Eradication / Recovery, Post-Incident Activity, IoCs, dwell time, MTTD, MTTR) is the per-receiver per-incident operations-layer playbook the per- publisher per-domain DMARC-fail verdict stream the ramp progression THIS page documents structurally feeds at the per-incident SOC triage boundary; (iii) MITRE ATT&CK Initial- Access / Phishing-technique vocabulary as per-portfolio threat-modelling framework the ramp progression participates in — the MITRE ATT&CK / MITRE D3FEND / kill-chain / Diamond Model / Pyramid of Pain / TTP vocabulary the security glossary catalogues (T1566 Phishing, T1566.001 Spearphishing Attachment, T1566.002 Spearphishing Link, T1566.003 Spearphishing via Service) is the per- portfolio threat-modelling framework the per-publisher per-domain DMARC ramp- progression THIS page documents structurally participates in at the Initial-Access-defense boundary; (iv) runbook and playbook vocabulary as per-publisher per-phase ramp-rollback safety contract catalogue — the runbook / playbook / threat-hunting vocabulary the security glossary catalogues is the per- publisher per-phase ramp-rollback safety contract catalogue every per-phase tightening commit (Phase 2 → pct=10 → pct=25 → pct=50 → pct=100 → p=reject) the ramp progression THIS page documents structurally requires for the operator- side rollback-readiness discipline. Read THIS page when AUTHORING the per- publisher per-domain DMARC five-phase ramp progression; read the email- security-glossary spoke when CO- AUTHORING the per-receiver operations- layer playbook vocabulary whose per- incident SOC / SIEM / SOAR / runbook discipline the per-publisher per-domain DMARC verdict stream the ramp progression THIS page documents feeds into at the per-receiver operations- layer ingest boundary.
• DKIM replay attacks — the per-publisher per-domain POST- ENFORCEMENT-RESIDUAL-THREAT-CLASS companion to this five-phase DMARC ramp-progression reference. Where THIS page documents the per- publisher per-domain DMARC ramp progression (p=none → p=quarantine → p=reject) and the pct= percentage ramp + sp= / np= subdomain coverage that culminates in the per-publisher per-domain p=reject enforcement-stage commitment, the DKIM-replay-attacks spoke documents the specific per-message attack class that REMAINS UNCOVERED even after the per-publisher per-domain ramp THIS page documents successfully reaches the per- publisher per-domain p=reject terminal enforcement state: a sophisticated attacker captures a legitimately DKIM-signed message from a per-publisher per-domain sender and re-broadcasts the byte-for-byte signed message to an attacker-chosen recipient set; because the per-message DKIM signature still cryptographically verifies and the original From: still aligns with the original d=, the per-message DMARC verdict is pass — the per-publisher per-domain p=reject commitment the ramp progression THIS page documents culminates in applies NO protective enforcement to this per-message attack class. Three CROSS-RAMP-PHASE per-publisher per- domain residual-coverage-gap dimensions the DKIM-replay-attacks spoke documents the per- publisher per-domain operator MUST plan compensating defences for at the per-publisher per-domain ramp authoring tier: (i) per- publisher per-selector DKIM-key-rotation- cadence selection at the parallel-to-DMARC- ramp authoring tier the per-publisher per- domain DMARC TXT publication does NOT participate in — the per-publisher per-selector selector._domainkey.<d> TXT-RR rotation cadence (documented in help_dkim_key_rotation.php) bounds the per-publisher per-selector replay window to the per-selector active-key lifetime; the per-publisher per-domain DMARC ramp progression THIS page documents at _dmarc.<d> provides NO per-publisher per-domain authoring lever for the per-publisher per-selector replay-window- bounding discipline and the per-publisher per- domain operator MUST select the per-publisher per-selector DKIM-key-rotation cadence (weekly / monthly / quarterly) IN PARALLEL with the per-publisher per-domain DMARC ramp progression; (ii) per-receiver per- message replay-cache defence as the per- receiver out-of-band mitigation at the per- receiver verdict-evaluation boundary the per-publisher per-domain DMARC TXT publication cannot reach — the per-receiver per- message replay-cache discipline (the per- receiver tracks per-message Message-ID + signing-domain + body-hash tuples and refuses second- delivery) is a per-receiver per-message defence at the per-receiver verdict- evaluation tier; the per-publisher per- domain DMARC ramp progression THIS page documents provides NO per-publisher per- domain authoring lever for the per-receiver per-message replay-cache discipline and the per-publisher per-domain operator MUST depend on per-receiver implementation coverage at the per-receiver verdict- evaluation tier; (iii) per-publisher per-message RFC 6376bis body-length- restricted-replay future-protocol-extension adoption planning at the per-message DKIM- Signature header byte-grammar boundary the per-publisher per-domain DMARC TXT publication does NOT participate in — the per-message recipient-count tag the IETF DKIM-bis drafts propose would commit the per-message replay-defence to the per- message DKIM-Signature header byte-grammar (a per-message per-signer authoring-tier mitigation); the per-publisher per-domain DMARC ramp progression THIS page documents provides NO per-publisher per-domain authoring lever for the per-message recipient-count-restricted-replay defence class and the per-publisher per-domain operator MUST plan the per-publisher per- message DKIM-bis adoption roadmap in parallel with the per-publisher per-domain DMARC ramp progression. Read the DKIM- replay-attacks spoke ALONGSIDE this DMARC rollout reference whenever the per- publisher per-domain operator reaches the per-publisher per-domain p=reject terminal ramp phase and AUDITS the per-publisher per-domain post-enforcement residual-threat coverage — the per-publisher per-domain DMARC ramp progression THIS page documents is the per-publisher per-domain DMARC AUTHORING primitive against the per-publisher per- domain unauthenticated-forgery attack class; the per-publisher per-domain DKIM- replay-attacks spoke is the per-publisher per-message RESIDUAL-THREAT-CLASS-PLANNING primitive that closes the per-publisher per-domain post-enforcement coverage-gap at the per-publisher per-domain compensating-defence authoring tier.
• DKIM key rotation — the per-publisher per-selector DKIM-key-rotation-cadence as load-bearing Phase-1 / Phase-2 / Phase-3 / Phase-4 / Phase-5 DKIM-authentication-leg-continuity prerequisite companion to this five-phase DMARC policy-rollout progression reference. Where THIS page documents the canonical per-publisher per-domain DMARC ramp at _dmarc.<d> (p=none → p=quarantine → p=reject), the DKIM-key-rotation spoke documents the per- publisher per-selector rotation cadence at selector._domainkey.<d> whose dual-selector overlap-window publication-discipline IS the per- publisher per-selector DKIM-authentication- leg-continuity invariant every ramp-step tightening commit structurally depends on for the per-receiver per-day per-selector dkim-aligned-pass-rate floor to remain above the per-phase ramp-advancement threshold across rotation cutovers. Four per-rotation-cutover-vs-ramp-phase coupling axes the key-rotation spoke documents: (i) per-publisher per- selector dual-selector parallel-publication overlap window STRUCTURALLY GATES Phase-3 / Phase-4 enforcement-ramp advancement during the rotation cutover — a rotation that retires the old selector before the new selector's TXT-RR has propagated to per-recursive-resolver cache- coherence drops dkim-aligned-pass-rate below the per-phase ramp floor; (ii) per-publisher per-selector rotation cadence bounds the per-publisher per- message replay-window the sibling DKIM- replay-attacks spoke documents above — the rotation cadence is the per- publisher per-selector active-key lifetime that caps how long a captured DKIM-signed per-message remains replayable past its original send-time; (iii) per- publisher per-selector retired-key TTL- bounded de-publication preserves per- receiver per-day RUA dkim-aligned-pass-rate attribution accuracy across rotation cutovers — premature retired- key DNS removal before the per-receiver per-day RUA aggregation cycle completes creates per-receiver per-day RUA dkim= permerror attribution noise that masks per-phase ramp-readiness signal; (iv) per-publisher per-selector rotation event coordination with per-publisher per- domain DMARC ramp-step tightening commits prevents per-receiver per-message dual- risk events — per-publisher per-domain operators MUST schedule per- publisher per-selector rotation cutovers OUTSIDE per-publisher per-domain Phase 3 / Phase 4 ramp-advancement windows so per- receiver per-message dkim-verdict-drift from the rotation cutover cannot be misattributed to the ramp-step tightening commit as a per-receiver per-message false-quarantine / false-reject regression.
• MX records explained
• SPF permerror vs temperror
• Email authentication ecosystem — the PER-PUBLISHER-PER-DOMAIN-DMARC- POLICY-TIER-RAMP-PROGRESSION-AS-LOAD- BEARING-COMPOSITE-ENFORCEMENT-MODE- PROGRESSION-LEG-OF-THE-CROSS-PROTOCOL- EMAIL-AUTHENTICATION-ECOSYSTEM companion to this DMARC policy-mode ramp progression reference. Where THIS page documents the per-publisher per-domain DMARC five-phase ramp progression discipline (p=none monitoring → p=quarantine pct=1..100 partial-quarantine → p=quarantine full → p=reject pct=1..100 partial-reject → p=reject full enforcement per RFC 7489 §6.3 + §6.6 + §6.6.3) plus the per- publisher per-domain operator-side per- phase readiness-criteria publication- discipline, the email-authentication- ecosystem spoke is the CROSS-PROTOCOL OVERVIEW reference whose per-publisher per- domain SPF + DKIM + DMARC + ARC + BIMI publication-portfolio THIS DMARC policy- mode ramp page is the LOAD-BEARING composite-enforcement-mode-progression-leg of at FOUR per-publisher per-domain DMARC- policy-ramp-vs-cross-protocol-ecosystem coupling dimensions: (i) per- publisher per-domain DMARC policy-tier ramp AS load-bearing downstream consumer of per-publisher per-domain SPF + DKIM authentication-leg-aligned-pass-rate- floor upstream preservation — per-publisher per-domain DMARC policy-tier ramp THIS page documents the five-phase progression of materially depends on per-publisher per-domain composite SPF + DKIM authentication-leg- aligned-pass-rate-floor preservation upstream BEFORE per-publisher per-domain p=reject terminal-tier authoring; the email-authentication- ecosystem reference documents the cross- protocol publication-portfolio of which THIS DMARC ramp page is the downstream composite-enforcement-mode-progression- leg; (ii) per-publisher per- domain DMARC policy-tier ramp AS load- bearing upstream gating per-publisher per- domain BIMI Indicator-record brand- indicator-rendering eligibility per RFC 9716 §4.1 enforcement-mode prerequisite cascade — per-publisher per-domain DMARC p=quarantine or p=reject enforcement-mode publication-decision IS the load-bearing upstream application-layer authentication- policy precondition gating per-publisher per-domain BIMI Indicator-record brand- indicator-rendering eligibility downstream — THIS DMARC five-phase ramp page documents the ramp-progression discipline the email-authentication-ecosystem reference documents the cross-protocol publication-portfolio of; (iii) per-publisher per-domain DMARC policy- tier ramp publication-discipline cadence coordination with per-publisher per- domain composite SPF apex-TXT-RR publication-cadence + per-publisher per- selector DKIM TXT-RR publication-cadence + per-publisher per-MX-host MTA-STS policy-cadence cross-protocol coordination — per- publisher per-domain DMARC ramp progression THIS page documents the five-phase progression of IS the load-bearing per- publisher per-domain operator-side cross- protocol publication-cadence-coordination downstream-leg whose per-publisher per- domain ramp-progression readiness depends on per-publisher per-domain composite DNS-publication-discipline-propagation- tail completion across SPF + DKIM + MX + MTA-STS publication-portfolio the email- authentication-ecosystem reference documents the cross-protocol publication- portfolio of; (iv) per-publisher per-domain DMARC RUA aggregate-XML report per-row attribution evidence-stream AS load-bearing per-publisher per-domain operator-actionable per-phase readiness- criteria evidence-stream driving per- publisher per-domain DMARC ramp- progression decision-pipeline — per-publisher per-domain DMARC RUA aggregate-XML report per RFC 7489 §7.2 per-row policy_evaluated/spf + policy_evaluated/dkim attribution evidence-stream IS the load- bearing per-publisher per-domain operator- actionable evidence-channel through which the per-publisher per-domain DMARC ramp progression THIS page documents progresses the five-phase ramp; the email- authentication-ecosystem reference documents the cross-protocol observability- pipeline of which the DMARC ramp progression depends on as upstream evidence-stream. Read the email-authentication-ecosystem spoke WITH this DMARC policy-mode ramp progression reference when AUTHORING per- publisher per-domain composite cross- protocol authentication-and-policy publication-discipline portfolio at the per-publisher per-domain composite cross- protocol-email-authentication-ecosystem- and-DMARC-policy-ramp coordination boundary.
• 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.

12. Plan your DMARC rollout now

DMARC Analyzer ingests aggregate (rua) reports via the includes/DmarcParser.php pipeline and surfaces alignment outcomes per sending source in the dashboard — the same view you will rely on through every phase of the rollout. The Domain Security Checker (domain_checker.php) performs live DNS lookups so you can confirm the currently-published p= / sp= / np= / pct= values against the intended rollout stage. The Email Header Analyzer (header_analyzer.php) decodes individual messages when users report missed mail during the quarantine or reject phases.

Check my current DMARC record Sign up — Free plan