The Complete Guide to DMARC

Every day, billions of emails are sent claiming to be from domains they have no connection to. Phishing, spoofing, and impersonation are the default state of email — the protocol was designed in an era when trust was assumed.

DMARC (Domain-based Message Authentication, Reporting & Conformance) exists to fix that. It's the mechanism that lets you, as a domain owner, tell the world's mail servers exactly what to do when someone sends an email that claims to be from your domain but can't prove it.

This guide covers everything you need to understand and implement DMARC — whether you're starting from scratch or tightening an existing setup.

What is DMARC and Why Does It Matter?

DMARC is a DNS-based email authentication protocol. You publish a short text record in your domain's DNS, and every mail server that receives an email claiming to be from your domain checks that record to decide what to do.

The record answers three questions:

1. Should unauthenticated emails be accepted, quarantined, or rejected? This is your policy — the core of DMARC.
2. How strictly should authentication be checked? You control whether subdomains count as aligned or whether exact matches are required.
3. Where should reports be sent? Receiving servers send you daily summaries of who's sending email as your domain and whether it passed authentication.

Without DMARC, you're relying on each mail provider's best guess. Gmail might flag a spoofed email as spam. Outlook might deliver it to the inbox. Yahoo might bounce it. You have no say.

With DMARC, you set the rules. A failed authentication check results in exactly what you specify — every time, at every provider that supports DMARC (which is effectively all major providers at this point).

The business impact is real. Google, Yahoo, and Microsoft now require DMARC for bulk senders. If you send more than 5,000 emails per day to Gmail users, you need a DMARC record or your mail won't arrive. Beyond compliance, DMARC protects your brand — every phishing email that impersonates your domain erodes trust with your customers.

For a deeper dive into the protocol's history and design, see what DMARC is and why it matters.

How DMARC Works: The Authentication Chain

DMARC doesn't work alone. It sits on top of two older protocols — SPF and DKIM — and adds something neither provides on its own: a policy layer and a feedback loop.

Here's what happens when an email arrives at a receiving server:

1. SPF check — The server looks up the sending domain's SPF record to see if the sending IP address is authorised. SPF is essentially a list of "these servers are allowed to send email for this domain."
2. DKIM check — The server verifies a cryptographic signature attached to the email. If the signature is valid, it proves the message hasn't been altered since the authorised sender signed it.
3. DMARC alignment — This is DMARC's key contribution. SPF and DKIM can both pass, but DMARC asks a further question: does the domain that passed SPF or DKIM actually match the domain in the From header that the recipient sees? If your SPF record authorises a marketing tool to send from its own domain, but the From header says you@yourdomain.com, SPF passes but DMARC alignment fails. The authentication is real, but it doesn't prove that your domain sent the message.
4. Policy enforcement — Based on the alignment result and your published DMARC policy, the receiver takes action: deliver normally (p=none), send to spam (p=quarantine), or reject outright (p=reject).

The alignment concept trips up most people. You can have a perfectly valid SPF record and a correctly configured DKIM signature, but if neither one uses a domain that matches your From address, DMARC still fails. This is by design — it closes the gap where a third-party service passes SPF under its own domain while impersonating yours in the From header.

DMARC supports two alignment modes: relaxed (the organisational domain must match — so mail.example.com aligns with example.com) and strict (exact match required). Most organisations use relaxed, which is the default.

Read the full technical breakdown at how DMARC works, and see DMARC alignment explained for common alignment scenarios and how to fix mismatches.

Anatomy of a DMARC Record

A DMARC record is a TXT record published at _dmarc.yourdomain.com. It's a single line of text with semicolon-separated tags. Here's a typical example:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100; adkim=r; aspf=r

Each tag controls a specific aspect of your DMARC policy:

Only v and p are required. Everything else has sensible defaults. But in practice, you should always set rua — without it, you're flying blind. The aggregate reports are what tell you who's sending as your domain and whether your legitimate senders are passing.

A common mistake is publishing a record with p=reject but no rua. You're blocking unauthenticated email but have no way to see if you're also blocking email from a legitimate service you forgot to align.

For a complete walkthrough of every tag, including edge cases and common syntax errors, see DMARC record explained.

How to Create a DMARC Record

If you don't have a DMARC record yet, start with the simplest possible configuration:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

This tells receiving servers: "Don't take any action on failing emails, but send me daily reports about everything." It's monitoring mode — no email gets blocked, but you start building visibility into who's sending email as your domain.

Where you publish this record depends on your DNS provider. The record goes at _dmarc.yourdomain.com as a TXT record. The process is the same across providers — create a TXT record, set the host to _dmarc, paste your DMARC string as the value.

A few things to get right:

• One record per domain. If you already have a DMARC record, edit it rather than adding a second one. Multiple DMARC records cause the entire policy to be ignored.
• Start with p=none. Jumping to quarantine or reject before you've reviewed your reports risks blocking legitimate email.
• Use a real email address for rua. You'll receive XML files — consider using a dedicated mailbox or a DMARC reporting service rather than your personal inbox.

DNS propagation typically takes minutes but can take up to 48 hours. You can verify your record is live using our free DMARC record checker.

For step-by-step instructions with screenshots for popular DNS providers, see how to create a DMARC record. We also have provider-specific guides for Cloudflare, GoDaddy, Namecheap, and others.

DMARC, SPF, and DKIM: How They Work Together

A common misconception is that DMARC replaces SPF and DKIM. It doesn't — it depends on them. Think of it as three layers:

SPF (Sender Policy Framework) is a DNS record that lists which IP addresses are allowed to send email for your domain. When a server receives an email, it checks whether the sending IP appears in your SPF record. If it does, SPF passes. SPF is simple and effective, but it has a critical limitation: it checks the envelope sender (the Return-Path), not the From address the recipient sees. A phishing email can pass SPF by using a different Return-Path domain.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each email. The sending server signs the message with a private key, and the receiving server verifies it using a public key published in DNS. If the signature is valid, the message hasn't been altered in transit. DKIM is stronger than SPF in one important way: it survives email forwarding. When a message is forwarded, the envelope sender changes (breaking SPF), but the DKIM signature stays intact as long as the body isn't modified.

DMARC ties them together by requiring alignment. It's not enough for SPF or DKIM to pass — the domain that passed must match the From header. This closes the gap that SPF alone leaves open. DMARC also adds the policy layer (what to do with failures) and the reporting layer (visibility into authentication results).

In practice, you want both SPF and DKIM configured, not just one. SPF alone breaks on forwarding. DKIM alone doesn't prevent a spoofed envelope sender. Together, with DMARC alignment, they cover each other's weaknesses.

For the full comparison, see SPF, DKIM, and DMARC: how they work together and DKIM vs DMARC: what's the difference?.

Moving to Enforcement

Publishing a DMARC record with p=none is a starting point, not the finish line. Monitoring mode gives you visibility, but it doesn't stop anyone from spoofing your domain. The goal is to reach p=reject, where unauthenticated email is blocked outright.

The safe path has four stages:

1. p=none — Monitor for 2–4 weeks. Review your aggregate reports to identify every legitimate service sending email as your domain. Marketing platforms, CRMs, helpdesks, transactional email providers — they all need to be aligned before you enforce.
2. p=quarantine; pct=10 — Start enforcing, but only on 10% of failing messages. The other 90% are treated as if the policy were still p=none. This limits the blast radius if you missed a legitimate sender.
3. Ramp pct gradually — Increase to 25%, then 50%, then 100%. After each step, check your reports for legitimate senders that are failing. Fix their alignment before increasing further.
4. p=reject — Full enforcement. Receiving servers refuse unauthenticated messages entirely. This is the strongest protection against domain spoofing and the level Google and Yahoo recommend for bulk senders.

The timeline depends on your email ecosystem. A simple setup (one domain, one ESP) might take two weeks. An enterprise with dozens of third-party senders sending from multiple subdomains could take months.

The most common reason organisations stall at p=none is fear of breaking legitimate email. The pct tag exists specifically to address this — it lets you enforce gradually and catch problems early. The other common blocker is third-party senders that aren't configured for DKIM alignment. Most modern ESPs support custom DKIM signing — it's usually a DNS CNAME record and a toggle in the sender's settings.

For the full step-by-step playbook, including a week-by-week rollout schedule, see our DMARC enforcement guide.

Monitoring and Reporting

DMARC reports are what make the protocol actionable. Without them, enforcement is guesswork.

There are two types of reports:

Aggregate reports (RUA) arrive daily as XML files from every receiving server that processes your email. Each report contains a summary: which IP addresses sent email as your domain, how many messages came from each, and whether they passed or failed SPF, DKIM, and DMARC. These reports are the foundation — they tell you who's sending as your domain, whether they're authorised, and where your gaps are.

Forensic reports (RUF) contain details about individual messages that failed DMARC. They're useful for investigating specific incidents, but many receivers don't send them due to privacy concerns. Don't rely on them as your primary data source.

The raw aggregate XML is dense and not human-friendly. A single report from Google can contain hundreds of rows covering every IP that sent email claiming your domain. At scale, you might receive dozens of reports daily from different receivers. Most organisations use a parsing tool or reporting service to make sense of the data.

What to look for in your reports:

• Unknown senders passing DMARC — Could be a service you forgot about, or could be a misconfigured SPF record that's too permissive.
• Legitimate senders failing — These need alignment fixes before you can enforce. The report shows exactly which authentication check failed.
• High-volume unauthorised senders — This is spoofing. This is what enforcement stops.

Reports also serve as your safety net after enforcement. If a legitimate sender breaks their DKIM configuration or you accidentally remove an IP from your SPF record, the reports will show the failure before your users start complaining.

For a complete guide to DMARC reporting, including how to read aggregate reports and manage volume at scale, see our DMARC reporting guide.

Common Problems and Troubleshooting

DMARC failures are frustrating because the error messages are vague and the root causes are varied. Here are the issues you're most likely to encounter:

No DMARC record found — The most basic problem. Either you haven't published a record, it's at the wrong DNS location (check for typos — _dmarc.yourdomain.com, not dmarc.yourdomain.com), or DNS propagation hasn't completed. Use our checker to verify.

DMARC policy not enabled — Your record exists but is set to p=none. This isn't an error if you're in the monitoring phase. It is a problem if you've been at p=none for months and haven't moved toward enforcement — you're collecting reports but not protecting anything.

DMARC fail on legitimate email — The most common issue after publishing a record. A service you've authorised is sending email that fails DMARC alignment. Usually this means DKIM isn't configured to sign with your domain, or SPF is set up under the service's domain rather than yours. The fix is almost always in the third-party sender's settings, not in your DMARC record.

Email forwarding breaks DMARC — When an email is forwarded, the forwarding server typically changes the envelope sender (breaking SPF) without re-signing with DKIM. If the original DKIM signature is intact, DMARC can still pass via DKIM alignment. If the forwarder modifies the message body, DKIM breaks too, and DMARC fails. This is a known limitation — mailing lists and email forwarders are the edge cases where DMARC is hardest to get right.

554 5.7.5 permanent error — A hard bounce caused by DMARC policy rejection. The receiving server checked your DMARC record, the email failed authentication, and your policy says to reject. Check whether the sender is legitimate (fix their alignment) or a spoofer (the system is working as intended).

For detailed walkthroughs of each issue with specific fixes, see our DMARC troubleshooting guide.

Check Your DMARC Record

Use our free DMARC record checker to instantly validate your domain's DMARC configuration. We parse every tag, verify your reporting destinations, check SPF and DKIM alignment, and give you specific recommendations for strengthening your setup.

Whether you're publishing your first DMARC record or preparing to move from p=none to p=reject, start with a check to see where you stand.