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: 1. 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. 2. 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. 3. Policy. If neither SPF nor DKIM aligns, the receiver applies the action you

What is DMARC? Email Authentication Explained Simply

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 — 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.

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.

Your policy is set with the p= tag and takes one of three values:

p=none — take no action; just send reports. This is monitoring mode, used to learn who sends mail as you before you enforce.
p=quarantine — deliver failing mail to the spam or junk folder.
p=reject — refuse failing mail outright, so it never reaches the recipient.

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.

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 monitoring service turns the raw XML into a sender list you can act on.

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 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 — the receiver climbs the DNS tree from the sending subdomain looking for a published DMARC record — which makes policy discovery more predictable for subdomains. If you want the full breakdown, see what DMARCbis (RFC 9989) changes.

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 is now a sending requirement. Gmail, Yahoo, and Microsoft require any domain sending roughly 5,000 or more messages a day to personal inboxes to publish a DMARC record. Enforcement is active, and non-compliant bulk mail is rejected rather than merely filtered.
It gives you visibility. Aggregate reports show every service sending as your domain, legitimate or not — often the first time an organization sees its full sending footprint.
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.

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.

Things to get right before enforcing

DMARC is not set-and-forget. Before moving to p=quarantine or p=reject, confirm that every legitimate source — internal servers, transactional providers, marketing platforms — passes SPF or DKIM and aligns. Skipping the monitoring phase is the most common way to block your own mail. Start at p=none, read the reports for a full sending cycle, fix each failing sender, then tighten the policy in stages. For the safe rollout, see how to create a DMARC record.

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'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 → quarantine → reject as confidence grows; see reject vs quarantine for how to choose.

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.