SPF, DKIM and DMARC Explained Without the Jargon
An invoice you sent last week never arrived. It did not bounce, and it is not sitting in a spam folder you can find. Somewhere between your outbox and your customer’s inbox, a spam filter quietly made a decision about you, and SPF, DKIM and DMARC are the three records it was checking when it made that decision.
None of this is complicated once you see what each one actually does. It just tends to get explained in acronyms stacked on acronyms, which is how a fifteen-minute DNS job ends up looking like a project.
This sits alongside the rest of the business email guides in the knowledge centre, if you want the wider picture once these three records are sorted.
Short answer: SPF, DKIM and DMARC are DNS records that prove an email genuinely came from your domain. SPF lists which servers are allowed to send for you, DKIM signs each message with a private key so it cannot be altered in transit, and DMARC tells receiving mail servers what to do if either check fails.
What do SPF, DKIM and DMARC actually stand for?
SPF is Sender Policy Framework, DKIM is DomainKeys Identified Mail, and DMARC is Domain-based Message Authentication, Reporting and Conformance. The names are not worth memorising. Each one answers a different question, and a receiving mail server checks all three before deciding whether your message is trustworthy.
Think of it as three checks on the same envelope: who is allowed to send this, has it been tampered with, and what happens if something does not add up.
What does the SPF record check?
SPF is a list, published in your domain’s DNS, of every server allowed to send email claiming to be from your domain. When mail arrives, the receiving server checks whether it came from a server on that list. If it did not, that is a strong signal the message is spoofed.
The record itself is a single TXT entry, something like v=spf1 include:_spf.example.com ~all in plain text form, listing your mail provider’s sending servers. The trap is that a domain can only have one SPF record. Add a second mail tool, a marketing platform or an invoicing system that sends on your behalf, and it needs to be folded into that same record rather than added as a new one, or the whole check can start failing.
What does DKIM add that SPF does not cover?
DKIM attaches a digital signature to each outgoing message, generated with a private key your mail server holds. The receiving server looks up a matching public key in your DNS and checks the signature against the message content. If even a word has changed in transit, the signature no longer matches and the check fails.
Where SPF only checks which server sent the message, DKIM checks whether the message itself is intact. That distinction matters, because some spoofing methods can pass through an approved-looking path without SPF catching them. DKIM closes that gap by verifying content, not just the route.
What does DMARC do, and why isn’t SPF and DKIM enough on their own?
DMARC is the policy layer that sits above the other two. It tells a receiving server what to do when a message fails SPF, DKIM, or both: let it through, quarantine it, or reject it outright. Without a DMARC record, a receiving server checks SPF and DKIM but is left to decide for itself how strict to be with a failure, which most spam filters resolve by simply being cautious with your domain.
A DMARC record also sets up reporting, so you get a daily or weekly summary of who is sending mail using your domain, including anyone spoofing it. That reporting is often the first real evidence a business has that its domain is being impersonated at all.
| Record | What it checks | What happens on failure |
|---|---|---|
| SPF | Is this server allowed to send for this domain? | Flagged, but the receiving server decides how much weight to give it |
| DKIM | Has this message been altered since it was signed? | Signature mismatch, treated as suspicious |
| DMARC | What should happen when SPF or DKIM fails? | Follows the policy you set: none, quarantine or reject |
How do you set up SPF, DKIM and DMARC records?
All three live as TXT records in your domain’s DNS zone, usually added through your DNS management screen. Your mail provider will give you the exact values to paste in, since the DKIM key is generated on their side and is specific to your account.
- Get the exact SPF, DKIM and DMARC values from your email provider’s setup documentation, not a generic template.
- Add the SPF record first, checking whether one already exists so you merge rather than duplicate it.
- Add the DKIM TXT record using the selector and key your provider supplies.
- Add a DMARC record starting with a monitoring-only policy (
p=none) so you can watch the reports before anything gets blocked. - After a week or two of clean reports, tighten the DMARC policy to quarantine or reject.
Starting DMARC at p=none rather than jumping straight to reject is the one step worth not skipping. It lets you see who is legitimately sending on your behalf before you start bouncing anyone’s mail.
What goes wrong when these records are missing or wrong?
The most common symptom is mail landing in spam with no error message anywhere, which is exactly the situation covered in more depth in the guide to why business emails go to spam. A second common failure is a broken SPF record after adding a new sending tool, where the old record was simply overwritten instead of merged, quietly breaking authentication for every other sender on the domain.
A DMARC record set to reject before SPF and DKIM are confirmed working is the other classic mistake. It can cause legitimate mail, including your own, to be blocked outright, which is why the monitoring stage matters more than people expect.
Do you need all three, or is one enough?
SPF alone is better than nothing, but it is the weakest of the three on its own and easiest to work around. SPF and DKIM together cover most day-to-day spoofing. DMARC is what turns those two checks from a suggestion into an enforced policy, and it is also the only one of the three that gives you visibility into who is using your domain.
For any business sending invoices or quotes, something a scammer would like to impersonate, all three are worth having rather than picking one. The setup time is roughly the same either way, so there is little reason to stop halfway.
Frequently asked questions
Can I check whether my domain already has SPF, DKIM and DMARC set up?
Yes, several free online checker tools will look up your domain’s DNS and report which of the three are present and whether the syntax is valid. This is worth doing before you assume anything is missing, since a previous host or developer may have already added some of it.
Will adding SPF, DKIM and DMARC stop all spam emails pretending to be from me?
It stops a large share of them, but not every mail server checks DMARC strictly, and some older systems ignore it entirely. It is the best defence available and worth doing regardless, just not a guarantee that impersonation attempts will stop completely.
What happens if I change email providers and forget to update these records?
Mail sent from the new provider will likely fail SPF and DKIM checks because the old records still point to the previous provider’s servers, so it starts landing in spam or gets rejected. Updating these records should be one of the first steps in any provider change, not an afterthought.
Does a DMARC report tell me who is sending fake emails from my domain?
Yes, that is one of its main uses. The aggregate reports list the servers that sent mail claiming to be from your domain and whether they passed authentication, which is often how a business first discovers its domain is being spoofed.
Can I set up SPF, DKIM and DMARC myself, or do I need a developer?
Most people can do it themselves if their DNS management screen is reasonably clear and their mail provider gives exact values to paste in. Where it gets fiddly is merging a new SPF entry with an existing one, which is the step most likely to need a second pair of eyes. Whoever runs your mailboxes should supply the exact values; GoodHost’s email hosting is still listed as launching soon, so for now those values come from your current provider.
Query your own domain before you trust a word of this. Ask for the TXT record at _dmarc followed by your domain and see whether anything answers at all, since an empty result is both the most common finding and the quickest to correct. The records themselves are written out in the setup walk through, and if your provider will not hand over the DNS zone, every GoodHost hosting plan includes a control panel that will.