Your ESP isn’t your deliverability problem.

A client hired me to audit his SendGrid setup. His sender reputation was sitting at 93% and he didn't know whether that was good or bad. It isn't good. Under 90% and you're close to suspension. At 93%, Gmail and Outlook are already quietly deprioritising your mail. Meanwhile customers had started complaining they weren't receiving his webinar emails.

What started as a one-off audit turned into a full rebuild across three domains and two ESPs. This issue is the case. Three problems, how I found them, how I fixed them, and a concept called The Alignment Gap that explains why most DMARC setups silently fail.

TOGETHER WITH getmerlin.app

Every email he sent from his course domain through ConvertKit was showing up in Gmail like this:

His brand. His domain. And a grey tag next to it telling the recipient the email came from somewhere else. I pulled the delivery info on one of his broadcasts:

Most senders see those green ticks on SPF and DKIM and stop reading. They miss the second column.

Authenticated means the email passes a technical check. The server that sent it was allowed to send. Aligned means the domain in the "from" address matches the domain in the SPF or DKIM signature.

DMARC needs both. SPF or DKIM has to be authenticated and aligned. If either side fails alignment, DMARC fails. That's the Alignment Gap. It's the most common deliverability problem I see.

The fix: an afternoon of DNS edits. Two CNAME records for ConvertKit's signing keys pointed at his subdomain. A proper return-path record. Updated SPF to include ConvertKit as an authorised sender for his domain, not as a separate sender.

Fresh test after DNS propagated. SPF aligned, DKIM aligned, DMARC pass. The "via" tag was gone. Test email landed in Gmail Primary, not Promotions.

I did the same fix for his personal domain, which was also failing alignment through ConvertKit. Then I rebuilt authentication from scratch on his main webinar domain. It had no SPF record at all. None. Never been configured. Since February 2024, Gmail and Yahoo require SPF and DKIM for bulk senders. No authentication, no delivery. Instead you get this bounce, which he'd been getting without knowing what it meant:

Three domains. All authenticated. All aligned. All DMARC compliant.

SENDGRID BOUNCE LOG · AUDIT WINDOW · 57 BOUNCES CATEGORISED BY REASON

Next I pulled his SendGrid bounce log. 57 bounces in the window. I categorised them by reason. 54 of the 57 were "invalid address."

I picked one at random and ran it through Kickbox, a third-party email validator. Result: undeliverable. Sendex score 0. The address had never been valid. So where were they coming from?

His webinar opt-in form accepted anything. No real-time validation. No bot protection. No verification email. Someone could type "[email protected]" into his form and his funnel would fire a SendGrid email at it. The email would bounce. The bounce would drag down his sender reputation.

At low volume this is a real problem. A 2.4% bounce rate looks fine on paper. For a domain with modest sending volume, 2.4% from invalid addresses is a clear spam-pattern signal. Gmail's filters read it as "this sender is buying lists or scraping addresses."

The fix was three things:

He implemented the first two. The third he's still working on.

THE COLD IP PENALTY · COLD-START VOLUME VS MICROSOFT FILTER RESPONSE

Then the client wanted to start sending onboarding emails to paying customers from a new subdomain. Different audience, different content. Putting these on the same SendGrid account as his webinar emails would have been a mistake. Shared account, shared reputation. If the onboarding emails ever spiked in complaints, the webinar emails would land in spam.

So I set up a separate subdomain as a SendGrid subuser. Full authentication. New dedicated IP. Everything tested green. Then customers on Hotmail, Outlook, and Live started reporting they weren't getting onboarding emails.

The new dedicated IP was blocked by Microsoft's spam filters.

This was predictable in hindsight. Brand-new IP, zero sending history, no warm-up, full volume from the first send. Microsoft's filters read that pattern as spam. New IP plus instant volume looks the same as a spammer's behaviour. I call this the Cold IP Penalty. It's the most common mistake I see when senders move to dedicated infrastructure.

I tried the public Office 365 Anti-Spam IP Delist Portal first. The portal told me the IP wasn't blocked. Meanwhile delivery was failing to every Microsoft inbox. The public delisting tool rarely matches the filter's actual state. If it's the only lever you use, you'll sit there telling yourself you're not blocked while your customers tell you their emails aren't arriving.

"A dedicated IP isn't an upgrade by default. It's an upgrade once it's warmed up. Send from it cold at full volume and Microsoft will block you before your mail reaches a subscriber."

The fix: I opened a direct support ticket with Microsoft's anti-spam team. Submitted a realistic sending-volume profile. They cleared the subdomain IP after a hold period. The main webinar IP was flagged separately for deeper review and took longer.

SYNTHESIS

Every one of them was sitting upstream of the ESP.

ConvertKit didn't put the "via" tag in his inbox. His DNS did. SendGrid didn't drop his reputation. His opt-in form did. Microsoft didn't randomly block him. His decision to launch a new dedicated IP with no warm-up did.

Deliverability isn't something your platform handles for you. It's the sum of every decision you make about how your email gets sent. The form that captures the address. The DNS record that signs the message. The schedule you warm new IPs on. All of it sits upstream of the ESP, and all of it is yours to fix.