DMARC Record: Setup, Policies, and Reports

DMARC ties SPF and DKIM together and tells inbox providers what to do when authentication fails.

What is DMARC and why do you need it?

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS policy record that ties together SPF and DKIM authentication. It tells inbox providers what to do when an email from your domain fails authentication checks — and it gives you a reporting mechanism to see who is sending on your behalf.

Since February 2024, Google and Yahoo require DMARC for bulk senders (more than 5,000 emails per day). Without DMARC, a significant portion of your emails to Gmail and Yahoo addresses will be rejected or quarantined. DMARC is now mandatory infrastructure, not optional.

  • Google and Yahoo require DMARC for bulk senders since February 2024.
  • DMARC without SPF and DKIM is meaningless — all three must be configured.
  • Start with p=none to monitor, then escalate to p=quarantine and eventually p=reject.

How DMARC works

DMARC builds on SPF and DKIM by adding alignment checks. For DMARC to pass, the domain in the 'From' header must align with either the SPF-authenticated domain (envelope from) or the DKIM-signed domain. This alignment requirement prevents attackers from passing SPF/DKIM with their own domain while spoofing your domain in the visible 'From' field.

When an email fails DMARC, the receiving server follows the policy you set: none (do nothing, just report), quarantine (send to spam), or reject (bounce the message). DMARC also instructs servers to send aggregate and forensic reports back to an email address you specify, so you can see what's happening.

DMARC record syntax explained

A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. The most important tags are: v (version, always DMARC1), p (policy: none/quarantine/reject), rua (aggregate report email), and pct (percentage of messages the policy applies to).

Minimal DMARC record (monitoring only): Record name: _dmarc.yourdomain.com Record type: TXT Record value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
DMARC with quarantine policy: v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@yourdomain.com
Full DMARC with reject policy: v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; adkim=s; aspf=s
DMARC policy comparison: p=none → Monitor only. No action on failures. Start here. p=quarantine → Failed emails go to spam folder. p=reject → Failed emails are bounced entirely. Maximum protection.

Step-by-step DMARC setup

Step 1: Ensure SPF and DKIM are both set up and passing. Step 2: Create a dedicated email address for DMARC reports (e.g., dmarc@yourdomain.com). Step 3: Add a DMARC TXT record at _dmarc.yourdomain.com with p=none and your rua email. Step 4: Wait 1–2 weeks and analyse the reports. Step 5: Once reports confirm only legitimate senders are authenticated, escalate to p=quarantine. Step 6: After another 2–4 weeks of clean reports, escalate to p=reject.

  • Always start with p=none — jumping straight to p=reject can break legitimate mail flows.
  • DMARC reports are XML files — use a free DMARC report analyser (dmarcian.com, mxtoolbox.com) to read them.
  • The rua email address must be on the same domain as the DMARC record, or you need a separate DNS record granting permission.

Reading DMARC reports

DMARC aggregate reports (RUA) arrive daily and show which servers sent email on behalf of your domain, and whether SPF and DKIM passed or failed for each. A good report shows 100% of mail passing from your authorised servers and zero mail from unknown sources.

If you see failures in the report: check whether you've missed authorising a sending service in your SPF record, check whether your DKIM keys are correctly published, and look for unknown sources (which might indicate your domain is being spoofed). Tools like dmarcian.com, Google Postmaster Tools, and Valimail provide readable dashboards for DMARC reports.

  • Set up a DMARC analyser tool before escalating to quarantine or reject — don't fly blind.
  • The 'source IP' column in reports tells you exactly which servers are sending on your behalf.
  • Forensic reports (ruf) contain actual failed email headers — useful for debugging but can be large.