DMARC Analyzer

TL;DR

• Four phases: Discovery (p=none) -> Triage (alignment fixing) -> Quarantine (p=quarantine) -> Enforcement (p=reject). Defined operationally on top of RFC 7489.
• Three prerequisites: DNS edit access, complete sender inventory, monitoring mailbox for aggregate (rua) reports.
• Typical duration: 3 to 6 months end-to-end. The bottleneck is Phase 2 (fixing alignment for every legitimate sender) and the confidence wait at Phase 3 quarantine.
• Single most common mistake: jumping from p=none straight to p=reject. Always quarantine first - the spam folder is recoverable; SMTP reject is not.
• This page is the operator checklist; the policy rollout deep dive explains the underlying mechanisms (three policy states, pct= sampling, sp= / np= subdomain timing).
• Rollback: lower p= one stage; keep DNS TTL at 300-3600 seconds during rollout for fast rollback.

1. Overview: how this checklist fits into your DMARC project

Deploying DMARC is a 3-to-6-month operational project, not a one-off DNS edit. The technical surface is small (publish a TXT record at _dmarc.example.com) but the organisational surface is large (every system that sends mail using your domain in the From: header must be inventoried and aligned before you can safely enforce). This checklist is the per-phase operator quick reference that complements the deeper rollout guide.

The four phases follow the canonical RFC 7489 p= progression but are operationally named after the work being done in each phase, not the policy value alone:

• Phase 1 - Discovery: publish p=none (often called "monitoring mode" - no enforcement, full reporting) with rua=mailto: and read aggregate reports for at least one full traffic cycle. Goal: inventory every legitimate sender.
• Phase 2 - Triage: for each discovered sender, fix alignment - turn on DKIM in the ESP control panel, clean up SPF includes, delegate third-party DMARC, consolidate where possible. Goal: every legitimate sender produces DMARC-aligned mail.
• Phase 3 - Quarantine: advance to p=quarantine (optionally with pct= sampling). Goal: confirm the spam folder is the worst outcome for any remaining edge cases.
• Phase 4 - Enforcement: advance to p=reject. Goal: refuse spoofed mail at the SMTP RCPT TO stage.

Each phase has explicit entry conditions, action items, and exit criteria documented below. Work through them in order. Do not skip phases.

2. Prerequisites checklist (before Phase 1)

Before you publish any DMARC record, confirm these three prerequisites. Missing any one will block the deployment partway through.

2.1 DNS edit access

• Verify you can publish a TXT record at _dmarc.example.com for the apex domain.
• Verify you can publish TXT records at sending subdomains (mail.example.com, marketing.example.com, etc.) if any subdomain-scoped policy is planned.
• Verify you can publish DKIM selector TXT records at the subdomains each ESP requires (Google Workspace, Microsoft 365, SendGrid, Mailgun, SES, Postmark all have different selector conventions; see the per-provider deployment guides).
• Lower the TTL on the _dmarc record to 300-3600 seconds for the duration of the rollout. Raise it back to 86400+ once you reach steady-state p=reject.

2.2 Complete sender inventory

Catalogue every system that sends mail using your domain in the From: header. Common categories operators miss:

• Production mail server (Postfix, Exchange, Sendmail, Exim, the MTA itself).
• Transactional ESP - SendGrid, Mailgun, Amazon SES, Postmark, SparkPost, Mandrill.
• Marketing automation - Mailchimp, HubSpot, Marketo, Salesforce Marketing Cloud, Pardot, Klaviyo, Constant Contact, ActiveCampaign.
• Helpdesk / CRM - Zendesk, Salesforce Service Cloud, Freshdesk, Intercom, Help Scout.
• Application notifications - GitHub, GitLab, Jira, Trello, Asana, Monday, Slack-to-email notifications, AWS CloudWatch alarms, PagerDuty.
• Monitoring + alerting - Datadog, New Relic, Grafana, Prometheus AlertManager, Opsgenie.
• Internal Linux cron jobs and Windows scheduled tasks - the easiest to miss because they rarely send daily.
• Partner integrations - shared mail relays, white-labelled SaaS that sends as your domain.

2.3 Monitoring mailbox for aggregate reports

• Create a dedicated mailbox - dmarc@example.com or dmarc-reports@example.com - to receive aggregate (rua) reports.
• Configure an automated parser - DMARC Analyzer (this site, free), Valimail, PowerDMARC, EasyDMARC, dmarcian, Cisco DMARC, or a self-hosted open-source parser like parsedmarc.
• Verify the parser ingests reports via IMAP or Microsoft Graph and aggregates per-source-IP and per-sender pass and fail metrics.
• Bookmark or pin the parser dashboard - you will read it weekly for the duration of the rollout.

3. Phase 1: Discovery (p=none)

Entry condition: prerequisites checklist complete.

Goal: inventory every legitimate sender that uses your domain in the From: header by reading aggregate reports.

3.1 Publish the initial DMARC record

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

• p=none requests no enforcement - receivers report but do not act on the result.
• rua= is the mailbox that receives aggregate (daily XML) reports. Mandatory.
• ruf= is the optional forensic (per-message) report mailbox. Few receivers send forensic reports, but the ones that do are valuable for diagnosis.
• fo=1 requests forensic reports for any DMARC-fail (rather than only SPF-and-DKIM both fail).
• adkim=r and aspf=r set relaxed alignment - the production default; switch to s for strict only after you understand which senders rely on relaxed.
• pct=100 is the default but make it explicit for clarity.
• ri=86400 requests daily aggregate reporting (the default; many receivers ignore this anyway).

3.2 Wait for at least one full traffic cycle

• Minimum 2 weeks - cover Monday through Sunday plus end-of-month batch jobs.
• Recommended 4 weeks - catch quarterly senders, monthly newsletters, and edge-case senders.
• Aggregate reports arrive 24-72 hours after the mail is sent; expect noise in the first 48 hours, signal stabilises after that.

3.3 Read the aggregate reports weekly

• Sort sources by mail volume - the biggest senders matter most.
• For each source IP, identify the d= domain in the DKIM-Signature and the envelope MAIL FROM domain - both must align with the From: header.
• Classify each source as: aligned (no action needed), misaligned but legitimate (queue for Phase 2), unknown legitimate (queue for Phase 2 investigation), forwarded (consider ARC), or attacker / spoofer (no action - DMARC rejection at p=reject will block it later).
• Build a sender registry - a spreadsheet with columns: source IP, organisation, what it sends, current alignment state, owner contact, Phase 2 action.

4. Phase 2: Triage (alignment fixing)

Entry condition: Phase 1 sender registry complete - every misaligned legitimate sender identified.

Goal: every legitimate sender produces DMARC-aligned mail.

4.1 SPF cleanup

• Audit the apex SPF record for unused include: mechanisms - every legacy SaaS that left the estate.
• Count the DNS lookup cost (RFC 7208 section 4.6.4 caps it at 10). If over budget, see the SPF lookup limit deep dive for remediation.
• Confirm each SPF-aligned source has an ip4, ip6, or include mechanism that authorises its sending IP.

4.2 DKIM enabling

• For each ESP and SaaS sender, follow the provider's DKIM activation procedure - usually a control-panel button that generates a key pair and gives you a CNAME or TXT record to publish.
• Verify the published selector resolves via dig TXT selector._domainkey.example.com and contains a valid public key.
• Send a test message and verify dkim=pass in the Authentication-Results header at a receiver (Gmail, Outlook, Yahoo).
• For DKIM key rotation guidance, see the DKIM key rotation deep dive.

4.3 Third-party DMARC delegation

• For senders that send as your domain but cannot align (rare modern ESPs, legacy partners), consider moving them to a subdomain (marketing.example.com, notifications.example.com) where a more permissive policy is acceptable.
• Some operators delegate the entire DMARC record management to a third-party SaaS (Valimail, PowerDMARC, EasyDMARC) by pointing _dmarc as a CNAME to their managed zone - useful for organisations without DNS edit access.

4.4 Re-verify with aggregate reports

• After each alignment fix, wait 48-72 hours for aggregate reports to confirm the source now produces DMARC-aligned mail.
• Update the sender registry: mark each source as aligned / still-misaligned / decommissioned.

5. Phase 3: Quarantine (p=quarantine)

Entry condition: sender registry shows 95%+ of legitimate mail volume aligned for at least 2 consecutive weeks.

Goal: confirm the spam folder is the worst outcome for any remaining edge cases.

5.1 Optionally start with pct= sampling

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

• pct=10 applies p=quarantine to 10% of failing mail and downgrades the rest to p=none behaviour.
• Ramp the value: 10 -> 25 -> 50 -> 100 over 4-8 weeks.
• Note: pct= is deprecated in the in-progress dmarcbis successor draft. Read the dmarcbis transition notes before depending on it for new long-term deployments.

5.2 Monitor for quarantine signals

• Watch the support inbox for "did not receive the email" reports - usually password resets, receipts, or partner notifications routed to spam.
• Check aggregate reports daily for new misaligned sources - a previously-aligned sender may have rotated keys without updating the published selector.
• Confirm the user-visible behaviour at major receivers (Gmail, Outlook, Yahoo) by sending test messages from each known legitimate source.

5.3 Stay at p=quarantine until exit criteria are met

Quarantine is not a destination - it is a safety-net stage. Do not stay here indefinitely "in case something breaks". The spam folder is a worse user experience than reject + bounce because there is no automatic feedback to the sender. Advance to p=reject when exit criteria are satisfied (see Section 7).

6. Phase 4: Enforcement (p=reject)

Entry condition: Phase 3 exit criteria all satisfied (see Section 7).

Goal: refuse spoofed mail at the SMTP RCPT TO stage; this is the steady state.

6.1 Publish p=reject

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

• Drop pct= at this point - leave the implicit default pct=100.
• Continue receiving aggregate reports - they remain the primary signal during steady-state operation.

6.2 Advance sp= and np= ahead of any non-sending subdomain

• sp=reject applies p=reject behaviour to ALL subdomains regardless of whether they send mail.
• np=reject (RFC 9091) applies p=reject only to non-existent subdomains - a stronger anti-spoofing protection because NXDOMAIN subdomains never send mail.
• If subdomains send under a different schedule, publish per-subdomain _dmarc.sub.example.com records with their own p= at their own rollout pace.

6.3 Raise DNS TTL and switch to maintenance mode

• Raise the _dmarc TTL from 300-3600 to 86400+ for caching efficiency.
• Schedule monthly review of aggregate reports - any new misaligned source is either a new legitimate sender to onboard or an attacker being rejected.
• Consider adding BIMI for the visible-brand-logo benefit (BIMI requires DMARC at p=quarantine or stricter).

7. Per-phase exit criteria

Do not advance between phases on a calendar - advance when the exit criteria for the current phase are satisfied. The cost of waiting an extra week is small; the cost of advancing prematurely is dropped legitimate mail.

7.1 Phase 1 -> Phase 2 (exit Discovery)

• At least 2 consecutive weeks of aggregate reports received and parsed.
• The sender registry covers at least 95% of observed mail volume - no large unknown sources remaining.
• Each row in the registry has an assigned owner and a Phase 2 action item.

7.2 Phase 2 -> Phase 3 (exit Triage)

• Each legitimate sender in the registry produces DMARC-aligned mail for at least 2 consecutive weeks of aggregate reports.
• Cumulative aligned-volume ratio is 95%+ across the entire observed mail estate.
• Known-misaligned sources are explicitly documented as accepted (legacy partner with no fix path) - not silently misaligned.

7.3 Phase 3 -> Phase 4 (exit Quarantine)

• Two to four consecutive weeks at pct=100 of p=quarantine with no support tickets about missed mail.
• Aggregate reports show zero DMARC-failing legitimate sources.
• The on-call team has been briefed on what to do if a missed-mail ticket arrives within 24 hours of advancing to p=reject.

7.4 Phase 4 steady-state

• Continue monthly aggregate report review.
• Onboard new senders into the registry as they appear.
• Rotate DKIM keys per cadence (see the DKIM key rotation deep dive).

8. Decision matrix for common scenarios

The decisions operators reach for most often during deployment. Use the matrix to short-circuit the "what do I do here" question without re-reading the policy rollout deep dive.

8.1 "I see a high-volume source I do not recognise in the aggregate reports"

1. Reverse-DNS the source IP - the PTR record often names the organisation (ESP, partner, attacker).
2. WHOIS the source IP - confirms the organisation.
3. If the organisation is unknown / hostile: no action - DMARC reject will block it later.
4. If the organisation is a SaaS your team uses but did not flag: open an internal ticket to onboard them into the sender registry.

8.2 "A previously-aligned sender is suddenly failing alignment"

1. Check if the source rotated DKIM keys - verify the published selector still resolves and matches the DKIM-Signature: s= tag.
2. Check if the source moved IP ranges - verify the SPF record still authorises the new IP.
3. Check if the source is forwarding mail through a relay - ARC may be needed.

8.3 "Should I use pct= sampling or jump straight to pct=100?"

• If your sending volume is small (under 10k messages per day) and your sender inventory is high-confidence: skip pct= and go straight to pct=100.
• If your sending volume is large (over 100k messages per day) or you have many third-party senders: ramp pct=10 -> 25 -> 50 -> 100 over 4-8 weeks.
• Note: pct= is being removed in dmarcbis. If you are starting a brand-new deployment in 2026, consider the alternative of staying longer at p=quarantine with pct=100 instead of using the soon-to-be-deprecated sampling mechanism.

8.4 "My organisation acquired another company - what about their domain?"

1. Treat the acquired domain as a separate deployment - run Phase 1 Discovery against it independently.
2. If the acquired domain sends low-volume mail only, you may be able to short-circuit by publishing p=reject after a 2-week Discovery phase.
3. Do not merge the rollout calendars - each domain advances on its own exit criteria.

8.5 "We have non-sending subdomains - what about them?"

1. Non-sending subdomains can move to p=reject on day one - they have no legitimate mail flow to break.
2. Publish _dmarc.parked.example.com with v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com.
3. Alternatively use the apex sp=reject tag to default ALL subdomains to reject and only override per-subdomain for actively-sending subdomains.
4. np=reject (RFC 9091) covers non-existent subdomains - a free anti-spoofing win.

9. Common mistakes

• Jumping from p=none straight to p=reject without an intermediate p=quarantine stage. This is the single most common cause of self-inflicted DMARC outages.
• Forgetting to publish rua= from day one. Without aggregate reports you are flying blind - you cannot identify misaligned senders, you cannot confirm progress, you cannot validate exit criteria. Always publish rua= even at p=none.
• Not lowering the DNS TTL during rollout. If something goes wrong you need fast rollback - a default 86400 TTL means a 24-hour wait for the change to propagate. Lower to 300-3600 during rollout and raise again at steady state.
• Skipping the sender inventory. Without a complete inventory you will find senders during Phase 3 quarantine that you missed during Phase 1 discovery, and they will arrive as user complaints about missed password resets and partner notifications.
• Treating Phase 3 quarantine as the destination. Quarantine is a safety-net stage, not a permanent state. The spam folder is a worse user experience than reject + bounce because there is no automatic feedback to the sending system. Always advance to p=reject once exit criteria are met.
• Forgetting sp= and np= for subdomains. The apex p= only covers the apex. Without sp=reject or np=reject, attackers can spoof from non-existent subdomains like billing.example.com with no protection.
• Publishing a forensic (ruf=) endpoint that is not protected. Forensic reports may contain message-content snippets that include sensitive data - protect the mailbox accordingly. Some operators avoid forensic reports entirely.

10. Troubleshooting common deployment failures

10.1 "I published p=none but I am not receiving any aggregate reports"

• Verify the published record syntax with a DMARC syntax checker - a malformed v=DMARC1 tag silently invalidates the entire record.
• Verify the rua= address accepts mail from outside the organisation - some spam filters block report-bearing messages from senders the organisation has never emailed.
• Send a few outbound messages to Gmail or Outlook to generate report-bearing traffic.
• Reports arrive 24-72 hours after the mail is sent - wait 3 days before assuming the pipeline is broken.

10.2 "Aggregate reports show a source IP I cannot identify"

• Reverse-DNS the IP - dig -x 192.0.2.10 usually resolves to the organisation's PTR record.
• WHOIS the IP - whois 192.0.2.10 shows the owning organisation.
• Check the d= domain in the DKIM-Signature column of the report - it often names the ESP.

10.3 "DKIM is misaligning even though the signature passes"

• DKIM passing is not the same as DMARC-aligned - DMARC requires the DKIM d= domain to match the From: header domain (with relaxed alignment allowing organisational-domain match).
• If the ESP signs with their own domain (d=sendgrid.net) instead of yours, you need to enable branded DKIM in the ESP control panel.
• See the DMARC alignment deep dive for the full alignment semantics.

10.4 "I moved to p=quarantine and now users are missing transactional email"

• Roll back to p=none immediately - do not debug in production with broken mail flows.
• Aggregate reports will show which sender hit the quarantine - usually a transactional ESP that needs branded DKIM enabled.
• Fix the alignment, then re-advance to p=quarantine.

11. Frequently asked questions

What is a DMARC deployment checklist?

A DMARC deployment checklist is the concise per-phase action list an operator works through to deploy DMARC end-to-end without breaking legitimate mail. It complements the policy-rollout deep dive (which explains the why) by giving the operator concrete checkboxes for prerequisites (DNS edit access, MTA + sender inventory, monitoring mailbox), per-phase action items (discovery, triage, quarantine, reject), and exit criteria for advancing between phases.

What are the prerequisites for a DMARC deployment?

Three prerequisites: DNS edit access for the apex and any sending subdomains, a complete inventory of every system that sends mail using your domain in the From: header (production MTA, transactional ESPs, marketing automation, helpdesk + CRM, monitoring + alerting systems, internal cron jobs and Windows scheduled tasks, partner integrations), and a monitoring mailbox to receive aggregate (rua) reports - ideally with an automated parser like this DMARC Analyzer instance.

How long should each DMARC deployment phase last?

Typical durations: Discovery 2-4 weeks; Triage 4-8 weeks; Quarantine 2-4 weeks; Reject is the steady state (ongoing). Larger organisations with diverse sending estates often need the upper end of each range. Skipping phases is the most common cause of self-inflicted DMARC outages.

When is it safe to advance from quarantine to reject?

Three signals must all be true: two to four weeks of aggregate reports show zero DMARC-failing mail from legitimate sources; no support tickets about missed mail; the pct= sampling ramp reached pct=100 with no new failure modes. If any one is false, hold at quarantine.

What is the difference between this checklist and the DMARC policy rollout page?

The policy rollout page is a deep-dive reference that explains the three policy states, the semantics of pct= sampling, the subdomain policy timing, and the worked Week 0 through Week 26 timeline - the WHY and the underlying mechanisms. This checklist is the operator quick-reference that converts those mechanisms into actionable per-phase checkboxes - the WHAT and WHEN, in the order an operator works through them during deployment.

Do I need a paid DMARC tool to deploy DMARC?

No, but you do need some way to parse aggregate (rua) reports. DMARC Analyzer is a free option that ingests reports via IMAP or Microsoft Graph and aggregates the per-source-IP, per-sender pass and fail metrics into a dashboard. Commercial alternatives include Valimail, PowerDMARC, EasyDMARC, dmarcian, and Cisco DMARC. Open-source alternatives include parsedmarc.

What is the most common DMARC deployment mistake?

Jumping straight from p=none to p=reject without an intermediate p=quarantine stage. Legitimate senders that were quietly failing alignment under p=none have never been noticed; moving directly to p=reject means every one of those senders now hits a hard SMTP reject and the messages are dropped. Pass through p=quarantine first.

How do I roll back a DMARC deployment if something goes wrong?

Lower the p= tag one stage - from p=reject back to p=quarantine, from p=quarantine back to p=none. The DNS TTL on the _dmarc TXT record determines propagation speed - keep the TTL at 300-3600 seconds during rollout for fast rollback (raise it to 86400+ once you reach steady-state p=reject). Aggregate reports continue regardless of the p= value as long as the rua= tag is published.

12. Related guides

• DMARC policy rollout - the deep-dive companion to this checklist. Covers the three policy states, the pct= sampling tag, subdomain policy timing (sp= / np=), the dmarcbis transition, and the worked Week 0 -> Week 26 timeline. Read this when the checklist's action item leaves you wanting "but why?".
• DMARC myths and misconceptions debunked (the DEPLOYMENT-PRECONDITION-MYTH-CLARIFICATION companion to this deployment checklist) - the DEPLOYMENT-PRECONDITION-MYTH- CLARIFICATION companion documenting the 18 most common DMARC mental-model ERRORS operators bring to the deployment workflow THIS checklist documents — myths that, if unaddressed BEFORE Phase 1 publication, cause checklist steps to be skipped or misexecuted in operationally-costly ways. Where THIS page documents the GREEN-PATH DEPLOYMENT WORKFLOW step-by-step (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=10 ramp, Phase 5 terminal p=reject pct=100), the myths-and- misconceptions spoke documents the 18 PRECONDITION MYTHS that operators MUST understand BEFORE executing the workflow — each myth tied to a specific checklist step it directly undermines: (i) "DMARC is set-and-forget" → undermines the post-publication monitoring cadence in §6-§9, (ii) "p=none means DMARC is off" → undermines the Phase 3 monitoring-window justification (Phase 3 is where the sender inventory is built — skipping it produces the legitimate-mail false-positive cascade at Phase 5), (iii) "I'll just go straight to p=reject" → undermines the entire Phase 1-through- Phase 4 ramp the checklist enforces, (iv) "My SaaS senders are already DMARC- aligned" → undermines the Phase 1 third-party-sender inventory step (every third-party-sender requires a per-sender DKIM-signing-domain verification independent of the sender's own DMARC posture), (v) "DMARC blocks all phishing" → undermines the operator's risk-justification for the multi-week ramp cadence (the residual phishing surface that survives p=reject requires complementary controls documented in adjacent spokes), (vi) "DMARC alignment and DKIM signing are the same" → undermines the Phase 1 DKIM prerequisite verification (DKIM signing without alignment to the From: domain produces aggregate-report rows showing dkim=pass + aligned=false at every legitimate-mail message), (vii) "My ESP/forwarder will just handle DMARC for me" → undermines the Phase 1 inventory step's exhaustive- sender-enumeration requirement. Read THIS checklist WITH the myths-and-misconceptions spoke when authoring the deployment runbook: the checklist documents the WORKFLOW STEPS, the myths-and- misconceptions spoke documents the 18 PRECONDITION MENTAL-MODEL ERRORS the operator must clear BEFORE the workflow produces the expected outcome.
• DNS propagation explained (TTL discipline as a phase-exit prerequisite) - the invisible timing layer that every phase-exit criterion in this checklist silently depends on. Every "publish the new record at Week N" item in the action list assumes the previously-published 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. The propagation reference documents the canonical Phase 0 prerequisite: lower the TTL one full TTL period BEFORE you change the record - the single rule that makes every subsequent phase advance in this checklist feel instantaneous rather than spanning a 4-to-24-hour cached-record straddle window. It also documents the recommended 300-second (5-minute) TTL for active rollouts vs the 3600-second (1-hour) TTL for steady-state production records, 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 before claiming the phase-exit criterion is met, and the emergency-rollback case for short TTLs when an inadvertent p=reject advance breaks legitimate mail. Add a Phase 0 line item to this checklist: "lower TTL on _dmarc, SPF, and every DKIM selector to 300 seconds at least 24 hours before publishing the first DMARC record" - it is the single highest-leverage prerequisite decision in the whole rollout playbook.
• DMARC policy modes: p=none vs p=quarantine vs p=reject - the head-to-head COMPARATIVE reference for the three policy values. Per-mode semantics, 11-row side-by-side comparison table, receiver behaviour at Gmail / Microsoft 365 / Yahoo / Apple iCloud, and a scenario-based decision matrix. Read this when you need to answer "what exactly happens under each mode?" — the checklist tells you WHAT to do at each phase, this page tells you WHAT THE POLICY VALUE MEANS.
• DMARC attacker bypass techniques — the RESIDUAL-ATTACK-SURFACE companion documenting what survives terminal p=reject enforcement - the RESIDUAL-ATTACK-SURFACE companion to this deployment checklist. Where THIS page documents the GREEN-PATH ROLLOUT WORKFLOW that gets a domain from p=none to terminal p=reject pct=100, the attacker-bypass spoke documents the EIGHT BYPASS CLASSES that survive even a correctly-deployed p=reject policy: (i) cousin/lookalike domain spoofing (the From: header impersonates example-corp.com instead of example.com — the bypass domain has its OWN DMARC posture and publishes its OWN SPF + DKIM + DMARC records, so DMARC alignment passes for the ATTACKER domain; the recipient sees the visually-similar From: and is fooled), (ii) display-name-only attacks (the From: header's display-name is set to "CEO Name <ceo@example.com>" but the actual address-domain is the attacker's; many mobile mail clients show only the display-name, hiding the actual address-domain from the user's view), (iii) IDN homograph attacks (the From: domain uses Cyrillic / Greek / Cherokee characters that render visually identical to Latin characters — аpple.com with a Cyrillic 'а' is a different domain than apple.com but renders identically in most fonts), (iv) unauthenticated-subdomain attacks against domains that publish DMARC at the organizational domain but have NO sp=reject subdomain policy AND NO catch-all wildcard _dmarc.* record (the attacker spoofs billing.example.com when the operator only published _dmarc.example.com), (v) ARC- sealed forwarded mail that the receiving domain trusts on the strength of the forwarder's ARC chain rather than the original sender's DMARC alignment (the bypass is operator-configured trust at the receiver, not a protocol weakness in DMARC), (vi) compromised legitimate sender (the attacker phishes credentials for a legitimate marketing@example.com account and sends DMARC-aligned mail from the compromised account — DMARC passes because the mail IS aligned, the attack succeeds because the sender IS authorized), (vii) third-party-sender abuse (an attacker signs up for an ESP that the target domain has authorized via include: in SPF, and sends from a shared-tenant pool IP that the target domain's SPF record blesses), (viii) DKIM-replay attacks (the attacker captures a DKIM-signed legitimate message and replays it through an SMTP relay to a new set of recipients — the captured DKIM signature is valid, the body is valid, DMARC passes, but the original recipients list was overwritten). Add a Phase 6 line item to this checklist: "publish complementary controls for the eight attacker-bypass classes above" — explicitly the cousin-domain monitoring playbook (defensive-registration of common typo variants + Brand Indicators for Message Identification (BIMI) to give recipients a visual cue that distinguishes legitimate mail from cousin-domain spoofing), the wildcard _dmarc.* DNS record (per the records-explained spoke's subdomain-policy-coverage section), the per-tenant DKIM-replay-mitigation timing (x= expiration tag + tight rotation cadence per the dkim-key-rotation spoke), and the third-party-sender authorization-scope-review (per the saas-senders spoke). The deployment checklist is the WORKFLOW; the attacker-bypass spoke is the LIMITS-OF- PROTECTION reference that prevents the operator from believing the checklist's terminal p=reject state is the END of the anti-spoofing engineering work.
• Email spoofing explained — the PRE-PHASE-1-BASELINE-THREAT- CATALOGUE-MOTIVATING-THE-ENTIRE- DEPLOYMENT-CHECKLIST companion to this provider-agnostic four-phase DMARC rollout reference. Where THIS page documents the GREEN-PATH WORKFLOW (Phase 0 protective-registration + Phase 1 discovery + Phase 2 backlog + Phase 3 pct=N quarantine ramp + Phase 4 pct=N reject ramp + Phase 5 terminal p=reject + Phase 6 complementary-controls) that gets a domain from no-DMARC-posture to full-stack anti-spoofing enforcement, the email-spoofing spoke documents the ADVERSARY-SIDE threat-catalogue this checklist's entire workflow EXISTS to defend against. Concretely, the spoke documents FOUR spoofing-technique-vs-deployment- checklist-phase-coverage dimensions: (i) exact-domain From-header forgery (spoofing Technique #1) is DEFENDED END-TO-END by the entire Phase 2 SPF + DKIM authoring + Phase 3 / 4 pct=N enforcement ramp — the canonical attack vector THIS checklist's green-path workflow STRUCTURALLY ELIMINATES at terminal p=reject; (ii) display-name-only attacks (spoofing Technique #4) STRUCTURALLY SURVIVE the terminal p=reject state because the attacker's From: header address-domain is NOT the protected domain (it is the attacker's own gmail.com / outlook.com / attacker-controlled.tld) and DMARC alignment evaluates against the attacker's domain — defending against this class requires the Phase 6 complementary-controls line item (gateway-content-scanner with impersonation-detection rules, executive-name/CEO-fraud allowlist, end-user-training programme) the DMARC trinity STRUCTURALLY CANNOT cover; (iii) cousin/lookalike domain registration (spoofing Technique #5) with Punycode-confusable IDN homograph is PARTIALLY DEFENDED by the Phase 0 protective-domain- registration prerequisite (registering common typo-permutations + IDN homograph permutations + commonly- used TLD permutations of the protected brand-domain) AND the Phase 6 multi-domain-portfolio coverage extension that publishes a defensive p=reject posture on every protective- registration domain — the threat-vector demonstrates why Phase 0's protective-registration line item IS STRUCTURALLY LOAD-BEARING and not an optional pre-flight nicety; and (iv) compromised-account VEC (spoofing Technique #7 — Vendor Email Compromise) STRUCTURALLY SURVIVES terminal p=reject because the attacker is using a genuine DKIM- signed message from the legitimate- sender's infrastructure (DMARC alignment passes for the legitimate sender) — defending against this class requires the Phase 6 complementary-controls line item (account-takeover-detection + anomalous-send-pattern-monitoring + vendor-payment-out-of-band-callback- procedure) the DMARC trinity STRUCTURALLY CANNOT cover. Read the email-spoofing spoke BEFORE Phase 1 kickoff when the new operator needs to understand WHAT THREAT THE CHECKLIST IS DEFENDING AGAINST (the spoke is the AUTHORITATIVE threat-catalogue baseline), AND before Phase 6 complementary-controls scoping when the operator needs to size the residual-attack-surface coverage the DMARC trinity STRUCTURALLY CANNOT eliminate (the spoke's Technique #4 / #7 entries catalogue the residual-coverage obligation the gateway-content- scanner + account-takeover-detection + end-user-training Phase 6 line items materialise against).
• DKIM replay attacks - the BYPASS-CLASS-(viii)-OPERATIONAL- COUNTERMEASURES-DEEP-DIVE companion to this deployment checklist. Where the attacker-bypass Related-Guides entry immediately above flags DKIM-replay as bypass class (viii) and the checklist's Phase 6 complementary-controls line item names "per-tenant DKIM-replay-mitigation timing (x= expiration tag + tight rotation cadence)" as the deployable countermeasure, the dkim-replay-attacks spoke is the OPERATIONAL-MECHANICS REFERENCE documenting the exact engineering model the Phase 6 line item materialises against. The spoke walks through the four-axis countermeasures stack: (i) per- selector recipient-velocity baseline thresholds at receivers — Gmail / Yahoo / Microsoft / Apple increasingly publish per-selector-per-time-window recipient-velocity baselines as the deliverability-tier-gate signal for signature reuse; the Phase 6 line item's intent maps directly onto the receiver-side detection signal this axis documents; (ii) narrow signature-expiration (x=) windows with deliberate t=−x= bounding ≤ 7 days — the documented signer-side hardening contract whereby the de-facto unbounded-emission default is replaced by a deliberately-narrow operational window, strictly bounding the post-capture replay-attempt window and shifting attacker economics; (iii) body-length-limit (l=) tag prohibition in production signing — the operational anti-pattern documentation whereby l= use enables attacker-chosen UNSIGNED trailing content to be appended AFTER the l=-bounded signed prefix while still earning dkim=pass (the operational reason DKIM best practices forbid l= in production signing — a hardening control applied at the SIGNER, not the receiver, and therefore deployable from the checklist's authoring phases without receiver coordination); and (iv) scheduled per-tenant DKIM selector rotation cadence — the dkim-key-rotation spoke already cited in Phase 6 names the OVERLAP-WINDOW contract; the replay-attacks spoke completes the picture by documenting how periodic rotation limits the per-selector signed-message-capture exposure window and increases the per-campaign attacker capture-and-replay cost. Read the replay-attacks spoke when the operator moves from Phase 5 (terminal p=reject + pct=100) into the Phase 6 complementary-controls publication step and needs the operational-engineering depth behind the "per-tenant DKIM- replay-mitigation timing" deliverable — the spoke is the canonical attack- mechanics and countermeasures reference downstream of bypass class (viii) of the attacker-bypass spoke and the operational mechanic the Phase 6 line item's deployable-control intent materialises against.
• MTA-STS explained - the DMARC-DEPLOYMENT-CHECKLIST-PHASE-5- TRANSPORT-LAYER-COMPANION-PUBLICATION- DISCIPLINE companion to this DMARC deployment-checklist reference. Where THIS page documents the seven-phase DMARC rollout checklist (Phase 1 records- publication; Phase 2 RUA-stream observation; Phase 3 alignment-quality-gates; Phase 4 p=quarantine ramp; Phase 5 transport-layer-hardening; Phase 6 attacker-bypass-residual-surface closure; Phase 7 p=reject steady-state monitoring), the dedicated MTA-STS-explained pillar documents the STRUCTURALLY-LOAD-BEARING transport-layer publisher-publication- discipline at four phase-integration coordination dimensions whose closure is the Phase 5 transport-layer-hardening tier operational checklist this page operationalises on: (i) MTA-STS publication is the FOUR-ARTIFACT coordinated publication discipline (apex TXT-RR with v=STSv1 + id=; HTTPS policy-host A/AAAA + cert + policy.txt file at mta-sts.<domain>; _mta-sts.<domain> TXT ID-pointer-RR; optional TLS-RPT _smtp._tls.<domain> TXT-RR with rua=mailbox) - the Phase 5 publication step requires the operator to coordinate all four artifacts atomically without leaving the publisher in a partial-publication state that would produce TLS-RPT validation failures before the policy takes effect at sending MTAs; the MTA-STS-explained pillar documents the four-artifact coordinated publication discipline and the Phase 5 authoring procedure that the checklist's transport-layer-hardening tier operationalises on; (ii) MTA-STS policy publication encodes a publisher-side ENFORCEMENT- STRICTNESS commitment via mode=none / mode=testing / mode=enforce tiered operator-rollout dial - the Phase 5 deployment-checklist procedure ramps the publisher through these tiers in parallel to the Phase 4 DMARC p=quarantine → p=reject ramp, with TLS-RPT validation- failure rate as the per-tier ramp-exit evidence the publisher consumes for ramp advancement; the MTA-STS- explained pillar documents the mode- tier publisher-ramp discipline that parallels the DMARC policy-tier ramp this page documents, identifying the operator-decision framework for staggering MTA-STS-mode and DMARC-policy-mode ramps; (iii) MTA-STS adoption is OPTIONAL but STRONGLY-RECOMMENDED at Phase 5 because the transport-layer- downgrade-attack class (man-in-the-middle stripping STARTTLS opportunistic- encryption advertisement to force cleartext SMTP delivery) is structurally independent of the application-layer SPF/DKIM/DMARC authentication-decision and is the dominant attacker-bypass residual surface remaining at the Phase 6 attacker-bypass-residual-surface- closure tier of this checklist - MTA-STS is the publisher-publishable opt-in defense against the STARTTLS-downgrade attack class; the MTA-STS-explained pillar documents the STARTTLS-downgrade- attack threat-model and the publisher- side commitment scope that closes the Phase 6 transport-layer residual attacker-bypass surface; and (iv) MTA-STS max_age TTL discipline produces a per-receiver-MTA policy- caching window where the publisher's policy update propagates to receiver- side caches over a max_age-bounded time window - the Phase 5 publication step requires the publisher to choose a max_age value (typical 604800 seconds = 7 days minimum recommended) that balances policy-update-propagation- latency vs DoS-resistance-via-cache- persistence trade-off, with publisher's ramp-back-from-enforce option requiring an MAX_AGE-bounded propagation window before receivers stop honoring the prior policy; the MTA-STS- explained pillar documents the max_age TTL discipline and the Phase 5 publisher- side max_age-selection operator-decision framework, closing the per-receiver-MTA cache-propagation window the deployment checklist's Phase 5 transport-layer- hardening tier coordinates around.
• MTA-STS policy file syntax - the DEPLOYMENT-CHECKLIST-MTA-STS-AUTHORING-STEP byte-level companion to this DMARC deployment checklist. Where THIS page documents the FULL-STACK ROLLOUT PLAYBOOK (Phase 0 TTL discipline → Phase 1 DMARC p=none monitoring → Phase 2 SPF / DKIM alignment fixes → Phase 3 p=quarantine with pct= ramp → Phase 4 p=reject at 100% → Phase 5 steady-state monitoring + reporting- ingestion) including the auxiliary TRANSPORT-SECURITY records the rollout ships ALONGSIDE the DMARC trinity (BIMI for brand-trust, MTA-STS + TLS-RPT for transport-security), the mta-sts-policy-syntax spoke documents the BYTE-LEVEL POLICY-FILE FORMAT the MTA-STS-AUTHORING step of the checklist produces — the plain-text mta-sts.txt policy file published at https://mta-sts.<domain>/.well-known/mta-sts.txt with the version: STSv1 + mode: enforce|testing|none + repeated mx: directives + max_age: <seconds> tag-value grammar (RFC 8461 §3.2). The MTA-STS-AUTHORING step has its OWN per-phase ramp parallel to the DMARC ramp (Phase A mode: testing for 14-30 days while baselining TLS-RPT reports → Phase B mode: enforce once the report stream confirms zero unexplained TLS-negotiation-failures), and the max_age: value choice (typical 86400-second baseline for active rollouts, 604800-second steady- state) follows the SAME TTL-discipline prerequisite documented in Phase 0 of this checklist for the DMARC + SPF + DKIM records. Read the mta-sts-policy-syntax spoke when AUTHORING the mta-sts.txt policy file at the MTA-STS-deployment step of this checklist — the byte-level grammar reference is the load-bearing operator- reference for that checklist step.
• DANE for SMTP (RFC 7672) explained - the DEPLOYMENT-FLOW-CONSUMER optional- but-strongly-recommended transport-security step companion to this DMARC deployment checklist documenting the RFC 7672 DNSSEC- anchored TLSA-based certificate-pinning mechanism that pairs with the MTA-STS rollout the checklist already documents to form a LAYERED transport-security posture. Where THIS page documents the FULL-STACK ROLLOUT PLAYBOOK including the auxiliary TRANSPORT-SECURITY records the rollout ships ALONGSIDE the DMARC trinity (BIMI for brand-trust, MTA-STS + TLS-RPT for transport-security), and the MTA-STS- policy-syntax spoke above documents the BYTE-LEVEL POLICY-FILE FORMAT the MTA-STS-AUTHORING step produces, the DANE-for-SMTP spoke documents the STRUCTURALLY-DISTINCT DNSSEC-anchored transport-security technology that LAYERS with (NOT replaces) MTA-STS for the most defensive transport-security posture. The four-axis CHECKLIST-EXTENSION comparison exposes the DEPLOYMENT-FLOW-STEPS DANE adds to the rollout playbook on top of the MTA-STS steps already documented: (i) DANE Phase 0 prerequisite — DNSSEC must be enabled on the domain zone and DS records published with the parent zone — DANE cannot deploy without DNSSEC because the TLSA records require the DNSSEC trust-chain for receivers to validate authenticity; this is a parent- zone-coordination step the MTA-STS rollout does NOT require; (ii) DANE Phase A authoring — publish the TLSA records at _25._tcp.<mxhost> with usage/selector/match-type/cert-data four- field grammar matching every MX host's STARTTLS cert — the TLSA RRtype (RR type 52) is a non-TXT first-class record type; (iii) DANE Phase B validation — verify the receiver-side TLSA-pinning is in effect via TLS-RPT report aggregation — TLS-RPT reports surface the "validation-failure" result- type when DANE TLSA-mismatch occurs, sharing the same RFC 8460 reporting channel as MTA-STS failures; (iv) DANE rotation discipline — publish new TLSA + wait-TTL + cutover- cert + retire-old TLSA cadence parallel to the DKIM-selector dual-publish rotation discipline this checklist documents for DKIM — the operational discipline translates one-to- one between DKIM-selector-rotation and DANE-TLSA-rotation, simplifying operator training. Read the DANE-for-SMTP spoke when EXTENDING the full-stack DMARC rollout to maximum defensive transport- security posture: this checklist documents the GREEN-PATH rollout, the DANE spoke documents the OPTIONAL-BUT-STRONGLY- RECOMMENDED transport-cert-pinning extension that pairs with MTA-STS for the operator who values DNSSEC-anchored transport-security alongside the MTA-STS public-PKI-anchored transport-security.
• MTA-STS vs DANE for SMTP — the DEPLOYMENT-CHECKLIST-TRANSPORT- LAYER-DECISION-STEP-AS-MTA-STS-VS-DANE- VS-BOTH-CHOICE companion to this DMARC deployment-checklist reference. Where THIS page documents the FULL-STACK rollout playbook including the auxiliary TRANSPORT-SECURITY records (BIMI for brand-trust, MTA-STS + TLS-RPT for transport-security, optional DANE for DNSSEC-anchored transport-security) the rollout ships ALONGSIDE the DMARC trinity, and the adjacent MTA-STS- policy-syntax + DANE-explained spokes document the BYTE-LEVEL byte-grammars for each transport-security technology independently, the MTA-STS-vs-DANE spoke is the OPERATOR-DECISION-TREE companion documenting the head-to-head comparison whose answer governs which transport-security technology (or both) the checklist's Phase A authoring step actually pulls onto the critical path for a given operator's deployment. Four DEPLOYMENT-CHECKLIST-VS-TRANSPORT- DECISION cross-correlation dimensions: (i) DNSSEC zone-state prerequisite — DANE requires DNSSEC-signed zones with DS records at the parent zone before TLSA records can validate; MTA-STS publishes via HTTPS- fetched policy + ordinary DNS TXT record (no DNSSEC dependency); the spoke documents the per-operator DNSSEC-readiness assessment that determines whether the checklist's Phase A authoring step can include the DANE-TLSA-publication sub-step or must defer DANE until a separate DNSSEC enablement project completes; (ii) HTTPS-policy-hosting infrastructure prerequisite — MTA-STS requires the operator to host an HTTPS-served policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt with a valid public-CA certificate; DANE publishes via TLSA records (no HTTPS infrastructure dependency); the spoke documents the per-operator HTTPS-policy- hosting readiness assessment (Azure Static Web Apps, Cloudflare Pages, Firebase Hosting, AWS S3+CloudFront, GitHub Pages — covered in the spoke's provider-specific cookbook) that determines whether the checklist's Phase A authoring step can include the MTA-STS-policy-file-publication sub- step or must coordinate with a separate HTTPS-hosting provisioning project; (iii) receiver-side support landscape — Gmail, Outlook.com, and most major receivers honour BOTH MTA-STS AND DANE; some receivers (Yandex, some Eastern European MTA fleets) prefer DANE; the spoke documents the per- receiver support matrix that determines whether the operator's checklist Phase A authoring step should target maximum coverage (BOTH technologies) or the operationally-simpler single-technology deployment; (iv) deployment-flow critical-path sequencing — when deploying BOTH technologies, the spoke documents the canonical Phase 0 sequencing (DNSSEC enablement → DANE-TLSA publication → HTTPS-policy infrastructure provisioning → MTA-STS policy-file publication → TLS-RPT activation) that the checklist's Phase A authoring step must respect to avoid the operationally- catastrophic mid-deployment-window receiver-side enforcement-mismatch state (DANE active without DNSSEC, MTA-STS policy referenced but HTTPS host returning 404). Pair this deployment- checklist (the full-stack rollout playbook) with the MTA-STS-vs-DANE spoke (the transport-layer decision-tree) when authoring the per-operator Phase A critical-path sequencing — the spoke is the canonical decision-reference whose per-operator answer determines which transport-security sub-steps the checklist's Phase A authoring step actually pulls onto the rollout's critical path.
• DMARC record tags explained - every tag in the DMARC DNS record (v, p, sp, np, pct, rua, ruf, adkim, aspf, fo, rf, ri).
• DMARC alignment explained - identifier alignment (RFC 7489 §3.1, §6.6.2): strict vs relaxed, the organisational domain, the Public Suffix List, and why DKIM passing is not the same as DMARC-aligned.
• DKIM alignment with DMARC — the PHASE-1-DKIM-PREREQUISITE- VERIFICATION-AT-PHASE-2-BACKLOG- CONSTRUCTION-AT-PHASE-3-PCT-RAMP-EXIT- CRITERIA companion to this deployment checklist. Where THIS page documents WHEN the DKIM alignment verification step appears in the rollout (Phase 1 prerequisite verification, Phase 2 mis-alignment backlog execution, Phase 3 + Phase 4 per-pct=-ramp per-stage-cutover confidence floor), the DKIM-alignment-with-DMARC spoke documents the BYTE-LEVEL alignment-evaluation DISCIPLINE the receiver applies at every per-message DMARC verdict: (i) the per- message comparison between the DKIM- Signature header's d=-tag signing-domain and the RFC 5322 From: header's organisational-domain; (ii) the strict-vs-relaxed alignment mode the publisher selects via the adkim=s / adkim=r tag-value in the DMARC record, where strict requires exact match and relaxed allows organisational- domain match per the Public Suffix List; (iii) the canonical defect class — per-message dkim=pass with aligned=false — that emerges in Phase 1 RUA aggregate reports when third-party ESPs sign with their own signing-domain (d=sendgrid.net, d=mandrillapp.com, d=amazonses.com) rather than the publisher's author-domain, which passes DKIM-protocol verification but fails DMARC-alignment-evaluation; (iv) the Phase 2 backlog-construction implication — every Phase 1 RUA aggregate row showing dkim=aligned=false for a legitimate sender becomes a Phase 2 backlog entry to either delegate a CNAME- based signing-domain (the canonical third-party-ESP remediation pattern) or accept the SPF-only path through the DMARC verdict; and (v) the Phase 3 / Phase 4 per-pct=-ramp exit-criteria gate — the per-pct=-stage cutover proceeds only when the per-author-domain rolling- average of per-message dkim=aligned =true rate exceeds the per-pct=- stage floor THIS checklist's ramp schedule documents. Read this WITH the deployment checklist when the Phase 1 DKIM prerequisite verification step surfaces aligned-pass-vs-protocol-pass divergence in the operator's RUA stream: the checklist documents the WORKFLOW STEP, the DKIM-alignment-with-DMARC spoke documents the BYTE-LEVEL ALIGNMENT-EVALUATION DISCIPLINE every per-message DMARC verdict downstream of Phase 1 STRUCTURALLY DEPENDS on.
• DMARC aggregate (rua) reports - the data behind every deployment decision. How to read the XML, what each field means, and how to translate report rows into Phase 2 action items.
• DMARC forensic (ruf) reports - the per-message diagnostic sibling. Few receivers send forensic reports but the ones that do are invaluable during Phase 2 triage.
• DMARC troubleshooting - the cross-cutting diagnostic guide for DMARC failures.
• DMARC monitoring - the operational discipline that sustains steady-state p=reject: monthly review, sender registry maintenance, alert thresholds.
• DMARC reporting pipeline - end-to-end rua + ruf ingestion, storage, deduplication, retention, and alerting reference.
• MX records explained — the PHASE-1-PREREQUISITE-RUA-MAILBOX-MX- PUBLICATION-AND-PHASE-5-STEADY-STATE- MONITORING-MAILBOX-DELIVERABILITY-FOUNDATION companion to this four-phase deployment checklist. Where THIS page documents the operator-side phased rollout from p=none Discovery to p=reject Enforcement, the mx-records spoke documents the apex DNS-zone-published MX-RR object whose receiver-side preference-ordering (priority-then-host-RFC-1035-§3.3.9 grammar) directly determines whether the Phase 1 prerequisite "monitoring mailbox for aggregate (rua) reports" actually RECEIVES the per-receiver-emitted aggregate-report stream the entire four- phase ramp STRUCTURALLY DEPENDS on as the per-phase-entry-and-exit-criteria evidence of record. Four MX-RR-PUBLICATION-VS- DEPLOYMENT-PHASE axes the mx-records spoke documents that converge on the operator-side checklist execution: (i) Phase 1 Discovery (p=none) PREREQUISITE: the rua=mailto:dmarc-rua@example.com tag STRUCTURALLY DEPENDS on the example.com apex MX RR being published at preference-0 (or some other receiver-MX-preference-ordering) to a host that actually accepts SMTP at port 25 and delivers to the dmarc-rua@ mailbox — a Phase 1 deployment with no MX, with the wrong MX, with an MX pointing to a host that is not listening on port 25, or with an MX pointing to a host that does not accept the dmarc-rua@ mailbox produces ZERO aggregate-report ingestion, blocks the sender-inventory enumeration the Phase 1 protocol on this page documents, and STRUCTURALLY PREVENTS the operator from advancing past Phase 1 because there is no evidence stream to read; (ii) Phase 2 Triage (alignment-fixing) PREREQUISITE: the same MX RR continues to ingest the per-source- IP-per-day aggregate-report stream the Phase 2 backlog enumerates against — an MX-RR change during Phase 2 (e.g. migrating the RUA mailbox to a new receiver host) introduces a per-DNS-TTL ingestion gap that produces under-counted misalignment backlog entries, leading to Phase 2 exit-criteria false-clear and Phase 3 ramp risk; the mx-records spoke documents the operator-side rollover procedure (publish second MX RR at lower preference, verify ingestion at second MX, retire first MX after TTL-bounded verification) that closes the per-DNS-TTL gap; (iii) Phase 3 Quarantine (p=quarantine pct=N) and Phase 4 Enforcement (p=reject) PREREQUISITE: the same MX RR continues to ingest the per-week-cadence-ramp-exit- criteria evidence the per-percentage ramp depends on — an MX-RR mistake at Phase 3 or Phase 4 produces a per-DNS-TTL evidence gap that masks per-percentage- ramp-exit-criteria false-positives, leading the operator to advance the ramp into legitimate-mail-loss exposure; the mx-records spoke's preference-ordering and host-priority documentation IS the per- receiver-evaluated MX-RR contract operators verify before each per-percentage ramp advance; (iv) Phase 5 Steady-State Monitoring PREREQUISITE: the same MX RR continues to ingest the ongoing per-week per-month per-quarter alignment-rate-KPI observability stream the steady-state monitoring discipline documents at the sustain-p=reject layer — the mx-records spoke documents the per-MX-RR availability discipline (TXT- check-of-mx + MX-RR-host-port-25-reachability probe + per-mailbox-quota-monitor) that sustains the steady-state RUA ingestion the post-Phase-4 four-phase-checklist- complete operator continues to operate against. Pair this deployment-checklist (the four-phase operator rollout) with the mx-records spoke (the apex MX-RR byte- syntax-and-deliverability-discipline reference) for the complete deployment- execution-discipline-AND-MX-RR- publication-foundation posture every operator needs to ramp DMARC from p=none to p=reject with a continuously-available RUA-ingestion evidence stream instead of a per-DNS-TTL gappy stream the per-phase-decision-gates depend on.
• SPF explained - the IP-authorisation layer. Phase 2 triage usually starts with an SPF cleanup.
• SPF DNS TXT-record byte syntax (RFC 7208 §3 tag-list grammar) — the PHASE-1-APEX-SPF-RECORD-AUTHORING-BYTE- LEVEL-REFERENCE companion to this deployment checklist. Where THIS page documents WHEN to publish the apex SPF record (Phase 1 — after the Phase 0 TTL discipline and BEFORE the Phase 2 RUA publication + monitoring inventory step), the SPF DNS syntax reference documents the BYTE-LEVEL HOW: the canonical v=spf1 version-prefix that distinguishes an SPF TXT record from arbitrary TXT records (without it, receivers ignore the record entirely); the per-mechanism token catalogue with byte-correct spacing and ordering semantics; the per-mechanism qualifier-prefix choice (+ Pass / - Fail / ~ SoftFail / ? Neutral) that determines per-receiver enforcement when the checklist advances from Phase 4 p=quarantine pct=N into Phase 5 p=reject pct=N; the 255-octet per-character-string chunking rule that determines how multi-string SPF records get authored in the zone file; the canonical single-record-per-domain constraint whose violation produces spf=permerror at receivers (RFC 7208 §3.2) — a recurring Phase 1 defect class when the operator accidentally publishes one SPF record for the on-prem MTA and a second for a SaaS sender like Microsoft 365 or Google Workspace; and the case-insensitive parser-tolerance rules per RFC 7208 §4.6.1 that determine which cosmetic byte-shape variations the receiver will accept versus collapse to spf=permerror. Read this WITH the checklist when the Phase 1 "publish the apex SPF record" line item moves to the operator's queue: the checklist documents the WORKFLOW STEP, the SPF DNS syntax reference documents the BYTE-LEVEL AUTHORING DISCIPLINE the published record must satisfy for every downstream phase's per-receiver SPF evaluation to succeed.
• SPF 10 DNS lookup limit and SPF flattening - the canonical Phase 2 SPF over-budget remediation reference.
• SPF PermError vs TempError - the PHASE-1-SPF-PREFLIGHT-AND-PHASE-2- RAMP-RFC-7208-§2.6.7-PERMERROR-VS-§2.6.8- TEMPERROR-RESULT-CODE-DIAGNOSTIC-DISCIPLINE companion to this deployment checklist. Where THIS page documents the GREEN-PATH DEPLOYMENT WORKFLOW step-by-step (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=10 ramp, Phase 5 terminal p=reject pct=100), the permerror-vs- temperror spoke is the focused per-code diagnostic reference on the two SPF-failure result codes the operator MUST distinguish BEFORE every ramp-phase advancement: the PermError verdict (record-grammar violations per RFC 7208 §4.5, the 10-DNS-lookup limit per §4.6.4, macro-expansion failures per §7 — all PERMANENT failures requiring operator- side record edits and BLOCKING the Phase 2 p=quarantine pct=N ramp until remediated) vs the TempError verdict (DNS resolver timeouts, SERVFAIL responses, transient name-resolution failures — likely self-resolving and NOT blocking the ramp but REQUIRING continuous monitoring to distinguish self-resolving outages from persistent receiver-side DNS infrastructure regressions). Four per-deployment-checklist- SPF-permerror-temperror-diagnostic dimensions: (i) PHASE-1-PREFLIGHT-SPF- PERMERROR-DETECTION before Phase 2 ramp advancement (every PermError row in the Phase 1 baseline RUA stream BLOCKS Phase 2 ramp advancement until the record-grammar / 10-lookup / macro-expansion root cause is remediated — operators who advance to Phase 2 with unresolved PermError rows observe legitimate-mail SPF=fail cascades at receivers that interpret PermError as hard-fail feeding DMARC evaluation per RFC 7489 §5.6.2), (ii) PHASE-3-RAMP-CONTINUOUS- TEMPERROR-OBSERVATION discipline (TempError rows in the Phase 3 p=reject pct=N ramp evidence stream are NOT operator-side bugs but REQUIRE per-receiver per-source-IP correlation to distinguish transient receiver-side DNS outages — self-resolving, no operator action — from persistent receiver-side DNS infrastructure regressions — escalation to the receiver's postmaster channel — using the AFRF / Authentication- Results forensic detection workflow at RFC 8601 §2.7.2), (iii) PER-RAMP-PHASE-RESULT- CODE-AGGREGATION baseline (the Phase 1 baseline RUA stream must catalogue per-code permerror / temperror ratios as upstream producers of the Phase 2 / Phase 3 ramp risk-assessment metrics — a 0% permerror baseline is the canonical Phase 2 ramp- readiness signal, a >0% permerror baseline BLOCKS ramp until remediated), (iv) PER- RECEIVER-INTERPRETATION-VARIANCE attribution (Gmail and Microsoft 365 both fail-OPEN on TempError to avoid legitimate-mail delivery loss but treat PermError as a hard SPF-fail feeding DMARC evaluation — the deployment-checklist operator MUST factor this per-receiver-interpretation-variance into the per-phase ramp risk-assessment because the same RUA evidence row produces different downstream policy_evaluated verdicts at different receivers depending on which SPF result code the receiver observed for the source IP). Critical when this deployment checklist's Phase 1 baseline-observation step or Phase 2 ramp-advancement gate reaches an SPF permerror or temperror symptom in the RUA evidence stream — the spoke's per-code diagnostic ladder is the canonical next step in the deployment-checklist preflight-and-continuous-monitoring workflow.
• SPF qualifiers explained (+ / - the PHASE-2-SPF-AUTHORING-TAIL-QUALIFIER- DECISION-AND-PHASE-3-ENFORCEMENT-RAMP- PREREQUISITE companion to this deployment checklist. Where THIS page documents the GREEN-PATH ROLLOUT WORKFLOW (Phase 0 TTL discipline → Phase 1 baseline observation → Phase 2 p=quarantine pct=N ramp → Phase 3 p=reject pct=N ramp → Phase 4 terminal p=reject pct=100), the qualifiers-explained spoke is the AUTHORING-DECISION REFERENCE for the single-character qualifier-prefix grammar (+ / - / ~ / ?) the operator encounters during Phase 2 when authoring or reviewing the domain's apex SPF record — the on-the-wire SEMANTIC DIFFERENTIATOR between a defensive Phase-3-ready SPF posture (-all hard-fail) and a misconfigured-by-omission record (+all universal-pass, ?all neutral, missing tail-qualifier) that breaks the deliverability-protection contract the checklist's Phase 3 ramp depends on. Four operationally-distinct qualifier-prefix-decision axes the spoke documents that this checklist's Phase 2 SPF-cleanup step individually triggers but never collectively interconnects: (i) -all hard-fail authoring decision as Phase 3 prerequisite — the spoke documents the receiver-side enforcement consequence of -all that the checklist's Phase 3 p=reject ramp depends on (Gmail Postmaster Tools surfaces -all rejection actions, Microsoft EOP treats -all as quarantine input, Yahoo/AOL applies stricter rate-limits to -all-violating IPs) — the qualifier-prefix the operator MUST publish before advancing into Phase 3 if the org wants the DMARC p=reject enforcement to translate into actual downstream sender-IP rejection; (ii) ~all soft-fail-only deployment as Phase 2 default — the multi-tenant ESP-deployment-specific decision (Workspace defaults to ~all because Google cannot commit to terminal -all rejection on behalf of every tenant's third-party-sender authorisation coverage) that the checklist's Phase 2 baseline observation MUST flag as an open authoring decision before Phase 3 ramp; (iii) +all universal-pass anti-pattern as Phase 2 audit gate — the catastrophic +all anti-pattern the spoke catalogues, in which an operator typed +all believing it is a permissive default, having published a record that explicitly authorises EVERY IP on the internet — the checklist's Phase 2 SPF-cleanup step MUST audit for this and block Phase 3 ramp until remediated; (iv) ?all / missing-all ambiguity as Phase 2 record-grammar review gate — the spoke catalogues ?all (neutral) and the missing-all-default-to-?all per RFC 7208 §4.7 as semantically-equivalent to publishing no SPF record at all, which produces no Phase 3 enforcement signal at receivers and breaks the deliverability-protection contract the checklist's terminal p=reject pct=100 state depends on. Read the qualifiers-explained spoke when executing the Phase 2 SPF-authoring step of this checklist — the spoke is the canonical authoring-decision reference for the tail-qualifier operator who is deciding between deliverability protection (-all) and advisory-only / open-relay anti-patterns (+all, ~all, ?all, missing-all).
• SPF forwarding issues (the second-hop break) — the PRE-DEPLOYMENT-CHECKLIST- FORWARDER-INVENTORY-AUDIT-AS-PHASE-2- PHASE-3-RAMP-RISK-ASSESSMENT- PREREQUISITE companion to this DMARC deployment checklist. Where THIS checklist documents the four-phase DMARC deployment workflow (Phase 1 baseline observation at p=none; Phase 2 SPF / DKIM prerequisite verification + ramp from p=none to p=quarantine pct=N; Phase 3 ramp from p=quarantine to p=reject pct=N; Phase 4 p=reject steady-state), the SPF-forwarding-issues spoke documents the FORWARDER-TOPOLOGY- INVENTORY-AUDIT-AT-PHASE-1-BASELINE- OBSERVATION-WINDOW step the operator must execute BEFORE advancing through Phase 2 and Phase 3 ramps where forwarder-induced SPF-fail rows translate into legitimate-mail- rejection at receivers. FIVE structurally-distinct PRE-DEPLOYMENT- FORWARDER-AUDIT-VS-CHECKLIST-PHASE- TRANSITION operational classes the spoke catalogues that THIS checklist cross-references but does not detail: (i) Phase 1 baseline- observation forwarder-attribution audit — during the p=none observation window, the operator MUST audit the aggregate-report stream for per- source-IP rows whose Header-From is the publisher domain but whose source- IP is OUTSIDE the publisher's SPF- authorised IP-set, attributing each non-authorised source-IP to either forwarder-relay-MTA infrastructure (legitimate, requires SRS / ARC remediation) or actual-spoofing- attempt infrastructure (legitimate spoofing target, p=reject is the remediation); (ii) per- organisation forwarder-topology catalogue (mailing-list-MTA / personal-forwarder / corporate- internal-relay / SaaS-feedback-loop- relay) before Phase 2 ramp — the publisher MUST inventory every forwarder-relay-MTA legitimately re-emitting publisher-domain mail (corporate distribution lists, partner-organisation mailing-list subscriptions, SaaS-platform bounce- and-feedback-loop relays, .forward- configured personal mailboxes, receiver-side trusted-forwarder allowlist registrations) BEFORE advancing to p=quarantine pct=N; (iii) per- forwarder remediation-strategy decision matrix (SRS rewriting vs ARC re-sealing vs receiver-side trusted-forwarder allowlist) before Phase 3 ramp — for each catalogued forwarder, the operator MUST decide which remediation strategy applies (SRS rewriting at the forwarder-side; ARC re-sealing at the forwarder-side; receiver-side trusted-forwarder allowlist registration at high-volume receivers) BEFORE advancing to p=reject pct=N to prevent legitimate-mail-rejection at the forwarder-second-hop boundary; (iv) Phase 4 steady-state forwarder-drift-monitoring — after reaching p=reject steady-state, the operator MUST continue monitoring the aggregate- report stream for NEW per-source-IP rows whose attribution indicates previously-uncatalogued forwarder infrastructure (corporate user signs up for new external mailing list, partner organisation adds new distribution-list-relay, internal team configures new .forward) — each new forwarder requires remediation- decision before producing legitimate-mail-rejection at receivers; (v) per-receiver- side trusted-forwarder allowlist coordination as deployment-checklist sub-step — the operator's deployment-checklist Phase 3 → Phase 4 transition includes coordinating with high-volume receivers (Gmail Postmaster Tools, Microsoft 365 Smart Network Data Service, Yahoo Sender Hub) to register the publisher's known-forwarder IP-set on the receiver's trusted-forwarder allowlist where available. Read the SPF-forwarding-issues spoke alongside THIS deployment checklist as the Phase 1 → Phase 2 → Phase 3 ramp- risk-assessment prerequisite — every forwarder catalogued during Phase 1 observation and remediated during Phase 2 directly de-risks the Phase 3 ramp from p=quarantine to p=reject where forwarder-induced SPF-fail rows translate into immediate legitimate- mail-rejection at receivers.
• SPF for Microsoft 365 - the DEPLOYMENT-CHECKLIST-M365-SPF-AUTHORING-STEP companion for M365-tenant operators executing the SPF prerequisite of this checklist - the M365-TENANT-SPF-DEPLOYMENT-STEP companion to this full-stack DMARC deployment checklist. Where THIS checklist documents the PROVIDER-AGNOSTIC procedural reference for first-time DMARC deployment (Phase 2's SPF + DKIM prerequisite verification step is framed in terms applicable to any sender operator persona), the SPF-for-Microsoft-365 spoke is the M365-tenant-SPECIFIC deep dive that documents the M365-tenant-specific authoring adaptations: the load-bearing baseline include:spf.protection.outlook.com token every M365 tenant must publish (one include slot, ~3 DNS lookups against the 10-lookup ceiling, covering both Exchange Online outbound MTAs and the Exchange Online Protection outbound IP space), the ~all-vs--all qualifier-selection decision tree for M365 tenants (M365 ships SPF guidance for both depending on Exchange-Hybrid topology presence), the hybrid Exchange-on-prem co-existence pattern (on-prem Edge / Exchange Server sending hostnames must be added as explicit ip4: or a: tokens because on-prem hostnames are NOT covered by the Microsoft-managed spf.protection.outlook.com include), the secondary-SaaS-sender pattern (MailChimp / SendGrid / Klaviyo / Mailgun-via-M365 senders need their own include tokens added alongside the M365 baseline), and the Direct-Send-vs-SMTP-AUTH bypass pattern (M365 Direct Send routes mail through M365 without per-mailbox auth and IS covered by the M365 SPF include, while third-party SMTP AUTH submission from outside M365 is NOT covered and needs its own SPF token). Read the SPF-for-M365 spoke when the operator running THIS checklist is on Microsoft 365 - the spoke is the authoritative per-provider SPF-authoring reference that contextualises Phase 2's provider-agnostic SPF prerequisite to the M365-tenant operator-empowerment model and the Microsoft-managed shared-outbound-IP envelope.
• SPF for Google Workspace — the DEPLOYMENT-CHECKLIST-WORKSPACE- TENANT-SPF-AUTHORING-STEP companion to this DMARC deployment checklist's Phase 2 SPF prerequisite. Where THIS page documents the provider-agnostic SPF publication step (verify the apex v=spf1 ... -all record is publishing, the per-third-party-sender include token is layered, the 10-DNS- lookup budget is respected, and the -all-vs-~all qualifier choice is operationally defensible), the SPF-for-Google- Workspace spoke is the WORKSPACE- TENANT-OPERATOR-EMPOWERMENT companion documenting the four Workspace-specific SPF-authoring checklist dimensions: (i) the canonical v=spf1 include:_spf.google.com ~all Workspace-tenant baseline record is the Phase 2 SPF authoring starting point for every Workspace tenant — the Workspace-managed _spf.google.com include cascade consumes ~4 lookup slots, leaving ~6 lookups of headroom for per-third-party-sender include tokens — the SPF-for-Workspace spoke documents this baseline consumption profile as the load-bearing prerequisite for the Phase 2 SPF checklist step at Workspace tenants; (ii) the per-third-party-sender include token layering discipline at Workspace tenants requires per-vendor canonical-include-token reference (SendGrid: include:sendgrid.net, Mailchimp: include:servers.mcsv.net, Salesforce SFMC: include:_spf.mtasv.net, Marketo: include:_spf.marketo.com, HubSpot: include:_spf.hubspotemail.net, Klaviyo: include:_spf.klaviyo.com) catalogued in the SPF-for-Workspace spoke — the spoke is the AUTHORITATIVE per-vendor SPF-include- token reference Phase 2's SPF prerequisite checklist step depends on for the Workspace cohort; (iii) the Phase 2 SPF lookup-budget verification step requires Workspace- tenant-specific accounting: ~4 baseline + N per-vendor include + 0-2 per- custom-subdomain include tokens cumulative against the 10-cap — the SPF-for-Workspace spoke documents the Workspace-tenant-specific lookup- budget envelope (~6 lookup headroom for third-party stacking) that operators executing the Phase 2 budget- verification step must reference; and (iv) the Phase 2 -all-vs-~all qualifier choice for Workspace tenants is constrained by Workspace's _spf.google.com-cascade publication behaviour + Google-Groups- mailing-list mediator effects + the Gmail-recipient-side auto-forwarding density — the SPF-for- Workspace spoke documents the Workspace-tenant qualifier-selection decision tree this checklist's downstream Phase 4 enforcement guidance depends on. (Note: Workspace-managed Google-Groups outbound IS covered by the _spf.google.com include chain, but Workspace-routing-rule- redirect outbound and Workspace SMTP- AUTH-from-outside-Workspace are NOT covered and need their own per-vendor include tokens.) Read the SPF-for- Workspace spoke when the operator running THIS checklist is on Google Workspace — the spoke is the authoritative per-provider SPF- authoring reference that contextualises Phase 2's provider-agnostic SPF prerequisite to the Workspace-tenant operator-empowerment model and the Google-managed shared-outbound-IP envelope, STRUCTURALLY-PARALLEL to the SPF-for-Microsoft-365 reference documented above but at the Workspace- tenant cohort.
• DKIM explained - the cryptographic-signing layer that survives forwarding.
• DKIM DNS TXT-record byte syntax (RFC 6376 §3.6.1 tag-list grammar) — the PHASE-2-PER-SELECTOR-DKIM-RECORD-AUTHORING-CHECKLIST-ITEM companion documenting the per-tag byte-level grammar (v=DKIM1 / k=rsa / p=<base64> / s=email / h=sha256 / t=y|s) the deployment checklist's Phase 2 ("Author DKIM TXT records for every sender") step structurally consumes when the operator translates the per-sender DKIM-publisher inventory into actual DNS-zone-file content, across FOUR deployment-checklist-specific DKIM byte-verification dimensions: (1) Phase 1 sender-inventory output → Phase 2 per-selector TXT-record byte-content per RFC 6376 §3.6.1 canonical tag-list — every sender identified in Phase 1 produces one (or more) <selector>._domainkey.<domain> TXT record whose v= / k= / p= byte-sequence MUST match the signing-platform's emitted public key byte-for-byte; the checklist's Phase 2 verification step is gated on byte-comparison of zone-file content against signer output; (2) Phase 2 p=<base64>-tag publication discipline at 2048-bit RSA — 2048-bit RSA public keys produce ~395-byte base64 strings exceeding the per-TXT-string 255-byte RFC 1035 §3.3.14 limit; the checklist operator MUST split the base64 across multiple double-quoted strings ("chunk1" "chunk2") at boundaries that do NOT bisect the base64 padding, OR use a DNS-provider UI (Route 53, Cloudflare, Azure DNS, GoDaddy) whose zone-import flow performs the split automatically — Phase 2 verification MUST confirm the receiver-side resolver re-concatenates the split correctly; (3) Phase 3 ramp-exit-criteria DKIM-pass-rate floor consumer of byte-syntax correctness — the checklist's Phase 3 ramp from pct=25 to pct=50 requires DKIM-aligned pass-rate ≥98% across the rolling 7-day window; byte-syntax malformation in ANY per-selector TXT record (missing v=DKIM1 prefix, malformed p=-tag, truncated chunk-split, wrong canonicalization-implied c=-tag) caps the achievable pass-rate below the ramp-exit floor regardless of signer-side correctness; (4) Phase 4 rotation-overlap t=y-tag publication discipline at key-rotation cadence — the checklist's Phase 4 ("Steady-state operations with quarterly DKIM key rotation") depends on the operator's ability to publish a side-channel selector with t=y (test mode) during the rotation overlap window, then transition to production (omitting t= per RFC 6376 §3.6.1 no-flags-default OR explicitly publishing t=s) before traffic migration — the per-tag t= byte-sequence is the load-bearing rotation-correctness signal. Byte-syntax correctness across these four Phase 2 / Phase 3 / Phase 4 dimensions is the load-bearing prerequisite for the checklist's ramp-to-p=reject trajectory whose per-phase exit-criteria-verification gate structurally depends on the per-selector DKIM TXT-record byte-content correctness.
• DKIM key rotation - the operational procedure for routine and emergency DKIM key rotation; the steady-state practice after Phase 4.
• DKIM best practices — the PHASE-1-PER-SELECTOR-DKIM-AUTHORING- RULE-CATALOGUE companion to this DMARC deployment-checklist reference. Where THIS page documents the four-phase deployment ladder (Phase 1 sender-inventory-and- monitoring-mode / Phase 2 alignment-fix- backlog-execution / Phase 3 quarantine-ramp / Phase 4 reject-ramp) and the per-phase exit- criteria gates the operator advances through, the DKIM-best-practices spoke documents the 15 prescriptive per-selector DKIM-authoring rules whose per-rule publisher-side compliance is the LOAD-BEARING UPSTREAM PREREQUISITE every Phase 1 DKIM-prerequisite-verification step + every Phase 2 per-sender alignment-fix backlog entry + every Phase 3 / Phase 4 per- percentage-ramp-exit-criteria gate THIS deployment checklist enforces STRUCTURALLY DEPENDS on. The PHASE-1-PER-SELECTOR-DKIM- BEST-PRACTICE cross-reference establishes FOUR structurally-distinct per-best-practice- rule-to-deployment-checklist-phase-gate coupling dimensions: (i) 2048-bit RSA minimum + dual k=rsa / k=ed25519 dual-publish discipline per RFC 8301 §3 + RFC 8463 as Phase 0 cryptographic-key-strength pre-deployment readiness audit input — the Phase 0 readiness audit this checklist's pre-Phase-1 gate enforces structurally depends on every production selector publishing keys at or above the RFC 8301 §3 RSA-2048 floor; selectors still publishing 1024-bit keys (a recurring defect class across selectors authored pre-2018) collapse the Phase 4 receiver-side DKIM-verification verdict to dkim=fail (insufficient key strength) at modern Microsoft / Google / Yahoo receivers — a canonical defect class the best-practices spoke documents as Rule 1 + Rule 2; (ii) annual rotation cadence with the 7-day-dual-selector-overlap + 30-day-in- flight-drain + 30-day-empty-p=- retention discipline as Phase 4 steady-state operational-discipline anchor — the Phase 4 reject-ramp steady-state operational discipline this checklist documents structurally depends on the per-selector rotation cadence being executed without producing a rotation-window dkim=fail spike in the aggregate-report row distribution; the best-practices spoke documents the canonical 67-day dual-selector overlap window as Rule 4 — the operational discipline that prevents rotation-driven DKIM-pass-rate regressions during steady-state; (iii) STRICT prohibition of the l= body-length tag as replay- attack vector + t=y burn-in cap of 24-72h then REMOVE as Phase 1 burn-in cleanup checklist item — the Phase 1 burn-in window's TERMINAL cleanup step this checklist enforces structurally depends on the publisher removing the t=y testing flag from every production selector before Phase 2 begins (stale t=y silently disables DMARC-via-DKIM evaluation at every receiver per RFC 6376 §3.6.1); the best-practices spoke documents the 24-72h burn-in cap as Rule 9 and the absolute prohibition of the l= body-length tag (Rule 8) — two byte-level publishing rules whose violation produces canonical Phase 1-cleanup defect classes; (iv) emergency revocation via empty- p= within minutes of compromise detection rather than record deletion as Phase 4 incident-response operational- discipline anchor — the Phase 4 steady-state incident-response runbook this checklist's Phase 4 exit-criteria gate structurally depends on the publisher executing emergency DKIM-key revocation by publishing an empty-p= selector record (a canonical RFC 6376 §3.6.1 revocation pattern) rather than deleting the selector TXT record (which collapses every in-flight message signed under that selector to dkim=permerror (selector NXDOMAIN) rather than the intended dkim=fail (revoked)); the best-practices spoke documents the empty-p= revocation pattern as Rule 13 — the load-bearing incident-response operational-discipline anchor whose Phase 4 steady-state execution distinguishes a controlled emergency-revocation outcome from a self-inflicted DKIM-cluster-wide outage. Read THIS deployment checklist WITH the DKIM-best-practices spoke when the per- selector DKIM-prerequisite-verification step arrives at the operator's queue: the checklist documents the DEPLOYMENT WORKFLOW STEPS, the best-practices spoke documents the 15 PER-SELECTOR PUBLISHING RULES every Phase 1 prerequisite-verification step + every Phase 2 per-sender alignment-fix backlog entry + every Phase 3 / Phase 4 per-percentage- ramp-exit-criteria gate structurally depends on.
• DKIM cryptography basics (RFC 8301) — the PHASE-0-CRYPTOGRAPHIC-PRIMITIVE- PRE-DEPLOYMENT-READINESS-AUDIT companion to this DMARC deployment-checklist reference. Where THIS page documents the four-phase deployment ladder (Phase 1 sender-inventory-and-monitoring-mode / Phase 2 alignment-fix-backlog-execution / Phase 3 quarantine-ramp / Phase 4 reject-ramp) and the per-phase exit- criteria gates the operator advances through, the DKIM cryptography basics spoke is the RFC 8301 cryptographic- primitive companion whose pre-Phase-1 cryptographic-key-generation / cryptographic- key-strength / cryptographic-algorithm- choice readiness audit is the structural Phase 0 prerequisite the entire deployment checklist THIS page documents depends on. The PHASE-0-CRYPTOGRAPHIC-PRIMITIVE- PRE-DEPLOYMENT-READINESS-AUDIT cross- reference establishes FOUR structurally- distinct cryptographic-primitive-vs- deployment-checklist-phase-gate dimensions: (i) Phase-0-RSA-2048- minimum-key-strength-readiness-audit- gate — Phase 1 sender-inventory- and-monitoring-mode begins by enumerating the operator's outbound sender population and the per-sender DKIM-signing posture; the Phase 0 pre-deployment readiness audit MUST verify every signing posture meets the RFC 8301 §3.1 RSA-2048-minimum- key-strength normative requirement BEFORE Phase 1 baseline measurements begin; any legacy RSA-1024 signers discovered during Phase 0 must be rotated to RSA-2048 (or migrated to Ed25519 per RFC 8463) before the Phase 1 baseline is locked, otherwise the Phase 2 alignment-fix backlog will inherit a structurally compromised cryptographic foundation; (ii) Phase-0-cryptographic-algorithm- deprecation-sweep-readiness-audit-gate — RFC 8301 §3.2 deprecates SHA-1 for DKIM signing (sunset 2018-11- 01); legacy signers using h=sha1 in the DKIM-Signature header produce silent dkim=fail verdicts at modern verifiers (Gmail, Microsoft 365); the Phase 0 readiness audit MUST sweep the operator's signing population for SHA-1-deprecated signers BEFORE Phase 1 baseline measurements begin, otherwise the Phase 1 baseline will see artificially-high dkim=fail rates that are NOT alignment-related and will confuse the Phase 2 alignment-fix- backlog triage; (iii) Phase-0- ed25519-algorithm-agility-readiness- evaluation-gate — RFC 8463 introduces Ed25519 as the post-RSA algorithm-agility path; operators deploying NEW DKIM signing keys during Phase 0 should evaluate Ed25519-vs-RSA per their ESP-vendor support matrix (Gmail / Microsoft 365 / SendGrid / Mailgun all support Ed25519 verification as of 2024; some legacy verifiers do NOT); the dual-signing pattern (publish BOTH an Ed25519 signature AND an RSA- 2048 signature with different selectors) is the algorithm-agility transition bridge per RFC 8463 normative guidance; Phase 0 cryptographic-algorithm-agility readiness evaluation determines the Phase 1 baseline measurement configuration; (iv) Phase-0- cryptographic-private-key-custody- readiness-audit-gate — DKIM private-key custody per RFC 6376 normative semantics MUST be confined to the operator's authorised outbound MTAs; Phase 0 readiness audit MUST inventory every location the DKIM private key is stored (production MTAs, staging MTAs, infrastructure-as-code secrets vaults, backup snapshots) and verify no leaked- key risk surfaces (unencrypted backups, committed-to-public-git, shared-with- third-party-ESP-without-rotation); any Phase 0 private-key-custody finding requires emergency key rotation (per the key- rotation playbook) BEFORE the Phase 1 baseline is locked, otherwise the Phase 4 reject-ramp posture will be structurally compromised by a known- leaked key. Pair this page (the four- phase DMARC deployment-checklist reference) with the DKIM cryptography basics spoke (the RFC 8301 cryptographic- primitive readiness-audit reference) when an operator begins the DMARC deployment ladder and needs to apply the same Phase 0 cryptographic-primitive readiness-audit discipline as the structural prerequisite that gates the Phase 1 baseline measurement / Phase 2 alignment-fix backlog execution / Phase 3 quarantine ramp / Phase 4 reject ramp deployment progression.
• DKIM failure verdicts explained — the PHASE-1-DISCOVERY-PER-SOURCE-IP-DKIM- VERDICT-CLASSIFICATION-AND-PHASE-2-TRIAGE- PER-VERDICT-ALIGNMENT-FIX-BACKLOG-EXECUTION- AND-PHASE-3-PHASE-4-PER-PERCENTAGE-RAMP-EXIT- CRITERIA-VERDICT-FLOOR-VERIFICATION companion to this four-phase deployment checklist. Where THIS page documents the operator-side phased rollout (Phase 1 Discovery -> Phase 2 Triage -> Phase 3 Quarantine -> Phase 4 Enforcement), the dkim-failures-explained spoke documents the seven canonical Authentication-Results dkim=X verdict-keyword catalogue with per-verdict receiver-side decode reference, per-verdict root-cause-class taxonomy (body-hash mismatch, signature-mismatch, multi-signature ordering collision, key-rotation gap, selector-misconfiguration, canonicalisation choice, third-party signer misalignment), and per-verdict per-mailbox-provider-receiver- behaviour reference operators consume to translate per-source-IP DKIM-verdict aggregate counts into concrete per-Phase decision evidence. Four DKIM-VERDICT-VS- DEPLOYMENT-PHASE-DECISION-INPUT axes the dkim-failures-explained spoke documents: (i) Phase 1 Discovery (p=none) as the PER-SOURCE-IP-DKIM-VERDICT- BASELINE-CLASSIFICATION-PHASE — the Phase 1 sender-inventory enumeration the checklist documents requires the operator to classify every Phase 1-collected per-source-IP aggregate-report row by its DKIM-verdict; the dkim-failures- explained spoke is the operator-side verdict-decode reference that converts each dkim=fail / dkim=permerror / dkim=temperror / dkim=none row into a concrete sender-classification (aligned- and-signed legitimate sender / mis-aligned legitimate sender / unsigned legitimate sender / suspicious sender / attacker traffic) the Phase 2 backlog enumerates against; (ii) Phase 2 Triage (alignment-fixing) as the PER-VERDICT- REMEDIATION-PATH-EXECUTION-PHASE — the Phase 2 backlog the checklist documents enumerates one alignment-fix task per Phase 1-discovered misaligned legitimate sender; the dkim-failures- explained spoke documents the per-verdict remediation-path mapping (dkim=fail body-hash mismatch -> sign before canonicalisation, dkim=permerror public-key-not-found -> publish DKIM TXT record at correct selector, dkim=fail signature-mismatch -> rotate compromised private key, dkim=none on legitimate sender -> enrol sender in DKIM signing via CNAME delegation or per-customer selector) every Phase 2 backlog entry resolves to; (iii) Phase 3 Quarantine (p=quarantine pct=N) as the PER-VERDICT-AGGREGATE-RATE-PER- PERCENTAGE-RAMP-EXIT-CRITERIA-PHASE — the Phase 3 per-percentage ramp (pct=10 -> pct=25 -> pct=50 -> pct=100 on a per-week cadence) STRUCTURALLY DEPENDS on the dkim-failures- explained spoke's per-verdict-decode reference to convert each per-week observed per-source-IP DKIM-verdict aggregate-rate into a concrete advance- or-hold decision; if the per-week observed dkim=fail / dkim=permerror aggregate-rate spikes on a legitimate-source IP, the operator MUST diagnose the regression via the dkim-failures-explained per- verdict ladder before advancing the per-percentage ramp; (iv) Phase 4 Enforcement (p=reject) as the PER-VERDICT-AGGREGATE-RATE-ROLLBACK- DECISION-TRIGGER-PHASE — the Phase 4 rollback procedure (lower p=reject back to p=quarantine within the per-DNS-TTL window) is triggered by a per-week observed dkim=fail aggregate-rate spike on legitimate-source IPs; the dkim-failures-explained spoke is the rollback-vs-hold decision reference operators consume to confirm the Phase 4-observed dkim=fail spike is a genuine misalignment regression rather than an attacker-driven baseline shift, AND to confirm the rollback procedure remediates the regression at the right per-verdict layer (DKIM TXT record / canonicalisation choice / signer selector / private-key rotation). Pair this deployment-checklist (the four-phase operator rollout) with the dkim-failures-explained spoke (the per-verdict-decode-and-remediation-path reference) for the complete deployment- execution-AND-DKIM-verdict-classification posture every operator needs to ramp DMARC from p=none to p=reject with per-verdict- driven Phase 2 backlog execution and per-percentage-ramp Phase 3 / Phase 4 per-verdict-aggregate-rate-exit-criteria decisions instead of blind aggregate- report-row-count gambling.
• DKIM canonicalization — the PHASE-1-DKIM-PUBLICATION- AUTHORING-CANONICALIZATION-ALGORITHM- CHOICE companion to this 6-phase DMARC deployment checklist. Where THIS page documents the per-phase prerequisite- verification + per-sender backlog execution + per-percentage-ramp exit- criteria gate workflow, the DKIM- canonicalization spoke documents the RFC 6376 §3.4 four-combination algorithm catalogue whose per-publisher per- selector authoring choice at the Phase 1 DKIM-record-publication step is the LOAD-BEARING UPSTREAM DETERMINANT of the per-message DKIM-pass-vs-fail verdict distribution every downstream phase consumes. Three concrete checklist-vs-canonicalization coupling points: (i) Phase 1 DKIM- record-publication authoring — the canonical operator-side best- practice is to publish c=relaxed/relaxed so the Phase 1 DKIM-prerequisite-verification baseline is established against the most forwarder-tolerant algorithm pair; the DKIM-canonicalization spoke documents the byte-level whitespace- tolerance rules each algorithm pair guarantees vs which mutations break each pair; (ii) Phase 2 per- sender DKIM-alignment-remediation backlog root-cause discrimination — when the Phase 1 RUA stream surfaces per-sender DKIM-fail-rate-above-floor rows, the Phase 2 backlog must discriminate canonicalization-axis root-cause (the per-publisher c=-tag choice cannot survive the per-sender forwarder mix) from key-rotation-axis root-cause from selector-publication-axis root-cause; the DKIM-canonicalization spoke documents the per-algorithm failure- signature catalogue the Phase 2 triage matrix consumes; (iii) Phase 3 / Phase 4 pct=N ramp exit-criteria gate — the per-phase exit- criteria require a per-domain DKIM- pass-rate floor that is structurally bounded by the canonicalization- algorithm choice; the DKIM- canonicalization spoke documents the per-algorithm expected-pass-rate baseline the deployment checklist's per-phase exit-criteria gate the ramp progression against. Read the DKIM-canonicalization spoke as the Phase 1 DKIM-publication-authoring prerequisite reference AND as the Phase 2 DKIM-failure backlog root- cause discrimination axis reference whenever the deployment checklist executes the per-phase ramp.
• DKIM troubleshooting (symptom-driven debugging) — the DEPLOYMENT-CHECKLIST-PHASED- RAMP-EMBEDS-PER-PHASE-DKIM- TROUBLESHOOTING-COROLLARY companion to this 6-phase DMARC deployment checklist. Where THIS page documents the 6-phase ramp the operator follows from green-field deployment through p=reject steady-state (Phase 1 sender-inventory discovery via aggregate-report row analysis; Phase 2 per-misaligned-sender DKIM / SPF authoring backlog; Phase 3 pct=N quarantine ramp at 10% → 25% → 50% → 100%; Phase 4 pct=N reject ramp; Phase 5 p=reject steady-state; Phase 6 complementary controls — MTA-STS, TLS-RPT, BIMI), the DKIM-troubleshooting spoke documents the SYMPTOM-DRIVEN DEBUGGING PLAYBOOK whose per- symptom triage flow embeds AS STRUCTURAL COROLLARIES at each phase of the ramp — every checklist phase has a phase- specific DKIM-troubleshooting- event class the operator must be PREPARED to execute. FOUR structurally-distinct PHASE-VS- DKIM-TROUBLESHOOTING-EVENT dimensions emerge: (1) Phase 1 sender-inventory- discovery-as-portfolio-wide- DKIM-coverage-gap-troubleshooting at the per-source_ip-dkim=none- verdict-row vs publisher- authorised-sender-inventory joint-investigation boundary — the troubleshooting-spoke documents the per-source_ip dkim=none-verdict triage flow where the operator identifies legitimate-publisher- sender streams that are NOT DKIM-signing (and thus require Phase 2 DKIM-authoring backlog entries) vs unfamiliar-source_ip streams that are unauthorised senders (and thus do NOT enter the Phase 2 backlog). Phase 1 of the checklist DEPENDS on the troubleshooting-spoke's per- source_ip per-verdict diagnostic capability to triage the RUA stream's source_ip cohort into legitimate-but-unsigned vs unauthorised-sender classes. THIS page's Phase 1 discovery step is the deployment-lifecycle primitive the troubleshooting playbook proves is the structural diagnostic-corollary at the sender-inventory boundary. (2) Phase 2 mis-alignment- backlog-execution-as-per-stream- DKIM-deployment-troubleshooting at the per-publisher-stream per-d=-record DKIM-publication- verification boundary — the troubleshooting-spoke documents the per-stream DKIM- record-publication verification flow where the operator confirms each Phase 2 backlog entry produces a working dkim=pass verdict in the RUA stream after the operator publishes the DKIM record. Phase 2 of the checklist DEPENDS on the troubleshooting-spoke's per- publisher-stream verification capability to confirm each Phase 2 backlog item closes cleanly (vs leaks dkim=permerror due to TXT-record syntax error, or dkim=temperror due to DNS-resolver-side caching issue, or dkim=fail due to canonicalization-vs- forwarder-modification mismatch). THIS page's Phase 2 backlog-execution step is the deployment-lifecycle primitive the troubleshooting playbook proves is the structural diagnostic- corollary at the per-stream DKIM-publication-verification boundary. (3) Phase 3/4 pct=N-ramp-as-per-percentage- ramp-exit-criteria-DKIM- verdict-floor-troubleshooting at the per-pct=N-window per-day per-source_ip dkim=pass-rate baseline-deviation boundary — the troubleshooting-spoke documents the per-pct=N- window per-source_ip per-day dkim=pass-rate baseline triage flow where the operator monitors the ramp's per-percentage exit criteria: a clean ramp completion REQUIRES per- source_ip dkim=pass- rate to remain at the floor-rate observed in the pre-ramp Phase 2 baseline, AND a baseline-deviation during the ramp indicates a per-source_ip DKIM- infrastructure event the troubleshooting playbook must surface BEFORE the operator advances to the next pct=N percentage. Phase 3/4 of the checklist DEPENDS on the troubleshooting-spoke's per-pct=N per-source_ip per- day verdict-floor monitoring capability to gate each percentage advance on verdict-stability evidence. THIS page's Phase 3/4 pct=N ramp steps are the deployment-lifecycle primitive the troubleshooting playbook proves is the structural diagnostic- corollary at the per- percentage-exit-criteria boundary. (4) Phase 5 p=reject-steady-state-as- post-deployment-DKIM- regression-detection- troubleshooting at the per- day RUA-stream-aggregate- verdict-floor regression boundary — the troubleshooting-spoke documents the post- deployment steady-state verdict-floor regression detection flow where the operator runs continuous per-day per-source_ip per-verdict aggregate-rate monitoring AT THE p=reject steady state to detect REGRESSIONS (a new ESP introduced an unsigned-stream, a DKIM- key-rotation event broke a portfolio-domain signer, an attacker-bypass campaign is concentrated on a weakest-link portfolio domain). Phase 5 of the checklist DEPENDS on the troubleshooting-spoke's post-deployment regression- detection capability to guarantee the p=reject steady-state remains a stable deliverability posture vs collapsing into per-stream-breakage. THIS page's Phase 5 steady-state step is the deployment- lifecycle primitive the troubleshooting playbook proves is the structural diagnostic-corollary at the post-deployment regression-detection boundary. Read the troubleshooting-spoke alongside THIS page when the operator is executing the 6-phase ramp: this page tells you WHAT EACH PHASE'S DECISION- POINTS ARE, the troubleshooting-spoke tells you WHAT SYMPTOM- SIGNATURES per-phase emerge in the RUA stream that the operator must triage AT EACH PHASE BOUNDARY AND WHY the per-symptom playbook is a structurally-necessary per-phase corollary.
• DMARC for Google Workspace - per-MUA deployment guide.
• MTA-STS for Google Workspace - the WORKSPACE-TENANT-MTA-STS-DEPLOYMENT- AS-OPTIONAL-BUT-STRONGLY-RECOMMENDED-PHASE- 5-TRANSPORT-LAYER-CHECKLIST-ITEM-RUNNING- ALONGSIDE-DMARC-p-reject-STEADY-STATE- MONITORING companion to this provider- agnostic DMARC deployment checklist. Where THIS page documents the provider-agnostic five-phase DMARC deployment procedure (Phase 0 TTL discipline → Phase 1 p=none baseline → Phase 2 SPF/DKIM alignment fixes → Phase 3 p=quarantine with pct= ramp → Phase 4 p=reject at 100% → Phase 5 steady-state monitoring) — i.e. the APPLICATION-LAYER MESSAGE-IDENTIFIER- AUTHENTICATION-POLICY deployment checklist side of the full-stack email-security deployment — the MTA-STS-for-Google- Workspace spoke is the WORKSPACE-TENANT- SPECIFIC TRANSPORT-LAYER PHASE-5 CHECKLIST COMPANION documenting the Workspace- tenant-specific MTA-STS deployment procedure that operators on Workspace- hosted domains add to the Phase 5 steady-state monitoring scope: (i) the Workspace MTA-STS deployment is a transport-layer-hardening procedure operators COMMONLY ship in the same deployment window as the Phase 4 p=reject flip OR during Phase 5 steady-state — both timings are defensible; the Workspace spoke documents the operator-choice trade-offs between parallel (ship MTA-STS-enforce and DMARC-reject in the same window) and sequential (ship MTA-STS-enforce after DMARC-reject has stabilised in Phase 5); (ii) the Workspace MTA-STS publication mechanics (the _mta-sts.<workspace-domain> TXT record + the https://mta-sts.<workspace- domain>/.well-known/mta-sts.txt HTTPS-hosted policy file with version: STSv1 + mode: testing|enforce + the 5-host tier'd Workspace MX inventory mx: aspmx.l.google.com + mx: alt{1,2,3,4}.aspmx.l.google.com + appropriate max_age:) are STRUCTURALLY-DISTINCT from the DMARC authoring this page documents — the operator MUST acquire a public-PKI certificate for the mta-sts.<workspace-domain> host (Let's Encrypt is the canonical choice, requires customer-domain CAA authorization), MUST host the policy file at the well-known path, MUST coordinate the mx: directive with the published MX RRset — none of these steps are part of the DMARC publication checklist this page documents; (iii) the Workspace MTA-STS mode:testing phase parallels Phase 1 p=none baseline monitoring — both publish- without-enforcement phases let the operator collect receiver-side feedback (TLS-RPT for MTA-STS-testing, RUA for DMARC-none) before flipping to enforcement; operators on Workspace commonly run these phases concurrently to compress the total deployment calendar; (iv) the Workspace MTA-STS mode:enforce phase parallels Phase 4 p=reject at 100% — both enforcement-with-real-consequences flips require receiver-side cooperation and produce deliverability cliffs if misconfigured; the Workspace spoke documents the per-phase verification steps the operator runs (the dig +short mta-sts.<workspace- domain> cert-chain sanity check, the TLS-RPT subscriber-endpoint validation, the post-flip TLS-RPT aggregate-report monitoring) before declaring Phase 5 steady-state complete. Read the MTA-STS-for-Google-Workspace spoke alongside this DMARC deployment checklist when planning the full email- security deployment calendar for a Workspace-hosted domain — the Workspace- tenant-specific MTA-STS publication procedure the spoke documents is the optional-but-strongly-recommended transport-layer Phase 5 checklist item that pairs with the DMARC p=reject steady-state this page's Phase 4-to-5 transition delivers.
• DMARC for Microsoft 365 - per-MUA deployment guide.
• DMARC for hybrid Exchange (on-premises + Exchange Online) — the HYBRID-EXCHANGE-DUAL-EGRESS-PATH- DEPLOYMENT-PROCEDURAL-CHECKLIST-COORDINATION companion to this provider-agnostic deployment checklist. Where THIS page is the PROVIDER-AGNOSTIC procedural reference (Phase 0 TTL discipline → Phase 1 p=none baseline + SPF/DKIM inventory → Phase 2 SPF/DKIM alignment fixes → Phase 3 p=quarantine with pct= ramp → Phase 4 p=reject at 100% → Phase 5 steady-state monitoring), the dmarc-for- office-365-hybrid spoke is the HYBRID- EXCHANGE-DUAL-EGRESS-PATH-DEPLOYMENT companion documenting how each checklist phase coordinates across the TWO outbound mail-flow boundaries a hybrid Exchange topology induces. Concretely, the spoke documents FOUR hybrid-Exchange-deployment- checklist-coordination dimensions: (i) Phase 1 sender inventory must enumerate BOTH egress paths separately — on-premises Exchange outbound mail (egressing through the perimeter firewall NAT pool, signed by an on-prem DKIM transport agent) AND Exchange Online outbound mail (egressing through spf.protection.outlook.com, signed by the cloud-side selector1 / selector2 CNAME-delegated keys) must both appear as DISTINCT rows in the operator's sender-inventory spreadsheet, because each path produces independent aggregate-report rows whose SPF/DKIM-pass and alignment dispositions must be tracked separately during the Phase 3 p=quarantine ramp; (ii) Centralized Mail Transport (CMT) collapses dual-egress-path checklist coordination to single-egress- path — when the operator enables CMT (Set-HybridConfiguration -CentralizedTransportEnabled $true), all outbound mail relays through Exchange Online which becomes the SOLE outbound boundary, and the deployment checklist collapses back to the standard cloud-only ramp THIS page documents — the operator publishes ONLY include:spf.protection.outlook.com for SPF, runs ONLY Set-DkimSigningConfig on the cloud side for DKIM, and applies the provider-agnostic phase ramp WITHOUT per-egress-path bifurcation; (iii) classic-hybrid topology with on- prem outbound requires ARC sealing as a Phase 1 prerequisite step the provider- agnostic checklist does not require — when CMT is not used and on-prem remains a parallel outbound boundary, the on-prem DKIM signer must additionally publish ARC seals (ARC-Seal + ARC-Message-Signature + ARC-Authentication-Results) BEFORE Phase 1 baseline mail starts flowing, and the operator must register the on-prem signing domain as a Trusted ARC Sealer in Defender for Office 365 (Set-ArcConfig -ArcTrustedSealers your-onprem-fqdn) — without this Phase 1 prerequisite, every hybrid-relayed message arrives at Exchange Online with broken SPF / DKIM verdicts because the relay invalidates the original alignment; and (iv) Phase 5 terminal p=reject in hybrid Exchange surfaces Default Frontend Connector DKIM-strip and Send-Connector- relay-loop failure modes the provider- agnostic checklist does not anticipate — the hybrid checklist additionally requires verifying Set-Connector -PreserveSmtpHeaders $true on the matching Exchange Online inbound connector (so the on-prem DKIM signature survives the cloud relay) AND verifying the HCW-generated connector pair does NOT overlap with manually-created Send Connectors (avoiding NDR 5.4.6 "Hop count exceeded" relay loops between the two boundaries). Read the DMARC-for-hybrid- Exchange spoke alongside this checklist when authoring the deployment runbook for a hybrid Exchange portfolio: the provider-agnostic phase ramp THIS page documents applies, but the per-egress- path bifurcation (or CMT collapse) and the ARC-sealer Phase 1 prerequisite change the SHAPE of the deployment workflow the spoke makes explicit.
• DMARC for cPanel — the cPanel-tenant deployment guide (the CPANEL-TENANT-CROSS-PROVIDER-DEPLOYMENT-WORKFLOW companion to this provider-agnostic checklist) - the CPANEL-TENANT-CROSS-PROVIDER-DEPLOYMENT-WORKFLOW companion documenting the cPanel-tenant-specific adaptation of this provider-agnostic deployment checklist. Where THIS page is the PROVIDER-AGNOSTIC procedural reference (Phase 0 TTL discipline → Phase 1 p=none baseline → Phase 2 SPF/DKIM alignment fixes → Phase 3 p=quarantine with pct= ramp → Phase 4 p=reject at 100% → Phase 5 steady-state monitoring — all framed for operators on ANY hosting platform), the dmarc_for_cpanel spoke is the CPANEL-SPECIFIC DEEP DIVE that documents how each phase translates to the cPanel UI surface. The cPanel deployment has FIVE cPanel-tenant-specific workflow deviations from this provider-agnostic checklist the cross-reference makes explicit: (i) Phase 0 TTL discipline maps to the cPanel Zone Editor "Edit" → TTL field — cPanel's default 14400-second TTL must be lowered to 300 seconds via Zone Editor 48 hours before Phase 1, otherwise the operator cannot roll back quickly if Phase 1's p=none publication surfaces a forwarding-break in the RUA stream; (ii) Phase 1 RUA-stream baseline must accommodate cPanel's shared outbound MTA — cPanel shared-hosting tenants often see RUA records dominated by d=<provider-domain> rather than d=<customer-domain> because the provider's MTA signs outbound mail with the provider's identity, so the sender-inventory must distinguish provider-MTA traffic from custom-domain-aligned traffic; (iii) Phase 2 SPF + DKIM alignment fixes face cPanel's operator-empowerment ceiling — most shared-hosting cPanel platforms do NOT support per-tenant custom-domain DKIM signing, meaning DKIM alignment for outbound transactional mail must be achieved via third-party ESP relay (e.g., SendGrid + cPanel SMTP proxy) rather than via cPanel's own MTA; (iv) Phase 3 p=quarantine with pct= ramp deployed via cPanel Zone Editor TXT-record edit — each ramp-step (pct=10 → pct=25 → pct=50 → pct=100) requires a Zone Editor edit + the DNS-propagation window documented in this checklist's TTL discipline; (v) Phase 5 steady-state monitoring may face cPanel's shared-IP-block reputation observability gap — per-tenant Postmaster Tools is unavailable when the IP block is shared across hundreds of tenants, so the cPanel deployment relies more heavily on RUA-stream-based observability than on per-receiver postmaster feedback. Read the cPanel deployment spoke when the deploying operator is on cPanel — the spoke is the per-provider procedural reference that contextualizes every step on THIS provider-agnostic checklist to the cPanel operator-empowerment surface.
• DMARC for transactional email - per-ESP deployment guide (SendGrid, Mailgun, SES, Postmark, SparkPost).
• DMARC for SaaS senders - marketing automation deployment guide (Mailchimp, HubSpot, Marketo, Salesforce Marketing Cloud, Klaviyo).
• DMARC for shared hosting (cPanel / Plesk / DirectAdmin) - per-provider deployment guide for the shared-hosting operator persona this provider-agnostic checklist necessarily leaves provider-detail-light. Where THIS checklist is the PROVIDER-AGNOSTIC procedural reference (pre-flight sender inventory, SPF + DKIM prerequisite verification, baseline RUA-stream instrumentation, initial p=none record construction, receiver-side propagation verification, post-publication monitoring cadence — all framed in terms applicable to any sender operator persona), the shared-hosting spoke is the provider-SPECIFIC deep dive that documents the cPanel / Plesk / DirectAdmin-specific procedural adaptations: where exactly in the control-panel UI to publish the _dmarc.<domain> TXT record (cPanel: Zone Editor; Plesk: Hosting Settings → DNS; DirectAdmin: DNS Management), how to inventory legitimate senders when many shared- hosting tenants send via the provider's SHARED outbound MTA whose d= domain belongs to the provider not to the tenant, the operator-empowerment ceiling that constrains custom-domain DKIM configuration (most shared-hosting platforms do NOT support per-tenant custom-domain DKIM signing — the provider's MTA signs all outbound mail with the provider's d= domain), the shared-IP-block reputation observability gap (per-tenant Postmaster Tools is unavailable when the IP block is shared across hundreds of tenants), and the ?all qualifier degradation many shared-hosting platforms force on operators (because the platform cannot enumerate ALL legitimate sending IPs for an -all hard-fail record without breaking tenants who use third-party ESPs from outside the platform's IP block). Read the shared- hosting spoke when the deploying operator is on cPanel / Plesk / DirectAdmin / any shared-hosting platform — the spoke is the authoritative per-provider procedural reference that contextualizes every step on THIS provider-agnostic checklist to the shared-hosting operator-empowerment ceiling.
• Multi-domain DMARC strategy - the PORTFOLIO-DEPLOYMENT-CHECKLIST-SCALING companion to this provider-agnostic DMARC deployment checklist. Where THIS checklist documents the SINGLE-DOMAIN PROCEDURAL REFERENCE for first-time DMARC deployment (Phase 0 TTL discipline → Phase 1 p=none baseline → Phase 2 SPF / DKIM alignment fixes → Phase 3 p=quarantine with pct= ramp → Phase 4 p=reject at 100% → Phase 5 steady-state monitoring) all framed for ONE apex domain, the multi-domain-strategy spoke documents the PORTFOLIO-COORDINATION decision framework that becomes load- bearing when the operator must apply THIS checklist across 3-30+ sender domains simultaneously. The portfolio-scaling constraint is STRUCTURALLY-DIFFERENT from the single-domain rollout the checklist anticipates because (i) per- domain phased-rollout staging cannot be calendar-aligned across the portfolio — domains with high-confidence sender inventories (the apex corporate domain) advance faster through Phase 1 → Phase 4 than domains with uncertain inventories (defensive parked-domains, acquired-startup mail-history domains, per-region sub-brand domains with unknown legacy senders), (ii) portfolio-wide ramp coordination means the operator must decide whether to advance domains in SEQUENCE (apex first → parked-domains second → per-brand subdomains third — risk-minimising but timeline-slow) or in PARALLEL (every portfolio domain advances Phase 1 → Phase 4 simultaneously — timeline-fast but operator-attention- compounding), (iii) cross-domain KPI synthesis means the operator must consolidate per-domain RUA streams into a portfolio dashboard (per-domain unauthenticated-volume, per-domain unknown-source-volume, per-domain policy-override-rate, per-domain DKIM-pass-rate / SPF-pass-rate / DMARC-aligned-rate) because checklist Phase 5 steady-state monitoring is unmanageable as N independent per-domain monitoring streams, (iv) per- domain checklist customisation means each portfolio domain follows a STRUCTURALLY-DIFFERENT checklist adaptation depending on its position in the four-pattern portfolio decision- framework the multi-domain spoke catalogues: the apex domain follows the full Phase 0 → Phase 5 checklist, the parked-domain defensive-registration follows a Phase-0 → Phase-1-only lockdown checklist (p=reject + v=spf1 -all + null-MX from Day 0, no ramp required), the acquired-domain wind-down follows a modified Phase 1 → Phase 2 short-ramp checklist (60-day rather than 26-week timeline), and the per-region sub-brand domains follow the full Phase 0 → Phase 5 but with each Phase's observation-window calibrated to the sub-brand's lower mail-volume baseline. The multi-domain spoke documents the load-bearing Public Suffix List (PSL) organisational-domain boundary that governs which portfolio subdomains the apex's sp= tag covers (Phase 2's subdomain-policy authoring step is portfolio-dependent), the np= tag (RFC 9091) for non-existent subdomain policy that hardens the apex against attacker- spoofing of invented-subdomain rendezvous addresses (a Phase-2 recommendation that becomes Phase-1 critical for portfolios with public sub-brand discovery), and the per-organisational-domain independent _dmarc. record requirement for portfolio domains under SEPARATE registered organisational-domains (the portfolio's apex-sp= does NOT cover them). Read the multi-domain spoke at the moment the operator prepares to apply THIS checklist across the SECOND portfolio domain — the portfolio-coordination decision framework is the load-bearing adaptation reference for every portfolio-scaled DMARC rollout.
• Email authentication glossary - definitions of every term used on this page.
• Business Email Compromise (BEC) - the financial-fraud threat scenario that makes the entire deployment investment justifiable - the operational deep dive on the financial-fraud threat scenario that makes the entire deployment- checklist investment justifiable. Where THIS checklist documents the PROCEDURAL REFERENCE for first-time DMARC deployment (pre-flight inventory, SPF + DKIM verification, baseline RUA instrumentation, initial p=none publication, propagation verification, 30-60-day monitoring cadence, advancement to p=quarantine and p=reject), the BEC spoke documents the THREAT-MODEL JUSTIFICATION that makes the procedural investment worth the operational risk - the financial-impact data and threat- pattern catalogue that converts the checklist from a "compliance exercise" into a "fraud-prevention control". Specifically: the BEC spoke catalogues the FBI IC3 data on Business Email Compromise losses (cumulative $50B+ 2013-2022 with $2.7B-$2.9B annual run rate 2019-2023) that justifies the procedural investment to skeptical finance / legal / executive stakeholders, the six canonical BEC variants (CEO fraud, vendor-invoice fraud, payroll-redirect, attorney impersonation, W-2 / data theft, account-compromise BEC) that map to specific deployment-checklist phase-exit decisions, the five-stage BEC kill chain (recon → setup → pretexting → execution → laundering) that explains why p=none alone is insufficient even after every deployment-checklist step on THIS page is satisfied, the precise DMARC gap (DMARC closes exact-domain spoofing BEC but NOT look-alike-domain or display-name BEC) that informs Phase 4+ defense-in-depth planning beyond the checklist, and the full defense-in-depth control stack (DMARC enforcement + wire-transfer verification + look-alike-domain monitoring + employee training) operators need beyond the deployment- checklist core. Where THIS checklist is the HOW of DMARC deployment, the BEC spoke is the WHY - the financial-impact threat scenario that gives every phase advance its business stakes. Read the BEC spoke when building the executive / finance / legal case for why the deployment-checklist procedure is worth the operational investment - the spoke is the authoritative threat-model reference that justifies every step on this checklist.
• BIMI explained — the POST-DMARC-ENFORCEMENT-BRAND-TRUST- MONETISATION-PILLAR companion to this deployment checklist. Where THIS page documents the WORKFLOW THAT REACHES p=quarantine / p=reject terminal enforcement (Phase 0 TTL discipline → Phase 1 SPF + DKIM prerequisite verification → Phase 2 RUA monitoring inventory → Phase 3 p=none observation → Phase 4 p=quarantine pct=N ramp → Phase 5 terminal p=reject pct=100), the BIMI-explained pillar documents the BRAND-TRUST-MONETISATION OUTCOME that becomes operationally available at the Phase 5 terminal state: the publisher's authoritative DNS publishes a default._bimi.<author- domain> TXT RR carrying the v=BIMI1; version-prefix plus the l=<SVG-Tiny-PS-URL> tag-value pointing at the publisher's brand-logo asset plus the optional a=<VMC-URL> tag-value pointing at the trademark-bound X.509 Verified Mark Certificate (or the free Common Mark Certificate equivalent), and Gmail / Yahoo / Apple Mail / Fastmail receivers render the per-message brand-indicator at the recipient-side consumer-inbox-view — STRUCTURALLY GATED on the per-message DMARC-aligned-pass verdict at a publisher policy of p=quarantine or p=reject (Gmail historically required p=quarantine pct=100 or better; the receiver-side rendering policy verifies the publisher's terminal DMARC enforcement state at the moment of each per-message rendering decision). Read this WITH the checklist when the operator's Phase 6 question is "what comes after p=reject?": the checklist documents how to GET to terminal enforcement, the BIMI-explained pillar documents the brand-trust-monetisation OUTCOME that terminal enforcement unlocks at the publisher's recipient-side brand-impression surface — the canonical commercial- justification artefact for the multi-week Phase 1-through-Phase 5 ramp investment.
• BIMI Verified Mark Certificates (VMC / CMC) - the certificate-side prerequisite reference for the BIMI-as-final-step item already cited in this checklist's section 5 "Consider adding BIMI" recommendation. Where THIS checklist documents BIMI as a downstream rollout milestone gated on DMARC reaching p=quarantine or p=reject, the BIMI certificates spoke documents the FULL upstream certificate procurement workflow operators must complete BEFORE BIMI deployment is operationally viable: the trademark-registration prerequisite (USPTO / EUIPO / UKIPO / JPO or other WIPO-recognised national IP office — registration must be ACTIVE and current at the time of CA verification), the dual-CA-vendor landscape (DigiCert + Entrust as the only qualified VMC issuers, neither available through the general-purpose web PKI TLS-certificate storefront — operators familiar with Let's Encrypt / commodity DV TLS-cert procurement need a different vendor relationship for VMC), the VMC vs CMC selection logic (registered-trademark domains get VMC honored by Gmail / Yahoo / Apple Mail / Fastmail; unregistered-trademark domains with prior-use evidence get CMC honored only by Apple Mail), the indicator-uri / mark-type tag binding from the certificate Subject CN to the SVG asset URI in the BIMI DNS TXT record, and the 1-to-2-year renewal cadence with annual CA re-verification of trademark registration status. Read this when the BIMI checklist item from section 5 graduates from "consider" to "execute" — the certificates spoke is the procurement prerequisite an operator runs in parallel with the SVG-asset-preparation prerequisite.
• BIMI SVG Tiny Portable / Secure profile requirements - the asset-preparation prerequisite reference for the BIMI-as-final-step item cited in this checklist's section 5. Where THIS checklist documents BIMI as a downstream rollout milestone, the BIMI SVG-requirements spoke documents the FILE-format constraints operators must apply to the brand logo BEFORE BIMI deployment can be validated by the CA and rendered by honoring mailbox providers. The format is SVG Tiny 1.2 Portable / Secure (SVG-T-P/S): no scripts (no <script> elements, no event-handler attributes), no external references (no remote <use href="https://...">, no remote font imports), no animation elements, fixed viewBox square aspect (1:1), file size capped at 32 KB post-optimisation, and text-as-paths only (no external font references). Brand teams unfamiliar with the SVG-T-P/S subset frequently deliver a brand-asset SVG that includes a remote font reference or a decorative animation, both of which cause CA-side validation rejection — the SVG-requirements page documents the FULL operator-runnable validation rules and the common preparation-step pitfalls (Adobe Illustrator export defaults include features the subset forbids; the SVG asset typically requires a manual post-export normalisation pass to comply). Read this when the BIMI checklist item graduates from "consider" to "execute" — the SVG-requirements spoke is the asset-preparation prerequisite an operator runs in parallel with the certificate-procurement prerequisite. The two prerequisites converge at BIMI DNS publish time: the default._bimi.<domain> TXT record references the SVG asset URI (l= tag) and the VMC URI (a= tag) — both must validate for the mailbox provider to render the brand logo in the inbox.
• TLS-RPT record syntax — the DEPLOYMENT-CHECKLIST-TLS-RPT- PUBLICATION-STEP-BYTE-SYNTAX-REFERENCE companion reference. Where THIS page documents the END-TO-END deployment checklist (SPF publication, DKIM publication, DMARC monitor → quarantine → reject progression, MTA-STS policy publication, BIMI asset preparation, TLS-RPT co-publication for transport- layer reporting, CAA hardening, DNSSEC zone signing), the TLS-RPT-record- syntax spoke is the BYTE-LEVEL CANONICAL REFERENCE for the TLS-RPT publication step in the record-roster: the _smtp._tls.<domain> TXT record location (NOT the apex domain — the underscore-prefixed sub- zone per RFC 8460 §3.1), the v=TLSRPTv1 version identifier (the canonical version tag every TLS-RPT-aware sender expects), the rua=mailto:... or rua=https://... report delivery target (the per-receiver TLS- encryption failure aggregate report destination), and the per-tag canonicalisation discipline (whitespace sensitivity, semicolon separator, ordering constraints) every TLS-RPT publication must satisfy. Read the TLS-RPT-record-syntax spoke alongside this page when executing the TRANSPORT-ENCRYPTION-MONITORING step of the deployment checklist — this page gives the WHEN-TO-PUBLISH ordering in the linear checklist (after MTA-STS policy goes live, before BIMI asset preparation), the TLS-RPT-record-syntax spoke gives the WHAT-TO-PUBLISH byte- level reference for the actual TXT record value the checklist step produces.
• DKIM for Microsoft 365 - the DEPLOYMENT-CHECKLIST-M365-TENANT- DKIM-PUBLICATION-STEP-PER-TENANT- SELECTOR-CNAME-ENABLEMENT companion reference. Where THIS page documents the LINEAR DMARC deployment checklist (DNS inventory, SPF authoring, DKIM publication, DMARC p=none monitoring, progressive enforcement to p=quarantine then p=reject, MTA-STS, TLS-RPT, BIMI, CAA, DNSSEC, ramp-gate criteria), the DKIM-for-Microsoft-365 spoke documents the EXCHANGE-ONLINE- TENANT-SPECIFIC DKIM publication mechanics — the two selector1._domainkey.<domain> and selector2._domainkey.<domain> CNAME records targeting selector1-<tenant>._domainkey.<onmicrosoft.com> and selector2-<tenant>._domainkey.<onmicrosoft.com> respectively that delegate DKIM key management to Microsoft 365's tenant-managed key infrastructure (with automatic 1024→2048-bit rotation, dual-selector overlap rotation, and tenant-portal signing enablement). When the operator's primary mail relay is Exchange Online (the canonical M365 deployment topology), the checklist's DKIM-publication step IS the M365 CNAME publication step — there is no separate "self-managed DKIM key" path on M365 unless the operator opts into the rarely-used BYO-key mode. Read the M365-DKIM spoke alongside this page when executing the DKIM-publication step on a domain whose primary mail egress is M365 Exchange Online — the CNAME publication and tenant-portal DKIM enablement together close the checklist's DKIM step on the M365 topology.
• DKIM for Google Workspace - the DEPLOYMENT-CHECKLIST-WORKSPACE- TENANT-DKIM-TXT-PUBLICATION-STEP-PER- OPERATOR-CONTROLLED-KEY-CUSTODY companion reference. Where THIS page documents the LINEAR DMARC deployment checklist (DNS inventory, SPF authoring, DKIM publication, DMARC p=none monitoring, progressive enforcement to p=quarantine then p=reject, MTA-STS, TLS-RPT, BIMI, CAA, DNSSEC, ramp-gate criteria), the DKIM-for-Google-Workspace spoke documents the WORKSPACE-TENANT- SPECIFIC DKIM publication mechanics — the single <selector>._domainkey.<domain> TXT record (typically named google._domainkey or a rotation-aware selector like 2026q2._domainkey) carrying an OPERATOR-GENERATED 2048-bit RSA public key whose corresponding private key remains in Workspace Admin Console- managed signing infrastructure, with MANUAL single-selector key rotation (no automatic dual-selector overlap rotation like M365), the 255-byte TXT-chunk concatenation rule (p= tag's base64 key must be split into 255-byte segments wrapped in adjacent quoted strings within the same TXT record so resolvers concatenate them at lookup time), and the gappssmtp.com signing-identity gotcha (Workspace fall-back signing identity when domain DKIM is not yet activated or misconfigured — produces d=<tenant>.gappssmtp.com signatures that DMARC-align with the gappssmtp.com domain rather than the operator's intended sending domain). When the operator's primary mail egress is Google Workspace SMTP relay (the canonical Workspace deployment topology), the checklist's DKIM-publication step IS the Workspace TXT publication step — but unlike M365's CNAME-delegation model (where Microsoft manages key custody), the Workspace TXT-publication model places key custody and rotation operations on the operator. Read the Workspace-DKIM spoke alongside this page when executing the DKIM-publication step on a domain whose primary mail egress is Google Workspace — the TXT publication plus Workspace Admin Console DKIM activation together close the checklist's DKIM step on the Workspace topology, and the manual single-selector rotation procedure documented in the Workspace- DKIM spoke is what the checklist's "key rotation cadence" guidance operationally requires when the operator's DKIM keys are operator-custodied rather than platform-managed.
• Why SPF alone is insufficient — the DEPLOYMENT-CHECKLIST-MULTI-PHASE- WORKFLOW-AS-OPERATIONAL-EMBODIMENT-OF-THE- SPF-ALONE-INSUFFICIENT-THESIS companion to this deployment-checklist reference. Where THIS page documents the GREEN-PATH DEPLOYMENT WORKFLOW step-by-step (Phase 0 TTL discipline, Phase 1 SPF + DKIM prerequisite verification, Phase 2 alignment- fixing triage, Phase 3 p=none observation window, Phase 4 p=quarantine pct=10 ramp, Phase 5 terminal p=reject pct=100), the SPF-alone-insufficient thesis page is the STRUCTURAL-PROTOCOL-LEVEL companion articulating the first-principles argument WHY the workflow this checklist documents EXISTS AT ALL — an argument the multi-phase checklist IS the operational embodiment of, at FOUR per-phase workflow-evidence dimensions: (i) PHASE-1-DUAL-PREREQUISITE — both SPF AND DKIM are prerequisites, not just SPF; the dual prerequisite IS the workflow-level expression of the SPF-alone-insufficient thesis — if SPF alone were sufficient, the checklist's Phase 1 would terminate at "publish SPF, done" and the operator would never enter Phase 2 through Phase 5; the very fact Phase 1 requires DKIM verification alongside SPF verification is the workflow-encoding of the thesis's first-principles argument that SPF cannot carry the authentication posture alone; (ii) PHASE-2-ALIGNMENT-FIXING — the alignment-triage phase exists ONLY because DMARC alignment between the From: header domain and SPF / DKIM authenticated domains must be repaired post-publication — the SPF-aligned-only failure modes the alignment-fixing phase resolves (envelope- MAIL-FROM rewrites by SaaS-ESPs that break SPF alignment with the From: header, bounce- domain delegation patterns at transactional senders, forwarder source-IP substitution at mailing-list operators) are the SPF-alone- insufficient thesis's forwarder-independence failure mode expressed as deployment-workflow triage; (iii) PHASE-3-OBSERVATION- WINDOW — the multi-week p=none observation phase exists to DISCOVER the full population of senders where SPF alone would have failed in production — the observation phase's exit criterion ("all legitimate sender catalogue surfaces in the RUA aggregate-report population with stable per-sender alignment-pass-rate baseline") operationally demonstrates the SPF-alone- insufficient thesis at per-domain production scale; if SPF alone were sufficient, the observation phase would be unnecessary because SPF would unambiguously identify every authorised sender's authentication outcome at publication; (iv) PHASE-4-5-RAMP- CADENCE — the multi-week ramp from p=none through p=quarantine pct=10 to terminal p=reject pct=100 is the operator's hedge against the very failure modes the SPF-alone-insufficient thesis catalogues — the slow per-pct increment cadence (10% → 25% → 50% → 100% over 6-12 weeks at p=quarantine + a parallel cadence at p=reject) exists structurally to LIMIT THE BLAST RADIUS of every legitimate- mail false positive caused by SPF-alone insufficiency the deployment did not pre- detect during Phase 3, demonstrating the SPF-alone-insufficient thesis's predictive validity at the per-publisher operational- cadence level. Read the SPF-alone-insufficient thesis page alongside this deployment-checklist reference when authoring the operator's first-principles rationale for the multi-phase ramp workflow — the thesis page is the STRUCTURAL ARGUMENT WHY the workflow exists, and THIS checklist is the OPERATIONAL EXECUTION-LAYER reference that embodies the thesis at every per-phase step structure.
• Phishing protection — the MULTI-LAYER-ANTI-PHISHING-DEFENCE- STACK-AS-CHECKLIST-PHASE-CLOSURE-DOWNSTREAM- CONSUMER companion to this deployment- checklist reference. Where THIS page documents the GREEN-PATH DEPLOYMENT WORKFLOW step-by-step (Phase 0 TTL discipline, Phase 1 SPF + DKIM prerequisite verification, Phase 2 alignment-fixing triage, Phase 3 p=none observation window, Phase 4 p=quarantine pct=10 ramp, Phase 5 terminal p=reject pct=100), the phishing-protection spoke is the OPERATIONAL CONTROL CATALOGUE documenting how the per-phase checklist closure outcome on THIS page directly enables the receiver-side and publisher-side anti- phishing defence-stack at FOUR per- checklist-phase-to-anti-phishing-control coupling dimensions: (i) Phase 5 p=reject pct=100 terminal- state closure as direct-domain-spoofing receiver-side SMTP-bounce anti-phishing control — once the checklist's terminal phase is reached, every attacker-originated direct-domain-spoof attempt is rejected at receiver-side DMARC evaluation, converting the publisher's per-domain DMARC posture into the strongest receiver-side anti- phishing control class catalogued on the phishing-protection spoke; (ii) Phase 1 SPF + DKIM dual- prerequisite gate as pre-anti-phishing message-layer authentication floor — the checklist's Phase 1 dual- prerequisite gate establishes the SPF publication and per-selector DKIM signing-discipline floor every downstream anti-phishing control class on the phishing-protection spoke (DMARC alignment-based direct-domain-spoof defeat, BIMI-display gating, ARC-chain forwarder-versus-attacker differentiation) structurally depends on; (iii) checklist's rua= aggregate-report observability gate as anti-phishing detection-feedback-loop precondition — the checklist's per-phase progression decision requires the per-publisher per-receiver per-source-IP per-disposition rua-stream evidence whose ingestion is the load-bearing detection-feedback-loop the phishing-protection spoke catalogues as the receiver-side observability control class every per-publisher anti- phishing programme depends on; (iv) per-subdomain sp= and np= coordination as subdomain-scoped phishing defence control — the checklist's Phase 5 closure includes per-subdomain sp= + np= tag coordination that extends the anti-phishing defence across the per- org-domain subdomain namespace, closing the per-subdomain Header-From-spoofing residual the phishing-protection spoke catalogues as a distinct anti-phishing control class requiring per-publisher subdomain-policy publication discipline. Read the phishing-protection spoke alongside this deployment-checklist reference when scoping the per-publisher end-state anti-phishing posture the checklist's terminal-phase closure is the operational gateway to.
• include vs ip4 vs a vs mx — the PER-PUBLISHER-SPF-MECHANISM- CHOICE-AS-LOAD-BEARING-PHASE-1- DEPLOYMENT-CHECKLIST-PREREQUISITE- WHOSE-MECHANISM-DECISION-DETERMINES- DOWNSTREAM-PHASE-CLOSURE companion to this DMARC deployment-checklist. Where THIS page documents the canonical per- publisher 5-phase DMARC deployment workflow (Phase 1 SPF + DKIM publication prerequisite gate, Phase 2 p=none baseline observability, Phase 3 quarantine pct ramping, Phase 4 p=reject pct ramping, Phase 5 p=reject pct=100 terminal- state closure), the include-vs-ip4-vs-a- vs-mx spoke is the PHASE-1-SPF-MECHANISM- CHOICE companion documenting the foundational per-publisher SPF-record authoring decision the checklist's Phase 1 prerequisite gate consumes. The four- axis CHECKLIST-PHASE-VS-SPF-MECHANISM- CHOICE comparison exposes the structurally-distinct per-phase dependencies on the per-publisher mechanism choice: (i) Phase 1's SPF-record-publication gate REQUIRES a syntactically-valid v=spf1 record with all-mechanisms-resolve-under- the-RFC-7208-§4.6.4-10-DNS-lookup- cap — operators picking include cascades for multi-ESP topologies (M365 + Mailchimp + SendGrid + Mailgun) must verify the cumulative lookup-cost stays below 10 OR adopt SPF flattening before any Phase 1 closure; the include-vs-ip4- vs-a-vs-mx decision matrix surfaces the per-mechanism lookup-cost (include = 1 + included records' lookups, ip4 = 0, a = 1, mx = 1 + 1 per MX target) operators must sum against the 10-lookup cap; (ii) Phase 2's p=none observability gate depends on SPF- mechanism-coverage-completeness to produce signal-rich rua aggregate reports — an SPF record with insufficient mechanism coverage (e.g. missing include: for the 3rd-party ESP, or stale ip4: ranges pointing at decommissioned on-prem relays) produces Phase 2 rua reports with FALSE-FAIL SPF rows the operator cannot distinguish from genuine unauthorised sources; the include-vs-ip4-vs-a-vs-mx spoke catalogues the seven most common mechanism-choice mistakes operators make at Phase 1 that surface as Phase 2 false-positive noise; (iii) Phases 3 and 4's quarantine + reject pct-ramping gates depend on SPF- alignment-pass-rate above the safety threshold (typically ≥98% SPF-aligned- pass for legitimate sources) before any pct-bump — operators who pick the wrong mechanism at Phase 1 (e.g. a: on an apex shared with a hosting-panel webserver, or mx: when outbound egress no longer matches the MX RR-set) find Phase 3-4 pct-ramping blocked by sub-threshold SPF-pass rates; the include-vs-ip4-vs-a- vs-mx spoke surfaces the four mechanism- choice classes whose correctness determines whether Phase 3-4 can proceed safely; (iv) Phase 5's p=reject pct=100 terminal- state closure REQUIRES every legitimate sender to be covered by an SPF mechanism that produces SPF-aligned-pass — operators consolidating a multi-ESP topology into a final SPF record at Phase 5 must pick the right mechanism per ESP (include for managed providers, ip4 for static owned IPs, a for self- hosted servers, mx only for the historical "outbound-also-serves-as-MX" pattern) and verify cumulative lookups stay below the 10-cap as the terminal- state record is locked in; the include- vs-ip4-vs-a-vs-mx spoke provides the canonical decision matrix operators apply at Phase 5 record consolidation. Read the include-vs-ip4-vs-a-vs-mx spoke alongside this deployment checklist when scoping the per-phase SPF-mechanism-choice closure — the spoke documents the foundational mechanism-decision surface every checklist phase from prerequisite gate to terminal-state closure structurally depends on.
• TLS-RPT JSON report format - the PER-PUBLISHER-TLS-RPT-JSON- REPORT-INGESTION-AS-LOAD-BEARING- DEPLOYMENT-CHECKLIST-TRANSPORT-LAYER- OBSERVABILITY-GATE-COMPLEMENT-TO-PER- PHASE-DMARC-AGGREGATE-INGESTION companion to this DMARC deployment- checklist. Where THIS page documents the canonical per-publisher 5-phase DMARC deployment workflow (Phase 1 SPF + DKIM publication prerequisite gate, Phase 2 p=none baseline observability, Phase 3 quarantine pct ramping, Phase 4 p=reject pct ramping, Phase 5 p=reject pct=100 terminal-state closure), the TLS-RPT JSON-report-format spoke is the TRANSPORT-LAYER-OBSERVABILITY-GATE companion documenting the RFC 8460 §4 JSON report grammar whose per- failure-class catalogue completes the cross-layer per-publisher observability picture every checklist phase from Phase 1 prerequisite gate through Phase 5 terminal-state closure consumes. The four-axis CHECKLIST-PHASE-VS-TLS-RPT-JSON-REPORT comparison exposes the structurally- distinct per-phase dependencies on per-publisher TLS-RPT JSON-report ingestion: (i) Phase 1's SPF + DKIM publication prerequisite gate is ALWAYS preceded operationally by a TLS-RPT _smtp._tls.<d> TXT-RR publication step — operators ratcheting from p=none through to p=reject without TLS-RPT publication discover at Phase 5 terminal-state closure that the per-publisher transport-layer TLS-handshake-collapse events at peer-receiver MX boundaries were invisible the entire deployment; the TLS-RPT JSON-report-format spoke documents the per-failure- class grammar (starttls-not- supported, certificate-host- mismatch, certificate-expired, certificate-not-trusted, validation-failure) operators must ingest from Phase 1 onward to surface upstream STARTTLS- availability outcomes; (ii) Phase 2's p=none baseline-observability gate depends on BOTH rua aggregate-XML AND TLS-RPT JSON for cross-layer observability completeness — rua reports the AUTHENTICATION outcome AFTER the TLS handshake succeeds; TLS-RPT reports the TRANSPORT outcome whether the authentication-layer ever runs; Phase 2 operators ingesting ONLY rua aggregate-XML systematically miss the per-receiver TLS- handshake-collapse events that produce zero-rua-row mailflow gaps; the TLS-RPT JSON-report- format spoke surfaces the missing observability surface; (iii) Phases 3 and 4's quarantine + reject pct-ramping gates require per-publisher confidence that transport-layer TLS handshakes succeed at peer- receiver boundaries BEFORE any pct-bump — operators ramping reject-pct against a peer- receiver population with degraded TLS-handshake-success rates risk producing legitimate-mail blast- radius incidents at receiver-side rua-aggregate-pass-rate fluctuations whose root cause is upstream TLS handshake fragility the per- publisher TLS-RPT JSON-report- format ingestion would have surfaced before pct-ramping; (iv) Phase 5's p=reject pct=100 terminal-state closure REQUIRES per-publisher TLS-RPT JSON-report ingestion as an ongoing operational discipline parallel to per-publisher rua aggregate- XML ingestion — the terminal-state closure is not a one-time configuration commit but an ongoing per-publisher observability stack the operator must maintain; the TLS-RPT JSON- report-format spoke documents the canonical report-aggregator infrastructure operators must provision alongside the rua aggregate-XML aggregator the checklist's Phase 2 gate establishes. Read the TLS-RPT JSON-report-format spoke alongside this deployment checklist when scoping the per- publisher cross-layer observability stack — the spoke documents the per-failure-class JSON-report grammar that surfaces every per-publisher transport- layer TLS-handshake outcome the per-publisher DMARC rua aggregate-XML observability layer the checklist's Phase 2 onward ingests cannot directly capture.
• MTA-STS for Microsoft 365 — the M365-TENANT-SPECIFIC-MTA-STS- DEPLOYMENT-AS-CANONICAL-PHASE-1-AND-PHASE- 2-AND-PHASE-3-AND-PHASE-4-CROSS-LAYER- TRANSPORT-LAYER-HARDENING-CHECKLIST-STEP- INSTANTIATION companion to this DMARC deployment-checklist reference. Where THIS page documents the per-publisher per- domain canonical SPF → DKIM → DMARC → MTA-STS → TLS-RPT phased-deployment checklist (Phase 1 publication-baseline, Phase 2 observability-baseline, Phase 3 pct=-ramp advancement, Phase 4/5 terminal- state p=reject + transport- layer-hardening), the mta-sts-for-microsoft- 365 spoke is the M365-TENANT-SPECIFIC instantiation reference whose per-M365- tenant per-domain MTA-STS deployment procedure is the canonical Phase 1 through Phase 4/5 cross-layer transport-layer- hardening checklist-step at the M365 Exchange Online tenant boundary at four M365-tenant deployment-checklist coupling dimensions: (i) Phase 1 per-M365- tenant per-domain MTA-STS-policy-file publication-baseline checklist-step — the per-M365-tenant per-domain MTA-STS- policy-file at mta-sts.<d> HTTPS well-known-path + _mta-sts.<d> TXT-RR publication step the mta-sts-for- microsoft-365 spoke documents IS the canonical Phase 1 publication-baseline checklist-step instantiation at the M365 Exchange Online tenant boundary; the per- tenant per-domain DNS-zone-management + HTTPS-host-management operator-discipline the checklist's Phase 1 step requires is the per-M365-tenant operator-specific instantiation the mta-sts-for-microsoft- 365 spoke documents; (ii) Phase 2 per-M365-tenant per-domain MTA-STS-policy- testing-mode observability-baseline checklist-step — the per-M365- tenant per-domain mode: testing MTA-STS-policy-file publication stage the mta-sts-for-microsoft-365 spoke documents IS the canonical Phase 2 observability- baseline checklist-step instantiation at the M365 Exchange Online tenant boundary; the per-publisher per-tenant mode: testing publication emits per-receiver per-MX-host TLS-RPT- JSON failure-report stream evidence the checklist's Phase 2 observability-baseline gate consumes BEFORE Phase 3 advancement; (iii) Phase 3 per-M365-tenant per-domain MTA-STS-policy-enforce-mode pct=-ramp-advancement checklist-step — the per-M365-tenant per-domain mode: enforce MTA-STS-policy- file publication stage the mta-sts-for- microsoft-365 spoke documents IS the canonical Phase 3 pct=-ramp-advancement checklist-step instantiation at the M365 Exchange Online tenant boundary; the per- publisher per-tenant Phase 2 → Phase 3 advancement decision consumes the per-MX- host TLS-handshake-success-rate evidence the per-tenant TLS-RPT JSON-failure-report stream produces under mode: testing as the canonical advancement gate-input; (iv) Phase 4/5 per-M365-tenant per- domain complete cross-layer publication- discipline-stack terminal-state checklist-step — the per-M365- tenant per-domain complete cross-layer publication-discipline-stack (message- layer SPF + DKIM + DMARC + transport-layer MTA-STS + TLS-RPT) at terminal-state composition the mta-sts-for-microsoft-365 spoke documents IS the canonical Phase 4/5 terminal-state checklist-step instantiation at the M365 Exchange Online tenant boundary; the per-publisher per-tenant per-domain Bulk Sender Requirements 2024 compliance- coverage the checklist's Phase 4/5 terminal-state step requires IS consumed by the per-tenant per-domain complete cross-layer publication-discipline-stack the mta-sts-for-microsoft-365 spoke documents as the per-M365-tenant operator- specific instantiation. Read the mta-sts- for-microsoft-365 spoke ALONGSIDE this DMARC deployment-checklist reference whenever the protected domain is hosted on the M365 Exchange Online cloud tenant and the canonical SPF → DKIM → DMARC → MTA- STS → TLS-RPT phased-deployment checklist THIS page documents needs an M365-tenant- specific cross-layer transport-layer- hardening checklist-step instantiation baseline for the per-M365-tenant per- domain operator-specific deployment- progression.
• Email deliverability — the PHASE-1-THROUGH-PHASE-5-DEPLOYMENT- CHECKLIST-AS-LOAD-BEARING-OPERATIONAL- PROGRESSION-FROM-PER-PUBLISHER-PRE- DEPLOYMENT-BASELINE-DELIVERABILITY-TO- TERMINAL-STATE-BULK-SENDER-COMPLIANT- DELIVERABILITY companion to this DMARC deployment-checklist reference. Where THIS page documents the Phase 0 → Phase 5 per-publisher per-domain phased deployment-progression discipline (Phase 0 pre-deployment audit → Phase 1 publication baseline → Phase 2 observability baseline at p=none → Phase 3 pct=-ramp policy advancement → Phase 4 strict-mode policy publication → Phase 5 ongoing observability discipline), the email-deliverability spoke is the per-publisher per-domain BUSINESS-OUTCOME reference documenting the 14-section OUTCOME-LAYER deliverability framework (authentication-verdict → reputation → engagement → SMTP-bounce-taxonomy → Postmaster-Tools telemetry → inbox- placement-rate) whose per-publisher per- domain pre-deployment-baseline-vs- terminal-state delta IS the load-bearing operational measure every per-phase checklist closure is structurally engineered to produce at four per- checklist-phase-to-deliverability-outcome coupling dimensions: (i) Phase 1 publication-baseline checklist-closure as per-publisher per-domain authentication- verdict-baseline establishment at the receiver-side reputation-model input — Phase 1 SPF + DKIM + DMARC TXT-RR publication discipline is the per-publisher per-domain authentication- verdict baseline every major receiver's reputation model (Gmail / Outlook / Yahoo / Apple / Comcast) consumes as load-bearing per-message inbox-placement-vs-spam-folder routing input; (ii) Phase 2 observability-baseline checklist-closure as per-publisher per-domain pre- enforcement-deliverability-instrumentation establishment — Phase 2 p=none + rua=mailto: ingestion is the per-publisher per-domain pre-enforcement DMARC-aligned- pass-rate observability baseline whose per-source-IP per-message attribution evidence stream IS the load-bearing input into the per-publisher per-domain reputation-degradation root-cause identification the email-deliverability framework's Section 5 (Postmaster-Tools telemetry) and Section 8 (SMTP-bounce- taxonomy) cross-reference; (iii) Phase 3 pct=-ramp-advancement checklist-closure as per-publisher per- domain enforcement-ramp-driven- deliverability-uplift trajectory — Phase 3 per-pct=-stage enforcement-ramp advancement is the per-publisher per- domain authentication-enforcement-driven deliverability-uplift trajectory whose per-stage receiver-side reputation-model recalibration produces the per-publisher per-domain inbox-placement-rate-vs-spam- folder-rate delta the email-deliverability framework's Section 6 (engagement metrics) and Section 10 (inbox-placement-rate measurement) document; (iv) Phase 4/5 terminal-state checklist-closure as per-publisher per-domain Bulk-Sender- Requirements-2024-compliant deliverability- floor establishment — Phase 4/5 terminal-state p=reject + cross-layer MTA-STS + TLS-RPT + DKIM-key-rotation + BIMI-VMC publication-discipline IS the per-publisher per-domain Feb-2024 Gmail/ Yahoo Bulk Sender Requirements compliance- coverage floor whose per-publisher per- domain terminal-state composition the email-deliverability framework's Section 13 (Bulk Sender Requirements deliverability floor) and Section 14 (multi-receiver reputation-model deliverability composition) document. Read the email- deliverability spoke ALONGSIDE this DMARC deployment-checklist reference whenever a per-publisher per-domain per-phase checklist-closure-to- deliverability-outcome attribution question emerges — THIS page gives the per-phase operational closure discipline, the email-deliverability spoke gives the per-publisher per-domain BUSINESS-OUTCOME framework every per-phase closure is structurally engineered to produce at the receiver-side reputation-model verdict boundary.
• ARC (Authenticated Received Chain) explained — the PER-FORWARDER-HOP-AUTHENTICATION- RESULT-PRESERVATION-CHAIN-AS-LOAD-BEARING- PHASE-4-AND-PHASE-5-FORWARDER-CHAIN- PRESERVATION-CHECKLIST-STEP-PREREQUISITE companion to this DMARC deployment- checklist reference. Where THIS page documents the Phase 0 → Phase 5 per-publisher per-domain phased deployment-progression discipline (Phase 0 pre-deployment audit → Phase 1 publication baseline → Phase 2 observability baseline at p=none → Phase 3 pct=-ramp policy advancement → Phase 4 strict-mode policy publication → Phase 5 ongoing observability discipline), 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 Phase 4 forwarder-chain-preservation and Phase 5 ongoing-observability checklist-step prerequisite at four per-deployment- checklist-phase-to-ARC-chain-preservation coupling dimensions: (i) Phase 1 publication-baseline as load-bearing per- publisher per-domain ARC-trusted-sealer- list-receiver-side-coverage-baseline publication prerequisite — the Phase 1 per-publisher per-domain SPF + DKIM + DMARC TXT-RR publication discipline THIS page's Phase 1 step documents IS the per-publisher per-domain baseline the per-receiver-side ARC-trusted-sealer- list-coverage configuration evaluates against; the per-publisher per-domain per-forwarder-hop ARC-trusted-sealer-list- coverage configuration (Gmail-as- canonical-ARC-trusted-sealer + per- receiver Exchange Online Trusted-ARC- Sealers list + ProtonMail / Yahoo / O365 per-receiver-side ARC-trusted-sealer configuration) consumes the per-publisher per-domain Phase 1 publication-baseline as the per-hop authentication-preservation ground-truth the ARC-explained spoke documents the per-hop chain-mechanism of; (ii) Phase 2 p=none observability- baseline as load-bearing per-forwarder- hop ARC-chain-pass-rate-observability rua-stream baseline prerequisite — every Phase 2 per-publisher per-domain p=none rua aggregate-XML stream the Phase 2 checklist-step closure produces 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 observability primitive the Phase 2 step prerequisite produces; (iii) Phase 4 strict-mode-policy- publication as load-bearing per-forwarder- hop ARC-chain-pass-rate-coverage- completeness checklist-step closure gate — the Phase 4 per-publisher per-domain p=reject strict-mode policy- publication checklist-step closure THIS page documents IS the per-publisher per- domain terminal-enforcement step the per- forwarder-hop ARC-trusted-sealer-coverage- completeness gate-keeps; without per- forwarder-hop ARC-chain-pass-rate- coverage-completeness the per-publisher per-domain Phase 4 strict-mode-policy- publication checklist-step closure produces per-forwarder-hop alignment-loss- driven reject-disposition events the per- publisher per-domain Phase 5 ongoing- observability checklist-step IS structurally engineered to mitigate; (iv) Phase 5 ongoing-observability-discipline as load-bearing per-forwarder-hop ARC- Authentication-Results AAR-evidence- vocabulary forensic-investigation checklist-step prerequisite — every Phase 5 per-publisher per-domain ongoing-observability checklist-step closure event the Phase 5 step's per- forwarder-hop forensic-investigation sub-step closure 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 Phase 5 ongoing-observability-discipline checklist-step's per-forwarder-hop forensic-investigation sub-step gates on. Read the ARC-explained spoke ALONGSIDE this DMARC deployment- checklist reference whenever a per- publisher per-domain Phase 4 strict- mode-policy-publication or Phase 5 ongoing-observability checklist-step closure question emerges with a per- forwarder-hop alignment-preservation attribution dimension — THIS page gives the per-phase per-publisher per-domain operational closure discipline, the ARC- explained spoke gives the canonical per- forwarder-hop ARC-chain primitive every Phase 4 strict-mode-policy-publication and Phase 5 ongoing-observability checklist-step closure consumes as the load-bearing per-forwarder-hop authentication-preservation primitive.
• CAA records explained — the pre-flight DNS-hygiene companion to this deployment checklist - the PRE-FLIGHT TLS-CERT-ISSUANCE- AUTHORISATION DNS-HYGIENE companion to this DMARC deployment checklist. Where THIS page documents the phased DMARC ramp (Phase 0 TTL discipline → Phase 1 SPF + DKIM prerequisite verification → Phase 2 RUA publication → Phase 3 p=none observation → Phase 4 p=quarantine ramp → Phase 5 terminal p=reject), the CAA reference documents the parallel DNS-publication-policy record (RFC 8659) that constrains WHICH Certificate Authorities may issue TLS certificates for hosts under the same domain. Audit CAA records during Phase 1 prerequisite verification — an absent or overly-permissive CAA record allows ANY publicly-trusted CA to issue a TLS certificate for mta-sts.<domain> (RFC 8461 §3.2's HTTPS policy endpoint), the BIMI VMC certificate's hosting host, or any other email-related sub-domain — silently weakening the TLS-cert layer the downstream MTA-STS / BIMI / TLS-RPT adjacent spokes all rely on. Add a CAA publication step to the Phase 1 checklist whenever the domain's email-authentication rollout extends beyond DMARC + SPF + DKIM into the TLS-cert-issuance attack surface.
• Reverse DNS / PTR records for mail servers — the PHASE-1-PRE-DEPLOYMENT-DNS- HYGIENE-IP-IDENTITY-LAYER-PUBLICATION- PRECONDITION companion documenting the IN-ADDR.ARPA / IP6.ARPA reverse-zone PTR-record publication discipline whose Forward-Confirmed reverse DNS (FCrDNS) verification on every per- publisher per-sending-IP is among the Phase 1 pre-enforcement DNS-hygiene preconditions every per-publisher per- domain DMARC deployment checklist runner must clear BEFORE ramping Phase 2 p=none → Phase 3 p=quarantine → Phase 4 p=reject enforcement-progression. Where THIS page documents the 5-phase per- publisher per-domain DMARC deployment progression discipline (Phase 1 pre- deployment DNS-hygiene gates, Phase 2 p=none monitoring window, Phase 3 p=quarantine ramp, Phase 4 p=reject terminal-enforcement state, Phase 5 ongoing-observability discipline), the reverse-DNS-PTR spoke is the PHASE-1-PRE-DEPLOYMENT-PRECONDITION IP-IDENTITY-LAYER companion across four per-deployment-checklist-phase- to-per-publisher-PTR-record-publication- discipline-coupling dimensions: (i) Phase-1-pre-deployment-FCrDNS- verification-on-per-publisher-per- sending-IP-set-as-pre-enforcement- DNS-hygiene-gate — every per-publisher per-sending-IP enumerated in the per-publisher SPF FORWARD-zone record (the per-publisher per-domain authorised sending-IP set) MUST clear a Phase 1 FCrDNS verification gate BEFORE the Phase 2 monitoring window begins; per-publisher per-sending-IP FCrDNS verification failures surfaced during Phase 1 should be remediated BEFORE Phase 2 monitoring begins so per-publisher RUA aggregate-report evidence captured during Phase 2 reflects the per-publisher per- sending-IP set's STEADY-STATE authentication-result baseline; (ii) Phase-2-monitoring-window- per-source-IP-rDNS-evidence-stream- as-load-bearing-per-source-IP- identity-attribution-input — per-publisher RUA aggregate-report rows during Phase 2 monitoring contain per-source-IP evidence whose per-publisher per-source-IP-identity attribution discipline (mapping per-source-IP row to per-publisher- authorised-sender vs unauthorised- third-party) structurally depends on per-source-IP rDNS lookup; per-source- IP PTR records with consistent FQDN- target byte-grammar make per-source- IP-identity attribution unambiguous, whereas per-source-IP rDNS-misalignment or missing-PTR-record states force per-publisher per-source-IP-identity attribution down a per-source-IP per-CIDR-block-WHOIS evidence-stream fallback path; (iii) Phase- 3-quarantine-ramp-per-receiver- mailbox-provider-per-day-IP-reputation- aggregate-floor-determinant — the Phase 3 p=quarantine ramp tightens per-receiver-mailbox- provider per-day delivery-placement- policy strictness; the per-receiver per-day IP-reputation aggregate floor for the per-publisher per-sending-IP set DIRECTLY DETERMINES per-receiver per-message delivery-placement verdict; per-publisher per-sending-IP FCrDNS-misalignment OR per-PTR-record publication-discipline defects degrade per-receiver per-day IP- reputation aggregate floor, producing elevated per-publisher per-message spam-folder-placement rates AT THE SAME Phase 3 enforcement-ramp step that DMARC-aligned per-publisher per- message authentication-result verdicts achieve dmarc=pass; (iv) Phase-4-terminal-state- p=reject-per-publisher-per-domain- per-receiver-per-message-bounce- floor-determinant — at Phase 4 p=reject terminal-enforcement state, per- publisher per-sending-IP FCrDNS- misalignment paired with per-message dmarc=fail produces per- receiver per-message hard-bounce verdict on EVERY DMARC-honouring receiver; per-publisher per-sending-IP PTR-record publication discipline IS the Phase-1-pre-deployment IP-IDENTITY- LAYER prerequisite whose correctness determines whether the Phase 4 terminal-state-p=reject per-publisher per-domain bounce-floor is collapsed to a dmarc=fail- only origin (per-publisher per-message DKIM-signature / SPF-mechanism operational fault) versus an FCrDNS- misalignment-amplified origin (per-publisher per-sending-IP IP- identity-layer publication discipline fault). Read THIS page when SEQUENCING the 5-phase per-publisher per-domain DMARC deployment progression checklist; read the reverse-DNS-PTR spoke when EXECUTING the Phase-1 per-publisher per-sending-IP FCrDNS- verification gate BEFORE the Phase-2 monitoring window begins, or when investigating per-receiver-mailbox- provider per-day IP-reputation- aggregate-floor degradation surfaced during Phase 3 / Phase 4 enforcement- ramp steps.
• Domain Security Checker - live DNS lookups for SPF, DKIM, DMARC, MTA-STS, CAA, BIMI, and DNSSEC against any domain.
• Email Header Analyzer - paste a raw email header to see SPF, DKIM, and DMARC pass/fail results inline.
• DNS Record Generator - interactive wizards for building SPF, DKIM, DMARC, BIMI, MTA-STS, CAA, and TLS-RPT records.
• DKIM selectors explained (RFC 6376 §3.1) - the PER-DEPLOYMENT-CHECKLIST-PHASE-1-DNS- HYGIENE companion to this DMARC deployment checklist. Where THIS page documents the per-publisher per-domain DMARC deployment checklist (Phase 1 pre-deployment DNS hygiene: confirm per-publisher SPF record is below the 10-DNS-lookup ceiling, confirm per-publisher per-selector DKIM key-pair is published and signing correctly, confirm the per-publisher RUA-aggregate-report mailbox is reachable; Phase 2-5: progressive p=none -> p=quarantine pct=<N> -> p=reject ramp), the DKIM-selectors-explained spoke is the per-publisher per-selector key- identifier-scheme reference documenting the RFC 6376 §3.1 naming convention whose per- selector public-key TXT-RR publication discipline IS the Phase-1 checklist line item that gates entry into the per-publisher DMARC ramp-step progression. The DEPLOYMENT- CHECKLIST-VS-DKIM-SELECTOR-IDENTIFIER cross- reference establishes the per-publisher per- selector primary-key publication + per- selector rotation-secondary-key publication + per-selector key-revocation-marker publication discipline that each per- publisher's Phase-1 DNS-hygiene checklist line item structurally requires. Read THIS page when WORKING the per-publisher per- domain DMARC deployment checklist phase- by-phase; read the DKIM-selectors-explained spoke when AUDITING the per-publisher per- selector DKIM-key publication discipline that closes the Phase-1 DNS-hygiene gate.
• SPF mechanisms explained (RFC 7208 §5) - the PER-DEPLOYMENT-CHECKLIST-PHASE-1-SPF- LOOKUP-BUDGET companion to this DMARC deployment checklist. Where THIS page documents the per-publisher per-domain DMARC deployment checklist phase-by-phase (Phase 1 pre-deployment DNS hygiene: confirm per- publisher SPF record is below the 10-DNS- lookup ceiling, confirm per-publisher per- selector DKIM key-pair is published and signing correctly, confirm the per-publisher RUA-aggregate-report mailbox is reachable; Phase 2-5 progressive p=none -> p=quarantine pct=<N> -> p=reject ramp), the SPF- mechanisms-explained spoke is the per- mechanism lookup-cost-and-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 left-to-right evaluation discipline the receiver applies before yielding the SPF result. The DEPLOYMENT-CHECKLIST-VS-SPF- MECHANISM cross-reference establishes the per-publisher per-mechanism lookup-budget arithmetic that each Phase-1 DNS-hygiene checklist line item structurally requires: every include: mechanism costs 1 DNS lookup PLUS the nested-mechanism cost of the included record (so an ESP's include:spf.provider.tld can consume 3-5 lookups out of the 10-lookup budget all by itself), every a: / mx: mechanism costs 1 lookup PLUS one per A/AAAA record returned by the target host, and the RFC 7208 §4.6.4 10-lookup hard ceiling is the gate condition that determines whether Phase-1 SPF prerequisite verification yields pass versus permerror — and permerror at the SPF leg cascades into dmarc=fail at Phase 5 p=reject on every DMARC-honouring receiver. Read THIS page when WORKING the per-publisher per-domain DMARC deployment checklist phase-by-phase; read the SPF-mechanisms-explained spoke when AUDITING the per-publisher per- mechanism lookup-budget arithmetic that closes the Phase-1 SPF-record-publication gate BEFORE the DKIM and DMARC publication steps proceed.
• TLS-RPT explained — the PER-RECEIVER-PER-SESSION- TRANSPORT-LAYER-ENCRYPTION-FAILURE-TELEMETRY- PUBLICATION-AS-LOAD-BEARING-PHASE-4-TERMINAL- STATE-TRANSPORT-LAYER-OBSERVABILITY-CHECKLIST- STEP-PREREQUISITE companion to this DMARC deployment-checklist. Where THIS page documents the per-publisher per-domain DMARC deployment-checklist phase-by-phase progression (Phase 0 inventory through Phase 5 terminal-state ongoing observability), the TLS-RPT-explained spoke is the per-publisher per-domain RFC 8460 transport-encryption- failure-telemetry publication discipline whose Phase 4 terminal-state _smtp._tls TXT publication step is the load-bearing per- publisher per-domain transport-layer- encryption-failure observability checklist- closure at FOUR per-deployment-checklist- phase-to-TLS-RPT-publication coupling dimensions: (i) Phase 4 MTA-STS-and- TLS-RPT-paired-publication checklist-closure as transport-layer authentication-and- encryption terminal-state — the deployment-checklist Phase 4 terminal- state publication step requires BOTH the MTA-STS policy publication AND the TLS-RPT record publication as paired cross-layer publication discipline because MTA-STS policy without TLS-RPT publication ships the per- receiver per-session transport-encryption ENFORCEMENT gate without the per-publisher per-domain operator-side OBSERVABILITY gate to detect when the MTA-STS enforcement downgrades, and TLS-RPT publication WITHOUT MTA-STS policy ships the per-publisher per- domain operator-side observability gate without the per-receiver per-session enforcement gate to drive remediation; (ii) Phase 4 _smtp._tls TXT publication as load-bearing transport-encryption- failure-mode-distribution baseline establishment — the deployment-checklist Phase 4 _smtp._tls TXT publication step is the per-publisher per- domain rua-mailto-equivalent transport-layer- encryption failure-mode-distribution observability-baseline-establishment step whose receiver-side aggregation cadence produces the per-publisher per-domain per-MX hop starttls-not-supported / certificate- host-mismatch / certificate-expired / validation-failure / sts-policy-fetch-error / sts-policy-invalid / tlsa-invalid / dnssec- invalid failure-mode-rate baseline the per- publisher per-domain operator reads BEFORE every Phase 4 MTA-STS mode=enforce ramp-step commit; (iii) Phase 5 ongoing- observability TLS-RPT-aggregation-monitoring as terminal-state transport-encryption- failure-mode-drift detection — the deployment-checklist Phase 5 terminal-state ongoing-observability step requires per-publisher per-domain TLS-RPT aggregation-monitoring as the load-bearing per-MX hop transport-layer-encryption- failure-mode-drift detection mechanism whose per-receiver per-session per-failure- mode-class rolling-window distribution produces the per-publisher per-domain terminal-state transport-encryption-failure- rate stability signal; (iv) Phase 4 TLS-RPT publication as load-bearing Bulk- Sender-Requirements-2024 deliverability- floor composition contributor — the deployment-checklist Phase 4 terminal-state TLS-RPT publication step is one of the cross-layer publication disciplines the per-publisher per-domain Feb-2024 Gmail/Yahoo Bulk Sender Requirements deliverability-floor composition explicitly requires alongside MTA-STS policy, DKIM-key- rotation discipline, BIMI-VMC, and DMARC p=reject for the per-publisher per-domain complete cross-layer authentication-and- encryption deliverability posture. Read THIS page when WORKING the per-publisher per-domain DMARC deployment checklist phase- by-phase; read the TLS-RPT-explained spoke when AUTHORING the per-publisher per-domain Phase 4 _smtp._tls TXT publication step whose paired-with-MTA-STS cross-layer terminal-state publication discipline closes the transport-layer-encryption- failure observability gate the per-publisher per-domain Bulk-Sender-Requirements-2024 deliverability-floor composition structurally requires.
• DKIM-Signature header tag anatomy — the per-message DKIM-Signature header per-tag anatomy as load-bearing Phase-1 DKIM-authentication-leg byte-grammar publication-baseline companion to this five-phase DMARC deployment checklist. Where THIS page documents the canonical four-phase operator-side rollout (Phase 1 Discovery + DNS hygiene, Phase 2 Triage of misaligned senders, Phase 3 p=quarantine, Phase 4 p=reject), the DKIM- Signature-anatomy spoke documents the per- message header byte-grammar whose per-tag publication baseline is the LOAD-BEARING Phase-1 DKIM-authentication-leg byte- grammar publication discipline every Phase-2 misalignment triage and every Phase-3 / Phase-4 enforcement-ramp commit STRUCTURALLY DEPENDS on. Four DKIM- SIGNATURE-HEADER-ANATOMY-VS-DEPLOYMENT- CHECKLIST-PHASE cross-correlation axes the signature-anatomy spoke documents: (i) per-message DKIM-Signature d=<domain> tag value STRUCTURALLY DETERMINES the per-message DKIM-leg DMARC-alignment evaluation that the Phase-2 misalignment triage backlog enumerates per-sender — the per-message d= tag value MUST match the per-message From: header organizational domain under adkim=r for the per-message DKIM-leg DMARC-aligned- pass verdict to emit; Phase-2 triage MUST enumerate every per-sender per-message d= tag value vs From-header organizational-domain divergence as the per-sender misalignment-fix backlog; (ii) per-message DKIM-Signature s=<selector> selector tag publication-discipline STRUCTURALLY GATES Phase-1 DNS-hygiene completion — every per-publisher per-selector signing identity MUST have a corresponding <selector>._domainkey.<domain> TXT-RR published BEFORE Phase 1 closes; a missing per-selector TXT-RR produces per-receiver verifier-side dkim=permerror verdicts that cumulate into a per-publisher per-domain DKIM-aligned-pass coverage-rate floor below the Phase-3 ramp-advancement gate (typical 95-99 percent coverage requirement); (iii) per-message DKIM-Signature h=<header-list> signed-headers tag CONTENT STRUCTURALLY GATES Phase-3 / Phase-4 per-receiver verifier-trust posture — the per-message h= tag MUST cover the From:, Subject:, Date:, To:, and Message-ID: headers for receivers to trust the per-message identifier against intermediary rewriting; per-publisher per-domain h=-tag-coverage discipline MUST be audited at Phase-1 baseline AND re-verified before Phase-3 commits because per-receiver per-day per-source per-disposition aggregate-XML evidence decays under partial-signed-header coverage; (iv) per-message DKIM- Signature t= and x= timestamp tag VALUE publication-discipline STRUCTURALLY GATES Phase-3 / Phase-4 replay-attack-window attribution — per-publisher per- domain DKIM-Signature timestamps MUST carry t= (sign-time) AND a bounded x= (expiration, typical sign-time + 7 days per RFC 6376 recommendation) to prevent per-message signature-replay-attacks; Phase-3 / Phase-4 enforcement-ramp commit MUST verify per-publisher per-selector timestamp-discipline publication BEFORE the per-receiver dispositional- enforcement boundary crosses because a missing x= tag exposes the per-publisher per-domain identifier to replay-attacks the per-receiver-side cache-window cannot mitigate. Read THIS page when AUTHORING the per-publisher per-domain five-phase DMARC deployment progression; read the DKIM-Signature- anatomy spoke when AUDITING the per- publisher per-domain Phase-1 DKIM- authentication-leg byte-grammar publication baseline whose per-tag publication discipline is the LOAD- BEARING Phase-1 prerequisite every Phase-2 misalignment-fix triage and every Phase-3 / Phase-4 enforcement- ramp commit structurally requires BEFORE the per-receiver dispositional- enforcement boundary crosses.
• Email security glossary — the DMARC-DEPLOYMENT-CHECKLIST- VOCABULARY-RESOLVES-TO-CROSS-CLUSTER- EMAIL-SECURITY-TERMINOLOGY-HUB companion to this DMARC-deployment-checklist reference. Where THIS page documents the per-publisher per-domain DMARC-deployment- checklist (the canonical Phase-1 preparation, Phase-2 monitoring, Phase-3 quarantine ramp, Phase-4 reject full-enforcement progression, per-phase per-publisher per-domain operator responsibilities, per-phase per-receiver evaluator behaviour, per- phase aggregate-report telemetry confirmation), the email-security- glossary spoke is the cross-cluster TERMINOLOGY-RESOLUTION reference whose per-term canonical definitions establish the shared vocabulary every DMARC- deployment-checklist 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 (v= version tag, 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, np= non-existent-subdomain-policy tag) THIS page's per-publisher per-domain deployment-phase reference structurally references at every per-phase per-tag- commit entry is canonically defined in the glossary spoke; the per- publisher per-domain DMARC-record per- tag terminology vocabulary that drives every deployment-phase authoring discussion lives in the glossary's per- tag entry-set; (ii) per-term DMARC-deployment-phase vocabulary resolution — the DMARC-deployment-phase vocabulary (Phase-1 preparation, Phase-2 monitoring, Phase-3 quarantine ramp, Phase-4 reject full-enforcement, per- phase pct= rollout cadence, per-phase per-receiver evaluator behaviour, per- phase per-publisher rollback discipline) THIS page's deployment-checklist reference references when describing per-phase commit boundaries is canonically defined in the glossary spoke; the per-phase per-publisher per- domain deployment-progression terminology vocabulary that drives every deployment-checklist authoring discussion lives in the glossary's per- term deployment-phase entry-set; (iii) per-term DMARC-alignment vocabulary resolution — the DMARC- alignment vocabulary (organizational domain, public suffix list, aspf= s/ relaxed mode, adkim= s/relaxed mode, RFC5322-From domain, SPF-aligned-pass, DKIM-aligned-pass, alignment-strictness mode commit boundary) THIS page's deployment-checklist reference references when describing per-phase per-receiver alignment-evaluation outcomes is canonically defined in the glossary spoke; the per-message alignment-mode-evaluation terminology vocabulary that drives every per-phase per-publisher alignment-decision discussion lives in the glossary's per- term alignment-vocabulary entry-set; (iv) per-term DMARC-deployment- prerequisite vocabulary resolution — the DMARC-deployment-prerequisite vocabulary (SPF publication prerequisite, DKIM publication prerequisite, per-publisher per-domain authoritative DNS-zone editor, per-publisher rua= mailbox provisioning, per-publisher operational monitoring readiness, per-publisher per-domain known-sender inventory enumeration) THIS page's deployment- checklist reference references when describing Phase-1 per-publisher readiness requirements is canonically defined in the glossary spoke; the per-publisher per-domain deployment-prerequisite terminology vocabulary that drives every Phase-1 per-publisher readiness-evaluation discussion lives in the glossary's per- term deployment-prerequisite entry-set. Read the email-security-glossary spoke alongside this DMARC-deployment- checklist reference when authoring per- publisher per-domain deployment-phase runbooks and per-phase-coordination documents that need the shared terminology hub.
• RFC 7489 - DMARC - the DMARC specification itself.
• RFC 9091 - DMARC np= tag - the non-existent-subdomain policy tag extension.
• Microsoft SNDS + JMRP monitoring — DMARC reporting shows who fails authentication; Microsoft SNDS + JMRP shows how Outlook.com's filter and its users judge the mail that passes — the per-IP reputation signal aggregate reports cannot see.

13. Start your DMARC deployment now

DMARC Analyzer's free Domain Security Checker performs live DMARC + SPF + DKIM + MTA-STS + BIMI lookups against any domain. Use it to check your current DMARC record before Phase 1, to validate new selectors during Phase 2 triage, and to confirm each phase advance has propagated through DNS. The DNS Record Generator (linked above) builds syntactically-correct DMARC records with the right rua= + fo= + pct= + sp= tags for each phase. Imported DMARC aggregate reports (via includes/DmarcParser.php) drive the per-source-IP pass and fail dashboard that powers your sender registry. The includes/EmailHeaderParser.php backend surfaces inline Authentication-Results diagnosis when troubleshooting individual failure cases.

Check my current DMARC record Sign up — Free plan