The three DNS records that decide whether your email arrives

Two problems that look unrelated have the same cause.

Problem one: your quotes and invoices keep landing in customers’ spam folders, and you have started apologising for it on phone calls.

Problem two: anyone in the world can send an email that says it’s from accounts@yourcompany.com, and nothing stops them. This is how supplier-invoice fraud works — a convincing email, apparently from you, with different bank details.

Both come down to three DNS records that most small business domains either don’t have or have set up wrongly.

SPF — who is allowed to send as you

SPF is a list of the servers permitted to send email using your domain. It’s one TXT record:

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

That says: Google Workspace may send as us; treat anything else as suspicious.

The mistakes we see constantly:

• Two SPF records on one domain. This is invalid, and the correct behaviour for the receiving server is to fail the check entirely. If you add Zoho and later add Google without merging, you have made things worse than having nothing. There must be exactly one.
• Forgetting the other senders. Your accounting software, your CRM, your website’s contact form and your email marketing tool all send mail claiming to be you. Each needs including, or its mail gets marked.
• Ending with +all, which means “anyone may send as us” and defeats the purpose.

DKIM — proof the message wasn’t tampered with

DKIM adds a cryptographic signature to every message you send, and publishes the matching public key in DNS. The receiving server verifies the signature and knows both that the mail genuinely came from your provider and that nobody altered it in transit.

You don’t hand-craft this one. Your email provider generates the key and gives you a record to publish. The work is turning it on and confirming it’s actually signing — plenty of domains have the DNS record published and signing switched off in the admin console.

DMARC — what to do when the checks fail

SPF and DKIM detect forgery. DMARC decides what happens next, and it also gets you reports.

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

p=none means “check, report, but deliver anyway.” That’s where you start — it’s diagnostic, it changes nothing about delivery, and after a couple of weeks the reports tell you every system sending mail as your domain. Almost always there are one or two you had forgotten.

Once the legitimate senders are all passing, you tighten it:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com

then eventually p=reject, which is the point where forged mail claiming to be from your company stops being delivered to anyone, anywhere.

Do not start at p=reject. You will silently block your own invoices, and you’ll find out from an angry customer rather than from a report.

Doing it in the right order

1. Inventory every system that sends email as your domain. This is the step people skip, and it’s the one that determines whether the rest works.
2. Publish one correct SPF record covering all of them.
3. Enable DKIM at your provider and verify signing is actually on.
4. Publish DMARC at p=none and read the reports for two weeks.
5. Move to p=quarantine, then p=reject.

The whole thing is an afternoon of work plus a two-week observation window. It costs nothing but the time, it measurably improves whether your mail reaches people, and it closes off one of the cheapest frauds anyone can run against your business.

This is included as standard when we set up business email — see Office IT setup.