DMARC: from monitoring to enforcement

Published September 4, 2026. Updated September 9, 2026.

A DMARC record tells receivers what to do with mail that claims to be from your domain but fails authentication (SPF and DKIM), and where to send reports. It is published as a TXT record at _dmarc.yourdomain.

Why it matters

SPF and DKIM prove a message is authorized; DMARC ties them to the visible "from" domain and states a policy. Without DMARC, a forged message that fails those checks may still be delivered. With an enforcing DMARC policy, receivers can quarantine or reject it.

What "p=none" means

p=none is monitoring only: you receive reports but receivers take no action on failures. It is the right first step, but it is not protection. The goal is to move to p=quarantine and then p=reject once your legitimate mail passes.

How to roll it out safely

Publish p=none with a reporting address and watch the aggregate reports for a few weeks.

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Make sure every legitimate source passes SPF or DKIM (and aligns with your domain).
Move to p=quarantine (optionally with pct= to ramp up), then p=reject.

cPanel / Cloudflare: add a TXT record named _dmarc with the value above.

How to verify

dig _dmarc.example.com TXT +short

You should see one v=DMARC1 record. Read the aggregate (rua) reports before tightening the policy.

Common mistakes

Staying on p=none forever. Monitoring is step one, not protection. The goal is p=quarantine then p=reject.
Jumping straight to p=reject. Do it before your legitimate mail all passes SPF or DKIM and you will bounce your own newsletters and app mail. Watch the aggregate reports first, optionally ramp with pct=.
Alignment. DMARC needs SPF or DKIM to pass and align with the visible From domain. Mail relayed through a third party often passes SPF for the relay's domain, not yours; DKIM signing with your domain fixes alignment.
Wrong record name. The record lives at _dmarc.example.com, not the apex.