Why do my business emails keep going to spam? (UK, 2026)

You send an invoice, a quote, or a reply to a new enquiry, and it never arrives. The customer did not ignore you. Your message quietly dropped into their spam folder, or was rejected before it ever reached them. For a small business, that is lost work, missed replies, and slowly eroded trust, because the customer assumes you did not bother, when in fact you did.

The good news is that this is one of the most fixable problems in all of small-business technology. Email deliverability is not luck and it is not a black art. It comes down to whether the receiving server can prove that a message really came from you. When it cannot, it does the safe thing and treats you as suspicious. When it can, your mail is trusted and it lands where it should. This guide explains, in plain English, why business email goes to spam and how three DNS records put it right.

What actually decides whether your email lands

Every time you send an email, the receiving server (Gmail, Outlook, a customer’s company mail system) has to make a quick judgement: is this real, and is it safe? It has no way to phone you and check. So it looks for proof built into the message and published in your domain’s DNS settings.

If that proof is missing or does not add up, the receiver has a choice. It can reject the message outright, or it can deliver it to the junk folder to be safe. When a message cannot be verified, a cautious receiver does the safe thing and files it under junk, and there is nothing you can do from the outside to talk it back out. The customer never sees it, and you never know it failed.

So the whole game is: give the receiving server the proof it is looking for. That proof has three parts.

Why it goes wrong in the first place

Before the fixes, it helps to know the common causes. Almost every case of business mail landing in spam comes down to one of these.

• Missing or misconfigured authentication. The three records below (SPF, DKIM, DMARC) are absent, incomplete, or set up incorrectly, so the receiver has nothing to verify against.
• Sending from a free or mismatched domain. Business mail from yourname@gmail.com cannot be tied to your own brand, and looks weaker for it. Worse is a mismatch, where the visible from-address is your domain but the server actually sending the message is not authorised to send for it. That mismatch is exactly what authentication is built to catch.
• Poor sender reputation. Mail servers build up a reputation over time based on how their mail behaves. If your domain or sending service has previously sent spam, been compromised, or blasted a large cold list, that history follows you and depresses deliverability until it recovers.

The first two are configuration, and they are fixable in an afternoon by someone who knows the records. The third is behaviour over time, but good authentication is the foundation that lets a clean reputation build in the first place.

SPF: who is allowed to send for you

SPF stands for Sender Policy Framework. It is a single DNS TXT record on your domain that lists which mail servers are allowed to send email on your behalf. Your own mailbox provider, your newsletter tool, your booking system, anything that legitimately sends as your domain gets named in it.

When a message arrives, the receiving server looks up your SPF record and checks whether the server that actually sent the message is on the approved list. If it is, that check passes. If the message came from a server you never authorised, the receiver can flag or reject it, because as far as SPF is concerned, that is not you.

SPF, on its own, answers one question: is this sending server allowed to send for this domain? It does not check the contents of the message, and it has a known weakness when mail is forwarded. That is why it is never the whole answer, only the first of three parts.

DKIM: proof the message was not tampered with

DKIM stands for DomainKeys Identified Mail. Where SPF checks the server, DKIM checks the message itself.

When your mail server sends a message, it adds a cryptographic signature to it, calculated from the message’s contents using a private key that only your setup holds. Alongside that, a matching public key is published in your domain’s DNS. The receiving server reads the signature, fetches your public key from DNS, and checks that the two match.

If they match, two things are proven at once: the message genuinely came from your domain, and it was not altered in transit between you and the recipient. If a single character had been changed along the way, the signature would no longer verify, and the check would fail. DKIM is the part that gives a message its cryptographic seal of authenticity.

DMARC: the policy that ties it all together

SPF and DKIM each do a useful job, but on their own they leave a gap. DMARC (Domain-based Message Authentication, Reporting and Conformance) closes it. DMARC is a policy you publish in DNS that sits on top of SPF and DKIM, and it does three things.

It requires alignment. This is the key idea, and the one most setups get wrong. It is not enough for SPF or DKIM to simply pass; DMARC requires that the domain they pass for actually matches the domain in the visible from-address the customer sees. A spammer can pass SPF for their own domain all day, but they cannot make it align with yours. Alignment is what makes the check meaningful. SPF answers who is allowed to send, DKIM answers whether the message arrived intact, and DMARC decides what to do when the answer is no.

It sets a policy for failures. Your DMARC record tells receiving servers what to do with a message that fails alignment. There are three settings: none (take no action, just watch and report), quarantine (send it to spam), and reject (refuse it outright). Most setups begin at none to observe safely, then move up to quarantine and eventually reject once the legitimate mail is confirmed to be passing.

It sends you reports. This is the part people overlook, and it is genuinely valuable. DMARC asks receivers to send aggregate reports back to an address you choose, showing every source sending mail as your domain and whether it passed or failed. That is how you discover the forgotten newsletter tool, or the fact that someone is trying to impersonate you, before you tighten the policy. The reporting is what turns email authentication from guesswork into something you can actually see.

Encryption in transit: a different layer

Authentication proves who sent a message. A separate layer protects the message while it travels across the internet, and it is worth a brief word because the two are easy to confuse.

MTA-STS (Mail Transfer Agent Strict Transport Security) is a policy you publish that tells other mail servers they must use an encrypted TLS connection when delivering mail to your servers, and refuse to fall back to an unencrypted one. TLS-RPT (TLS Reporting) is its companion: it asks sending servers to send you reports when a secure connection to your mail could not be established, so you find out about delivery problems on the encrypted channel.

Together these protect your mail on the wire, so a message cannot be quietly downgraded to an unencrypted connection and read or altered in transit. This is distinct from SPF, DKIM and DMARC, which prove the message is authentic. One layer proves who you are; the other keeps the delivery private. A properly set-up domain has both.

How to check where you stand

You do not have to guess. There are two straightforward ways to see the state of your own email setup.

• Send a test to a checker. Free tools such as mail-tester.com give you an address to email; you send a normal message to it, and it reads the headers and DNS records and returns a plain report on whether SPF, DKIM and DMARC are present and passing, along with other deliverability signals. It is the quickest way to get a real answer.
• Look up your own records. A public DMARC or SPF lookup tool lets you type in your domain and see exactly which authentication records are published and how they are configured. If SPF, DKIM or DMARC is missing, or DMARC is sitting at none with failures showing, that is your to-do list.

We would rather point you at the mechanism than promise a specific score, because the right numbers depend on your setup. What matters is that all three records are present, passing, and aligned.

Where this becomes our job

Getting email authentication right is fiddly. The records have their own syntax, a small mistake fails silently, and there is no error message when a customer’s message lands in junk, only the quiet cost of the reply that never comes. It is exactly the kind of technical plumbing that a managed service should handle so you never have to think about it.

Setting up business email properly, with SPF, DKIM and DMARC aligned, is a core part of what we do. We wire it on EU-hosted, privacy-first infrastructure: DNS managed on Cloudflare, business email set up on Proton where it makes sense, and the authentication and encryption layers configured correctly so your mail is trusted and stays close to home. You can read how we approach the whole setup on our domains and email service page, and how deliverability sits inside the wider managed offering on our managed website service page.

If you want to go deeper on the surrounding subjects, our guide to small-business security basics covers where email fits in the wider picture, the UK/EU sovereign stack explains the EU-hosted infrastructure this runs on, and our best privacy and security tools roundup covers the wider toolkit. And if you are still weighing up whether the whole thing is worth it, do you still need a website in 2026 makes the case.

The fastest way to find out where your email stands today is to have us look. Start with a free Site Score, and we will tell you whether your SPF, DKIM and DMARC are set up properly, and put them right if they are not.