What is DMARC, and what does a policy do?

DMARC — Domain-based Message Authentication, Reporting and Conformance, defined in RFC 7489 — is the record that makes SPF and DKIM add up to something. On its own, each authenticates an identity the recipient never sees. DMARC requires one of them to match the From: address that is actually displayed, states what a receiver should do when neither does, and asks for reports on both.

The record

A TXT record at _dmarc on your domain:

_dmarc.yourapp.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@yourapp.com; adkim=s; aspf=s"

The tags:

• p= — the policy: none, quarantine or reject. What a receiver should do with mail that fails.
• rua= — where to send aggregate reports. Daily XML summaries of everything sent as your domain, from everywhere.
• ruf= — forensic reports on individual failures. Most large receivers do not send these; do not build a process around them.
• adkim= / aspf= — alignment mode, r for relaxed (the default) or s for strict. See DMARC alignment.
• pct= — apply the policy to a percentage of failing mail. A rollout tool, not a destination.
• sp= — a separate policy for subdomains.

What the three policies mean

p=none — do nothing differently, but send me reports. This is a monitoring mode. It changes no delivery outcome, and a domain sitting on p=none is a domain that has published its intention to do nothing about impersonation. It is the correct first step and a poor permanent state.

p=quarantine — treat failing mail as suspicious. In practice, the spam folder.

p=reject — refuse failing mail at the SMTP conversation. It never reaches the recipient and the sending server is told so.

A policy only applies to mail that fails DMARC, which means fails both SPF alignment and DKIM alignment. Correctly configured senders are unaffected by p=reject. That is worth being precise about, because the fear of moving off p=none is usually a fear of breaking legitimate mail — and the mail that breaks is the mail you did not know was being sent as you.

Getting to enforcement without breaking things

1. Publish p=none with a rua= address. Change nothing else.
2. Read aggregate reports for two to four weeks. They will name senders you forgot: the invoicing system, a monitoring tool, a support desk, a script on a server.
3. Fix each one — add it to SPF, get it signing with DKIM, or stop it sending as your domain.
4. Move to p=quarantine, optionally with pct= to ramp.
5. Move to p=reject when reports show nothing legitimate failing.

The reports are XML and unpleasant to read by hand; any DMARC reporting service will parse them. The point of the exercise is the inventory, not the file format.

What DMARC does not do

• It does not stop display-name spoofing. A message from attacker@gmail.com with the display name “YourApp Support” passes DMARC for gmail.com and never touches your domain. DMARC protects the domain in the From: address, not the words next to it.
• It does not encrypt anything. That is TLS.
• It does not make your mail arrive. It removes one reason for it to be filtered and stops others impersonating you. Reputation still decides the rest.
• It does not authenticate by itself. With no SPF and no DKIM, a DMARC record is a policy about checks that never pass.

Why it is the check that decides

Gmail and Yahoo have required a DMARC policy — at minimum p=none — from bulk senders since February 2024, and a domain with no DMARC record at all is increasingly treated as an unmaintained one. More practically: SPF and DKIM can both pass while the message has nothing to do with the domain the recipient is reading. DMARC is the only one of the three that asks the question the recipient would ask.

Pharos checks alignment at send time rather than reporting on it afterwards — a domain whose mail would fail cannot send in the first place. What Pharos does and does not claim is on the deliverability page.