DMARC Explained: The Policy That Ties Email Authentication Together

If you've already read our piece on SPF records, you know the punchline at the end: SPF authenticates the envelope sender, not the visible From: header. A perfectly configured SPF record still lets a spammer slap your domain on the From: line of a message they're sending from their own legitimately-SPF-authorised server. DKIM has a similar gap — it signs whatever domain the sender chooses to sign, which doesn't have to be the one shown to the recipient.

DMARC fixes that gap. It isn't a new authentication mechanism. It doesn't sign messages. It doesn't authorise IPs. What it does is take the results from SPF and DKIM, check whether either one validated a domain that matches the From: header the user actually sees, and tell the receiving mail server what to do when the answer is no. Plus it asks for reports — and the reports are the part that makes the whole thing work.

What DMARC actually does

Domain-based Message Authentication, Reporting and Conformance is a policy layer on top of SPF and DKIM. A DMARC record is a single DNS TXT record published at _dmarc.yourdomain.com — note the underscore subdomain. When a receiver evaluates an incoming message, it does three things in order:

• Run SPF and DKIM as normal.
• Check whether the domain those checks authenticated aligns with the domain in the From: header.
• Look up the From: domain's DMARC record and apply its policy to messages that fail the alignment check.

Then, periodically, the receiver compiles aggregate data about every message it saw claiming to be from your domain — pass and fail, by sending IP — and ships those reports to the address you nominated in the DMARC record. That feedback loop is what lets you safely deploy a strict policy without breaking your own mail.

The alignment concept

This is the conceptual heart of DMARC and the part that trips up most people learning it. There are three different domains floating around a typical email, and they don't have to be the same:

• The envelope sender — the MAIL FROM address in the SMTP handshake, also called the Return-Path. This is what SPF checks against.
• The DKIM signing domain — the d= tag in a DKIM-Signature header. This is what DKIM cryptographically validates.
• The From: header — the address your mail client actually displays to the user.

SPF and DKIM individually each validate one of the first two. They tell the receiver "yes, the server that connected is allowed to send for envelope-domain.com" or "yes, this message is genuinely signed by dkim-domain.com." Neither says anything about whether either of those matches the visible From:.

DMARC requires alignment — that the domain SPF or DKIM authenticated has to match (in a specific way) the From: domain. DMARC defines two levels of strictness:

• Relaxed alignment (adkim=r, aspf=r — the default) allows subdomains. Mail from news.example.com aligns with a From: of example.com, because they share the organisational domain. This is what almost everyone uses.
• Strict alignment (adkim=s, aspf=s) requires the domains to be identical character-for-character. news.example.com does not align with example.com under strict. Useful in narrow scenarios; usually overkill.

Crucially, DMARC passes if either SPF or DKIM produces an aligned pass. You don't need both. This matters because forwarders routinely break SPF (the forwarder's IP isn't in your SPF record) but DKIM signatures usually survive a forward intact — so a message that fails SPF can still pass DMARC if its DKIM signature is aligned. That's the design.

The three policies

The p= tag is the heart of a DMARC record. It tells receivers what to do with messages that fail alignment:

• p=none — monitoring only. Receivers collect data and report back, but take no action on failing messages. This is where every deployment starts. It is not where any deployment should end. A domain stuck on p=none forever is gathering data nobody acts on.
• p=quarantine — failing messages get delivered to the spam or junk folder. The middle ground: spoofed mail still reaches the recipient, but in a place they're far less likely to act on.
• p=reject — failing messages are dropped at the SMTP layer. The recipient never sees them. This is the gold standard, and it's what protects your domain from being used in phishing campaigns against your own customers.

The progression is meant to be none → quarantine → reject, driven by what the reports show. You start at none for a few weeks to a couple of months, identify every legitimate sender that wasn't already authorised (every CRM, every marketing platform, every transactional service that quietly sends mail for your domain), fix their SPF and DKIM, then move to quarantine, watch for a while, then move to reject. The trick is to keep moving. A domain that publishes p=none in 2023 and is still on p=none in 2026 is doing the work of zero DMARC.

Reading a DMARC record

Here's a typical published DMARC record. Picking it apart is the fastest way to understand the syntax:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100; adkim=r; aspf=r

• v=DMARC1 — the version identifier. Always present, always first.
• p=reject — the policy. Failing messages get dropped.
• rua=mailto:dmarc@example.com — the aggregate reporting address. Receivers send a daily XML rollup here.
• pct=100 — apply the policy to 100% of failing messages. Setting pct=50 would apply it to half and let the rest through, which is sometimes used as an intermediate step between quarantine and reject.
• adkim=r — relaxed DKIM alignment.
• aspf=r — relaxed SPF alignment.

A few other tags you'll see less often: sp= sets a different policy for subdomains (defaults to the same as p=); ruf= nominates an address for individual failure reports (most receivers no longer send these for privacy reasons); fo= controls when failure reports are generated; ri= requests a different aggregate report interval (most receivers ignore it and send once a day).

Why reporting matters more than you think

The single most undervalued part of DMARC is the rua tag. Every major mail provider that supports DMARC — Google, Microsoft, Yahoo, Apple, Comcast, and most large-volume receivers — generates an XML aggregate report once a day for every domain that asked for one. Each report contains, for that 24-hour window, every IP that sent mail claiming to be from your domain, the count of messages per IP, the SPF and DKIM results, and the DMARC alignment outcome.

That data is what makes safe deployment possible. The first time you turn on DMARC reporting, two things happen:

• You discover legitimate senders you completely forgot about. The marketing automation platform someone signed up for three years ago. The HR vendor sending interview confirmations. The transactional email service running on a forgotten side project. Every one of them is a future SPF failure waiting to bite you.
• You see attackers actively spoofing your domain. The IPs flagged "DMARC fail" that aren't yours — sending from countries you've never operated in, in volumes you've never authorised — are the phishing campaigns running against your customers right now.

Without reports, deploying p=reject is flying blind. You're guessing at which senders are legitimate, and if you guess wrong, real mail bounces silently and the people who depend on it call your support team. With reports, you can see the full picture before you tighten the policy.

Most companies don't read XML by hand — they use a DMARC report processor (Dmarcian, Postmark, EasyDMARC, Valimail, and similar services). For small operations, dumping reports into a single mailbox and skimming them weekly works fine.

Google and Yahoo's 2024 requirement

In October 2023, Google and Yahoo jointly announced new sender requirements that took effect February 2024. For any sender pushing more than 5,000 messages per day to Gmail or Yahoo recipients, three things became mandatory:

• SPF and DKIM properly configured.
• A DMARC policy published, at minimum p=none.
• One-click unsubscribe in the message body and headers.

Microsoft followed in 2025 with a similar bar. Senders below the threshold weren't required to comply, but the trend is unmistakable: DMARC moved from "best practice" to "table stakes" inside one quarter. Mail from large senders without DMARC simply stopped being delivered. If you operate a domain that sends transactional or marketing mail, even small volumes, this is no longer optional.

Common mistakes

The failures that come up most often:

• Going straight to p=reject without spending time at p=none first. Almost guaranteed to drop legitimate mail you didn't know about. The reports are there to prevent this — use them.
• Sitting on p=none forever. Monitoring without action is theatre. Attackers can still spoof your domain freely. Most domains we audit have been on p=none for years.
• No rua= tag. You're flying blind. You won't see the spoofing happening and you won't safely be able to tighten the policy.
• pct=0 — accidentally applying the policy to zero messages. Not a typo most people make on purpose, but it sneaks into intermediate-step rollouts and quietly nullifies enforcement.
• Multiple DMARC records at the same name. A domain may publish only one TXT record starting with v=DMARC1. Two records (usually from someone adding a new entry rather than editing the existing one) cause receivers to ignore both.

The three legs of the stool

SPF, DKIM, and DMARC are the three protocols that together make modern email authentication work. None of them is sufficient alone:

• SPF (TXT record at the domain root) declares which IPs can send mail for the domain. Authenticates the envelope sender.
• DKIM (TXT record at {selector}._domainkey.{domain}) publishes a public key. The sender signs each message; the receiver verifies the signature.
• DMARC (TXT record at _dmarc.{domain}) requires alignment between the visible From: and at least one of the SPF/DKIM-authenticated domains, sets a policy for failures, and requests reports.

SPF is who. DKIM is what. DMARC is the rule.

If you operate a domain that sends any mail at all — transactional, marketing, contact-form forwarding, anything — you need all three. The DMARC checker reads your domain's policy and grades it A through F. The SPF checker walks the include tree and counts you against the 10-lookup ceiling. The email header analyzer traces a specific message through every server that touched it and shows the SPF/DKIM/DMARC results in plain English. A DKIM-focused post is coming next.