In partnership with
Hey, it's Pavel. Email Deliverability Expert helping email operators raise the bar for themselves and their teams. I'm building this newsletter for high-performing email marketers who want to stay ahead of the game. If you're serious about email deliverability, don't forget to subscribe.
When Multiple ESPs Break Your Email Delivery
You do everything by the book. New app, new domain, Mailgun connected, tests pass, developers see every email. Then you launch, real users arrive, and suddenly email stops behaving.
That is what happened with a client I worked with recently.
They had a small product app with a weekly re-engagement email that worked perfectly during beta. Once the user base passed one thousand people, that same campaign stopped reaching most inboxes.
Roughly 30% of users received the email. The other 70% saw nothing.
SPF and DKIM were configured. Mailgun was in place. Dashboards looked fine. Yet Gmail and Outlook were either rejecting messages or dropping them into spam.
This is what real-world authentication failure looks like.
Easy setup, easy money
Making money from your content shouldn’t be complicated. With Google AdSense, it isn’t.
Automatic ad placement and optimization ensure the highest-paying, most relevant ads appear on your site. And it literally takes just seconds to set up.
That’s why WikiHow, the world’s most popular how-to site, keeps it simple with Google AdSense: “All you do is drop a little code on your website and Google AdSense immediately starts working.”
The TL;DR? You focus on creating. Google AdSense handles the rest.
Start earning the easy way with AdSense.
What Authentication Failure Actually Looks Like
The first thing I check in any deliverability case is authentication: SPF, DKIM, DMARC. It sounds repetitive, but this is where most problems start.
Here, the developers had created all the records themselves. SPF existed, but with a structural error that made the evaluation unpredictable. DKIM signed only some of the messages depending on which subsystem generated the email. DMARC wasn’t set up at all.
After one test email, the picture became obvious. The UI said “pass”. Gmail said:
SPF: neutral
DKIM: inconsistent
Evaluated IP: incorrect service
🪄Did you know?:
When authentication acts like an ID card, inconsistency is the fastest way to lose trust. If SPF and DKIM point to different identities, Gmail assumes the safest answer: “I can’t trust this.”
This discrepancy is the part most teams miss. ESP dashboards show their evaluation, not what Gmail actually receives.
Why the ESP Dashboard Misleads You
Most ESPs only show whether:
Their sending IP is in your SPF
The message was signed with DKIM
Your DMARC policy didn’t reject the message
But this is only half the story.
Forwarding, routing, intermediate servers, and automated reply handling can all modify the message in ways your ESP never sees.
⚠️Warning:
Your ESP’s UI can show authentication as “pass” even when Gmail receives a message that fails alignment. The only accurate source of truth is the raw header inside the .eml file.
This case was a perfect example of the gap between UI and reality.
The client’s app did something common: the app sent messages from their domain, but replies were forwarded to a personal inbox through a completely different provider. That forwarding logic quietly rewrote parts of the envelope.
In Gmail’s view, the email appeared to be coming from a domain that never authorized the sending IP.
SPF alignment broke. DMARC couldn’t evaluate at all. And Gmail responded exactly as expected.
⚠️Warning:
Forwarding reply emails through a different domain or helpdesk platform often destroys SPF alignment. Even perfect DNS can’t protect you from a forwarding step that rewrites headers.
Here’s what their flow looked like:
App sends from
[email protected]via MailgunUser replies
App forwards to
[email protected]Zendesk forwards again to a personal inbox
Each hop changed enough details to confuse Gmail’s evaluation chain. Some messages landed. Most didn’t. Nothing appeared consistent.
When Testing Holds Back the Fix
One more complication: Mailgun didn’t allow them to trigger direct test sends in this account tier. The only way to generate a message was to run through the application logic.
Their weekly email went out on Mondays.
Every DNS adjustment meant waiting up to seven days to confirm whether it worked. Devs were overloaded and couldn’t immediately build API-triggered tests.
If you cannot test authentication on demand, every mistake costs days. Without instant testing, a two-day fix becomes a two-month delay. We needed faster iteration, but the infrastructure made that impossible.
Rebuilding the Authentication Stack
Given all the inconsistencies, we started over.
SPF rebuilt: included A records, MX records, Mailgun hosts, and the correct sending infrastructure for Gmail/Outlook mailboxes.
DMARC created: aligned with the From domain, with proper reporting enabled.
DKIM stabilized: custom DKIM was enforced so every Mailgun message carried a signature from the domain, not sometimes-from-somewhere.
Reply logic fixed: replies now routed to a mailbox under the same domain, eliminating cross-domain forwarding that rewrote headers.
Testing shifted to header-based verification: we downloaded .eml files and checked Authentication-Results directly.
🪄 Real Example:
If you're forwarding reply emails through a different domain or service, you're probably breaking SPF alignment. Keep everything under the same domain—send address, reply address, all of it.
Let’s say:
You send from
[email protected]via Mailgun.Users click "Reply," and your app forwards replies to
[email protected].
What can go wrong:
When Zendesk forwards the reply to your internal team, it may rewrite headers.
Gmail sees an SPF fail (IP not authorized by
productapp.com) and possibly a DMARC fail (because SPF is no longer aligned).
Even if the email reaches your inbox, this setup hurts:
Domain reputation (especially with Gmail and Outlook)
Inbox placement for future sends
Behold! The Spam Filter Slayer speaks! 🔮
You can get started with beehiiv and get 20% off for three months using my link or simply paste my promo code: PAGTH7YX. They've built their entire platform around deliverability best practices, which means you won't end up troubleshooting broken authentication chains at midnight. From reverse I will get 50% of your payment from beehive so I can continue supporting my infrastructure, tools and day-to-day business.
✨Practical Checklists
🧄 Before You Configure Email Authentication
Verify these items before you touch DNS:
Your sending IP addresses are documented. All of them. Including your ESP's IPs, your application server IPs, and any backup or failover IPs.
Your From: domain is decided. This is what recipients see. It should match where you're authenticating from.
Your reply-to address uses the same domain. No forwarding through Gmail, no routing through a different service. Same domain, period.
Your ESP supports custom DKIM signing. If they only sign with their own domain, you'll fail DMARC alignment no matter what you do.
You have a way to trigger test emails on demand. You cannot troubleshoot authentication if you can only test once a week.
🧄 Post-Configuration Verification
After you've set up SPF, DKIM, and DMARC:
Send a test email to yourself. Download the .eml file. Open it in a text editor and check the raw headers manually.
Look for "Authentication-Results" header. SPF should show "pass" not "neutral" or "softfail". DKIM should show "pass" with your domain. DMARC should show "pass" with alignment.
Verify the sending IP in the Received headers matches what's in your SPF record. If it doesn't match, your SPF record is incomplete.
Check that DKIM is signing with your domain, not your ESP's domain. Look for "d=" in the DKIM-Signature header.
Send to a brand new email address that's never interacted with your domain. See where it lands. Inbox means authentication is working. Spam means something's still broken.
|