DMARC connects authentication to the visible sender.
SPF checks whether the sending IP is authorized for the envelope domain. DKIM verifies a signature associated with a signing domain. DMARC asks whether at least one passing mechanism also aligns with the domain in the visible From header.
A raw SPF pass on an unrelated return-path is not enough. Likewise, a valid DKIM signature from an unrelated domain is not enough. Relaxed alignment uses the organizational domain; strict alignment requires exact equality. Receivers may use different discovery models during the RFC 7489 to RFC 9989 transition.
| Observation | DMARC interpretation |
|---|---|
| SPF passes and aligns; DKIM fails | DMARC can pass through SPF. |
| DKIM passes and aligns; SPF fails after forwarding | DMARC can pass through DKIM. |
| SPF and DKIM pass, but neither aligns | DMARC fails alignment. |
| A header says dmarc=pass | A claim to trust only if added by your receiving service. |
A rollout checklist you can actually use.
- Inventory senders. Include transactional mail, CRM, support, newsletters, billing, forwarding and mailing lists. Assign an owner to each.
- Establish DNS. Run the email health check, trace SPF includes and inspect the provider’s DKIM selector.
- Prepare reporting. Choose a mailbox or service you control. Confirm authorization, retention and report handling before adding rua.
- Start with monitoring. Generate an explicit p=none policy. Do not use pct as a safety gate: RFC 9989 removed it.
- Observe representative traffic. Review several reporting cycles, including infrequent business systems. There is no universal number of days that makes enforcement safe.
- Fix legitimate flows. Confirm alignment in real message headers. Treat forwarding and mailing lists separately.
- Approve enforcement. Test quarantine/reject with owners, monitor impact and keep a documented rollback.
Read reports as weighted observations.
Aggregate reports group messages by source and outcomes. Weight metrics by the message count, not the number of XML rows. The policy_evaluated SPF/DKIM fields represent aligned outcomes; raw auth_results can pass even while DMARC fails.
Check the reporting organization, period, report ID and policy snapshot. Sources are not automatically identified providers or attackers. Repeated and overlapping reports need deduplication before calculating long-term trends. The public parser analyzes one report only.
Open the XML report analyzerWhat this does not protect against.
DMARC does not prevent lookalike domains, display-name impersonation, account takeover or every phishing message. p=reject is a requested treatment, not a guarantee that every receiver will reject. Inbox placement also depends on reputation, content and recipient policy.
Do not equate a green DNS result with regulatory compliance. Security requirements need a broader risk assessment, operational evidence and controls.
Standards and further reading.
- RFC 9989 — DMARC policy and discovery
- RFC 9990 — aggregate reports and external authorization
- RFC 9991 — failure reporting
- RFC 7489 — legacy receiver behavior
Maail’s tools are diagnostic aids, not cryptographic message validators or a universal receiver simulator. Review their data boundaries.