InboxRatio
Check your domain

Glossary term

What is DMARC? Policy, alignment and unread reports

What DMARC is

DMARC — Domain-based Message Authentication, Reporting and Conformance — is a DNS-published policy that tells receiving mail servers what to do with messages that claim to come from your domain but fail authentication. It is defined in RFC 7489 and sits on top of SPF and DKIM rather than replacing either.

A DMARC record is a TXT record at _dmarc.yourdomain.com. A typical one looks like this:

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

Read left to right: this is a DMARC version 1 record; messages that fail should be quarantined (typically filed to spam); aggregate reports should be mailed to the listed address; both DKIM and SPF alignment are relaxed; the policy applies to all failing mail.

Two things make DMARC different from the mechanisms beneath it. First, it is the only one of the three that checks the From: address the recipient actually sees. Second, it is the only one that reports back: receivers send you regular summaries of who is sending mail as your domain and whether it authenticates. For most organizations, that reporting stream is the first time they learn how many systems — legitimate and otherwise — send mail in their name.

DMARC stopped being optional for anyone sending at volume when Gmail and Yahoo made a published DMARC policy part of their bulk sender requirements. The exact thresholds are documented in the Google Postmaster guidelines and Yahoo Sender Hub; the direction is unambiguous.

How DMARC differs from SPF and DKIM

SPF and DKIM each answer a narrow question. SPF asks: did this message arrive from an IP the envelope-sender domain authorized? DKIM asks: does this message carry a valid cryptographic signature from some domain? Neither one, on its own, says anything about the From: header displayed to the human recipient.

That gap is exploitable. A message can pass SPF for bounce.attacker.com, carry a valid DKIM signature for attacker.com, and still display From: ceo@yourcompany.com. Both underlying checks pass. The recipient sees your domain.

DMARC closes the gap with alignment: to pass DMARC, a message needs at least one of SPF or DKIM to pass and the passing domain must match the From: header domain. In the example above, neither passing domain matches yourcompany.com, so DMARC fails and your published policy applies.

The other structural difference: SPF and DKIM results are advisory. Nothing in either specification tells a receiver what to do with a failure. DMARC is where you, the domain owner, state the consequence — none, quarantine, or reject.

How DMARC works

When a message arrives claiming From: anything@yourdomain.com, the receiver:

  1. Looks up _dmarc.yourdomain.com in DNS.
  2. Evaluates SPF and DKIM as usual.
  3. Checks alignment for each: does the SPF-validated envelope domain match the From domain? Does any valid DKIM signature's d= domain match it?
  4. If at least one aligned mechanism passes, DMARC passes. Otherwise the record's policy applies.
  5. Periodically, the receiver sends an aggregate report (XML, usually daily) to the rua address describing everything it saw from your domain.

The record tags you will actually use:

  • p= — the policy for the domain: none (monitor only), quarantine, or reject.
  • sp= — a separate policy for subdomains. If omitted, subdomains inherit p=. Attackers know this: an unprotected subdomain under a p=none root is free spoofing real estate.
  • rua= — where aggregate reports go. This is the monitoring channel.
  • ruf= — forensic (per-message) reports. Many large receivers no longer send them for privacy reasons; do not build a process that depends on them.
  • adkim= / aspf= — alignment mode, relaxed (r, the default) or strict (s). Relaxed accepts an organizational-domain match: a DKIM d= of mail.yourdomain.com aligns with a From of yourdomain.com. Strict requires an exact match. Almost every sender should stay relaxed; strict alignment breaks the standard ESP pattern of signing from a subdomain.
  • pct= — apply the policy to a sampled percentage of failing mail. Useful for a staged rollout to quarantine, though receivers vary in how faithfully they honor it.

Deployment is a ladder, not a switch. Publish p=none with a rua address, read the reports for several weeks, fix every legitimate source that fails alignment (the CRM, the billing system, the helpdesk tool someone connected in 2019), then move to p=quarantine, then p=reject. A DMARC checker validates the record syntax at each step, and a DMARC generator builds a correct starting record if you are writing your first one.

DMARC and your deliverability

DMARC affects deliverability from two directions at once.

As a requirement. Gmail and Yahoo require bulk senders to publish a DMARC policy — even p=none satisfies the letter of the requirement. Senders without one face increased filtering and, at the extreme, outright rejection. This is the rare deliverability lever where the receiving side has told everyone exactly what it wants.

As protection for your reputation. Domain reputation is built on the mail receivers associate with your domain. If spoofers can send as you, their spam becomes part of your domain's track record. An enforced DMARC policy (quarantine or reject) cuts that traffic off, which is why enforcement — not mere publication — is the state worth reaching.

There is a subtler operational benefit. The aggregate report stream is the only free, receiver-side view of your authentication health. It will show you an ESP whose DKIM key rotation broke, a forwarding service mangling signatures, or a regional office that quietly started sending through an unauthenticated relay. Our test methodology measures where mail lands; DMARC reports tell you why authentication contributed to it.

One thing DMARC does not do: passing DMARC is not an inbox pass. It removes an authentication reason for filtering. Content, engagement and sending reputation still decide placement — a fully aligned spammer is still a spammer, and receivers treat them accordingly.

Limitations and failure modes

p=none forever, reports unread. The canonical DMARC failure: an organization publishes p=none with a rua address to satisfy a checklist, aggregate XML piles up in a mailbox nobody opens, and years later the policy is still none — providing zero spoofing protection while creating the impression of a completed project. If your record has said p=none for more than a quarter and no one can name the last thing learned from the reports, the deployment stalled.

Forwarding breaks SPF alignment. When a message is forwarded, the forwarder's server becomes the sending IP, so SPF fails for your domain. DMARC anticipated this: DKIM signatures usually survive forwarding intact, and one aligned pass is enough. But if your mail relies on SPF alone for alignment — common when an ESP signs DKIM with its own domain instead of yours — every forwarded message fails DMARC. RFC 7960 catalogs these indirect-flow failures at length. The fix is always the same: get aligned DKIM signing (a custom d= domain) from your platform.

Mailing lists. Traditional discussion lists modify the subject or append a footer, invalidating the DKIM signature, then resend from their own servers, failing SPF alignment too. Mail from your users to such lists will fail DMARC at every subscriber's provider. Lists have adapted with From-rewriting, but the behavior depends on software the list runs, not on anything you control.

The subdomain gap. p=reject on the root with no sp= covers subdomains by inheritance — but a delegated or forgotten subdomain with its own weaker DMARC record overrides the parent. Audit what actually resolves.

Misreading pct. pct=50 at p=quarantine does not mean half of your legitimate mail is at risk; it applies only to failing mail. But it also means half of the spoofed traffic sails through. Sampling is a rollout tool, not a destination.

Aggregate reports are not real-time. Reports arrive on a delay measured in hours to days, summarize rather than itemize, and different receivers format edge cases differently. They are a trend instrument. Do not expect to trace an individual message through them.

Related terms

SPF record, DKIM, SPF alignment, DKIM alignment, BIMI, domain reputation, sender reputation, feedback loop, spam complaint rate.

Frequently asked questions

Do I need DMARC if I already have SPF and DKIM? Yes. SPF and DKIM authenticate transport details invisible to recipients; neither checks the From address people see, and neither tells receivers what to do on failure. DMARC does both, and major mailbox providers now require it from bulk senders.

Is p=none good enough? As a starting point, yes — it turns on reporting without risking legitimate mail. As a destination, no. At p=none a spoofed message failing every check is still delivered normally. The protection begins at quarantine and is complete at reject.

What is DMARC alignment in plain terms? The domain that passed SPF or DKIM must match the domain in the From header. Relaxed alignment accepts a subdomain relationship (mail.example.com aligns with example.com); strict requires an exact match.

How long should I stay at p=none? Until the aggregate reports show all legitimate sending sources passing with alignment — typically a few weeks to a few months depending on how many systems send as your domain. The calendar matters less than the report contents: move up when failures are only traffic you do not recognize as yours.

Will DMARC put my emails in the inbox? No. It removes authentication failure as a reason to filter you and protects your domain's reputation from spoofers. Placement still depends on reputation, engagement and content.

Why am I getting DMARC failure reports for mail I really sent? Usually forwarding (SPF alignment breaks in transit) or an ESP signing DKIM with its own domain rather than yours. Check whether the reported source is a forwarder, then check your platform's DKIM d= domain.

Publish p=none with a report address this week, put a recurring slot in someone's calendar to actually read the reports, and verify the record with the DMARC checker before you call it done.

Sources