What is DMARC? A complete guide

DMARC (Domain-based Message Authentication, Reporting and Conformance) is an email authentication standard that lets a domain owner publish a policy telling receiving mail servers what to do with messages that fail authentication checks: deliver them, send them to spam, or reject them outright. It builds on two older standards, SPF and DKIM, and adds the two things they lack: enforcement and visibility.

If you own a domain, anyone in the world can put your domain in the From address of an email. SPF and DKIM give receivers ways to check whether a message is legitimate, but on their own they do not tell receivers what to do when the checks fail, and they give you no feedback about what is happening. DMARC, defined in RFC 7489, closes both gaps. This guide explains how it works, what the policies mean, how reporting works, and why it matters for any organisation that sends email.

What problem does DMARC solve?

Email was designed in an era of trusted networks, and the core protocol does not verify the From address at all. A message claiming to be from accounts@yourcompany.com can be sent from any server on the internet. This is called spoofing, and it underpins a large share of phishing and invoice fraud, because a message that appears to come from a real, trusted domain is far more convincing than one from a lookalike address. This is why unprotected domains are such attractive targets.

Two standards emerged to address this:

• SPF (Sender Policy Framework, RFC 7208) lets a domain publish the list of servers authorised to send mail on its behalf. Receivers check the connecting server's IP address against that list. Read the full explanation in what is SPF.
• DKIM (DomainKeys Identified Mail, RFC 6376) adds a cryptographic signature to each message, which receivers verify against a public key published in the sending domain's DNS. See what is DKIM for the details.

Both are useful, but both have a critical limitation: neither one checks the From address that the recipient actually sees. SPF checks the envelope sender (the Return-Path), which is often a different domain entirely, and DKIM can sign with any domain the sender controls. A phishing message can pass SPF and DKIM for the attacker's own domain while displaying your domain in the From header. DMARC is the standard that ties authentication back to the visible From address.

How does DMARC work?

DMARC does not perform any new cryptography or IP checking of its own. Instead, it takes the results of SPF and DKIM and asks one extra question about each: does the domain that passed match the domain in the From header? This matching requirement is called alignment.

A message passes DMARC when at least one of the following is true:

• SPF passes, and the domain SPF checked (the Return-Path domain) aligns with the From header domain.
• DKIM verifies, and the signing domain (the d= value in the signature) aligns with the From header domain.

Only one aligned pass is needed. If neither check passes in alignment, the message fails DMARC, and the receiver consults your published policy to decide what to do. By default alignment is relaxed, meaning a subdomain match counts: mail signed by mail.example.com aligns with a From address at example.com. Strict alignment requires an exact match. The rules are covered fully in DMARC alignment explained.

The alignment requirement is the whole point. It means a message can no longer pass authentication using an unrelated domain while displaying yours. It is the piece that makes SPF and DKIM answer for the address the recipient actually reads.

A worked example

Suppose a phishing message arrives with From: finance@example.com, sent through a bulk mail service the attacker signed up for. The receiving server evaluates it:

• SPF passes, but for the bulk service's own Return-Path domain, bounce.bulkmailer.net. That does not align with example.com. No aligned SPF pass.
• DKIM verifies, but the signature's d= is bulkmailer.net. That does not align either. No aligned DKIM pass.

The message fails DMARC. If example.com publishes p=reject, the receiver refuses the message and the recipient never sees it. If the domain publishes no DMARC record at all, the receiver has no instruction from the domain owner and the message is judged on spam filtering alone, which it may well get through.

What does a DMARC policy do?

The policy is the instruction you publish for handling mail that fails DMARC. There are three levels:

Policy	Record value	Effect on failing mail
Monitor	p=none	No effect on delivery. Mail is delivered as normal and you receive reports. This is the correct starting point for every domain.
Quarantine	p=quarantine	Receivers are asked to treat failing mail with suspicion, typically delivering it to the spam or junk folder.
Reject	p=reject	Receivers are asked to refuse failing mail outright during the SMTP transaction. The strongest protection.

Two things are worth being clear about. First, p=none is genuinely monitoring only: it never causes mail to be blocked or junked, which is why it is safe to publish immediately. Second, a policy is a request, not a command. Receivers may apply local overrides, for example delivering a rejected message from a known mailing list. In practice the major mailbox providers honour published policies closely. The trade-offs between the three levels are explored in p=none vs p=quarantine vs p=reject.

What does a DMARC record look like?

A DMARC record is a single DNS TXT record published at the name _dmarc under your domain. A typical starting record looks like this:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

The tags in common use:

• v=DMARC1 - the version, always this exact value, and it must come first.
• p= - the policy for the domain: none, quarantine or reject.
• rua= - the address that aggregate reports should be sent to.
• sp= - an optional separate policy for subdomains; without it, subdomains inherit p=.
• pct= - apply the policy to a percentage of failing mail, used during gradual rollout. Note that some receivers do not implement sampling.
• adkim= and aspf= - set DKIM and SPF alignment to strict (s) rather than the default relaxed (r).

Only v and p are required, though a record without rua gives you no reporting and therefore no visibility, which defeats much of the purpose.

What are DMARC reports?

Reporting is the feature that makes DMARC deployable in the real world, because it shows you what is actually sending as your domain before you enforce anything. There are two kinds.

Aggregate reports (requested with the rua tag) are XML files that participating receivers, including Google, Microsoft and Yahoo, send you on a regular cycle, usually daily. Each report summarises the mail that receiver saw claiming to be from your domain: the sending IP addresses, message counts, SPF and DKIM results, and the policy action applied. They contain no message content, so they are safe to receive and process. Almost everyone who deploys DMARC finds surprises in the first batch: a payroll system, a CRM, a newsletter tool that nobody had documented. Learning to interpret them is covered in how to read DMARC reports.

Failure reports (requested with the ruf tag) are per-message notifications about individual failures. They can include message headers and sometimes content, which raises privacy considerations, and for that reason many large receivers simply do not send them. Aggregate reports are the ones to build your rollout on.

The honest caveat is that aggregate reports arrive as raw XML, one file per receiver per day, and a domain of any size accumulates hundreds of them. Reading them by hand does not scale, which is why most organisations use a monitoring service to parse them into something usable.

Why does DMARC matter?

Four reasons, in rough order of importance for most organisations.

It stops direct spoofing of your domain. At p=reject, mail that impersonates your exact domain and fails authentication is refused by every major mailbox provider. That protects your customers, your suppliers and your own staff from the most convincing form of phishing. It does not stop lookalike domains or display-name tricks, so it is one layer among several, but it is the layer only the domain owner can provide.

It is increasingly required. Google and Yahoo require bulk senders to publish a DMARC policy, and Microsoft has followed with similar requirements. If you send any volume of email, DMARC has moved from best practice to a condition of reaching the inbox, and enforcement of these requirements is only tightening.

It helps deliverability. Authenticated, aligned mail gives mailbox providers a reliable identity to attach reputation to. Domains with a track record of authenticated sending are treated with more confidence than domains without one.

It gives you visibility you cannot get any other way. Even at p=none, aggregate reports are the only comprehensive record of everything sending as your domain across the world's mailbox providers, legitimate or not. Many organisations deploy DMARC for the reporting alone.

How do you get started with DMARC?

The standard path is deliberately gradual, because moving to enforcement before your legitimate senders are authenticated will cause real mail to be junked or rejected.

1. Publish a monitoring record. Start with p=none and a rua address. This changes nothing about delivery and starts the flow of reports.
2. Collect reports for several weeks. Build a list of every source sending as your domain: your mail platform, marketing tools, invoicing systems, support desks and anything else that appears.
3. Fix authentication for each legitimate source. Add sending services to SPF where appropriate and, more importantly, enable DKIM signing with your own domain for each one. Aligned DKIM is the more robust foundation because it survives forwarding.
4. Tighten the policy. Once reports show your legitimate mail passing in alignment, move to p=quarantine, monitor, then p=reject.

A typical rollout takes a few weeks to a few months depending on how many sending services a domain has. The full process, including record syntax and common pitfalls, is walked through in how to set up DMARC. For the reporting stage, a DMARC monitoring service such as DMARCHub parses the raw XML into readable dashboards so you can see every sender and its authentication status at a glance; see /features for what that looks like.

Frequently asked questions

Do I need DMARC if I already have SPF and DKIM?

Yes. SPF and DKIM authenticate a message, but neither one checks the From address the recipient sees, and neither tells receivers what to do on failure. Without DMARC, a spoofed message can pass both checks using the attacker's own domain while displaying yours. DMARC adds the alignment check, the policy and the reporting that make the other two effective.

Does my domain need DMARC if it never sends email?

Yes, arguably more urgently. A domain that sends no mail can still be spoofed, and because nobody is watching its mail flow, abuse can run unnoticed for years. Non-sending domains can usually go straight to p=reject, since there is no legitimate mail to protect during a rollout.

Will publishing a DMARC record break my email?

Not if you start correctly. A record with p=none has no effect on delivery at all; it only switches on reporting. Mail can only be affected once you deliberately move to p=quarantine or p=reject, which you should do only after the reports confirm your legitimate senders pass in alignment.

How long does DMARC take to work?

The DNS record takes effect within hours, and the first aggregate reports normally arrive within a day or two, since most receivers send them on a daily cycle. Reaching full enforcement is a longer project: expect a few weeks of monitoring at minimum, and longer for organisations with many sending services to identify and authenticate.