DMARC Explained: How to Deploy, Monitor, and Enforce Your Email Authentication Policy
What DMARC Does (and What It Doesn't)
DMARC — Domain-based Message Authentication, Reporting and Conformance — is a DNS policy that tells receiving mail servers what to do when a message claims to be from your domain but fails authentication. It builds on SPF and DKIM, so you need both configured and passing before DMARC is worth enforcing. Without them, DMARC has nothing meaningful to check against.
What DMARC adds beyond those two standards is the policy layer and the reporting layer. The policy layer specifies whether failing mail should be delivered anyway (none), quarantined to the spam folder (quarantine), or rejected outright at the SMTP level (reject). The reporting layer delivers daily aggregate reports to an address you specify, showing you every source that claims to be your domain — including unauthorized senders you may not know about.
How DMARC Authentication Actually Works
DMARC doesn't run its own authentication check. Instead, it looks at the results from SPF and DKIM and applies an additional rule: alignment. A message passes DMARC only if at least one of the following conditions is true:
- SPF alignment: The domain in the Return-Path (envelope sender) matches your From domain, and SPF passes for that domain.
- DKIM alignment: The domain in the DKIM signature's
d=tag matches your From domain, and the signature is valid.
This alignment requirement is what closes the gap that SPF and DKIM alone leave open. An attacker could forge your From address while using a different domain for the SPF check — but they can't pass DMARC alignment without controlling your actual domain.
Publishing Your First DMARC Record
DMARC is a TXT record published at _dmarc.yourdomain.com. Always start with a monitoring-only policy:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.comThe p=none policy means receiving servers won't change how they handle failing mail — they'll just send you reports. This gives you a safe window to understand what's sending email on behalf of your domain before you enforce anything that could affect delivery.
The rua tag specifies where aggregate reports are sent. These arrive daily as XML files, one per receiving organization (Google, Yahoo, Microsoft, etc.). Tools that parse and visualize them make the data far more readable than raw XML — your email provider's dashboard may include this, or you can use a standalone DMARC reporting tool.
Reading DMARC Aggregate Reports
Aggregate reports tell you which IP addresses sent mail claiming to be from your domain, how many messages each IP sent, whether those messages passed SPF and DKIM, and which DMARC policy was applied. When you first turn on monitoring, you'll frequently discover sending sources you didn't know about — a CRM tool, a third-party ticketing system, a bulk email vendor that was set up years ago. Before moving to enforcement, every legitimate source needs to authenticate correctly. That usually means configuring DKIM signing for each service and ensuring its sending domain aligns with your From domain.
Moving to Enforcement: quarantine vs reject
Once your reports show that nearly all legitimate mail is passing DMARC, you can move toward enforcement. The standard progression:
- p=none — Monitor for at least 2–4 weeks
- p=quarantine; pct=10 — Apply quarantine to 10% of failing mail
- p=quarantine; pct=100 — Quarantine all failing mail
- p=reject — Reject failing mail at the SMTP level
The pct tag lets you roll out enforcement gradually, which is the safest approach. Start at 10%, monitor your reports for a week, and ramp up only when you're confident no legitimate mail is failing. Moving too fast is the most common way organizations disrupt their own email during a DMARC deployment.
p=reject is the goal. At reject, spoofed mail using your domain gets blocked before it reaches anyone's inbox. This is the enforcement level that major inbox providers like Google and Yahoo now strongly encourage — and in some cases require — for senders above certain volume thresholds.
DMARC for Subdomains
DMARC has a separate policy tag for subdomains: sp=. If you want all subdomains covered by the same policy as your root domain, add it explicitly:
v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@yourdomain.comWithout an sp= tag, subdomains inherit the root domain policy. This is usually fine — but be aware that a p=none root policy also means sp=none, even if an attacker is actively spoofing billing.yourdomain.com.
Forensic Reports (RUF): Useful but Limited
Beyond aggregate reports, DMARC supports per-message forensic reports via the ruf tag. These are sent when a specific message fails DMARC and can help diagnose isolated failures. However, forensic reports contain actual message content, which raises privacy considerations, and many major ISPs no longer send them. In practice, aggregate reports paired with a good visualization tool give you most of what you need for day-to-day management.
Connecting DMARC to the Broader Authentication Stack
DMARC delivers full value as part of a complete authentication setup. The DNS security overview covers SPF, DKIM, and DMARC together and how they interact at the receiving end. If you haven't tackled SPF and DKIM yet, those come first — DMARC enforcement against unauthenticated mail is meaningless if your own legitimate sends aren't authenticating.
For teams using MailDog's SMTP relay, DKIM signing is handled automatically, which means outbound mail from MailDog infrastructure is already DMARC-aligned. The remaining step is publishing the DMARC TXT record for your domain — the MailDog documentation covers exactly what to publish alongside your sending configuration.
If you've deployed DMARC recently and are seeing unexpected failures, the email deliverability audit checklist is a useful companion for identifying authentication gaps alongside other delivery factors. The MailDog support team can also review your authentication records directly and help you move to rejection policy without disrupting legitimate mail flow.
