Email Deliverability Triage
"Our email is going to spam" is a symptom with at least four unrelated causes, and working them in the wrong order costs days. Authentication, reputation, the sending infrastructure and the message itself all produce the same complaint. This is the order that eliminates the most possibilities per check.
First: is it everyone, or one recipient domain?
Before touching any configuration, establish the scope. Mail failing to one recipient domain and arriving everywhere else is a reputation or policy issue with that provider, and your records are probably fine. Mail degrading across every destination at once points at authentication or a listing. Getting this wrong sends you rewriting SPF for a problem that lives entirely at one receiver.
Second: authentication, as a set
Check SPF, DKIM and DMARC together rather than in sequence, because the failures live in their interaction. The specific combinations worth looking for:
- SPF exceeding the ten-lookup limit — the record is valid and too expensive to evaluate, so authentication fails permanently and silently.
- Two SPF records, which invalidates both. Nothing warns you.
- A DKIM selector signing with a key whose public half was never published, which is the standard outcome of a platform migration.
- DMARC at enforcement while SPF omits a legitimate sending platform — you have instructed the world to discard some of your own mail.
That last one is the expensive case, and it is created by a single reasonable edit: someone tightens DMARC without auditing which senders are covered.
Third: reputation
Check your sending addresses and domain against blocklists. Listings often have nothing to do with your behaviour — a shared host's neighbour, an address recycled from a previous owner, a compromised account that sent a burst before anyone noticed. Delisting is usually quick once you know, so the cost here is almost entirely detection latency.
Check reverse DNS at the same time. Receiving servers routinely verify that a connecting address has a PTR record resolving back to the same address, and failing that check is a reliable way to be filtered. Because the reverse record lives with your hosting provider rather than with you, no change on your side correlates with it breaking.
Fourth: the sending path itself
Connect to your mail server as a sending server would. A host that is listening can still be failing to negotiate TLS after a package update, or advertising an authentication mechanism that does not work, or presenting a banner hostname that trips the receiver's checks. None of these bounce anything; they degrade delivery while the service reports itself healthy.
Then, and only then, the message
Content-based filtering is the last thing to investigate, not the first, because it is the hardest to reason about and the least likely to have changed suddenly. If authentication is clean, reputation is clear and the path negotiates properly, then content and sending patterns are what remain — but arriving here after eliminating the rest is a very different position from guessing at it on day one.
Why this needs to run continuously
Every record above is edited by people who do not consider themselves to be editing mail configuration: marketing adding a sending platform, a vendor's onboarding wizard, someone tidying DNS. Mail then degrades gradually rather than failing, so there is no event to react to. A scheduled check across the whole set is frequently the only thing that will notice before a customer mentions it in passing.
Tools used in this playbook
For the underlying concepts rather than this procedure, NetTests.NET covers the topic in more depth in its guide.