What Is DMARC? How It Works, What the Tags Mean, and How to Roll It Out

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS TXT record that tells receiving mail servers what to do when a message claiming to be from your domain fails authentication, and asks them to send you reports about it. It works by checking that SPF or DKIM not only passes but passes for the same domain shown in the From address. That last part, called alignment, is what makes DMARC more than a wrapper around SPF and DKIM.

If you send mail from your own domain, you need it. Gmail and Yahoo require a DMARC record from bulk senders, and without one anyone can put your domain in the From line with nothing to stop them.

The problem DMARC solves

SPF and DKIM were built before anyone worried much about the address people actually see.

• SPF checks whether the sending IP is allowed to send for the domain in the envelope sender (the Return-Path, also called MAIL FROM). That's the bounce address, which recipients never see.
• DKIM checks a cryptographic signature against a public key published by whatever domain is in the signature's d= tag. That can be any domain.

So a spammer can send a message with From: billing@example.com, use their own domain in the Return-Path, sign it with DKIM for their own domain, and pass both SPF and DKIM. Neither check says anything about example.com.

DMARC closes that gap. It asks: did SPF or DKIM pass for a domain that matches the visible From domain? If not, the message fails DMARC, and your published policy tells the receiver what you'd like done with it.

How DMARC alignment works

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

1. SPF passes, and the Return-Path domain aligns with the From domain.
2. DKIM passes, and the d= domain of a valid signature aligns with the From domain.

You only need one. In practice DKIM is the one to rely on, because SPF breaks when mail is forwarded and DKIM usually survives.

"Aligns" has two modes:

• Relaxed (the default): the two domains share the same organizational domain. news.example.com aligns with example.com.
• Strict: the domains must match exactly.

Here's the classic failure. You send through an email service provider, and your headers look like this:

From: news@example.com
Return-Path: bounce-12345@mail.esp-example.net
DKIM-Signature: v=1; a=rsa-sha256; d=esp-example.net; s=s1; ...

SPF passes (for esp-example.net). DKIM passes (for esp-example.net). DMARC fails, because neither passing domain is example.com. The fix is to set up custom DKIM so the provider signs with d=example.com, and ideally a custom Return-Path on a subdomain like bounce.example.com. If you're stuck on a failure like this, DMARC fail: why it fails and how to fix it walks through every common cause.

What a DMARC record looks like

The record lives at _dmarc. plus your domain. For example.com, that's a TXT record at _dmarc.example.com:

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

The tags you'll actually use:

If you'd rather not hand-type it, the DMARC record generator builds a valid record, and the SPF, DKIM and DMARC checker will tell you whether the one you published parses.

The three policies

• p=none is monitoring mode. Receivers deliver mail as they normally would and send you reports. It's the right starting point, and it satisfies Gmail's and Yahoo's bulk sender requirements.
• p=quarantine asks receivers to treat failing mail as suspicious, which usually means the spam folder.
• p=reject asks receivers to refuse failing mail at the SMTP level.

Note the word "asks." DMARC is a request, not a command. The spec itself says receivers shouldn't reject messages solely because a domain publishes p=reject, and big providers apply their own judgment. A reject policy makes spoofing your domain far less useful, but it isn't a force field.

The reports are the point

The rua reports are XML files, usually sent daily by each receiver that supports them, summarizing every IP that sent mail using your domain in the From line, how much it sent, and whether SPF, DKIM and alignment passed.

That's the most valuable thing DMARC gives you. The first week of reports almost always turns up senders nobody remembered: the CRM sending quotes, the HR platform, the helpdesk, an old marketing tool someone still logs into. Every one of those needs to pass aligned SPF or DKIM before you tighten the policy, or you'll block your own mail.

Raw XML is miserable to read by hand. Send the reports to an address that feeds a parser or a reporting service.

How to roll DMARC out without breaking your mail

1. Fix SPF and DKIM first. Make sure every service that sends as your domain has custom DKIM signing with your domain, and that your SPF record is under the 10-lookup limit. (See the SPF 10 DNS lookup limit.)
2. Publish p=none with a rua address. Collect reports for a few weeks, long enough to catch monthly sends like invoices and statements.
3. Inventory every source in the reports. Fix each legitimate one until it passes aligned DKIM. Anything you don't recognize is either forgotten or spoofing.
4. Move to p=quarantine. Watch the reports and your bounce logs for legitimate mail that starts failing.
5. Move to p=reject once quarantine has run clean.
6. Keep reading the reports. New tools get added, vendors change infrastructure, and alignment quietly breaks.

What Gmail and Yahoo require

Google's sender guidelines require bulk senders (more than 5,000 messages a day to personal Gmail accounts) to publish DMARC, and say the policy can be set to none. They also require that for direct mail, the From domain aligns with either the SPF domain or the DKIM domain. Yahoo's requirements are essentially the same: a valid DMARC policy of at least p=none, DMARC must pass, and relaxed alignment is acceptable. For the bigger picture, see the Gmail and Yahoo bulk sender updates.

DMARCbis: the new standard (RFC 9989)

The original DMARC specification, RFC 7489, was published in 2015 as an informational document, not a formal standard. In May 2026 the IETF published its replacement as a Proposed Standard, split across three documents: RFC 9989 (the core protocol), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting). They obsolete RFC 7489 and RFC 9091.

The changes that matter to most domain owners:

• pct is retired. It's marked historic. The new t tag (test mode) covers the common use: with t=y, receivers apply your policy one level lower, so p=reject; t=y is treated like quarantine and p=quarantine; t=y like none.
• rf and ri are retired as well.
• np sets a policy for non-existent subdomains, which helps against spoofing of made-up subdomains like billing-alerts.example.com.
• The organizational domain is found by a DNS "tree walk" instead of relying on the public suffix list.

Your existing record doesn't need an emergency rewrite. v=DMARC1 is still the version, and receivers are required to ignore tags they don't understand. When you next touch the record, drop pct and use t if you need a test phase.

When to get help

If your reports show legitimate mail failing and you can't tell which system it's coming from, or you're ready for p=reject and want a second set of eyes before you flip it, that's a good time to bring in someone who does this daily.

FAQ

Is DMARC required?

For bulk senders to Gmail and Yahoo, yes: both require a DMARC record, though p=none is enough. For everyone else it isn't strictly required, but without it nothing stops others from using your domain in the From line.

Does DMARC improve deliverability?

Indirectly. DMARC by itself doesn't earn you inbox placement, but it's a requirement for bulk senders at the biggest providers, and aligned authentication lets them tie reputation to your domain rather than to your provider's.

Can I have more than one DMARC record?

No. If a receiver finds more than one DMARC record at _dmarc.example.com, it treats the domain as having no DMARC policy at all. Merge them into one.

Do subdomains need their own DMARC record?

Not necessarily. If a subdomain has no record, receivers fall back to the organizational domain's record and apply its sp policy (or p if sp isn't set). Publish a separate record only if a subdomain needs different settings.