Most small businesses never think about email authentication until something goes wrong. Quotes start landing in customers' spam folders, or a supplier gets an invoice "from you" with someone else's bank details on it. Both problems usually trace back to the same three DNS records: SPF, DKIM and DMARC.
They're not hard to set up, but they're easy to set up half-way, and half-way is where most small business domains sit. In our September 2026 audit of 325 South West small business websites, 24% had no SPF record or a broken one (more than one record), and 50% had no DMARC record at all. Only 17% (54 of 325) had a DMARC policy that told inboxes to quarantine or reject fake email sent in their name.
Here's what each record does and how they work together.
The short version
| Record | What it answers | Where it lives |
|---|---|---|
| SPF | "Is this server allowed to send email for this domain?" | A TXT record on your domain |
| DKIM | "Was this message really sent by the domain, and unchanged since?" | A TXT record at a selector, like google._domainkey |
| DMARC | "If a message fails, what should the receiver do, and who should it tell?" | A TXT record at _dmarc |
SPF and DKIM are the checks. DMARC is the policy that makes the checks count. Without DMARC, a receiving server that sees a failed SPF check has to guess what you'd want, and many will deliver the message anyway.
SPF: the list of who can send
SPF (Sender Policy Framework) is a single TXT record that lists the services allowed to send email using your domain. A typical one for a business on Google Workspace looks like this:
v=spf1 include:_spf.google.com ~all
That says: Google's mail servers may send for this domain, and anything else should be treated with suspicion. If you also send from a newsletter tool, a booking system or an invoicing app, each of those needs adding with its own include:.
The common mistakes:
- No SPF record at all. Receivers can't tell your real email from a forgery.
- Two SPF records. You're only allowed one. Two is an error, and receivers treat SPF as failed. This often happens when a new tool's setup guide says "add this SPF record" and someone adds it alongside the existing one instead of merging the two.
- Too many lookups. Each
include:costs DNS lookups, and the limit is 10. Go over it and SPF fails for every message. - Ending in
+all. That authorises every server on the internet, which makes the record pointless.
Our SPF checker looks for every one of these, counts your lookups, and tells you in plain English what to change.
DKIM: a signature on every message
DKIM (DomainKeys Identified Mail) adds a digital signature to each email you send. Your email provider holds a private key and signs outgoing messages with it. You publish the matching public key in DNS, and receivers use it to check the signature.
Two things make DKIM useful where SPF alone isn't:
- It survives forwarding. When a message is forwarded, it arrives from a different server, so SPF often fails. The DKIM signature travels with the message, so it still passes.
- It proves the message wasn't changed. If anyone alters the signed parts of the email in transit, the signature no longer matches.
You don't write a DKIM record by hand. Your email provider generates it. In Google Workspace it's in the Admin console under Gmail's "Authenticate email" setting; in Microsoft 365 it's in the Defender portal's email authentication settings. You copy the record they give you into your DNS, then switch signing on.
One honest limitation: DKIM records sit at a "selector" name that only your provider knows (Google's default is google, so the record lives at google._domainkey.yourdomain.co.uk). That means no outside tool can reliably find your DKIM record just from your domain name, ours included. The reliable check is to send yourself a test email and look at the message headers for dkim=pass.
DMARC: the policy that makes the checks count
DMARC (Domain-based Message Authentication, Reporting and Conformance) does two jobs.
First, it tells receivers what to do with a message that fails. A message passes DMARC if it passes SPF or DKIM, and the domain that passed matches the "From" address your reader sees. That matching step is called alignment, and it's what stops a scammer passing SPF on their own domain while putting yours in the From line.
Second, it asks receivers to send you reports, so you can see every server sending email in your name.
A DMARC record lives at _dmarc.yourdomain.co.uk and looks like this:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.co.uk
The p= tag is the policy, and there are three levels:
p=none: monitoring only. Failed messages are still delivered, but you get reports.p=quarantine: failed messages go to spam.p=reject: failed messages are refused outright.
p=none is the right place to start, but it gives no protection on its own. It's a listening phase, not the finish line. The rua= address is what makes it useful: without it you get no reports, and you'll never have the evidence you need to tighten the policy safely.
Our DMARC checker reads your record, tells you which policy you're on, and flags a missing reporting address.
Why this matters more than it used to
Since February 2024, Gmail and Yahoo require anyone sending in bulk (around 5,000 or more messages a day to their users) to have SPF, DKIM and a DMARC record, and expect every sender to have at least SPF or DKIM. Microsoft introduced similar rules for high-volume senders to Outlook.com addresses in 2025.
Most small businesses send nowhere near those volumes, but that's not the point. The big inbox providers now treat authentication as the baseline, and unauthenticated mail is more likely to be filtered. If customers say they "never got" your quote, this is one of the first things to check.
Then there's spoofing. Without DMARC at quarantine or reject, nothing stops someone sending an email that says it's from accounts@yourdomain.co.uk. Invoice fraud aimed at your customers and suppliers is the most common form, and it lands on your reputation even though you didn't send it.
The order to set them up
- Make a list of everything that sends email as you. Your mailbox provider, plus website contact forms, newsletter tools, booking systems, invoicing and accounting software, and your CRM. This is the step people skip, and it's the one that causes problems later.
- Publish one SPF record that includes every service on that list, ending in
~all. Check it with the SPF checker. - Turn on DKIM in your email provider and in any other sending tool that supports it.
- Publish DMARC at
p=nonewith arua=reporting address. - Read the reports for a few weeks. They'll show you any sender you forgot in step 1. Add each one to SPF or set up DKIM for it.
- Move to
p=quarantine, thenp=reject, once the reports show your real email passing consistently.
Steps 2 to 4 are a short job for whoever manages your domain's DNS, usually your web developer, IT provider or domain registrar. Steps 5 and 6 take a few weeks of patience, not technical skill.
Check where you stand
You can check your SPF and DMARC records in a few seconds, free and without signing up: the SPF checker and the DMARC checker both read your live DNS and explain anything that needs fixing. If you're on Google Workspace, our guide to setting up an SPF record for Google Workspace walks through the exact record to add.
Email authentication sits alongside the other trust signals covered in our website security audit guide. It's all set up outside your website, but it's part of how customers decide whether to trust you.