The strange case where SMTP over VPN caused Gmail to rate-limit my transactional emails and the authenticated relay failover I built to save orders 

It all started on a quiet Tuesday morning. Coffee in hand, I was reviewing the daily order logs from our online store. Everything looked good—until I noticed orders were failing. Not because of inventory or credit card issues. The problem? Emails weren’t going out. Notification emails. Transaction receipts. Even password resets.

TL;DR:

Switching our server’s email service to route SMTP over a VPN caused Gmail to start rate-limiting our transactional emails. Turns out Gmail didn’t like the sudden region hop. Emails got delayed, and orders started failing. I built an authenticated relay failover system to save the day, and now everything works—even if Gmail gets picky.

Emails Matter More Than You Think

Every online store sends transactional emails. Things like:

• Order confirmations
• Shipping updates
• Password changes
• Failed payment alerts

Lose those, and things break. Your store looks unreliable. Customers get annoyed. Some might bounce for good.

Our app’s back-end lives in AWS. We use Gmail’s SMTP relay for sending transactional emails. Why Gmail? It’s easy, reliable, and we’ve never had a serious issue. Until this odd little bug popped up.

The VPN Curveball

Something triggered this whole mess: we enabled a company-wide VPN. All traffic from internal systems now routed through a remote proxy server in Europe. Our main app server is in the US. Not a problem, right?

Wrong.

Because our US-based server started sending SMTP requests via a VPN endpoint located thousands of miles away. Gmail didn’t like that. What used to be a trusted IP suddenly looked shady. Misconfigured. Suspicious at best.

Rate Limiting… and Rage

It started slow. Slight delays in customers getting their receipts. Nothing major. Then more orders failed because we rely on email responses to confirm payment finality. Before long, a mini flood of support tickets came in:

• “I didn’t get my confirmation email.”
• “Did my order actually go through?”
• “I reset my password but didn’t get the link.”

Gmail had slapped us with rate limiting. Too many SMTP connections from an unusual region? Email paused.

Guess what Gmail said? Basically: “You’re being throttled. Try again later.”

Digging Deeper

I went down some network rabbit holes. Trace routes, SMTP logs, header analysis. Sure enough, every email passed authentication. DKIM, SPF, and DMARC were all happy.

But buried in the Gmail logs was a hint: they thought our SMTP traffic looked like a bulk sender from overseas. Suspicious behavior kicked in automated throttles.

It wasn’t that emails were rejected. They were just… stuck. Delayed. Greylisted. Some queued for five minutes. Others for twenty.

I Had to Act Fast

Customers don’t wait twenty minutes to get what they expect in five seconds. Some canceled orders mid-way. Some placed duplicate orders and got double charged. It was chaos.

I couldn’t wait for Google to lift the limits. I needed a Plan B.

The Quick and Dirty Patch

First step: remove the VPN tunnel from SMTP traffic. That helped. A little. But Gmail still remembered us as “that sketchy account.” Limits kept applying, just less severe.

Time to build a better escape hatch.

The Authenticated Relay Failover

Here’s what I did:

1. Kept Gmail as our primary SMTP, but capped usage to avoid triggering limits.
2. Configured a secondary relay using a transactional email provider (like Mailgun).
3. Built a simple relay balancer: a script that detects delivery failures or slow queues, and reroutes emails through the backup provider instantly.

It worked like this:

• If an email hits a Gmail throttle → reroute to backup SMTP.
• If Gmail starts working again → revert to Gmail.

Nothing fancy. Just enough to survive Gmail’s mood swings for a few days.

Code-wise, It Wasn’t Rocket Science

The balancer was a simple Node.js middleware plugged into our queue handler. Here’s the pseudo-logic:

if (sendViaGmailFails()) {
  log("Gmail throttle detected.");
  switchToBackupRelay();
  sendEmail();
} else {
  sendViaGmail();
}

I even added some auto-healing. After five successful Gmail sends in a row, the system would try switching back.

The Results

Just hours after deploying the failover relays, email delays vanished. Order success metrics shot back up. Support tickets dropped. Revenue normalized.

It was like CPR for our email system.

Lessons Learned

This little episode taught me a lot about how fragile email systems are—especially when you involve:

• IP reputation
• VPN routing
• Global SMTP networks

Some key takeaways:

1. Always monitor SMTP queues & delay logs. Don’t wait for customer complaints.
2. VPNs mess with email geo-fingerprints. Gmail cares where you’re sending from.
3. Build a relay fallback. It doesn’t cost much, and it can save a day’s worth of sales.

What I’d Do Differently

Next time, I’d:

• Whitelist our VPN with Gmail ahead of time
• Use region-aware SMTP endpoints
• Have a failover system in place before things break

Sometimes you only learn by messing up.

Conclusion

SMTP can be deceptively fragile. One VPN routing change broke our email flow and almost torpedoed a week’s worth of orders. But with some smart failover scripting, relays, and observation, we came out stronger.

Moral of the story: monitor your transactional email like a hawk. Respect Gmail’s rituals. And never rely on just one mail pipe.

Because when Gmail gets grumpy, your entire business can feel it.