What is DMARC and how does it work?

10 May 2026 · 11 min read

Almost anyone can send an email that claims to be from your domain. The address bar of an email client shows a friendly name and a From: address, and for most of the history of email there was nothing in the protocol that stopped a stranger putting accounts@yourbank.com in that field and pressing send. DMARC is the control that finally closes that gap. It is the reason a modern mailbox provider can look at a message claiming to be from your domain, decide it is a forgery, and refuse to deliver it before your customer ever sees it.

This article explains what DMARC actually is, how it builds on two older mechanisms (SPF and DKIM) through a concept called alignment, what a DMARC policy instructs a receiving mail server to do, and why it is the only one of these controls that genuinely stops exact-domain spoofing. By the end you should be able to read a DMARC record, understand what each part does, and know what changes when you move from monitoring to enforcement.

The problem DMARC solves: exact-domain spoofing

To understand DMARC you first have to understand a quirk of email that surprises most people. An email message has two different "from" addresses, and they do not have to match.

• The envelope sender (also called the MAIL FROM or Return-Path) is used during the SMTP conversation between mail servers. The recipient almost never sees it.
• The header From (often called From: or the "friendly from") is the address displayed in the inbox. This is what a human reads and trusts.

Spammers and fraudsters exploited this for years. They could pass basic checks on the envelope address while putting your brand in the visible header. The result is exact-domain spoofing: a message that displays your real domain, From: billing@yourcompany.com, with no typos and no lookalike trickery, sent by someone who has no authority over your domain at all.

Exact-domain spoofing is what makes business email compromise, fake invoice fraud, and credential-phishing campaigns so effective. The victim sees a genuine domain they already trust. We have written about a concrete example of this in how a spoofed domain enables invoice fraud. DMARC exists specifically to make this attack fail.

SPF and DKIM: the two building blocks

DMARC does not work alone. It sits on top of two authentication mechanisms that came before it, and it is impossible to understand DMARC without first understanding what each of those does and, crucially, what each one fails to do.

SPF: authorising the sending server

SPF (Sender Policy Framework) lets a domain owner publish, in DNS, a list of the mail servers that are allowed to send on its behalf. A receiving server takes the envelope sender domain, looks up its SPF record, and checks whether the connecting IP address is on the approved list.

An SPF record is a single TXT record that looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net -all

That says: mail is allowed from the ranges Google and SendGrid publish, and everything else (-all) should be rejected. You can inspect any domain's SPF setup with the SPF checker, and you can learn more about the mechanism on the SPF product page.

SPF has two important limitations. First, it authenticates the envelope sender, not the visible header From, so on its own it does nothing about the address your customer actually sees. Second, SPF breaks when mail is forwarded, because the forwarding server is not on the original sender's approved list. SPF also has a hard limit of ten DNS lookups; exceed it and the check returns permerror, which we cover in why SPF returns permerror after ten lookups.

DKIM: a cryptographic signature

DKIM (DomainKeys Identified Mail) takes a different approach. The sending server adds a digital signature to the message headers, generated with a private key. The matching public key is published in the sender's DNS. The receiver fetches that public key, verifies the signature, and confirms two things: the message genuinely came from a system that holds the private key for the signing domain, and the signed parts of the message were not altered in transit.

A DKIM signature names the signing domain in its d= tag, for example d=yourcompany.com. Because the signature travels inside the message rather than depending on the connecting IP, DKIM usually survives forwarding where SPF does not. You can verify a domain's DKIM keys with the DKIM checker, and the DKIM product page goes deeper on key rotation and selectors.

DKIM's limitation is similar to SPF's: on its own, a valid DKIM signature does not have to have any relationship with the address shown in the inbox. A message could carry a perfectly valid signature for d=randomserver.com while displaying From: ceo@yourcompany.com. DKIM proves something signed the message; it does not, by itself, prove that the thing your customer sees is legitimate.

Why neither SPF nor DKIM stops spoofing alone

Here is the crux. Both SPF and DKIM check a domain, but neither of them checks the domain in the From header that the human actually reads. SPF checks the envelope sender. DKIM checks whatever domain chose to sign. A spoofer can satisfy both checks using a domain they fully control, while still printing your brand in the visible From field.

That gap is exactly the hole DMARC fills, and the mechanism it uses to fill it is called alignment.

Alignment: the idea that makes DMARC work

DMARC introduces one deceptively simple rule. The domain that passes SPF or DKIM must align with the domain in the visible From header. It is not enough for a message to pass authentication for some unrelated domain; the authenticated domain has to be your domain, the one your reader sees.

DMARC defines two kinds of alignment:

• SPF alignment: the envelope sender domain (the one SPF validated) matches the From header domain.
• DKIM alignment: the d= domain in a valid DKIM signature matches the From header domain.

A message passes DMARC if at least one of these aligns and the underlying check passes. So a message can fail SPF entirely yet still pass DMARC, as long as it carries an aligned, valid DKIM signature. This "either one is enough" design is deliberate: it lets legitimate forwarded mail, where SPF often breaks, still pass on the strength of its DKIM signature.

Strict versus relaxed alignment

Alignment comes in two modes, controlled by the aspf and adkim tags in your DMARC record:

• Relaxed (the default): the organisational domains must match. A signature for mail.yourcompany.com aligns with a From of yourcompany.com because they share the same registered domain.
• Strict: the domains must match exactly, subdomains included.

Relaxed alignment is right for almost everyone. Strict alignment is occasionally used by organisations that need to tightly control subdomain delegation, but it is easy to break legitimate mail with it, so reach for it only with good reason.

The practical consequence of alignment is the whole point. A fraudster spoofing From: billing@yourcompany.com would need to either pass SPF for yourcompany.com (impossible, because they are not on your published SPF record) or produce a valid DKIM signature with d=yourcompany.com (impossible, because they do not hold your private key). They can spoof the visible address all they like; they cannot make it align. DMARC turns "the From header is just decoration" into "the From header is an authenticated claim".

The DMARC policy: telling receivers what to do

Alignment decides whether a message passes or fails DMARC. The policy decides what the receiving server should do with a message that fails. This policy is published as a single DNS TXT record at a fixed location: _dmarc.yourdomain.com.

A typical record looks like this:

v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; adkim=r; aspf=r

Let us walk through the important tags.

• v=DMARC1 identifies the record version. It must come first.
• p= is the policy: the instruction to receivers. This is the most important tag and it takes one of three values.
• rua= is the address where receivers send aggregate reports: daily XML summaries of how much mail passed and failed DMARC for your domain.
• ruf= is the optional address for forensic (failure) reports: redacted copies of individual failing messages. Many providers no longer send these for privacy reasons.
• sp= sets a separate policy for subdomains, if you want one.
• pct= lets you apply the policy to only a percentage of failing mail during a rollout (now deprecated in the latest specification but still widely supported).
• adkim= / aspf= set DKIM and SPF alignment to relaxed (r) or strict (s).

You can build a valid record with the DMARC record generator, and there is a full breakdown of each field in understanding your DMARC record.

The three policy values

The p= tag is where DMARC moves from observation to enforcement. It has three settings, and the journey from one to the next is the heart of a safe DMARC deployment.

1. p=none is monitor-only. Receivers still evaluate alignment and still send you reports, but they take no action on failing mail. Nothing is blocked. This is where every deployment should start, because it lets you see your real mail flows, including the legitimate senders you forgot about, without any risk of dropping good mail.

1. p=quarantine tells receivers to treat failing mail as suspicious, typically by routing it to the spam or junk folder. It is the middle gear: enforcement, but with a safety margin, since a misclassified legitimate message lands in junk rather than vanishing.

1. p=reject tells receivers to refuse failing mail outright, at the SMTP layer, before it is ever delivered. This is full enforcement and the only setting that genuinely stops exact-domain spoofing. At p=reject, a forged message claiming to be from your domain is bounced by the recipient's own mail server.

The critical insight is that only p=reject (and to a lesser extent p=quarantine) actually protects you. A domain sitting at p=none is publishing a DMARC record, collecting reports, and learning a great deal, but it is not blocking a single spoofed message. Plenty of domains stall at p=none for years and believe they are protected when they are not. Enforcement is the goal; monitoring is only the path to it.

How a receiving server evaluates a message, step by step

It helps to trace exactly what happens when a mailbox provider receives a message claiming to be from your domain.

1. The receiver reads the From header domain, say yourcompany.com.
2. It runs SPF against the envelope sender and notes whether that domain passes and whether it aligns with the From domain.
3. It runs DKIM on any signatures and notes whether any valid signature aligns with the From domain.
4. It applies the DMARC rule: if SPF passed and aligned, or DKIM passed and aligned, the message passes DMARC.
5. If the message fails DMARC, the receiver looks up your policy at _dmarc.yourcompany.com and acts on it: do nothing (none), junk it (quarantine), or reject it (reject).
6. Regardless of the outcome, the receiver records the result and later bundles it into an aggregate report sent to your rua address.

That feedback loop in the final step is what makes DMARC safe to deploy. You are not flying blind. Before you ever turn on enforcement, the reports tell you precisely which senders are passing, which are failing, and from where.

Reading the reports: how you reach enforcement safely

Aggregate reports are XML documents, one per receiver per day, summarising message counts grouped by sending IP, with SPF, DKIM, and alignment results for each. They are not designed to be read by a human in raw form, which is why a parser is essential. You can paste a report into the DMARC report analyser to turn the XML into a readable picture, and there is a gentle walkthrough in reading your first DMARC report.

The reports are how you avoid the single biggest fear about DMARC: breaking your own legitimate email. The standard, safe rollout looks like this:

• Start at p=none and collect reports for a few weeks.
• Use the reports to find every legitimate sender (your marketing platform, your CRM, your helpdesk, your invoicing system, the payroll provider nobody told you about) and make sure each one is correctly set up to pass SPF or DKIM with alignment.
• Once your legitimate mail is passing cleanly, move to p=quarantine, watch the reports again, and confirm nothing legitimate is being caught.
• Finally, move to p=reject for full protection.

A common failure during this process is a third-party service that sends as your domain but is not aligned, so it passes raw SPF or DKIM yet still fails DMARC. We cover that scenario in when a service is not aligned at p=reject. Subdomains deserve their own attention too, since an unguarded subdomain can be spoofed even when your main domain is locked down; see setting a DMARC record for a subdomain.

If your reports come back empty, that usually points to a problem with the record or the reporting address rather than an absence of mail; why your DMARC reports are empty explains the usual causes.

DMARC and the wider authentication picture

DMARC also unlocks capabilities that sit on top of it. BIMI (Brand Indicators for Message Identification) lets your verified logo appear next to your messages in supporting inboxes, but only for domains that have reached p=quarantine or p=reject. In other words, BIMI is a reward for proper enforcement, not a substitute for it. You can check a domain's setup with the BIMI checker and read more on the BIMI product page.

Alongside DMARC, MTA-STS protects the transport layer by insisting that mail to your domain travels over TLS, closing off downgrade attacks that DMARC does not address. The MTA-STS checker and the MTA-STS product page cover that piece. Together, SPF, DKIM, DMARC, MTA-STS, and BIMI form a complete email-authentication posture, and the major mailbox providers increasingly expect all of it; the bulk-sender requirements are summarised on our requirements page and in why Gmail, Yahoo, and Microsoft now require DMARC.

A worked example

Suppose your domain is acme.co.uk and you have published:

v=DMARC1; p=reject; rua=mailto:dmarc@acme.co.uk

A fraudster sends a fake invoice with From: finance@acme.co.uk from their own server.

• SPF: their server is not on your SPF record, so SPF for acme.co.uk fails. (They might pass SPF for their own domain on the envelope, but that domain does not align with acme.co.uk.)
• DKIM: they cannot produce a valid signature for d=acme.co.uk because they do not have your private key. Any signature they add is for a domain that does not align.
• DMARC: neither SPF nor DKIM aligns and passes, so the message fails DMARC.
• Policy: the receiver reads p=reject and refuses the message. Your customer never sees the forgery.

Now compare your own legitimate invoicing system. It sends from an approved IP (SPF passes and aligns) and signs with d=acme.co.uk (DKIM passes and aligns). It passes DMARC on both counts and is delivered normally. The same policy that blocks the fraud lets your real mail straight through. That is the asymmetry DMARC creates, and it is why exact-domain spoofing simply stops working once you reach p=reject.

The practical takeaway

DMARC is not a separate scanner or filter you bolt on. It is a published instruction, backed by alignment, that turns SPF and DKIM from disconnected checks into a real guarantee about the address your customers actually read. SPF authorises sending servers. DKIM signs messages. DMARC ties both to the visible From header and tells the world's mailbox providers what to do when the tie does not hold. Until you reach p=reject, anyone can still impersonate your domain; once you do, that attack fails at the recipient's own server.

The honest catch is that getting to p=reject without breaking legitimate mail takes careful reading of reports and patient configuration of every sender. If you want to see where your domain stands right now, run it through the DMARC checker or browse the full set of free diagnostic tools. And if you would rather have the whole journey from p=none to p=reject handled for you, with no email outage and ongoing monitoring with change alerts, that is exactly what the DMARC product and continuous monitoring are built to do. For deeper reading on the rollout itself, see how to reach p=reject without breaking email.