E-mail authentication for a small business: SPF, DKIM and DMARC
Two symptoms usually give away that a domain's e-mail authentication is missing. One is loud and annoying; the other is quiet and expensive.
The first: your mail keeps landing in the spam folder, even though you're advertising nothing, just sending a quote. The second, quieter one: somebody sends mail in your domain's name — typically a fake invoice with an altered bank account number, to your clients. The same three DNS records defend against both.
Setting them up is one-off work, needs no new service, and the large mail providers now expect it. This piece describes what the three records do, how to put them in place, and why it's worth tightening gradually — with the experience of having gone through it on my own domain.
What the receiving mail system checks
When your message arrives at the recipient's provider, it asks three questions, and reads the answers from your domain's DNS records:
- SPF — did the message come from an authorised server? The SPF record lists which servers may send in your domain's name. Anything not on the list is suspect.
- DKIM — is the message's seal intact? The sending server signs every message; the receiver verifies with the key published in your domain that it really came from you and wasn't altered in transit.
- DMARC — what should happen to what fails? This policy tells the receiver whether to let a suspicious-looking message through, put it in spam, or reject it — and it also requests reports on what was seen.
The three work together. SPF and DKIM prove; DMARC decides and reports — with any one missing, the protection has a hole. Without the records the receiving system has no basis for distinguishing your mail from a forgery, so it treats both with the same suspicion.
- 01 your message
- 02 SPF · the server
- 03 DKIM · the seal
- 04 DMARC decides
without records there is nothing to pass — · legitimate mail can end up on the suspicious side too
How the records get into place
All three are simple text DNS entries at your domain — no new service is needed, they just have to go in the right place. Most hosting providers supply a ready SPF value; the DKIM key is generated by whatever runs your mail; and DMARC is a policy line you assemble yourself. The exact values depend on how your mail is arranged — whether messages go out in your domain's name from the host, from Google, or from a newsletter tool as well.
One pitfall I ran into on my own setup: the DNS may not be where you look for it. Some hosting control panels offer and recommend these records while the domain's DNS is managed elsewhere entirely — and what you configure in the panel then stays silently ineffective. After setting up, always verify from outside, not on the provider's own screen.
Why tighten gradually
The DMARC policy has three levels: a monitoring state that lets everything through and only requests reports, a middle level that puts suspicious mail into spam, and the strictest one that refuses it outright. The temptation is to go straight to the strictest — don't, because if one legitimate sender was left out of the configuration, from then on your own mail stops arriving too.
On my own domain I did it this way: monitoring only for the first weeks, reading the incoming reports. The reports show which servers send in the domain's name and whether they pass the checks — once every legitimate sender has been correct there for weeks, the next level can follow. Tightening is then not a leap but the recording of an observed state.
How you know it works
The quickest test: send a message from your own domain to a Gmail address, and on the received mail ask to show original. At the top of the header sit the three verdicts — the state you want is PASS on all three. The same requirements appear in Google's sender guidelines; the details of the standard are on the DMARC.org site.
An honest limit to close with: this protection covers your own domain. It stops someone sending forged mail from exactly your domain. It doesn't protect against lookalike domains — where the fraudster registers their own with a one-letter difference. That takes an attentive recipient and a verifiable, consistent online presence. Together the two cover the ground.
Questions on this topic
Do I need this for mail sent from my Gmail address?
No — authenticating gmail.com is Google's job, and it is in order. These three records are needed when you send from your own domain: behind info@yourcompany.com stand your DNS settings, and while they are empty the receiving system has no basis for trusting the message.
Is setting it up once enough?
For the basics, yes: once configured, the records work by themselves. One case needs attention — when a new service starts sending in your name, a newsletter tool or an invoicing system, it has to be added to SPF and given DKIM, or it is precisely your legitimate mail that fails the check.
What is a DMARC report, and who reads it?
Receiving systems, including the large mail providers, periodically send a summary of what they saw sent in your domain's name and whether it passed the checks. It shows both when a legitimate sender was left out of the configuration and when somebody is forging your domain. The format is machine-readable, but the substance can be read out — and it is worth watching for a few weeks before tightening.
Can a wrong configuration do harm?
Yes — this is the one point where care is needed. If you tighten the policy to rejection while a legitimate sender is missing from the configuration, your own mail is what gets blocked. That is why the process goes gradually: monitoring and reports first, tightening only once every legitimate sender appears correct in the reports.
For reading the reports themselves there is a small open-source tool: dmarc-report-reader — it reads a folder of aggregate reports and shows which senders would break under a stricter policy.
If you don't know where your domain stands, send me an e-mail with the domain name. I'll look at the records — they are visible from outside — and write back what I found and what's missing. Short, one-off work, not a monthly commitment.
kristof@kristofkarner.com