What is DMARC, really?

DMARC is the policy layer that sits on top of SPF and DKIM. It tells receivers what to do with mail that fails authentication, and it sends you reports so you can see what is happening to your domain's mail — including mail you did not send.

The problem DMARC solves

Before DMARC, SPF and DKIM had a gap: even if both checks passed, there was no requirement that the domain in the "From" header — the address the recipient sees — matched the domain that was authenticated. Spammers could use a legitimate SPF record for one domain while displaying a different domain in the From field.

DMARC closes this gap with "alignment" — it requires that the domain in the From header matches the domain that passed SPF or DKIM. No alignment means DMARC fails, regardless of whether SPF or DKIM pass on their own.

The three DMARC policies

p=none (monitoring only)

Mail continues to flow exactly as it would without DMARC. The only effect is that receivers send you aggregate reports about authentication results. This is your starting point — you cannot safely move to quarantine or reject without first understanding what is in your mail stream.

p=quarantine

Mail that fails DMARC is moved to the spam/junk folder. It is not rejected — it still arrives, but in a lower-trust folder. This is the right intermediate step between monitoring and full enforcement. A percentage modifier (pct=10) lets you apply the policy to only a fraction of failing mail, so you can ramp up gradually.

p=reject

Mail that fails DMARC is rejected at the server level. The message never reaches the recipient at all. This is maximum protection against spoofing — but it will block your own mail if any legitimate sending source is not properly authenticated. Do not move to reject until your aggregate reports show 100% of your legitimate mail passing.

What DMARC reports tell you

DMARC aggregate reports (sent to the address in your rua= tag) show, for each sending IP:

• How many messages were sent claiming to be from your domain
• Whether they passed or failed SPF and DKIM
• Whether DMARC alignment passed
• What policy was applied

These reports come as XML files and are hard to read raw — use a DMARC reporting service (Postmark, Valimail, Dmarcian, or similar) to parse and visualise them.

What p=reject stops — and what it doesn't

p=reject stops direct-domain spoofing: mail that claims to come from exactly your domain (e.g. from@yourdomain.com) but was not sent by your authorised sending infrastructure.

It does NOT stop:

• Lookalike domains — attackers registering y0urdomain.com or yourdomain-support.com and sending from those. These are different domains and your DMARC record cannot protect them.
• Display name spoofing — mail that shows your name in the display name but uses a completely different address ("Your Bank" <attacker@unrelated.com>)
• Cousin domains — similar domains that fool users visually but don't claim to be your exact domain

For protection against lookalike and impersonation attacks, see the Brand impersonation and lookalikes guide.

The path to p=reject without breaking your mail

1. Add a DMARC record at p=none with a reporting address.
2. Read reports for 4–6 weeks. Catalogue every sending source.
3. Ensure every source has proper SPF inclusion and DKIM signing.
4. Move to p=quarantine; pct=10 — apply policy to 10% of failing mail.
5. Monitor for any legitimate mail landing in spam. Fix any missed sources.
6. Increase pct to 25%, 50%, 100% over a few weeks.
7. When aggregate reports show 100% pass rate on legitimate mail, move to p=reject.