A sender we worked with had exactly that setup: SPF/DKIM/DMARC all passing, no blocklist hits, a domain with real sending history. So when a four-email onboarding sequence was still landing in Spam nearly half the time, domain reputation wasn't the answer. The templates were re-scanned, the flagged issues fixed, and the same four emails were tested again through the same inbox-placement check, same domain, same send patterns: the only variable that changed was the template.
The results, before and after
Four different emails in the same sequence, four improvements, no exceptions. Two of them (the ones that started worst, near coin-flip odds on Spam) ended up the strongest movers, gaining 16 and 33 points of inbox placement respectively. This is one real sender's real sequence, not a controlled study with a control group, but the consistency across all four independent sends is the actual point: when the only thing that changes is the template, and every single send improves, the template was where the problem lived.
Exchange/Office365 stayed in Spam across all four re-tests. This fix didn't touch it; whatever's causing it is a separate problem. Onet.pl never reached Inbox once, and in two of the four sends it actually regressed from Inbox to Spam. A real fix moves most providers, not all of them, and pretending otherwise would be the same kind of dishonesty this whole write-up is arguing against.
What usually moves numbers like this
We don't have a line-by-line diff of this specific sender's before/after HTML to publish here. What follows are the categories that reliably move inbox placement this much when fixed, consistent across almost every template we've seen come through a scan, not a specific diagnosis of this one.
- A missing unsubscribe link or physical postal address: both a CAN-SPAM/GDPR requirement and a signal every major provider's classifier weighs directly.
- Spam-trigger phrasing in subject or body copy that a scan flags by name, not by vague "sounds spammy" guesswork.
- Tracking links scattered across many distinct third-party domains, versus a small, consistent set: link reputation is cumulative across a whole sequence, not just one send.
- Invalid or broken markup (unclosed tags, missing DOCTYPE, malformed tables) that some clients silently repair and others don't, in ways that change how the message gets classified.
None of this requires guessing. Run the same template through a full scan, fix what it flags as an error (not just a suggestion), and the placement math above is what fixing the actual cause looks like: not a new IP, not a longer warmup, just a template that no longer gives the classifier a reason to distrust it.