What DMARC Protects You From, and What It Does Not

← All articles Insight What DMARC Actually Protects You From, and What It Does Not 3 Aug 2026 · 8 min read Ask five people what DMARC does and you will get five answers: it stops phishing, it kills spam, it proves an email is safe. None of that is quite right. DMARC (the current spec is RFC 9989) checks one narrow thing: did the owner of the domain shown in the From line actually authorise this message, provable through SPF or DKIM? It is a good question to answer. It is also a lot smaller than the reputation DMARC has built up. Reach p=reject thinking you are now phishing-proof and you will quietly drop the controls that handle everything DMARC never touched in the first place. How email proves who sent it Two building blocks sit underneath DMARC. SPF is a list a domain publishes of the servers allowed to send mail on its behalf; the receiver checks whether the mail actually arrived from one of them. DKIM adds a cryptographic signature to the message, which lets the receiver confirm it came from the signing domain and was not altered along the way. DMARC then pins both of those to the address you see in the From line. Here is the part that trips people up. An email actually has two "from" addresses. There is the envelope address, which works like the address on a posted parcel: mail servers use it to route the message and then throw it away, so you never see it. And there is the visible From your mail app displays, the "Your Bank <alerts@your-bank.com>" you read at the top of the message. Nothing forces those two to match. That gap is the whole game: an attacker can show your bank in the visible From while the envelope quietly points at their own server. SPF looks at the envelope address. DKIM's signature carries a domain of its own. DMARC's job is to take whichever of those actually authenticated and check it against the From line you can see, because that is the address a human trusts. 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" p=reject is the strict setting: fail authentication and the mail gets turned away. rua= is simply where your aggregate reports land. 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 A[Incoming email] --> S{SPF authenticates and aligns with From domain?} S -->|yes| P([DMARC pass]) S -->|no| D{DKIM validates and aligns with From domain?} D -->|yes| P D -->|no| F([DMARC fail]) DMARC passes if either SPF or DKIM both authenticat