Email Deliverability: Why Your Business Mail Lands in Spam

A customer calls to ask why you never sent the quote. You did send it — it’s sitting right there in your sent folder, timestamped Tuesday. No bounce message came back. Nothing failed. It simply never arrived, or it arrived in a junk folder nobody checks.

This is one of the more frustrating problems a small business runs into, because it’s invisible from your side. Email that gets rejected outright produces a bounce you can see. Email that gets quietly filed as spam produces nothing at all.

The good news is that the rules deciding this are public, mechanical, and mostly fixable in an afternoon.

What the Receiving Server Is Actually Doing

When your mail arrives at the recipient’s provider, that server has to answer one question fast: is this message really from who it claims to be from?

It can’t take the message’s word for it. Anyone can type any name into a From field — that’s the whole basis of the phishing problem. So instead of trusting the message, the receiving server checks the internet’s public records for your domain, and asks three separate questions.

SPF: is this server allowed to send for this domain?

SPF is a short public record attached to your domain name that lists which mail servers are permitted to send email on your behalf. The receiving server looks up that list and checks whether the message came from one of them.

If your business sends mail from your own mail host, plus a website contact form, plus an invoicing system, all three need to be in that list. Miss one, and everything from that source becomes suspicious.

DKIM: has the message been tampered with?

DKIM adds an invisible cryptographic signature to each outgoing message. The receiving server verifies that signature against a public key published in your domain records. If it matches, the message genuinely came from your mail system and nothing altered it in transit.

DMARC: what should happen when the first two fail?

DMARC is your instruction to the world. It says: if a message claims to be from my domain but fails SPF and DKIM, here’s what I want you to do — ignore it, quarantine it, or reject it outright. It also lets you receive reports about who is sending mail using your domain name, which is how you find out someone is impersonating you.

Without DMARC, each receiving provider guesses. With it, you decide.

The Failure Mode Most Small Businesses Hit

Here’s the pattern we see most often, and it has nothing to do with the content of your emails.

Your ordinary person-to-person mail is fine — it goes out through your mail host, which is properly listed in SPF and signs with DKIM. But your automated mail is a different story. The invoice from your accounting software, the notification from your booking system, the reply from your website contact form — those are often sent by some other service on your behalf, from entirely different servers.

If those services aren’t in your SPF record and aren’t signing with your DKIM key, they look like impersonation, because technically that’s exactly what they resemble. So the personal mail arrives and the invoices don’t. The failure is selective, which is why it takes so long to notice.

The Other One: Shared Sending Reputation

There’s a second problem worth knowing about, because it’s the hardest to diagnose from your side.

Many bulk-sending and relay services send everyone’s mail from a shared pool of servers. Your reputation is therefore partly other people’s reputation. If another customer on that shared pool sends something abusive, the pool’s address can end up on a public blocklist — and strict receiving providers will then throttle or refuse mail from it, including yours.

You did nothing wrong, your records are correct, and your mail still gets deferred. We’ve hit this on our own infrastructure: alerts from internal systems started arriving late or not at all, and the cause turned out to be a shared relay address that had landed on a blocklist. The fix wasn’t to rewrite the messages — it was to stop sending through that shared pool and send directly through our own mail host instead.

If a service can’t tell you what address your mail leaves from, that’s worth asking about.

What to Check This Week

• Confirm all three records exist for your domain — SPF, DKIM and DMARC. Your mail host can tell you, and there are free public checkers that show what the rest of the world sees.
• List every system that sends mail as you. Mail host, website forms, invoicing, booking, CRM, newsletter tool. Each one needs to be authorised.
• Start DMARC in reporting mode. Don’t jump straight to rejecting — watch the reports first, confirm your legitimate senders pass, then tighten.
• Send a test to a different provider than your own. Mail to a colleague on the same host proves very little; it often never leaves the building.

The Takeaway

Email deliverability is not about wording, subject lines or attachments. It’s about whether your domain’s public records back up what your messages claim. Three records, set correctly and covering every system that sends on your behalf, resolve the large majority of “they never got it” problems.

If your invoices or quotes are going missing and you’d like someone to check the records properly, get in touch.