Back to Learning Center Email Authentication

What is DMARC and how does it stop email spoofing?

By Samuel ChenardApril 23, 2025Updated September 2, 202614 min read

Ask AI to explain

In brief

What DMARC is, how SPF and DKIM alignment stops spoofing, the three policies, the record and its key tags, the 2026 sender rules, and reaching enforcement.

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication standard that lets a domain owner tell receiving mail servers two things: how to check that a message genuinely came from the domain, and what to do with messages that fail that check. It closes the gap that SPF and DKIM leave open on their own, because neither of those, by itself, protects the address a recipient actually sees.

DMARC is published as a single record in your DNS. It builds directly on SPF and DKIM: rather than inventing a new way to authenticate mail, it ties their results to the visible From: domain and adds a policy plus a reporting channel. That combination is what makes DMARC the control that stops spoofing and domain-based phishing.

DMARC DNS record example — Source: Palisade.

How does DMARC work?

You publish a DMARC policy as a TXT record at _dmarc.yourdomain.com. When a receiver gets a message claiming to be from your domain, it runs three checks:

SPF and DKIM evaluation. The receiver checks whether the sending IP is authorized by your SPF record and whether the message carries a valid DKIM signature for your domain.
Alignment. This is DMARC's core idea. A pass only counts if the domain that SPF or DKIM authenticated aligns with the domain in the visible From: header. An attacker can send perfectly SPF- and DKIM-valid mail for a domain they control; alignment is what stops them from borrowing yours.
Policy. If neither SPF nor DKIM aligns, the receiver applies the action your policy requests.

DMARC needs only one of SPF or DKIM to pass and align, not both. Because a DKIM signature travels with the message, it often survives forwarding when SPF breaks, which is why a correctly signed domain keeps authenticating through mailing lists and forwarders.

What is DMARC alignment?

Alignment compares two domains: the one SPF or DKIM authenticated, and the one in the visible From: header. In relaxed alignment, the default, they only need to share the same organizational domain, so mail.yourdomain.com aligns with yourdomain.com. In strict alignment they must match exactly. You control the mode per mechanism with the adkim and aspf tags, and relaxed is the right choice for almost every domain, because strict breaks common setups like sending from a subdomain.

The three DMARC policies

Your policy is set with the p tag and takes one of three values. The DMARC policy is a ladder you climb with evidence, not three equal options.

p=none: monitor

p=none asks receivers to deliver failing mail normally and send you reports about it. It exists so you can discover every service sending as your domain before you enforce anything. Nothing is protected at none: spoofed mail still arrives. It is the right place to start and the wrong place to stay.

p=quarantine: send failures to spam

p=quarantine asks receivers to file failing mail as spam or junk. A wrongly-failed legitimate message is still recoverable from the spam folder, which makes quarantine the standard intermediate step while you confirm the last of your senders authenticate correctly.

p=reject: refuse failures outright

p=reject asks receivers to refuse failing mail during delivery, so it never reaches a mailbox. This is enforcement: the only policy that actually stops exact-domain spoofing, and the destination the whole DMARC process points toward. Subdomains can carry their own policy through the sp and np tags; without them, the domain policy covers subdomains too.

What does a DMARC record contain?

A DMARC record is one line of text. A typical starting record looks like this:

Technical exampletext

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

Each part is a tag. The current specification, RFC 9989, requires only v and recommends p; everything else is optional.

v (version): always DMARC1, and the only tag with a fixed position, first in the record.
p (policy): the action requested for failing mail, none, quarantine, or reject. If p is missing or invalid, receivers treat the record as p=none when it carries a valid rua address, and ignore it entirely when it does not.
rua: where receivers send aggregate reports. A record without it collects no evidence.
ruf: where receivers send failure reports, individual message samples that many providers decline to send for privacy reasons.
sp and np: separate policies for subdomains, and for subdomains that do not exist in DNS.
adkim and aspf: alignment mode, relaxed (r, the default) or strict (s), per mechanism.
t: testing flag (t=y) signaling that receivers should treat the policy as advisory during rollout. It replaces part of what the retired pct percentage tag did under the old specification.

Three tags you will still see in older records, pct, rf, and ri, were retired by RFC 9989. Records that carry them keep working, because receivers ignore unknown tags rather than failing the record. For the full tag-by-tag reference with valid values and examples, see the DMARC record guide, and to build one for your domain, the DMARC record generator outputs the exact TXT record to publish.

The reporting side: RUA and RUF

DMARC's second job is visibility. Receivers send structured reports back to the addresses you name in your record:

Aggregate reports (RUA) are daily XML summaries of every source sending mail under your domain, with pass/fail counts. They are how you discover forgotten senders, a billing platform, a helpdesk, a marketing tool, before you turn on enforcement.
Failure reports (RUF) are near-real-time samples of individual messages that failed. Support for them is uneven across receivers because of privacy concerns, so aggregate reports do most of the practical work.

Reading these reports is the whole reason to start at p=none: they tell you which legitimate senders still need SPF or DKIM fixed before a stricter policy would block them. A DMARC report reader or an agent that does the reading for you turns the raw XML into a sender list you can act on.

Is DMARC required in 2026?

DMARC is required in 2026 for anyone sending at volume, and the requirements have teeth.

Gmail and Yahoo have required senders of roughly 5,000 or more messages a day to publish a DMARC policy since February 2024, alongside SPF and DKIM published with at least one aligned so DMARC passes, a spam complaint rate below 0.3% with 0.10% the recommended target, and one-click unsubscribe on marketing mail. Non-compliant bulk mail is rejected rather than quietly filtered. Google publishes the rules in its email sender guidelines and Yahoo in its Sender Best Practices.
Microsoft applied matching requirements to high-volume senders to consumer Outlook.com addresses in 2025, rejecting mail that fails SPF, DKIM, or DMARC with error 550 5.7.515, which Microsoft documents in Fix NDR error 550 5.7.515 in Outlook.com.
Below those volumes the rules are softer, but the direction is one-way: unauthenticated mail increasingly lands in spam at any volume, and compliance frameworks and cyber-insurance questionnaires now routinely ask for DMARC.

Note what the bulk-sender rules do not require: enforcement. Publishing p=none satisfies the letter of the requirement while leaving the domain fully spoofable, which is why requirement-driven DMARC and protection-driven DMARC are different projects with the same first step. The full sender requirements are broken down on the deliverability hub.

Why DMARC matters

It stops exact-domain spoofing. With an enforced policy, attackers can no longer send mail that displays your real domain in the From: field, the single most convincing form of phishing.
It gives you visibility. Aggregate reports show every service sending as your domain, legitimate or not. For most organizations this is the first complete view of their own sending footprint they have ever had.
It protects deliverability and brand trust. A domain that authenticates consistently earns better inbox placement, and DMARC at enforcement is a prerequisite for a BIMI logo in supporting inboxes.
It is measurable across the industry. Palisade's DMARC adoption statistics from 100,000 domains publish the counts, methodology, and downloadable data behind current adoption and enforcement rates.

You can check your current DMARC record, policy, and alignment with the DMARC lookup tool, or see SPF, DKIM, and DMARC together in the Email Security Score.

How do you set up DMARC?

Setting up DMARC takes minutes to publish the record and weeks of evidence to reach enforcement safely. The arc looks like this:

Confirm SPF and DKIM first. DMARC evaluates their results, so it does nothing useful without at least one of them working and aligned.
Create the record. Start at p=none with a rua reporting address, using the generator or writing it by hand.
Publish it at your DNS host as a TXT record at _dmarc.yourdomain.com, at whichever provider actually answers for your zone.
Read the aggregate reports for at least one full sending cycle, usually two to four weeks.
Fix every legitimate sender that fails authentication or alignment, one service at a time.
Tighten in stages, to p=quarantine, then p=reject, watching the reports at each step.

The DMARC setup guide walks through each step with the record built inline, plus provider-specific instructions for publishing it at your DNS host. Skipping the monitoring phase is the most common way organizations block their own mail, so treat step 4 as load-bearing rather than optional.

Common issues with DMARC

Four failures cover most broken DMARC deployments. The setup guide walks the publishing-order versions of these with the fix at each step; this is the diagnosis view.

No reports are arriving

Usually the record itself. A missing or mistyped rua address collects nothing, and a reporting address on another domain is ignored unless that domain publishes an authorization record. Check what your domain actually publishes with the DMARC lookup, then confirm the mailbox accepts large XML attachments from any sender.

Legitimate mail is failing DMARC

Almost always alignment rather than authentication. A vendor can pass SPF on its own bounce domain while your domain gets no credit, because the passing domain does not match your visible From: address. The fix is custom DKIM signing or a custom return path at that vendor, so the authenticated domain becomes yours. To inspect one delivered message rather than the public record, check DMARC alignment from a delivered message.

The record is published but receivers do not see it

Two common causes. A record added at the registrar while different nameservers answer for the zone saves successfully and resolves never; publish where your NS records point. And a domain must carry exactly one DMARC record: receivers that find two treat the domain as having none, so the policy silently stops applying.

Forwarded mail keeps failing

Forwarding usually breaks SPF, because the forwarder's IP is not in your record. That is expected and survivable: a valid DKIM signature travels with the message, so DMARC still passes on the DKIM side. If forwarded mail fails both checks, the fix is DKIM signing at the original platform, not a wider SPF record.

What changed with DMARCbis (RFC 9989)

For its first decade DMARC was defined by RFC 7489, published as Informational. In May 2026 the IETF published the DMARCbis revision as three Standards-Track documents: RFC 9989 (the core protocol), RFC 9990 (aggregate reporting), and RFC 9991 (failure reporting), which obsolete RFC 7489 and the experimental RFC 9091 PSD extension, and promote DMARC to a Proposed Standard.

DMARCbis is a clarification, not a new protocol: it introduces no breaking changes, and records written for RFC 7489 keep working. The most notable technical change is how the organizational domain is determined. RFC 9989 replaces the old dependency on the Public Suffix List with a DNS Tree Walk, where the receiver climbs the DNS tree from the sending subdomain looking for a published DMARC record, which makes policy discovery more predictable for subdomains. For the full breakdown, see what DMARCbis (RFC 9989) changes.

Evidence

Sources and further reading

RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC) - the core protocol, alignment, and the DNS Tree Walk.
RFC 9990: DMARC Aggregate Reporting - the aggregate report format behind the rua tag.
Google: Email sender guidelines - Gmail's authentication, complaint-rate, and unsubscribe requirements for bulk senders.
Yahoo Sender Best Practices - Yahoo's matching bulk-sender requirements.
Microsoft: Fix NDR error 550 5.7.515 in Outlook.com - the rejection consumer Outlook.com returns for unauthenticated bulk mail.

Questions readers ask

Frequently asked questions

Do I need SPF and DKIM before adding DMARC?

Yes. DMARC does not authenticate anything itself; it evaluates the results of SPF and DKIM and checks alignment. A DMARC record with no working SPF or DKIM behind it will fail every legitimate message once you enforce. Set up both first, confirm they align with your From: domain, then publish DMARC.

What is the difference between DKIM and DMARC?

DKIM signs individual messages: a cryptographic signature proves a message was authorized by the signing domain and was not altered in transit. DMARC is the policy layer above it. It checks whether the domain DKIM (or SPF) authenticated aligns with the visible From: address, tells receivers what to do when nothing aligns, and tells them where to send you reports. DKIM authenticates a message; DMARC decides what that authentication means for your domain. The three protocols work as a set; see what DMARC, DKIM, and SPF each do.

Is DMARC for sending or receiving email?

Both sides are involved, but you publish it for the mail you send. The domain owner publishes the policy in DNS; receiving mail servers do the enforcement, checking each inbound message that claims to come from that domain and applying the policy when the message fails. So DMARC protects your outbound identity, and the work of honoring it happens at the receiver.

How do you explain DMARC in plain English?

DMARC is a public instruction sheet for the world's mail servers. It says three things: here is how to check that a message really came from my domain, here is what to do with mail that fails the check (deliver it, send it to spam, or refuse it), and here is where to send me the daily report about all of it. Everything else about DMARC (the record, the tags, and alignment) is detail in service of those three instructions.

What's the difference between quarantine and reject?

Quarantine tells receivers to deliver failing mail to the spam folder, so a wrongly-failed message is recoverable. Reject tells them to refuse it entirely, so it never arrives. Most domains move none to quarantine to reject as confidence grows; see reject vs quarantine for how to choose.

Does DMARC improve email deliverability?

DMARC removes one of the main reasons receivers filter or reject mail. Gmail, Yahoo, and Outlook.com all require authentication from bulk senders, and a domain that consistently passes DMARC gives receivers a verified identity to build reputation on. It is not a placement guarantee: reputation and engagement still decide the inbox-or-spam call for authenticated mail. The deliverability improvement guide covers the full sequence.

Is p=none enough to satisfy Google and Yahoo?

For the bulk-sender requirement itself, yes: the rules require a published DMARC policy, and p=none qualifies. For protection, no: at none, spoofed mail is still delivered. Treat none as the evidence-gathering stage the requirement happens to accept, not as the finish line.

Does DMARC encrypt my email?

No. DMARC is about authenticity and policy, not confidentiality. It verifies that a message truly came from your domain and tells receivers what to do if that can't be proven, but the message body still travels in plain text unless the connection is separately protected with TLS.

Will publishing DMARC block my newsletters or forwarded mail?

Only if those streams aren't authenticated. Forwarding often breaks SPF, but a valid DKIM signature usually survives it, so DMARC still passes on DKIM. The risk is a legitimate sender you forgot to authenticate, which is exactly what the p=none monitoring phase and aggregate reports exist to surface before you enforce.

Is RFC 7489 still valid?

RFC 7489 has been obsoleted by RFC 9989, 9990, and 9991, but existing DMARC records don't need to change. DMARCbis introduced no breaking changes; it reclassified and clarified the standard rather than replacing the syntax you already publish.

Turn DMARC findings into a managed fix path

Start in Palisade.

Get started

Share this article

Written by

Samuel Chenard

CEO & Co-Founder, Palisade

Samuel Chenard is the CEO and co-founder of Palisade, agentic DMARC software for IT teams and MSPs, from one domain to thousands.