DNS Record Explainer

v=DMARC1
Version tag. Must be first, always literally "DMARC1". Tells receivers this is a DMARC policy.

p=none
Policy action. When email fails DMARC checks (SPF or DKIM alignment), receivers get "none" — report the failure but deliver anyway. This is the safest starting position. Other options: quarantine (spam folder), reject (bounce it). You'd move to stricter policies after monitoring.

rua=mailto:[email protected]
Reporting URI for aggregate reports. Receivers send daily XML summaries of DMARC results to [email protected]. These show pass/fail patterns, volume, and source IPs. Essential for monitoring — you need this mailbox set up and monitored, or reports pile up unread.

• rua points to example.com but you haven't stated if this domain actually receives mail or if the mailbox exists. Aggregate reports will fail silently if the destination doesn't accept them. Verify [email protected] exists and has capacity.

• No ruf tag (forensic reports). You're missing failure details. Add ruf=mailto:[email protected] if you want per-message reports when DMARC fails — useful for debugging alignment issues, but generates volume. Optional but recommended during p=none phase.

• p=none is correct for initial deployment, but you need a timeline to tighten this. After 2-4 weeks of clean aggregate data, move to p=quarantine; after another week+ with no false positives, p=reject. Staying on "none" indefinitely defeats DMARC's purpose (blocking spoofing).

• No subdomain policy (sp= tag). If you later need different rules for mail from subdomains, you'll add this. Not essential now.

This record sits at _dmarc.example.com as a TXT record. It tells receivers how to handle mail claiming to be from @example.com. Without DMARC, SPF and DKIM pass/fail independently and receivers guess whether to trust the sender. With p=none, you're in audit mode — learning your mail ecosystem before enforcing policy. The aggregate reports are your data source for knowing when it's safe to reject.

→ /tools/dmarc-checker run the live checker on a real domain → /blog/dmarc-policies-explained