Key takeaways
Overview
A DMARC result depends on both authentication and alignment. A domain can request monitoring, quarantine or rejection treatment, while receivers retain their own processing policies. Deployments should inventory legitimate senders and examine reports before enforcing a policy that could disrupt valid mail. DMARC addresses domain impersonation patterns; it does not make every authenticated message benign.
How it works
Alignment is the missing link between identity checks
A message can pass SPF for a provider’s envelope domain and DKIM for a provider’s signing domain while neither aligns with the domain in the visible From address. DMARC checks that relationship. A pass can come from an aligned passing SPF result or an aligned passing DKIM signature; receiver requirements may separately require configuring both mechanisms.
RFC 9989 is the current core DMARC specification and replaces the older RFC 7489 framework together with separate reporting specifications. It distinguishes strict alignment, where the relevant domains are identical, from relaxed alignment based on organizational-domain relationships. Use current documentation for implementation details rather than relying on an old DNS tutorial.
| Policy value | Requested treatment of failures | Operational purpose |
|---|---|---|
| none | No specific enforcement treatment requested | Observe available reports and diagnose senders |
| quarantine | Treat failing messages as suspicious | Apply stronger handling after validation |
| reject | Reject failing messages | Request the strongest listed treatment after legitimate paths are ready |
Source material: IETF / RFC Editor — RFC 9989: DMARC ↓
Inventory legitimate senders before enforcement
List employee, support, billing, product and marketing mail streams. For each, inspect a received message and confirm the intended domain identities and authentication. A forgotten invoicing service can become a customer-facing failure when a stricter policy is introduced. The existence of a DMARC record does not establish that every legitimate service is aligned.
Use available aggregate reporting to identify sources and authentication gaps. RFC 9990 specifies aggregate reporting separately. Reports are useful evidence about observed traffic, but coverage depends on participating receivers; absence from a report does not prove a service never sends mail. Reconcile reports with the sender inventory and controlled tests.
Source material: IETF / RFC Editor — RFC 9990: DMARC aggregate reporting ↓
Investigate failures by message stream
An illustrative deployment finds that employee mail aligns while receipts use an unrelated provider signing domain and return path. Repair the receipt service’s supported domain configuration, then test its actual messages before strengthening policy. Changing the policy alone would not repair that stream; it could make its failures more visible to customers.
Continue monitoring after enforcement because integrations, forwarding paths and sending services change. Keep a record of authorized sources and investigate unexpected traffic. DMARC addresses a particular domain-authentication problem. Lookalike domains, deceptive display names and harmful content from an authenticated sender still require other controls, and a DMARC pass does not promise inbox placement.
What this looks like in practice
A company discovers that its invoicing service signs with a provider domain that does not align. It corrects the sending configuration before strengthening the company’s DMARC policy.
Examples explain the concept; they are not reported customer results.What to check
Check alignment for every legitimate sending service, report coverage and unexpected failures. Test actual messages rather than only the presence of DNS records.
Common mistake
Switching directly to a strict policy without identifying all legitimate senders, or assuming a published record means alignment is working.
DMARC vs. DomainKeys Identified Mail
DKIM provides signature-based authentication. DMARC evaluates aligned authentication and communicates domain policy and reporting preferences. DKIM can contribute to a DMARC pass without being the whole mechanism.
Read the DomainKeys Identified Mail definition →Questions answered
What is DMARC?
DMARC is an email authentication policy and reporting mechanism that connects SPF or DKIM authentication to the visible From domain through alignment and lets domain owners publish handling preferences.
Does DMARC require both SPF and DKIM to pass?
A DMARC pass can be achieved through an aligned passing SPF result or an aligned passing DKIM signature. Sender-provider requirements may separately require configuring both mechanisms.
Does a monitoring policy block spoofed messages?
A monitoring policy primarily requests reporting rather than enforcement treatment. Receivers may still filter messages using their own rules.
Does p=none mean DMARC is broken?
No. It is a valid monitoring-oriented policy choice, though it does not request quarantine or rejection treatment for failures. Whether it is appropriate depends on the deployment stage and requirements. Authentication and alignment results should still be checked; publishing a monitoring policy is not the same as completing the rollout.
Will receivers always follow a reject policy?
Receivers retain their own handling decisions and can apply local policy. The published DMARC preference is an input to that process. Test legitimate mail and inspect available reports rather than assuming the policy guarantees one universal result for every message and receiver.
References and further reading
Primary documentation and source material for this topic. Sources checked September 14, 2026; provider requirements can change.
- RFC 9989: DMARC ↗IETF / RFC Editor
Current DMARC specification; replaces RFC 7489 together with the separate reporting specifications.
- Email sender guidelines ↗Google
- RFC 9990: DMARC aggregate reporting ↗IETF / RFC Editor
Continue reading on the blog
- Email verification and deliverability in outbound workflows →
- Personalize outreach with supporting evidence →
Put the concept to work.
Explore the relevant AstroFabric workflow and see how the pieces connect.
Help keep this guide useful. Suggest a correction or browse the full glossary.