What is DMARC, and how does it work?

DMARC is the record that finally ties email authentication to the address people actually read. SPF and DKIM can both pass on a forged message, because neither one checks the visible From line. DMARC does, and it lets you tell receivers what to do when that check fails. This is the hub for our DMARC guides: start here, then follow the links for each step.

What is DMARC?

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. Since May 2026 it is defined in RFC 9989, a Standards Track document that replaced RFC 7489. Reporting moved into two companion documents: RFC 9990 for aggregate reports and RFC 9991 for failure reports.

The record itself is a single TXT record at _dmarc. in front of your domain:

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

It does three things:

1. Validates that mail using your domain in the From header really comes from you.
2. States a policy for mail that fails: none, quarantine or reject.
3. Requests reports so you can see every source sending as your domain.

DMARC doesn't scan content and doesn't look at the display name. RFC 9989 lists display name attacks and content analysis as out of scope. It also validates only the domain, not the part of the address before the @.

How does DMARC work with SPF and DKIM?

DMARC doesn't authenticate anything by itself. It reuses the results of two older checks:

• SPF (RFC 7208) checks whether the sending server is allowed to use the envelope sender domain (the MAIL FROM, often shown as Return-Path).
• DKIM (RFC 6376) checks a cryptographic signature added by the sender. The signing domain is the d= value in the DKIM-Signature header.

The receiver then asks one question: did SPF or DKIM pass for a domain that aligns with the From domain? RFC 9989 section 5.3.5 puts it simply: if one or more authenticated identifiers align with the Author Domain, the message passes. If none do, it fails.

Here's the order of events at the receiving server:

1. Read the domain in the From: header (RFC 9989 calls it the Author Domain).
2. Look up the DMARC record for it, walking up the DNS tree to the organizational domain if the exact name has none.
3. Take the SPF result for the MAIL FROM domain and the DKIM result for each valid signature.
4. Check whether any passing domain aligns with the From domain.
5. Pass or fail, then apply local policy, informed by your p= value, and log the result for reports.

If you want the background on what each of the three checks proves on its own, read SPF vs DKIM vs DMARC.

What is DMARC alignment?

Alignment is the heart of DMARC. Without it, an attacker could publish SPF and DKIM for their own domain, pass both, and still put your domain in From. RFC 9989 section 4.4.1 says it directly: "a message can bear a valid signature from any domain, even one used by a bad actor."

There are two alignment modes:

• Relaxed (the default): the two domains share the same organizational domain. mail.example.com aligns with example.com.
• Strict: the two domains are identical.

This table follows the examples in RFC 9989 section 4.4:

RFC 9989 notes that "nearly all Domain Owners have found relaxed alignment sufficient." Leave adkim and aspf at their relaxed defaults unless you have a specific reason.

What do p=none, p=quarantine and p=reject mean?

The p tag is your request to receivers about mail that fails DMARC. Receivers make the final decision. RFC 9989 section 7.4 even says receivers must not reject solely on the basis of p=reject, without other knowledge and analysis.

Microsoft documents how it handles each one for inbound mail when Honor DMARC record policy is on: p=quarantine goes to Junk Email, and p=reject is rejected during SMTP with a dmarc=fail action=oreject result (Microsoft Learn).

Two more tags shape the policy. sp sets it for existing subdomains and np for subdomains that don't exist. If left out, np falls back to sp, and sp falls back to p. Our DMARC subdomain policy guide explains the inheritance. The t=y tag, new in RFC 9989, asks receivers to apply your policy one level down while you test. Every tag is explained in DMARC record examples.

What are DMARC reports?

When your record includes rua=mailto:..., receivers that support reporting send you aggregate reports: compressed XML files listing each sending IP, how many messages it sent as your domain, and whether SPF and DKIM passed and aligned. RFC 9989 section 5.3.8 says receivers should send them at least once every 24 hours.

Aggregate reports are how you find the invoicing tool, CRM or website form that sends as your domain without authentication. They're hard to read raw. Our free DMARC Report Analyzer turns a report into a table in your browser, and how to read DMARC reports explains each field.

The ruf tag requests failure reports about individual messages. RFC 9989 notes that privacy-minded receivers either redact them heavily or don't send them at all, and Microsoft 365 doesn't send them. Start with rua only.

How do I set up DMARC?

In outline, following RFC 9989 section 5.1 and Google's DMARC guide:

1. List every service that sends as your domain, and give each one aligned SPF or DKIM. Our DKIM setup guide and SPF records by provider pages cover the common ones.
2. Publish p=none with an rua address. The DMARC Record Generator builds the record.
3. Read the reports, fix failing senders, then move to p=quarantine and p=reject.

The full procedure, with the record for each stage and how long to stay there, is in moving DMARC from p=none to p=reject. If a scanner says your DMARC policy is not enabled, start with fixing "DMARC policy not enabled". A domain that never sends email can skip the rollout and publish p=reject straight away, as shown in protecting parked domains from spoofing.

Do I need DMARC?

If your domain sends email, yes. For bulk senders it's now a hard requirement:

• Google requires SPF, DKIM and DMARC from senders of close to 5,000 or more messages a day to personal Gmail accounts, with the From domain aligned to SPF or DKIM. The policy can be none (Google sender guidelines). Google Postmaster Tools shows whether Gmail sees you as compliant.
• Yahoo requires bulk senders to "publish a valid DMARC policy with at least p=none" and says DMARC must pass (Yahoo Sender Hub). It strongly urges all other senders to publish one too.

The details are in our Gmail, Yahoo and Microsoft bulk sender requirements guide.

Plenty of large domains still aren't protected. In our scan of the Tranco top 1,000 domains in October 2026, 26.5% had no DMARC record and 38.3% didn't enforce DMARC.

What DMARC doesn't do

DMARC is strong against one specific attack: mail that puts your exact domain in From. It doesn't stop:

• Lookalike domains such as examp1e.com, which have their own DNS. See lookalike domain phishing.
• Display name tricks, where the name says "CEO" but the address is a free mailbox.
• Spam and phishing sent to you from domains that authenticate correctly.

It protects your domain in other people's inboxes. Mail arriving at your own domain still needs inbound filtering.

Our DMARC guides

Next steps

1. Check your domain with the DMARC Checker. It shows whether you have a record, what the policy is, and whether reporting is set up.
2. If you have no record, list your senders and confirm SPF and DKIM with the SPF Checker and DKIM Checker.
3. Publish p=none with a reporting address, using the DMARC Record Generator.
4. Review at least a month of reports, fix failing senders, then move to quarantine and reject.

DMARC protects your domain's name elsewhere. For the mail coming in, an inbound filter such as iBlockSpam screens for spam, phishing and spoofing before it reaches your users; see how it works.

Once your record has a reporting address, iBlockSpam's DMARC monitoring can read the daily reports for you and say when your senders are ready for a stricter policy. If you only want to know when your DMARC, SPF or MX records change, the Free Domain Watch checks them weekly at no cost.

Browse our other SPF, DKIM and DMARC guides.