DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy layer on top of SPF and DKIM: a DNS record telling receivers what to do with mail that claims to be from your domain but fails authentication—and, crucially, asking them to report back what they’re seeing.
Why this is a yes
- The requirements say so. Google, Yahoo, and Microsoft all require bulk senders to publish a DMARC policy. Send meaningful volume without one and you’re volunteering for the spam folder.
- Spoofing is your problem even when you didn’t send the mail. Phishing that wears your domain burns your customers and your reputation. DMARC is the mechanism that lets receivers refuse it.
- The reports alone are worth it. With reporting enabled, you get visibility into every source sending as your domain—including the marketing tool someone connected two years ago and forgot. (Read them—publishing without reading is half the value.)
Starting is free
The minimum viable DMARC is one TXT record:
_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"p=none is observation mode: no enforcement, no risk to legitimate mail, full visibility. This is the right starting point for almost everyone—it establishes a baseline of who sends on your behalf and surfaces misconfigured senders before they become incidents.
Where it goes from here
none is the floor, not the destination. The escalation path is none → fix what the reports surface → quarantine → reject. Enforcement is where DMARC actually stops spoofing—but it’s a decision with teeth, which is why it gets its own verdict.
One warning: don’t publish quarantine or reject on day one because a security checklist told you to. Unauthenticated legitimate mail—a billing system, a support desk, that forgotten marketing tool—gets filtered or bounced, and you’ll find out from angry humans instead of tidy reports.
One footnote: the spec itself is evolving—a new revision of DMARC is on the way, and everything above carries over.