Understanding DMARC
DMARC helps domain owners protect the domain shown in the visible From: header. It works by taking SPF and DKIM results and then checking whether those authenticated domains align with the domain the recipient sees in the message.
This alignment step is what makes DMARC different from using SPF or DKIM alone. A message can have a technically valid DKIM signature or SPF result but still fail DMARC if the authenticated domain does not match or align with the visible sender domain.
DMARC also lets the domain owner publish a policy in DNS that tells participating receivers how to handle failing mail. Common policy states are p=none for monitoring, p=quarantine for suspicious treatment, and p=reject for stronger enforcement.
On top of that, DMARC supports reporting. Aggregate reports help you see who is sending on behalf of your domain and whether those sources authenticate correctly. That reporting layer is what makes DMARC especially useful during rollout and cleanup.
Example
If a message shows From: billing@example.com and either SPF or DKIM passes with alignment to example.com, the message can pass DMARC. If neither aligned result is present, it fails DMARC.
How DMARC works
DMARC usually follows a simple sequence: authenticate the message, compare the authenticated domains to the visible From domain, then apply policy and reporting rules. The protocol is most effective when you already know all legitimate sending sources for your domain.
Authenticate
The receiver checks SPF and DKIM to see whether the message was sent by authorized infrastructure or signed correctly.
Align
The receiver compares the SPF-authenticated domain or DKIM signing domain to the visible From: domain.
Apply policy and report
If aligned authentication is missing, the receiver can follow the published DMARC policy and may send reports back to the domain owner.
Note: DMARC can pass when either SPF or DKIM passes with alignment. You do not need both for every message, although many organizations configure both for resilience.
Common DMARC tags and controls
A DMARC record is usually published as a DNS TXT record at _dmarc.yourdomain.com. The record contains tags that control policy, reporting, and alignment behavior.
Policy tag: p
Sets the requested action for failing mail. Common values are none, quarantine, and reject.
Reporting tags: rua and ruf
rua requests aggregate reports. ruf requests message-specific failure reports, though not every receiver sends them.
Alignment tags: adkim and aspf
These tags control whether DKIM and SPF alignment is relaxed or strict for DMARC evaluation.
Starter record
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Decision tree: how to roll out DMARC
Goal
Protect a domain with DMARC
Have you identified all legitimate senders using the domain?
Action
Inventory platforms first. Find every ESP, CRM, help desk, and vendor sending mail with your domain before enforcing policy.
Do legitimate sources already pass aligned SPF or DKIM?
Check alignment against the visible From: domain, not just authentication in isolation.
Action
Publish p=none, collect reports, and fix misaligned or missing authentication before moving toward enforcement.
Action
Move toward enforcement with quarantine or reject once reports show that failing traffic is mostly unauthorized or understood.
Monitor
Watch aggregate reports, investigate failures by source, and re-check third-party senders, forwarders, and mailing-list traffic whenever you make policy changes.
Key implications
Better domain protection
DMARC helps reduce visible-domain spoofing and gives receivers a clearer signal about unauthenticated mail.
Rollout is operational, not just technical
Successful DMARC depends on inventorying real senders, configuring DNS correctly, and fixing vendor alignment.
Reports create visibility
Aggregate reports can reveal forgotten tools, broken configurations, and unauthorized senders using your domain.
Common challenges
Indirect mail flows
Forwarders and mailing lists can break SPF or DKIM alignment, which may cause legitimate mail to fail DMARC.
Third-party sender misalignment
A vendor may authenticate mail, but against its own domain rather than yours, which prevents DMARC pass.
Going to reject too early
Moving straight to hard enforcement can block wanted mail if you have not fully mapped all legitimate sources.
DMARC vs SPF vs DKIM
| Type | What it is | Common limit |
|---|---|---|
| DMARC | Policy and reporting layer that uses SPF/DKIM results plus alignment | Needs correct sender inventory and can be affected by forwarding or list changes |
| SPF | DNS-based authorization of sending infrastructure | Can break during forwarding and does not protect the visible From domain by itself |
| DKIM | Cryptographic signing of messages by a domain | Can fail if messages are modified in transit or signed by a non-aligned domain |
FAQs
What is DMARC?
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is an email authentication, policy, and reporting protocol that helps domain owners tell receivers how to handle messages that fail authentication checks tied to the visible From domain.
Does DMARC replace SPF and DKIM?
No. DMARC builds on SPF and DKIM. It uses their results together with domain alignment checks to decide whether a message passes DMARC.
Does a message need both SPF and DKIM to pass DMARC?
No. A message can pass DMARC when either SPF or DKIM passes and is aligned with the visible From domain.
What do p=none, p=quarantine, and p=reject mean?
p=none is monitoring mode, p=quarantine asks receivers to treat failing mail suspiciously, and p=reject asks receivers to reject failing mail at the edge when they choose to enforce the policy.
Where is a DMARC record published?
A DMARC record is typically published as a DNS TXT record at the _dmarc subdomain of the domain you want to protect, such as _dmarc.example.com.
What are DMARC aggregate reports?
Aggregate reports are summary reports sent by participating receivers to the address listed in the rua tag. They help domain owners see which systems are sending mail that claims to use their domain and how that mail is authenticating.
Can forwarding or mailing lists break DMARC?
Yes. Forwarding, list modification, and other indirect mail flows can break SPF or DKIM alignment and cause legitimate mail to fail DMARC in some situations.
Should I start with p=reject right away?
Usually no. Most organizations begin with p=none to monitor traffic, fix legitimate sources, and then move gradually toward enforcement.