Debug deliverability in layers, hardest evidence first: authentication (SPF, DKIM, DMARC), then domain reputation, then volume and ramp, then list quality, then content. Almost everyone starts at content because it is the only layer they can see, and content is the layer that matters least. If authentication is broken, nothing else you change will help.
Deliverability is debugged badly for a structural reason: the only layer most people can see is the copy, so the copy is what they change. The layers that actually decide the outcome are invisible unless you go and look at them, and they sit underneath.
So work it the way you would work any other outage. Start at the layer that fails loudest and most unambiguously, confirm it is healthy, and only then move up. Here is the order.
Layer 1: authentication
This is binary, it takes about a minute to check, and a failure here makes everything above it irrelevant. Three records, on the sending domain:
SPF says which servers are allowed to send as your domain. DKIM signs each message so the receiver can verify it was not altered and did come from you. DMARC tells the receiver what to do when SPF or DKIM fails, and gives you a reporting address so you find out.
The check: send one message to a Gmail address you control, open it, and view the original. Gmail prints SPF, DKIM and DMARC with a PASS or FAIL next to each. Three passes and this layer is done. Anything else and you stop here.
The failure people hit most often is not a missing record but a second one. Two SPF records on a domain is not additive, it is a permanent error, and a permanent error is a fail. It happens whenever a second tool is added by someone who did not know the first one existed.
The DMARC policy is a decision, not a default
p=none monitors and asks receivers to do nothing. p=quarantine sends failures to spam. p=reject has them refused outright. Start at none, read the reports for a fortnight until you know what legitimately sends as you, then tighten. Going straight to reject usually blocks something you forgot you had, and the thing you forgot is often your invoicing.
Layer 2: reputation
Every mailbox provider keeps a score for your sending domain, and to a lesser degree your IP. It is earned over weeks, lost in days, and applied to everything that domain sends including messages to people who asked for them.
A brand-new domain does not start neutral. It starts unknown, and at volume unknown is treated very much like suspicious, because the cheapest thing a spammer can buy is a new domain.
This is the whole argument for separate sending domains. Not a trick: an isolation boundary. If cold volume damages the score on a name you send from, you want that name to be one whose reputation you can afford to lose, rather than the one your customers, your investors and your password resets go out on.
Layer 3: volume and ramp
The most common self-inflicted failure in cold email is sending real volume on day one from a domain with no history. There is no pattern to compare it to, and a spike from nothing is the exact shape of a compromised account.
The fix is a ramp: a handful of messages a day, climbing over about three weeks, with replies coming back. Replies matter — a conversation is a much stronger signal than a delivery. This is what warm-up means, and three weeks is not a superstition, it is roughly how long providers need to form a view.
| Symptom | Most likely layer | What to check first |
|---|---|---|
| Everything lands in spam from the first send | Authentication | SPF, DKIM, DMARC on the sending domain |
| Inbox for a week, then a cliff | Volume and ramp | Daily send rate against the age of the domain |
| Gmail fine, Outlook spam | Reputation | The two score differently; Outlook is stricter on new domains |
| Gradual decline over a month | List quality | Bounce rate and complaint rate, not the copy |
| Fine at 20 a day, spam at 200 | Volume and ramp | The ramp curve, and how many addresses each domain sends from |
| Only one recipient domain rejects | Their filter, not you | Whether that company runs an aggressive gateway |
Layer 4: list quality
A bad list damages reputation faster than bad writing ever will, because bounces and complaints are counted and prose is not.
Two numbers decide it. Bounce rate should sit in the low single digits; above about 5% you are telling providers you do not know who you are writing to, which is the defining behaviour of a list buyer. Complaint rate should stay under roughly one in a thousand, and this one is brutal because it is so small a number that a handful of annoyed recipients moves it.
Verification before sending is not optional at any volume worth the name. Neither is removing anyone who has not engaged across several sends, which feels wasteful and is not: continuing to write to people who never open is a reputation cost with no upside.
Layer 5: content, finally
Content does matter. It matters less than the four layers underneath it, and it is where almost everyone starts.
What actually registers: a message with one link performs better than one with five, because link count and link reputation both get scored. Images and tracking pixels add weight and add another domain whose reputation is not yours. Plain text, or something close to it, is not a stylistic preference here, it is a smaller surface area.
Spam-word lists are close to useless. Filters have been statistical for twenty years. A tool that flags 'free' and 'guarantee' is modelling something that stopped existing before most of your prospects started working.
The content problem that is real is relevance, and it is scored by humans rather than machines. A message that does not obviously apply to the person reading it gets deleted, and deletion without reading is weak negative signal at volume.
The order matters more than any individual fix
If you take one thing: the sequence is the method. Authentication, reputation, ramp, list, content. Rewriting a subject line while DMARC fails is debugging the interface while the database is down, and you can spend a fortnight there without ever touching the actual fault.
Nothing above is difficult. It is mostly checking things in a specific order and being willing to find out that the layer you like thinking about is not the broken one.
Where this fits with an agent
Every layer here is a decision someone has to make and then keep making — buying the sending domains, authenticating them, ramping for three weeks, watching bounce and complaint rates weekly, pruning the list. Operater's Sales agent does that work as part of sending: it buys and warms its own domains in your company's name, keeps the ramp, and stops sending from an address whose numbers go bad rather than continuing until the domain is spent.
That is the honest reason this post exists. Not because the checklist is secret, but because doing it every week, forever, is the part that does not happen when you also have a product to build.
Key takeaways
- Check authentication first. It is binary, it is machine-checkable in about a minute, and a failure there makes every other fix pointless.
- Reputation is per-domain and per-IP, earned over weeks and lost in days. A new domain with no history is not trusted, it is unknown, and unknown behaves like suspicious at volume.
- Volume ramp matters more than total volume. Sending 500 on day one from a fresh domain is the single most common self-inflicted wound.
- A bad list damages reputation faster than bad copy ever will, because bounces and spam complaints are scored and prose is not.
- Content is real but it is the last layer. Rewriting subject lines while DMARC fails is debugging the UI when the database is down.