Guide · Email security
SPF, DKIM and DMARC explained for a small business
Three short records in your domain settings decide whether your email reaches inboxes and whether someone can send fake email in your name. Here is what each one does, in the order to set them up.
Why it matters
Email has no built-in way to prove who sent a message. Anyone can write "From: you@yourcompany.com". SPF, DKIM and DMARC are the checks that let a receiving mail server decide whether a message really came from you. Without them, your genuine mail is more likely to land in spam, and criminals can send invoices or password requests that look like they came from your domain. Google and Yahoo have required these records from bulk senders since February 2024, and many other receivers expect them too.
SPF: who is allowed to send
SPF (Sender Policy Framework) is a list, published in your domain's DNS, of the services allowed to send mail as your domain: your mail provider, your newsletter tool, your invoicing system. A receiver looks up the list and checks the sending server against it.
A typical record for a company on Google Workspace that also uses one newsletter service looks like this
(a TXT record on example.com):
v=spf1 include:_spf.google.com include:newsletter-service.example -all
- One record only. Two SPF records on the same domain make receivers treat SPF as broken.
- The ending matters.
-allmeans "reject anything not listed".~allmeans "treat it as suspicious", which is fine while you are testing.+allallows everyone and cancels the protection. - Ten lookups at most. Each
include:can cost extra DNS lookups, and the standard allows ten in total. Past that, SPF fails.
DKIM: a signature on each message
DKIM (DomainKeys Identified Mail) adds a digital signature to every message you send. The matching public key is
published in your DNS under a name your mail provider gives you, called a selector, in the form
selector._domainkey.example.com. The receiver uses it to check that the message came from your provider and was
not altered on the way.
You do not create the signature yourself. In Google Workspace, Microsoft 365 and most email services you turn DKIM on in the admin settings and paste the record they give you into your DNS. Each service that sends mail for you needs its own DKIM setup.
DMARC: what to do when a check fails
DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the two together. It tells receivers what to do
with mail that fails SPF and DKIM checks that line up with the visible "From" address, and it asks them to send you reports.
It is a TXT record at _dmarc.example.com:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
p=none: watch only. Fake mail is still delivered, but you start receiving reports.p=quarantine: fake mail goes to spam.p=reject: fake mail is refused. This is the goal.
Order of work
- List every service that sends mail as your domain. Include the ones people forget: the website contact form, invoicing, the helpdesk, the newsletter tool.
- Publish SPF with that list, ending in
~allat first. - Turn on DKIM for each of those services.
- Publish DMARC with
p=noneand a reports address. Read the reports for a few weeks to find senders you missed. - Tighten to
quarantine, thenreject, and change SPF to-all.
Common mistakes
- Two SPF records, often after adding a new tool without editing the old record.
- Going straight to
p=rejectbefore every legitimate sender is listed, so real invoices bounce. - Setting DMARC to
p=noneand never moving on. - Forgetting a service that sends on your behalf.
- Assuming a domain you do not send mail from needs no protection. Criminals like those domains too; they can be set to
publish
v=spf1 -alland ap=rejectDMARC policy.
Check yours
Olodu's free 7-day systems audit checks your SPF, DKIM and DMARC records along with accounts, backups, certificates and cloud spend, and tells you in plain words what to change.