DMARC
By Federico Donatone · Updated October 15, 2026DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS record that tells receiving mail servers what to do with email that uses your domain but fails authentication: deliver it, send it to spam or block it. It builds on SPF and DKIM and sends you reports on who is sending email as your domain.
What is DMARC used for
DMARC does two jobs. First, it protects your domain from spoofing, where someone sends email that pretends to come from you. Without DMARC, a receiver that sees SPF or DKIM fail has no instruction from you and decides on its own. Second, it gives you visibility: aggregate reports list the servers sending email as your domain and whether they passed, so a forgotten tool or an impostor shows up quickly.
It is also a requirement at volume. Google's email sender guidelines require SPF, DKIM and DMARC from anyone sending 5,000 or more messages a day to Gmail, along with one-click unsubscribe and a spam complaint rate under 0.3%.
How DMARC works
DMARC adds one rule on top of SPF and DKIM: alignment. A message passes DMARC when SPF or DKIM passes and the domain that passed matches the domain in the From line the reader sees. On their own, SPF and DKIM can pass for a different domain than the one shown to the reader. Alignment closes that gap.
_dmarc.example.comv=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.comv=DMARC1 marks the record, p=quarantine sends failing mail to spam, and rua= is the address that receives aggregate reports.growthcab.com runs this setup: a DMARC policy of p=quarantine with aggregate reports turned on (checked October 15, 2026).
Aggregate reports arrive as XML files from each receiving provider. They are hard to read raw, so many teams route them to a DMARC report reader that groups results by sending source. Look for two things: your own tools failing alignment, which you fix, and unknown servers sending as you, which your policy should stop.
DMARC vs SPF vs DKIM
| SPF | DKIM | DMARC | |
|---|---|---|---|
| What it checks | Which servers may send | A signature on each message | That SPF or DKIM passed for the From domain |
| Where it lives | TXT at the domain | TXT or CNAME at selector._domainkey | TXT at _dmarc |
| Survives forwarding | Often not | Usually | Yes, through DKIM |
| Tells receivers what to do | Partly, with ~all or -all | No | Yes, with the p= policy |
| Sends you reports | No | No | Yes, with rua= |
You need all three. SPF and DKIM prove identity, and DMARC ties that proof to the address the reader sees.
DMARC policies and how to roll them out
DMARC has three policies (RFC 7489): p=none only monitors, p=quarantine asks receivers to send failing mail to spam, and p=reject asks them to block it. Move through them in order:
- Publish SPF and DKIM for every service that sends as your domain.
- Add a DMARC record with p=none and an rua address, then read the reports for a few weeks.
- Fix every legitimate sender that fails alignment, usually a CRM or marketing tool signing with its own domain.
- Move to p=quarantine once your own mail passes consistently.
- Move to p=reject when the reports show only impostors failing.
Our free cold email domain checker reads your DMARC record along with SPF and DKIM. For alignment problems that survive these steps, our email deliverability consultant service works from message headers and DMARC reports. The cold email deliverability checklist covers the rest of the sending setup.