DNS Record Explainer

v=DMARC1
Version tag. Always "DMARC1" for current spec. Tells receivers this is a valid DMARC policy.

p=none
Policy directive. "none" means: monitor and report, but don't reject or quarantine mail that fails SPF/DKIM. Receivers still check alignment and send aggregate reports to your rua address, but they pass the mail through. This is the safe deployment phase before you enforce stricter policies (p=quarantine or p=reject).

rua=mailto:[email protected]
Reporting address for aggregate reports. Receivers send you XML summaries (usually daily) of authentication results from mail claiming your domain. This is how you detect spoofing attempts and see SPF/DKIM pass/fail rates. You need a real, monitored mailbox here—unreadable reports waste the point.

Missing ruf address. You have aggregate reporting (rua) but no forensic reporting (ruf). Forensic reports give you the actual message headers and content from failures, not just counts. Add ruf=mailto:[email protected] if you want visibility into individual failures (note: some receivers ignore ruf due to privacy, but it's still useful). Not critical, but limits debugging power.

Missing DKIM/SPF alignment tags. The record doesn't specify aspf or adkim, so they default to "r" (relaxed alignment). This is usually fine—relaxed alignment allows subdomain mismatches—but you may want explicit aspf=s; adkim=s; if you require strict alignment. Document your intent clearly.

No fo (failure reporting) option. Defaults to "0" (report only alignment failures). If you want reports on all SPF/DKIM failures regardless of alignment, add fo=1. Minor, but clarifies reporting scope.

rua address is example.com. Confirm [email protected] is actually monitored and can receive large XML attachments. Bouncing DMARC reports wastes sender time.

This policy is actively monitoring your domain's authentication. Mail that claims to be from example.com will be checked against published SPF and DKIM records. Failures are logged and emailed to you, but not blocked. Without DMARC, receivers have no standardized signal about whether spoofed mail is acceptable. With p=none, you're in the safe phase: collect data, fix your SPF/DKIM alignment, then move to p=quarantine or p=reject once you trust your sender list.

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