The policy values
p=none asks receivers only to report. p=quarantine asks them to treat failing mail with suspicion, typically by delivering it to spam. p=reject asks them to refuse it. Moving from none to reject is a sensible hardening path once reports show that legitimate mail passes.
Why it matters for DNS changes
With a strict policy, a small mistake in SPF or DKIM becomes rejected mail. Do not tighten DMARC and change DNS on the same day, and read the aggregate reports before raising the policy.
An example
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com" asks receivers only to report and to send aggregate reports to that address. When the reports show that every legitimate source passes, move to p=quarantine and later p=reject. A new newsletter tool added without SPF or DKIM set up would then fail, so list every sending service before tightening. Check the record with dig TXT _dmarc.example.com +short.
Aggregate reports arrive as XML files from the large mailbox providers, often compressed. Reading them by hand is tedious, so many agencies use a report reader; either way, look for sending sources you do not recognise before raising the policy.
What to check
The current policy, the address that receives reports and a test message that shows dmarc=pass.
Sources
Read on . Standards and vendor pages change; confirm the current text before you rely on it.
- RFC 7489, DMARC (www.rfc-editor.org)