Anyone can send an email claiming to be from your domain. Nothing in the original design of email prevents it. That's why invoice fraud and brand impersonation still work so well.
DMARC helps close that gap. It lets receiving mail servers verify use of your visible From domain, consider your published handling policy, and report what they see.
What Is DMARC?
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It isn't a new authentication method. It sits on top of SPF and DKIM and adds what they lack: a policy and a feedback loop.
SPF says which servers may send for your domain. DKIM signs the message so tampering shows. Neither checks the address your recipient sees. DMARC does.
How Does DMARC Work?
The key concept is alignment. A receiving server checks whether the visible From domain matches the domain that passed SPF or DKIM.
That check runs in one of two modes. Relaxed alignment, the default, accepts domains that share the same organisational domain. Strict alignment requires the domains to be identical.
The full sequence looks like this:
- Mail arrives claiming to be from your domain
- The receiver looks up your DMARC record in DNS
- It runs SPF and DKIM checks
- It tests whether either result aligns with the From domain
- If neither SPF nor DKIM produces an aligned pass, DMARC fails and the receiver considers your published policy
- It reports back what it saw
Step 6 is the part people underestimate. You find out who's sending as you, including systems your own teams forgot.
The Three DMARC Policies
p=none takes no action. Mail flows as before while you collect reports. Every rollout starts here.
p=quarantine tells receivers to accept but flag failing mail, usually into junk.
p=reject is the strongest published policy and tells receivers that DMARC failures should be treated as unauthorised use of your domain. Whether a receiver rejects the message still depends on its local handling rules.
If you want a testing phase, current DMARC provides the t tag. t=y signals test mode; the historic pct tag is deprecated.
What a DMARC Record Looks Like
A single TXT record published at the _dmarc hostname on your domain:
v=DMARC1; p=none; rua=mailto:[email protected]
Once you're confident, it becomes:
v=DMARC1; p=reject; rua=mailto:[email protected]
Two report types exist. rua sends aggregate reports, usually daily, as compressed XML summarising what passed and failed. ruf requests per-message failure reports. Not every receiver sends them, and they may contain sensitive message details, so don't build your monitoring around them.
Why Does It Matter?
Without enforcement, an attacker sending as your finance team looks identical to the real thing. Staff have nothing to check against.
There's a deliverability angle too. Gmail and Yahoo now require bulk senders to publish DMARC alongside SPF and DKIM, with at least p=none.
The reporting is worth having on its own. DMARC reports reveal forgotten or undocumented systems sending mail with your domain.
How to Roll Out DMARC Safely
Rushing this breaks legitimate mail. Work in order.
- Inventory every system that sends as you, including marketing, ticketing, and payroll platforms
- Configure SPF and DKIM for legitimate senders first. DMARC passes when at least one method passes and aligns with the From domain, though both is recommended
- Publish
p=nonewith an rua address and leave it for several weeks - Read the reports and fix or remove anything legitimate that's failing
- Move to quarantine once legitimate mail is aligned. For a testing phase, use
t=y - Consider reject once you have reviewed the impact on forwarding and mailing lists
Expect months, not days. That's normal.
Common Mistakes
Jumping straight to reject. Invoices stop arriving and someone reverts the record within a day.
Stopping at none. Monitoring blocks nothing. A domain sitting at p=none for two years has documentation, not protection.
Forgetting subdomains. Use sp to set policy for existing subdomains, and np for non-existent ones attackers could spoof.
Ignoring the reports. They're XML and unpleasant to read by hand. Use a parser, or the exercise stalls at step three.
What Should Security Testing Cover?
Ask your testers to confirm:
- Whether your domain and subdomains can be spoofed in practice
- That your published policy is enforcing, not none
- Whether SPF is too broad or exceeds the DNS lookup limit
- Whether DKIM signing works across every sending platform
- How staff respond to a lookalike domain, which DMARC cannot stop
That last point matters. DMARC protects your exact domain, not one that merely resembles it.
How OraSec Can Help
OraSec tests email authentication as an attacker would, checking whether your domain can be spoofed and what happens when it is. We pair that with phishing simulation, because the gap DMARC leaves is where people fall through.
Conclusion
DMARC gives useful visibility at p=none, but anti-spoofing enforcement starts at quarantine or reject. A permanent p=none only asks receivers to monitor failures, not block them.
Inventory your senders, fix SPF and DKIM, monitor honestly, then move to enforcement. Then test that an outsider genuinely can't send as you.
FAQs
Do I need SPF and DKIM before DMARC? Configure both where possible. A message passes DMARC when either SPF or DKIM passes and aligns with the From domain.
Is p=none enough? No. It monitors and blocks nothing. Treat it as the first week, not the destination.
Will DMARC break our newsletters? Only if the platform isn't authenticated. That's what the monitoring phase is for.
Does DMARC stop all phishing? No. It stops spoofing of your exact domain. Lookalike domains and compromised accounts still get through.
How long does rollout take? Weeks to months, depending on how many systems send as you. Most of the delay is finding them all.
