← Back to home
Blog.
Field notes on diagnosing deliverability. What actually causes placement problems, and why the obvious fix is usually the wrong one.
What actually decides whether mail reaches the inbox, and the six checks I run, in order, to find which cause is yours. The method behind everything else on this blog.
Klaviyo says delivered. Gmail and Outlook decide where it lands. The order I rule causes out in a Klaviyo account, cheapest check first.
Which domain to add, what each of Google's six dashboards shows, and the one worth checking first.
Every guide gives you a checklist. None of them explain how to tell which item on it is actually your problem.
Most spam placement traces back to one of six causes. They all look identical from the outside.
A generic warmup schedule can be worse than no warmup at all. Here's why, and what to do instead.
Multiple SPF records, ~all vs -all, and the lookup limit that quietly kills senders who think they're fine.
How a neighbor on the same IP block can tank your placement, and how to tell if it's happening to you.
Most advice hands you twelve things to fix and never says which one is yours. This is the sequence I actually run instead.
Google publishes a hard threshold you can measure yourself. What it doesn't publish is how the pieces interact.
Most of the damage from p=reject hits senders who set it correctly and had no idea what it would do to forwarded mail.
Warmup works. A generic day-count schedule that ignores your list, volume and mailbox providers doesn't.
Temporary versus permanent is the textbook answer. It hides the part worth knowing: a hard bounce doesn't reliably mean the address is bad.
The receiving server accepted your message and refused it for a policy reason. How I tell an authentication gap from a reputation problem.
The receiving server found no mailbox at that address. How I tell a genuinely dead address from a typo or a full mailbox.
A 421 is the server closing the connection, not rejecting your message. How to tell a capacity blip from a reputation throttle.
UCEPROTECT runs three separate lists. Which one is blocking you decides who can actually fix it.
The DBL lists domains by how they were used in mail traffic, not by who owns them.
GoDaddy hosts your DNS, not your email. Exactly where the DKIM record goes, and why most failures aren't GoDaddy's fault.
Generated in the Admin console, not your DNS panel. The exact steps, and why it's the first thing worth checking.
One value, repeated. The exact record, and what a correct MX record doesn't fix on its own.
Resolves the one thing SPF and DKIM can't decide alone: what happens after an authentication check fails.
Confirms a message wasn't altered and that a domain authorized it. It doesn't check the address you actually see.
Authenticates the envelope sender, not the visible From address you see in your inbox. What that distinction means.
Displays your logo in a recipient's inbox, gated on DMARC enforcement you may already have. What actually unlocks it.
A TXT record like any other, but only one may exist per domain. Where it goes, and the most common way it breaks.
One line, published at your DNS host, not the Admin console. The exact value, and where it actually goes.
Microsoft 365 DKIM uses two CNAME records, not one, so it can rotate keys automatically. Missing the second is the common gap.
Most BRBL listings trace to bad data or a dynamic IP's history, not malicious sending. What actually causes each.
Lists IP addresses, not domains. What actually gets an IP listed, and why it's a different problem than a DBL listing.
A DSN failure is the receiving system's own bounce report. How to read it as a sender, not just a stuck message.
Means resending will not help, not that the problem is unfixable. Here is the difference, and how I read the code underneath it.
The same policy refusal as 550 5.7.1, on a different base code. What the 554 specifically signals, and what doesn't change.