DMARC Explained: Policies, Alignment, Reports and a Safe Path to Reject

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS record that tells receiving mail servers how to handle messages that claim to come from your domain but fail authentication, and where to send reports about them. A message passes DMARC when SPF or DKIM passes and the domain that passed matches the domain in the visible From address.

That second condition, alignment, is what makes DMARC different from SPF and DKIM on their own. Neither of them, by itself, checks the address your recipients actually see. DMARC ties the two results to that address.

DMARC was first published in 2015 as RFC 7489, an informational document. In May 2026 it was replaced by three standards-track RFCs: RFC 9989 for the core protocol, RFC 9990 for aggregate reports and RFC 9991 for failure reports. The basics haven’t changed, but a few tags have, which we’ll point out where it matters. Receivers will take time to adopt the new version, so for now you’ll meet both in practice.

How does a message pass DMARC?

A message passes if at least one of these is true:

• DKIM passes, and the signing domain (d=) aligns with the From domain.
• SPF passes, and the envelope sender (Return-Path) domain aligns with the From domain.

Only one is needed. Here’s how that plays out for a newsletter sent as news@example.com:

• Signed with d=example.com, bounce domain belongs to the platform: passes through DKIM.
• Signed with d=platform-example.net, custom return path at bounce.example.com: passes through SPF.
• Signed with d=platform-example.net, bounce domain belongs to the platform: fails. Both checks pass for the platform, but neither aligns with you.

The third case is common, and it’s why a platform can report “authenticated” while your DMARC reports show failures. Our SPF guide and DKIM guide cover how to set up each side with your own domain.

Relaxed vs strict alignment

With relaxed alignment, the default, the domains only need to share the same organizational domain. mail.example.com aligns with example.com. With strict alignment, they must match exactly. You set this separately for DKIM (adkim=s) and SPF (aspf=s). Relaxed is right for nearly everyone. Gmail and Yahoo both accept it.

Anatomy of a DMARC record

DMARC lives in a TXT record at _dmarc under your domain. A starting record might be:

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

The tags you’ll use:

• v=DMARC1 must come first.
• p= is the policy for the domain: none, quarantine or reject.
• sp= sets a different policy for subdomains. Without it, subdomains inherit p.
• np= sets the policy for subdomains that don’t exist, a favorite target for spoofing. It’s part of RFC 9989.
• rua= is where aggregate reports go.
• ruf= is where failure reports go, if any receiver sends them.
• adkim= and aspf= set alignment mode (r or s).
• t=y puts the policy in testing mode under RFC 9989, explained below.
• pct= sets the percentage of failing mail the policy applies to. It exists in RFC 7489 but was removed in RFC 9989.

A domain must have only one DMARC record. If a receiver finds two, it treats the domain as having no DMARC policy at all.

What do none, quarantine and reject mean?

p=none asks receivers to take no special action on failing mail, but still send reports. It’s monitoring mode. It gives no protection against spoofing, but it’s what Gmail and Yahoo require at minimum from bulk senders, and Microsoft requires at minimum for high-volume senders to Outlook.com.

p=quarantine asks receivers to treat failing mail as suspicious, which in practice usually means the spam folder.

p=reject asks receivers to refuse failing mail during delivery. This is the strongest protection against someone sending as your domain, and Microsoft’s own sender guidance recommends it.

Note the word “asks”. A DMARC policy is a request, and receivers can apply their own judgment, for example when they recognize mail as legitimately forwarded. A policy also does nothing for messages that pass. Passing DMARC doesn’t guarantee the inbox; it only means the authentication check didn’t count against you.

DMARC aggregate reports (rua)

Aggregate reports are XML files that participating receivers send to the rua address, typically once a day. Each one summarizes the mail a receiver saw using your domain in the From address: the sending IP addresses, message counts, the SPF and DKIM results with the domains they were evaluated against, whether each aligned, and what the receiver did with the mail.

They’re the most useful deliverability data you can get for free, because they show every source sending as your domain, not just the ones you know about. The first week of reports often turns up a forgotten system: a billing tool sending invoices, a website contact form, an old server in a cupboard, a recruiter’s applicant tracking system.

Some practical points:

• Use a report processor. Raw XML from dozens of receivers is unreadable at any real volume. A DMARC reporting service groups sources, resolves IPs to provider names and shows trends.
• Sending reports to another domain needs authorization. If example.com sends reports to reports.dmarc-vendor.net, that vendor domain must publish a record (example.com._report._dmarc.reports.dmarc-vendor.net) confirming it accepts them. Reputable reporting services set this up for you. Without it, receivers may not send the reports.
• Not every receiver reports. The large providers do, but coverage varies, so treat reports as a strong sample rather than a complete census.
• Failure reports (ruf) are rarely sent. They contain message-level detail, which raises privacy concerns, and most large mailbox providers don’t send them. Don’t plan your rollout around them.

How to read what you find

Sort every source into one of four groups:

1. Legitimate and aligned. No action.
2. Legitimate but not aligned. Your platforms that need custom DKIM or a custom return path. Fix these before enforcement.
3. Forwarded mail. Messages forwarded by mailing lists or recipients’ mail rules. SPF usually fails here, and DKIM passes if the content wasn’t changed. Some failure is normal.
4. Unknown or abusive. Senders you don’t recognize. If they’re not yours, enforcement is what stops them.

The staged rollout: p=none to quarantine to reject

Moving straight to p=reject on a domain that sends real mail is how companies block their own invoices. The safe route is staged, and each step depends on what the reports show.

Using pct and the new t= tag

Under RFC 7489, pct lets you apply the policy to a share of failing mail. p=quarantine; pct=25 asks receivers to quarantine a quarter of failing messages and treat the rest as if the policy were one step lower. Many teams have used pct to ramp up gently.

RFC 9989 removes pct and replaces it with t=y, which keeps the policy published but asks receivers to apply the next level down: p=reject; t=y behaves like quarantine, and p=quarantine; t=y behaves like none. It isn’t a percentage dial, and t=y isn’t the same as pct=0.

During the transition, receivers on the older specification may still honor pct and ignore t, while those on the new one do the reverse. Because of that, don’t treat either tag as precise. Use them to soften a step if you want, but rely on the reports, not the tag, to tell you when a step is safe.

DMARC and forwarding

Forwarding is the main legitimate cause of DMARC failures after enforcement. When a message is forwarded, SPF fails because the forwarding server isn’t in your record. If the forwarder also changes the message (a mailing list adding a footer, for example), DKIM breaks too, and the message fails DMARC.

ARC (Authenticated Received Chain) helps here. It lets an intermediary record the authentication results it saw before making changes, so the final receiver can choose to trust them. Large providers use ARC as one input to their decisions. It isn’t something you configure on your own domain unless you operate a forwarding service, but it explains why some forwarded mail still arrives under a reject policy.

Common DMARC mistakes

• Staying at p=none indefinitely. It satisfies the bulk sender rules, but it doesn’t protect your domain from spoofing.
• Jumping to reject without reports. The first sign of a problem is usually a customer asking why they never received an invoice.
• Two DMARC records. Often created when a reporting vendor’s setup is added on top of an existing record.
• Record on the wrong host. It must be at _dmarc.example.com, not at example.com.
• Forgetting parked domains. Domains that never send mail should have p=reject and an SPF record of v=spf1 -all.
• Assuming a platform’s “verified” badge means aligned. Confirm it in the reports.