How to check SPF, DKIM and DMARC for a business, and explain what you found

Email authentication is the finding business owners feel most and understand least. They do not know what DMARC is. They do know that their quotes sometimes go to spam, that a customer once received a fake invoice "from" them, or that a new supplier never replied. Three DNS records explain most of it, and checking them takes minutes.

Why this matters more than it used to

In February 2024 Google and Yahoo began enforcing requirements for bulk senders: authenticate with SPF and DKIM, publish a DMARC record, and keep spam complaints low. Microsoft followed with similar rules for high-volume senders to Outlook.com in 2025. Small businesses sending a few emails a day are not the target of those rules, but mailbox providers increasingly treat unauthenticated mail with suspicion regardless of volume. Missing records are no longer a theoretical risk.

SPF: who may send as this domain

SPF (Sender Policy Framework) is a TXT record on the domain listing the servers allowed to send mail for it. A typical record looks like:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

What to check:

• It exists, and there is only one. Two SPF records on the same domain is an error, and receivers may treat it as no SPF at all.

• It covers every real sender. The mail provider, plus the website's contact form, the invoicing tool, the newsletter service and the booking system. A forgotten sender is why invoices land in spam.

• It stays under ten DNS lookups. Each include: costs at least one. Over ten and SPF fails outright.

• It ends with ~all or -all. ~all (softfail) and -all (fail) tell receivers what to do with everyone else. +all allows anyone, which defeats the point, and a record with no all at all is weak.

DKIM: is the message genuinely signed

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message, verified against a public key published in DNS at selector._domainkey.example.com. The selector depends on the provider: Google Workspace commonly uses google, Microsoft 365 uses selector1 and selector2.

What to check:

• A key is published for the provider the business actually uses. The MX records tell you which provider that is.

• Any other sending service (newsletters, invoicing) has its own DKIM set up, rather than sending unsigned.

You cannot list every DKIM selector on a domain from outside, so an external check probes the common ones. If none is found, say "no DKIM key found at the common selectors" rather than "DKIM is missing". That is the honest wording, and the business's IT provider will know the difference.

DMARC: what to do when the checks fail

DMARC ties SPF and DKIM to the visible "From" address and tells receivers what to do when a message fails. It lives at _dmarc.example.com:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

What to check:

• A record exists. Without one, anyone can send mail that appears to come from the domain, and receivers have no instruction from the owner.

• The policy. p=none monitors only. p=quarantine sends failing mail to spam. p=reject blocks it. none is the right place to start and the wrong place to stay.

• Reports go somewhere. The rua address receives daily aggregate reports showing who is sending as the domain. Without it, the owner has no way to find the forgotten senders before tightening the policy.

BIMI and blocklists

Two further checks are worth running. BIMI lets a brand's logo appear beside its mail in supporting inboxes, but only once DMARC is at enforcement; it is a nice-to-have, not a fix. Mail blocklists matter more: if the domain or the mail server's IP appears on a major blocklist, mail will be rejected no matter how good the records are.

How to explain it to the owner

Skip the acronyms on page one. Describe the consequence:

Anyone can currently send email that looks like it comes from yourcompany.co.uk, and your own emails are more likely to be treated as spam, because your domain does not publish the record that tells inbox providers how to check.

Then the fix, in plain terms: "Adding one DNS record fixes the first part today. We start in monitoring mode, so nothing you send is blocked, then tighten it over a few weeks once we have confirmed every service that sends on your behalf."

That second sentence matters. The owner's fear is that fixing email will break email, and a staged rollout answers it.

A safe rollout

1. Fix SPF so it lists every real sender and ends in ~all.

2. Confirm DKIM is set up for the main provider and any other sending service.

3. Publish DMARC at p=none with a reporting address.

4. Read the aggregate reports for two to four weeks and fix any legitimate sender that fails.

5. Move to p=quarantine, then p=reject once the reports are clean.

Check it now

Our free email deliverability checker reads a domain's SPF, DKIM and DMARC records and reports what they say. In a full SiteAssay audit these checks feed the security score and an A to F email security grade, and every finding comes with a paste-ready record for the business's actual mail provider. See the features page for how fixes are delivered, and the website audit checklist for the rest of an audit.