DMARC: tell the recipient what to do with forged email

SPF and DKIM both answer the same question: is this message genuine? Neither one tells the receiving server what to do if the answer is no. Every receiving system makes that call on its own, differently case by case. DMARC is the rulebook for what should happen.

What DMARC actually does

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS record that ties SPF and DKIM together and adds an instruction: approve, send to spam, or reject outright. It also requires the domain the recipient sees in the sender field to actually match the domain SPF or DKIM approved, known as alignment. Without that, a message can pass SPF on a completely different domain than the one it displays as the sender.

Prerequisite: SPF and DKIM need to be in place before DMARC does anything useful. DMARC has nothing to tie together otherwise.

What a record looks like

v=DMARC1; p=none; rua=mailto:[email protected]; pct=100

p= is the policy: none (monitor only), quarantine (send to spam) or reject (block outright).
rua= is the address receiving servers send summarized reports to, showing what passed and what failed.
pct= sets what share of messages the policy applies to, 100 means all of them.

How to add it without locking out your own mail

Create a TXT record at _dmarc.yourcompany.com with p=none and an rua address you'll actually read.
Leave it running for a few weeks. The reports show which senders, internal systems, newsletters, invoicing tools, are still missing SPF or DKIM.
Fix those, not the DMARC record.
Raise the policy in steps: none → quarantine → reject. Jumping straight to reject without reading a single report is the most common way to accidentally block your own email.

Only once SPF, DKIM and DMARC are in place, in that order, is the domain actually protected against someone sending forged email as you.