Three DNS records or policies decide whether a stranger can send email that appears to come from your company, SPF, DMARC and DKIM. Most businesses have one of them, some have two, and a surprising number have all three but have left the critical setting switched off.This article explains what each record does, what it means if you do not have it, and what the policy settings actually control.

The protocol that moves email around the internet was written in the early 1980s, for a small network of institutions where everybody broadly knew everybody. It contains no step at which a sending server has to prove it is entitled to use the address it is claiming.

The From field is simply text that the sender fills in. It is the return address written on the back of an envelope. Nothing in the postal system checks that you wrote the truth, and nothing in email checks it either.

This is worth being precise about, because it changes what you can expect. It is not a vulnerability waiting on a patch. It is how email works, and it cannot be changed without breaking email everywhere at once. So the fix had to be added on top, as three separate optional mechanisms that a domain owner chooses to publish.

No error appears. No warning is raised. Your email continues to send and receive exactly as it did. The only difference is that somebody else can also send as you, and you have no way of knowing whether they are.

The invoice that is not yours.
A customer receives what appears to be your invoice, with your layout and your name on it, and bank details that belong to somebody else. They pay it. The money is gone within minutes, and the conversation that follows is about whether your business or theirs absorbs the loss. The relationship rarely survives it intact.

The message to your customers.
Your domain is used to send phishing email to the people in your industry who would most expect to hear from you. You find out when one of them rings to ask why you sent it. Your name carries the damage, not the attacker's.

The request to your own finance team.
An email from the managing director, to the person who processes payments, asking for an urgent transfer or a change of supplier bank details. No attachment. No link. Nothing for a filter to catch, because there is nothing malicious in the message — only a sender address that is not real.There is a quieter fourth version that costs money without anybody noticing. Google, Microsoft and Yahoo have all tightened their requirements on sender authentication, and mail from domains that cannot prove who they are is increasingly filtered or rejected outright. If your quotes and invoices have been landing in junk folders more often than they used to, this is a likely cause.

A published list of the mail servers permitted to send on your behalf. The receiving server checks whether the message arrived from one of them.There is a catch that matters. SPF checks the hidden envelope address used in delivery, not the From address your recipient reads on screen. So SPF on its own does very little about the impersonation people actually worry about.

Without it receiving servers have nothing to check a sender against. Any machine anywhere can send mail claiming to be from your domain and there is no basis on which to question it. This is the most exposed position a domain can be in.

Your mail server adds a cryptographic signature to every message. The matching public key is published in your DNS. A receiving server can verify the signature and know two things: the message was sent by somebody holding your key, and it has not been altered in transit.

Without it there is no proof that emails are intact or genuinely yours, and a message that is forwarded legitimately will often fail SPF. DKIM is what keeps authentication working through mailing lists and forwarding, so without it your real mail is more likely to be treated as suspicious.

DMARC is the one that closes the gap, and it does two jobs.

First, it insists that an SPF or DKIM pass must align with the domain in the visible From address. That alignment requirement is what finally protects the name your recipient sees, and it is the reason the first two records are not sufficient without it.

Second, it tells receiving servers what to do when a message fails, and asks them to report back on what they saw.

Without it SPF and DKIM may both be passing, and none of it is tied to the address your recipient reads. Receiving servers are given no instruction, so they make their own decision — which is usually to deliver. You also receive no reports, so impersonation of your domain happens without you ever learning of it.

The short version: SPF and DKIM establish facts. DMARC decides what those facts mean and what should happen as a result. All three together are what actually protect your name.