The day a client's emails started landing in spam without us touching a single line of code

A client who runs a small real estate agency messaged me on a Friday afternoon, the worst possible time, saying he hadn’t received a single lead from his contact form in two weeks. Nobody had touched the form. Nobody had touched the server. The only thing that had changed was the hosting provider, migrated three weeks earlier over pricing, and right there I already had a good guess where this was going.

If your emails are landing in spam without any visible change on your end, it’s almost always a domain authentication problem: when you move hosting or your mail server, the SPF, DKIM and DMARC records in your DNS keep pointing at the old provider, and Gmail or Outlook can no longer verify that the email is actually coming from who it claims to. The result isn’t a visible bounce, it’s worse: the email gets delivered, just straight into the recipient’s spam folder, so nobody notices anything is wrong until someone goes looking for it on purpose.

And that’s exactly what we found. The SPF record still listed the old hosting servers as authorized senders, and the new provider, which routed the contact form’s transactional email through its own infrastructure, wasn’t on that list at all. DKIM wasn’t configured at all: the cryptographic signature that’s supposed to travel with every email to prove it wasn’t tampered with along the way, just blank. With both of those failing at once, any half-decent spam filter was going to get suspicious, and Gmail specifically has gotten noticeably stricter about this over the past couple of years.

What we checked with dig and a cup of coffee

Poking around a client’s DNS always feels a bit uncomfortable, especially when the domain was bought eight years ago through a registrar he barely remembered having an account with. We ran dig TXT against the domain to see the real SPF record (not the one we assumed was there, the one that actually was), and compared it against the new hosting provider’s documentation. It was missing the right include: and still had one left over from an email marketing tool the client had tried a year and a half earlier and hadn’t used since. Thirteen minutes of work, once we’d spotted it. The slow part wasn’t fixing it, it was realizing the problem was there and not in the form’s code, which is what we checked first, because developers always suspect the software before the infrastructure.

DMARC, the part almost nobody configures properly

We added DKIM from the new hosting panel (most providers generate it for you, you just copy a TXT record) and left DMARC at p=none at first, not reject straight away. With p=none you only collect reports on which emails fail verification without blocking anything, and that let us confirm over a few days that no legitimate mail was getting caught before we tightened the policy. Jumping straight to reject without checking first is the fastest way to make a client’s own legitimate email, sent from his phone through some other app, start bouncing for no obvious reason.

The contact form notification was back in the inbox the day after we fixed the SPF record, but the domain took almost two weeks to fully recover its reputation with Gmail, something nobody controls except Google and that no amount of configuration speeds up. Since then, whenever we migrate a client’s hosting or email, the first question isn’t about design or price: it’s who’s going to be sending the emails and whether that sender is declared where it needs to be. What’s odd is that it took us this many years of production incidents to make it the first step of any migration, instead of the last.