Article URL: https://senderledger.com/articles/what-dmarc-actually-protects-you-from Comments URL: https://news.ycombinator.com/item?id=49153361 Points: 20 # Comments: 5

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, and it is much narrower than the reputation DMARC has picked up. A team that reaches p=reject believing they are now phishing-proof will skip the controls that cover everything DMARC leaves untouched. 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. Every email is handled in two stages, and each stage has its own "from" address. The delivery stage uses an envelope address, like the address on a posted parcel: the mail servers read it to route the message, then the recipient never sees it. The message itself then carries the visible From, the name and address your mail app displays (for example, "Your Bank <alerts@your-bank.com>"). That is the one a human reads and trusts. Because the two are set independently, an attacker can put your bank in the visible From while the envelope points somewhere else entirely. SPF checks the envelope address; DKIM's signature carries its own domain; DMARC exists to tie whichever one authenticated back to the visible From, so authentication lines up with the address the reader can actually see. 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: 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: