Email deliverability and reputation: why your mail stops arriving

A bounced email is a good day. Something comes back, you read it, you fix it.

The failure that costs you money is the silent one. Your message is accepted without complaint, then filed into spam or dropped on the floor. Nothing bounces. The quotation, the invoice, the reply to a new enquiry: all sent, none read. You find out months later, if you ever find out at all, and usually because someone mentions it offhand at a meeting.

Nobody calls to tell you their spam filter ate your proposal.

The records live somewhere you are not looking

Your mail provider handles sending. Whether the other end accepts it is decided by signals published in your domain’s DNS, which is somewhere else entirely, usually managed by a different party, often one you stopped working with in 2020.

This trips up more businesses than anything else I deal with. You can have a perfectly good mail provider, a well-configured mailbox, a clean sending history, and mail that still does not land, because the things vouching for you are attached to your domain rather than to your mailbox.

Four records, briefly

MX says where your mail should be delivered. Everyone knows this one, and it is rarely the problem, because when MX breaks you find out within the hour and so does everyone else.

SPF publishes which servers are allowed to send as you. Think of it as a list pinned to the door: these ones are mine, be suspicious of anyone else. SPF has a hard ceiling of ten DNS lookups, which sounds generous until you count what you actually use. Mail provider, CRM, invoicing tool, newsletter platform, the booking system someone added last year. Cross the line and SPF does not degrade politely, it simply stops working.

DKIM signs each message cryptographically, so the receiver can confirm it came from you and arrived unaltered. Unlike SPF, that signature survives being forwarded, which is why you want both rather than either.

DMARC ties the other two to the address your recipient actually sees, and tells receivers what to do when checks fail: watch, quarantine, or reject. It also asks them to send you reports, which remain the only practical way to discover who else is out there sending mail with your name on it.

That last point is worth sitting with. Without DMARC, SPF and DKIM are protecting a domain buried in the message headers, not the one your customer reads. Which is a bit like checking the ID of the courier and not the parcel.

Reputation follows the name, and the name is permanent

Receiving systems keep score. That score used to attach mostly to the sending server’s IP address, which meant your reputation was largely your provider’s problem. Not anymore. Domain reputation now carries real weight, and unlike an IP address, your domain is yours forever.

Which means the damage travels with you. Switching mail providers does not wipe the slate. If your domain has been used to send spam, whether by you, by a compromised mailbox, or by someone forging your address precisely because you never published a DMARC policy, that history sticks to the name.

The bar has also moved. In 2024 Google and Yahoo started requiring authentication from bulk senders, and other major providers have tightened up since. A configuration that coasted along unnoticed for a decade suddenly started failing, and a lot of businesses found out the hard way.

Where it actually breaks

Someone connects a new tool. A CRM, an invoicing system, a marketing platform, and it starts sending on your behalf. Nobody updates SPF, nobody adds the DKIM selector. Those messages now fail authentication and nobody notices, because the person who set up the tool was measuring whether it sent, not whether it arrived.

SPF quietly runs out of lookups. Each new service nudges the count up. One afternoon it crosses ten and every check begins failing, with no error message anywhere a human would encounter it.

DMARC gets published as p=none and then forgotten. Monitoring mode is the correct place to start, and it protects nothing at all. I regularly find domains that have been sitting at p=none for four or five years, faithfully generating reports into a mailbox nobody has opened.

A migration leaves debris. The old provider’s SPF entries and DKIM selectors are still in DNS a year later, sitting alongside the new ones, because removing things feels riskier than leaving them.

And the reports go unread, which is entirely understandable. They arrive as XML. They are unreadable without tooling. The address they were pointed at often belongs to someone who has left.

”Our email works fine” is not evidence

This is the part that keeps the problem alive.

Mail to people you already correspond with will usually keep arriving even with badly broken authentication, because you have history with those recipients and the receiving system knows it. What fails is mail to people who have never heard from you before. New prospects. New customers. Anyone you most want to reach.

So the symptom is not complaints. The symptom is an absence, and absence is invisible. An enquiry that gets no reply looks exactly like a customer who changed their mind.

What we do about it

Securlogic does not host your email. Your mailboxes stay exactly where they are, with whoever you already use, and we have no interest in changing that.

What we look after is the layer underneath: keeping SPF accurate and inside its limits, making sure DKIM signs properly for every service that sends as you, and moving DMARC from monitoring to enforcement deliberately, once the reports show it is safe rather than because it seemed like a good idea. We read those reports so nobody at your end has to learn to.

If you do not know what your domain currently publishes, that is worth finding out before it becomes the reason somebody never replied.