SPF, DKIM and DMARC make your domain hard to forge, and tell receiving systems what you would like done when somebody tries. Published properly, watched through the rollout, and taken as far as an enforcing policy.
A customer gets an invoice that appears to come from your company. Right name in the From line, right logo, plausible amount, and new bank details. They pay it. By the time anybody works out what happened, the money is gone and the conversation you are having with that customer is about whose fault it was.
Nothing of yours was hacked. Somebody sent mail using your domain, and nothing you had published told the receiving end to treat it with suspicion.
No malware, no stolen password, no access to your systems at all. Just your domain in the From line.
SPF and DMARC are published in your DNS. DKIM does both: it signs each message on the way out, and its matching public key has to be published in DNS too, either directly or through your mail provider, so the receiver can check the signature. They do different things and they are strongest together.
Publishes which servers are allowed to send for your domain. It is checked against the return address the receiving server sees, which is not always the one your customer reads.
Your sending system signs each message, so the far end can check that the signed parts were not altered and that the signature really belongs to your domain.
Requires a passing SPF or DKIM result to match the domain in the visible From line, and publishes what you would like done when neither one matches.
Anybody telling you this stops impersonation is overselling it. What it does is make unauthorized use of your exact domain something the receiving system can detect and act on. Narrower than the pitch, and still worth having.
Three things sit outside it. A lookalike domain, which is somebody else's domain and nothing to do with your records. A free mailbox with your company put in the display name, which is the easy part to read and the part none of this authenticates.
And a real account of yours that somebody has the password to, where the mail can authenticate perfectly well because it genuinely is your system sending it. That last one is why multi-factor and training sit alongside this rather than after it.
A DMARC policy is a published preference. The system receiving your mail decides what it actually does.
The specification is explicit that final handling is always a matter of local policy and sits with the receiver, and that a receiver may accept a message that fails your checks even where you asked for rejection. The large mailbox providers publish their own authentication requirements, which is what makes yours worth publishing. It is still not a switch you get to throw on somebody else's mail server.
The DMARC policy value has three settings: none, quarantine and reject. A policy of none asks receivers for no action of its own, though it can still bring you the reports. It is the right place to start and the wrong place to stop.
We find records still sitting on none years after they went in. It satisfies a checklist and it never asked anybody to do anything. Getting from there to quarantine or reject is the actual work, because first you have to account for every legitimate system sending as you: the accounting package, the scheduling tool, the mail service marketing uses, the copier.
Since February 2024 Google has asked every sender to Gmail for SPF or DKIM, valid forward and reverse DNS, TLS, standards-compliant formatting, and a spam rate under 0.3 percent. At 5,000 messages a day or more it wants SPF and DKIM and DMARC, the From domain aligned to one of them, and one-click unsubscribe on marketing mail. It accepts a policy of none.
Microsoft asks much the same of domains sending more than 5,000 a day to Outlook: SPF and DKIM passing, and DMARC at least set to none and aligned.
If you are not sending thousands a day, those thresholds are not your reason to do this. The fake invoice is.
We do not sell this as a monthly product. The records go in, the reports get read while we account for everything that legitimately sends as you, and the policy moves up to enforcement. Then it is done until something about your mail changes.
New mail service, new vendor sending on your behalf, new domain: those want a look. If we already run your IT, that look is part of it and does not turn up as its own line item.
The obvious mail platform, and the other things signed up for over the years and never written down.
Including keeping SPF within its ten DNS lookup limit, past which Microsoft warns the check may fail.
Aggregate reports show the sending sources receivers actually observed, and how they authenticated. That is how legitimate senders surface before the policy tightens.
None, then quarantine, then reject, watching what the reports say at each step rather than jumping to the end.
Forwarding can break alignment. ARC can preserve the original result, so forwarded paths get considered and tested rather than found out about later.
What each record is, why it is there, and which system it exists for, so the next person is not guessing.
We will read what is there now, tell you plainly what it does and does not ask for, and what it would take to get to an enforcing policy.
Start a Conversation