Multi-region deliverability — why one region isn't enough

The first question is GDPR

Most teams asking about region come with a compliance hat on. Their general counsel said the customer-data-export must originate from EU infrastructure. Their healthcare customer needs HIPAA-aligned routing. Their German e-commerce co-founder won't sign a contract that ships email through US-only IPs.

That's the easy half of the answer: yes, we have an EU region (Gravelines, France), and yes, you can pin a send to it. region: "eu" on every /v1/email/send call.

The hard half is the question they didn't ask: does it actually matter to deliverability, beyond the legal hygiene? Yes. Here's why.

Half the problem: where you send from

Sending from an EU IP changes three things visible to recipient mail servers:

• The originating IP's geographic reputation. Some recipient providers (Yahoo, certain regional ISPs) treat IPs from your local region more favorably. Counter-intuitive, but documented in their public guides.
• The MTA-STS and TLS handshake performance. EU recipients see slightly faster handshake on EU origin IPs. The 15-30 ms difference matters when an aggressive recipient timeout is involved.
• Your DMARC alignment under relaxed mode. If your domain's _dmarc record specifies aspf=r; adkim=r;, the relax-mode comparison is between sub-domains. Sending bounces through an EU subdomain (bounce.eu.your-domain.com) keeps the alignment local.

The other half: where you send to

This is where the conversation gets interesting. Recipient mailbox providers have geographic preferences too — but in the opposite direction.

Gmail, for instance, runs MX servers in many regions. When your Haraka MTA does an MX lookup for @gmail.com, it gets back a list of hostnames; Google's load balancer steers you to one of them. The MX you actually connect to depends on your origin IP's geography.

Why this matters: if your origin IP is in Quebec but the connection is steered to a Gmail front-end in California (because of how Google peers with our datacenter), the round-trip overhead per SMTP command increases. Multiply by the 6-8 commands a typical SMTP transaction does (HELO → MAIL FROM → RCPT TO → DATA → ...) and you've added 200-500 ms per send.

For 100 sends, irrelevant. For a million-send blast, this is the difference between finishing in 2 hours and finishing in 6.

The third half (math allowing): MTA-STS

MTA-STS is the standard that says "always use TLS to deliver mail to me, and here's where to verify the policy." Recipient providers publishing strict MTA-STS policies are pickier about TLS handshakes.

If your origin IP is in a region where the cert chain has been historically problematic (some non-major regions had Let's Encrypt rate-limiting issues in 2023-2024), recipient servers can downgrade your TLS reputation. Multi-region origin lets you route around problem regions before they become customer-visible.

The DMARC-alignment angle

This one's specific to high-deliverability customers. DMARC alignment requires:

• The From: domain matches (or shares an organizational root with) the SPF or DKIM-validated identity.
• "Strict" alignment requires exact match. "Relaxed" allows organizational-root match.

If your customer's From: is support@your-eu-customer.de and the message is sent through US infrastructure, the SPF chain references your US-IP-pool, the DKIM signature uses your shared key. Both work, but they create a multi-jurisdictional audit trail. EU compliance teams flag this.

Sending from EU infrastructure with a per-account DKIM key keeps the entire trail in-region. Especially matters when the customer's own DPO is reviewing your system.

The data-residency angle

This one is the most overlooked. When you send through a multi-region ESP that also stores message metadata in a single region, you've got partial residency: the email goes through EU, but the metadata-record (recipient address, subject, send timestamp) is stored in US Postgres. Most data-protection authorities consider message metadata as PII.

Our approach: per-customer region pinning means the send and the metadata stay in the chosen region. The Gravelines instance has its own Postgres, ClickHouse, and Redis. Cross-region replication only happens for system-wide tables (suppressions are global) and never for per-account data.

The latency angle for transactional

For marketing email, latency rounds to nothing. For transactional — password resets, magic links, OTP — every 200 ms shows up in the user's perception.

If your user just clicked "Forgot password" from a hotel WiFi in Frankfurt, the optimal path is:

1. Browser → your app server (often US) → Relayly API in EU (because we route customer requests to the closest region by default)
2. EU MTA → Gmail's Frankfurt frontend
3. Recipient inbox

If we were US-only, step 1 to 2 would add another transatlantic hop. The math: ~80 ms. Per email. Tiny but real.

What multi-region doesn't get you

Honesty about scope. Multi-region origin doesn't:

• Improve your DKIM-signing speed materially. Signing is microseconds.
• Help you with spam filters that rely on content classification — those run on the recipient side regardless of origin.
• Move your reputation between regions. EU IPs have to warm independently from CA IPs. You don't get to use a hot CA IP's reputation when you switch to EU.
• Solve the "Gmail thinks you're spam" problem if your content is genuinely spammy. Geography is one signal among many.

The practical recommendation

If your sending pattern is:

• Mostly EU recipients → use EU region. Inbox rates at Yahoo, Orange, Comcast (yes, Comcast cares), and regional ISPs are measurably better.
• Mostly North American recipients → use CA region. Same logic.
• Mixed → use region: "auto" on every send. Our worker classifies the recipient's MX provider's geography and picks the closest origin.
• Compliance-bound to one region → pin to that region explicitly with region: "eu" and skip the auto-routing.

The bigger point

Most ESP marketing pages list "EU region" as a feature. Few explain why it actually matters. The honest answer is: it matters in roughly four overlapping ways (origin reputation, MTA-STS performance, DMARC alignment audit-trail, data residency for metadata), and the magnitude depends on your specific customer mix.

If your team has spent any time on a deliverability call where someone said "we just need to switch IPs", multi-region pinning is the long version of that fix. We built it because we needed it ourselves, and because building one region wasn't actually less work than building two.

Questions, counter-arguments, your own deliverability war stories: hello@relayly.io.