If your invoices land in customers' junk folders, or your newsletter reaches half the list it used to, the cause is almost always email authentication rather than content.

Three DNS records decide whether receiving servers trust mail claiming to come from your domain. Here is what each does, in order, and how to roll them out without blocking yourself.

The problem they solve

Email was designed without any way to verify who sent a message. Anybody can put your domain in the From field, which is why invoice fraud and impersonation are as common as they are.

SPF, DKIM and DMARC are the layers added afterwards to fix that. Since Google and Microsoft tightened their requirements for bulk senders, they are no longer optional refinements — mail that fails them is filtered aggressively.

SPF: which servers may send for you

SPF is a DNS record listing the servers permitted to send mail for your domain. A receiving server checks whether the message came from one of them.

Three rules that account for most SPF failures:

One record only. A domain must have exactly one SPF record. Two records is a permanent error and everything fails. When adding a sender, edit the existing record rather than creating another.

Ten lookups maximum. Each include statement costs a DNS lookup and some cost several internally. Exceed ten and the check fails permanently. Businesses using Microsoft 365 plus a marketing platform plus an accounting system plus a CRM hit this regularly.

List everything that sends as you. This is the step that gets missed. Not just your mail platform — the website contact form, the invoicing system, the CRM, the booking platform, the alarm monitoring. Each one that is absent will start failing.

DKIM: a signature on each message

DKIM adds a cryptographic signature to every outgoing message. The public key is published in DNS and the receiving server uses it to verify that the message genuinely came from your domain and was not altered on the way.

In Microsoft 365, DKIM is a two-step job: publish two CNAME records for your domain, then enable signing in the admin centre. Both steps are needed, and enabling without publishing the records fails.

Every other system that sends mail as you needs its own DKIM setup. Most reputable platforms document this clearly.

DMARC: what to do when checks fail

DMARC does two things. It tells receiving servers what to do with mail that fails SPF and DKIM, and it asks them to send you reports about what they saw.

Three policy levels:

  • p=none — do nothing differently, just report. The monitoring stage.
  • p=quarantine — send failing mail to junk.
  • p=reject — refuse it entirely.

Reject is the destination, because it is the only policy that actually prevents somebody spoofing your domain. Getting there safely is the whole discipline.

Almost every business that has blocked its own invoices did so by publishing p=reject on day one. The reports exist precisely so that you do not have to guess.

The safe rollout order

Week 1: inventory and SPF

List every system that sends mail using your domain. Go and check rather than relying on memory — look at the website, the finance system, the CRM, the marketing platform, any monitoring.

Build one SPF record covering all of them. Count your DNS lookups. If you are near ten, use SPF flattening or consolidate senders.

Week 2: DKIM

Enable it in Microsoft 365, then work through each other sender in turn. This is unglamorous and it is the part that most improves deliverability.

Weeks 3 to 6: DMARC at p=none

Publish DMARC with p=none and a reporting address. Then actually read the reports, which arrive as XML and are close to unreadable raw — use a reporting service, most of which have a free tier for a single domain.

You are looking for legitimate senders that are failing. There will be some, and they will be systems nobody remembered.

Week 7: quarantine

Once the reports show only genuine failures, move to p=quarantine. Watch for a fortnight.

Week 9: reject

Move to p=reject. Keep reading the reports monthly, because new senders get added over time and each one needs including.

The parts businesses miss

Subdomains. A domain with no mail sending should still publish an SPF record rejecting everything and a DMARC policy, or it can be used to impersonate you.

Your other domains. The old trading name, the redirect domain, the one bought for a campaign. Each is a spoofing opportunity if unprotected.

Forwarding. Automatic forwarding breaks SPF, because the forwarding server is not on your list. This is a known limitation and is why DKIM matters — it survives forwarding where SPF does not.

A migration. Changing mail provider means changing all three records. It is a common cause of a sudden deliverability collapse a week after a move, which is why it appears in the migration checklist.

Why it is worth the effort

Two returns. Your legitimate mail is delivered, which matters most for invoices and quotes. And nobody can convincingly send an invoice pretending to be you, which is the fraud most likely to cost one of your customers money and your business a relationship.

If you would rather this was done correctly first time, our security solutions team configures email authentication for UK businesses and monitors the reports afterwards. Ask us to check your domain — it takes a few minutes to tell you where you stand.