What DMARC Actually Protects You From, and What It Does Not - SenderLedger

Product

How it works

For MSPs

Pricing

Articles

Self-hosted

Request access

← All articles

Insight<br>What DMARC Actually Protects You From, and What It Does Not

3 Aug 2026 · 7 min read

DMARC gets asked to do a lot of jobs it was never designed for. Teams reach for it as a spam filter, a phishing filter, and a general trust signal. It is none of those. The current DMARC protocol, defined in RFC 9989, answers a deliberately narrow question: did the owner of the domain in the visible From address authorise this message, and can that authorisation be established through an aligned SPF or DKIM result?

That question is worth answering. It is also much narrower than the reputation DMARC has picked up. Getting the boundary right matters, because a team that reaches p=reject believing they are now phishing-proof will skip the controls that cover everything DMARC leaves untouched.

How email proves who sent it

Three terms come up throughout, so here they are in plain English. SPF is a published list of the servers a domain says are allowed to send mail for it; a receiver checks whether the message actually came from one of them. DKIM is a cryptographic signature added to the message, so a receiver can confirm it genuinely came from the signing domain and was not tampered with in transit. DMARC ties both back to one thing: the visible From address.

That last term matters more than it sounds. Every email carries two "from" addresses. One is the visible From , the name and address your mail app shows you (for example, "Your Bank "); it is the part a human actually reads and trusts. The other is a hidden envelope address used behind the scenes for delivery, which you never see. An attacker can set these two to different values, which is exactly how a message can look like it is from your bank while being delivered on behalf of somewhere else. DMARC's job is to make sure authentication lines up with the address you can see, not the hidden one.

What these actually look like

All three live as text records in your domain's DNS, the same place your website's address is configured. You do not need to memorise the syntax; it helps to recognise the shape.

An SPF record lists who is allowed to send. This one authorises Google Workspace and a marketing tool, and says anything else should be treated as suspicious:

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

The include: entries pull in each provider's own list of servers, and -all means "if it is not on those lists, it is not us".

A DKIM record publishes the public half of the signing key, so receivers can check the signature on your mail. The long string is the key itself:

selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ...AB"

Finally the DMARC record ties it together and tells receivers what to do when a message fails. This one asks them to reject failures and to send you reports:

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

The p=reject here is the same policy the rest of this article keeps referring to, and rua= is the address your aggregate reports are sent to.

How a pass is actually decided

DMARC sits on top of SPF and DKIM, and it evaluates them independently. There are two separate ways a message can pass: SPF passes for the hidden envelope domain and that domain aligns with the visible From domain, or a DKIM signature validates and its signing domain aligns with the visible From domain. If either aligned path succeeds, DMARC passes. If neither does, it fails. "Aligns" simply means the two domains match closely enough to count as the same organisation.

flowchart TD<br>A[Incoming email] --> S{SPF authenticates and aligns with From domain?}<br>S -->|yes| P([DMARC pass])<br>S -->|no| D{DKIM validates and aligns with From domain?}<br>D -->|yes| P<br>D -->|no| F([DMARC fail])

DMARC passes if either SPF or DKIM both authenticates and aligns with the visible From domain. It fails only when neither does.

Alignment is the part most explanations skip, and it is where a useful, verifiable detail lives. DMARC defines two alignment modes. In relaxed mode (the default) the two domains only need to share the same organisational domain, so a DKIM signature from mail.example.com aligns with a From of example.com. In strict mode they must be identical, and that same signature would fail. If you have seen "SPF pass, DMARC fail" and wondered how both can be true at once, it normally means SPF confirmed the hidden envelope domain successfully, but that domain did not match the visible From address closely enough to align. Strict versus relaxed mode then decides whether closely related domains count as the same.

Notice what the test never inspects: the body, the links, the attachments, or the sender's intent. It is a check on provenance, not on content.

Where DMARC helps

The case DMARC was built for is...