What Is a DMARC Record? Tags, Policy, and Examples

A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. It tells receiving mail servers how to treat messages that appear to come from your domain but fail email authentication checks.

DMARC sits on top of SPF and DKIM. It does not replace them. Instead, it checks whether SPF and or DKIM passed and whether the authenticated domain aligns with the visible From domain.

That combination makes DMARC both a policy standard and a reporting standard. It helps domain owners reduce spoofing while also measuring who is sending mail on their behalf.

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

A good review starts by breaking the record into tags. Each tag changes how receivers should interpret policy, reporting, or alignment.

• v=DMARC1: identifies the record as a DMARC policy
• p=none, quarantine, or reject: sets the requested handling for failing mail
• rua=mailto:...: sends aggregate reports to one or more mailboxes
• ruf=mailto:...: requests forensic reports where receivers support them
• adkim=r or s: controls relaxed or strict DKIM alignment
• aspf=r or s: controls relaxed or strict SPF alignment
• pct=100: applies the policy to a percentage of failing mail

The most important tags for day-to-day operations are usually p, rua, adkim, and aspf. Those are the ones that most directly affect enforcement and reporting.

• p=none means monitor only, with no requested enforcement
• p=quarantine means failing mail should usually be treated as suspicious
• p=reject means failing mail should usually be rejected during SMTP

A strict-looking DMARC record is not automatically a healthy one. A reject policy is only safe when all legitimate senders are already aligned through SPF or DKIM.

• The record is published at _dmarc.example.com and not at the root domain
• The syntax is valid and tags are separated with semicolons
• The policy matches your deployment stage and risk tolerance
• The aggregate report mailbox is monitored and can receive volume safely
• SPF and DKIM are aligned for every real sender, including third-party services

In practice, many DMARC problems are not DMARC syntax problems at all. They come from untracked SaaS platforms, forwarding behaviour, or misaligned SPF and DKIM settings.

• Publishing p=reject before reviewing aggregate reports
• Assuming SPF pass alone is enough without checking alignment
• Forgetting to add or verify a mailbox for rua reporting
• Leaving legitimate vendors unsigned or unauthorised
• Treating the record as finished once it exists, without ongoing report review

DMARC works best as an operational process, not a one-time DNS task. The record is only the start; the reports tell you whether enforcement is actually safe.

• What Is DMARC?
• How to Interpret DMARC Reports
• How to Troubleshoot DMARC Failures

If you want to validate this topic in practice, these DNS Pro tools are the fastest next step.

• DMARC Checker
• Email Security Check
• TXT Lookup