What DKIM, SPF and DMARC are for
They are three records published on a sending domain that together prove a message really came from who it claims. SPF lists the servers allowed to send, DKIM signs the message itself, and DMARC tells receivers what to do when either check fails.
On this page
These three acronyms are the wall most marketers bounce off. They are not difficult ideas, but they are explained almost everywhere by people who assume you already run a mail server, so this page explains them by what each one proves rather than by how it is configured.
What does SPF prove?
SPF is a list, published on your domain, of the servers allowed to send mail using it. A receiving server reads it and checks whether the message in front of it arrived from one of those.
It answers exactly one question: was this message sent from an approved place. It says nothing about whether the message was altered on the way.
What does DKIM prove?
DKIM is a signature attached to the message itself, checked against a key published on the sending domain. If the signature verifies, the message really was signed by the domain and the parts it covers have not been changed since.
So SPF is about where a message came from and DKIM is about whether it is intact. They are complementary, and a serious sender publishes both.
What does DMARC add?
DMARC is the instruction. It tells receiving servers what you want done with a message that fails the other two checks, and where to send the reports.
It also adds alignment, which means the domain in the address a reader actually sees has to match the one that passed the checks. That is the part that stops somebody passing SPF on their own domain while displaying yours in the from line.
| Record | What it proves | What happens without it |
|---|---|---|
| SPF | the sending server was approved | messages look unauthorised |
| DKIM | the message is intact and signed | tampering is undetectable |
| DMARC | what to do when a check fails | receivers decide for themselves |
| All three, published by you | you control the sending identity | you cannot send on that domain |
| None, supplied by a provider | the provider controls the identity | nothing, there is nothing to do |
Who actually has to publish them?
Whoever owns the domain the mail claims to come from. That is the sticking point for most people reading this, because the domain is held by an agency that stopped answering, or by an IT department with a change window next month.
If you do not control the domain you cannot publish the records, and no amount of wanting to send will change that. It is the single most common reason a ready campaign never leaves.
When do you need none of them?
When the mail is not going out on your domain at all. If the sending identity belongs to the provider, the provider has already published and maintained the records, and there is nothing left for you to configure.
That is the PhantomFox model: nothing to configure, no DKIM, no SPF, no DMARC, no mail server and no deliverability consultant, because the sending infrastructure is authenticated before your account exists. A team locked out of its own registrar can start from no setup sending without DNS access, and the mechanics are on how it works.
None of this decides where a message is filed, which is a separate subject covered in why emails go to spam. If you are also being asked to warm a new sender, read what email warm up is and can you skip it, and if a provider has already closed you down over authentication, read what happens when a sending account is suspended. Everything else is on the answers hub.