DMARC records tell receiving mail systems what to do when a message claims to be from your domain but fails aligned email authentication. The record is a DNS TXT value published at _dmarc.yourdomain.com. The safest way to understand it is to separate the required policy from optional reporting and rollout controls.
A monitoring example
A starting record may look like v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. The v tag identifies DMARC. The p=none policy asks receivers to take no special enforcement action, while rua requests aggregate reports. Monitoring is useful while you inventory legitimate senders, but it does not actively deter all spoofed mail.
A quarantine example
A cautious enforcement record might use v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com. Quarantine asks participating receivers to treat failing mail as suspicious, often placing it in spam. The percentage tag lets you begin with a subset of failing mail. Raise it only after reports and real message tests show your legitimate sources pass alignment.
A reject example
A mature policy may use v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com. Reject asks receivers to refuse failing mail. It is strong protection against direct domain spoofing, but it is not a setting to paste before testing every sender. A forgotten billing platform, support tool, or marketing vendor can be affected if it is not aligned.
Alignment is the deciding test
DMARC passes when SPF or DKIM passes and aligns with the visible From domain. An SPF or DKIM pass alone is not always enough. Inspect a fresh message header from each sender and verify the final DMARC result. See email authentication explained and how to check DKIM for the related evidence.
Common record mistakes
Publish only one DMARC record at the exact _dmarc host. Do not add a second TXT record with another DMARC policy. Use a reporting address that someone monitors, and confirm external-report authorization if reports go to another domain. Preserve the current record before editing it, because a simple syntax mistake can make the policy unreadable.
Safe rollout checklist
- List every system that sends as the domain.
- Enable DKIM where each system supports it.
- Review aggregate reports and fresh authentication headers.
- Start enforcement gradually with quarantine if appropriate.
- Move to reject only when aligned legitimate traffic is stable.
Read the full policy comparison and when quarantine makes sense before raising enforcement. Run Beacon’s free check to inspect the public SPF, DKIM, and DMARC records before and after any DNS change.
Use reports as evidence, not decoration
Aggregate reports can reveal a legitimate service you forgot, an old vendor still using the domain, or a source that deserves investigation. Assign a person to review them and document each decision. When a source is unclear, do not rush to reject it or authorize it: compare headers, account ownership, and provider documentation first. The report is the start of a controlled investigation, not an automatic verdict.
Keep the record readable
Use only the tags you understand and avoid adding every optional setting at once. A clear, documented record is easier to maintain than a long string copied from several guides. Review it after any sender migration, rebrand, or agency change, and test fresh messages after each meaningful update.
Keep the audit record with the date, responsible owner, tested senders, and final policy decision for future review.