The Deliverability Impact of Sending from New Geographic Regions

• October 2021
• Engineering Memo · External Release

Email sending infrastructure is increasingly distributed across geographies — organisations use datacenters in Europe, North America, Latin America, and Asia to improve delivery latency, comply with data residency requirements, or increase redundancy. Adding a new geographic region to a sending infrastructure is not a transparent operation: it introduces new IP addresses with new geographic attributes, different ISP relationship contexts, and PTR record expectations that vary by region. Understanding these effects before deploying to a new region prevents the deliverability surprises that operators encounter when a new datacenter's first sends produce unexpected deferral rates.

How Geographic Location Affects ISP Perception

ISPs evaluate the geographic consistency of sending infrastructure as one signal among many in their reputation assessment. An IP address in an Estonian datacenter sending email that claims to be from an American company is not inherently suspicious — many legitimate senders use European infrastructure for European audiences — but the PTR record, EHLO hostname, and FCrDNS alignment must be consistent with each other regardless of geographic location. An IP with a PTR record pointing to a German hostname sending with an Estonian EHLO hostname has alignment inconsistencies that some ISPs flag.

Geographic spam databases add another layer. Some regional ISPs and corporate mail servers use geo-IP-based spam blocking — automatically applying higher scrutiny or outright blocking to mail from IP ranges in regions associated with high spam volume. Certain Eastern European and Asian IP ranges are on geo-based block lists maintained by some ISPs, not because of any specific sender behaviour from those ranges but because of the historical association of those ranges with spam operations. New IP addresses in these ranges start with a reputation deficit that IPs in less-flagged geographic regions do not face.

The practical implication: IP warming in a new geographic region requires more patience than warming in a region with a clean geographic reputation baseline. What takes 4 weeks to warm in a European datacenter with a strong sender reputation history may take 6–8 weeks from a new Latin American or Southeast Asian datacenter, because the geographic baseline adds friction to the initial reputation building.

PTR Record Requirements Across Regions

PTR records (reverse DNS) must resolve to a hostname for every sending IP, and that hostname must forward-confirm to the IP address through FCrDNS. This is a universal requirement — not geographically variable — but the process of obtaining PTR records differs by geographic region and hosting provider.

In European datacenters (Germany, Estonia, Netherlands, UK), most major hosting providers offer PTR record management through their control panel or API. PTR records can be set at the time of IP provisioning and take effect within 24–48 hours. The PTR hostname convention should follow the sending infrastructure's naming scheme: mail01.eu.yourdomain.com, smtp1.amsterdam.yoursendingdomain.com, or similar patterns that are consistent with the EHLO hostname used in SMTP sessions.

In Latin American datacenters, PTR record management varies more significantly by provider. Some providers require submitting a support ticket to request PTR records rather than offering self-service management. This means PTR record setup can take 2–5 business days rather than immediate self-service. For new regional deployments, PTR record provisioning must be planned and submitted before the first send from those IPs — not as an afterthought after delivery problems emerge.

In Asian datacenters, the same variability applies. Additionally, some Asian IP ranges have legacy PTR record issues from previous tenant abuse — PTR records pointing to hostnames that are not consistent with the current tenant's domain. When provisioning IPs in Asian ranges, verify that the PTR record for each IP does not reference a hostname associated with previous spam operations, and that the PTR record can be updated to the correct hostname before any email sending begins.

ISP Coverage Differences by Region

The ISP distribution of a recipient list changes significantly by geographic region. A list of European subscribers has a fundamentally different ISP composition than a list of US subscribers. EU programmes encounter GMX, Web.de, T-Online, Orange, Free.fr, Libero, and similar regional providers as major destinations — providers that receive modest traffic from US-based infrastructure but are dominant in their respective local markets. Deploying EU-based sending infrastructure changes the relevant ISP configuration priorities from Gmail/Yahoo/Microsoft-first to a more balanced mix that includes regional providers.

This ISP composition shift affects PowerMTA configuration: EU-based sending infrastructure should have specific domain blocks for the EU regional providers (GMX, T-Online, Orange, Free, Libero) in addition to the standard US provider domain blocks. These EU-specific domain blocks need retry intervals tuned for greylisting (as documented in the EU ISP greylisting note), connection limits calibrated to each EU provider's acceptance patterns, and FBL integration where available (GMX offers an FBL; not all EU providers do).

Latin American deployments encounter regional providers (UOL, Terra, IG, Hotmail.com.br) as significant list constituents for Brazilian and other Latin American audiences. Asian deployments encounter local providers (QQ Mail, NetEase 163, Naver in Korea) that are significant for local audiences but receive minimal traffic from European infrastructure. Each regional deployment should include a domain block audit for the ISPs that constitute the top 80% of the target audience's email providers — not just the global ISPs that appear on generic configuration guides.

Data Residency and Compliance Considerations

Geographic infrastructure choices intersect with data residency requirements under GDPR and similar regulations. GDPR requires that personal data (including email addresses) of EU residents be processed within the EU or in countries deemed adequate by the European Commission, unless specific transfer mechanisms are in place. A sending infrastructure that stores EU resident email addresses in a US-based MailWizz database while using EU-based PowerMTA servers for delivery has a data residency question: where is the personal data processed?

The answer is jurisdiction-specific and legal-opinion-dependent — not a technical determination that an infrastructure team should make unilaterally. The infrastructure team's role is to document the data flow: where email addresses are stored, where they are processed (for segmentation, injection preparation, bounce processing), and which geographic infrastructure components each data element passes through. This documentation allows the legal/compliance team to assess whether the flow meets applicable requirements or requires modification.

Cloud Server for Email's infrastructure operates from our datacenter in Tallinn, Estonia, and is specifically designed for GDPR-compliant email operations for EU senders. Data processed within this EU datacenter does not cross to non-adequate jurisdictions, making compliance documentation straightforward for EU-based clients. For senders whose programmes require infrastructure presence in other regions (LGPD-relevant operations in Brazil, PDPA-relevant operations in Thailand, or operational presence in additional EU member states), the same principle applies — the infrastructure's geographic footprint should match the data residency requirements of the applicable regulation, and the technical documentation of data flows should support the compliance assessment. The patterns described in this note are equally relevant whether the regional infrastructure is operated in-house or through a regional infrastructure partner.

Operational Checklist for New Region Deployment

Deploying email sending infrastructure in a new geographic region requires completing a checklist before the first message is sent. Each item on this checklist prevents a category of deliverability problem that is significantly harder to resolve after sending has begun than before.

Pre-deployment checks:

1. PTR records are set for all sending IPs, pointing to hostnames consistent with the EHLO hostname that will be used in SMTP sessions. Verify FCrDNS: the hostname in the PTR record resolves forward to the same IP address. This check takes 5 minutes per IP and prevents FCrDNS failures that affect deliverability at all ISPs.

2. DKIM keys are generated and published in DNS for the sending domain. The keys use 2048-bit RSA and are published at a selector specific to this infrastructure (not the same selector as other infrastructure, to enable independent key rotation). Verify publication with: dig TXT selector._domainkey.yourdomain.com. Wait for DNS propagation (24–48 hours) before first send.

3. SPF record is updated to include the new sending IP range. Check that the update does not push the SPF lookup count above 10. Verify that the new IPs are correctly covered after the update: send a test message and check the Authentication-Results header for spf=pass.

4. DMARC record is confirmed to include a valid RUA address that receives aggregate reports. The new infrastructure's sending from the new region should appear in DMARC aggregate reports within 48 hours of first send. Verify that the RUA mailbox is monitored.

5. Postmaster Tools: register any new sending IPs with Google Postmaster Tools (requires DNS verification for each IP). This registration enables IP reputation data to appear in Postmaster Tools for the new IPs after sufficient sending volume.

6. DNSBL check: verify each new IP against Spamhaus ZEN, Barracuda, and SORBS before first send. Any IP that appears on a DNSBL before any sending has occurred has a history problem from previous tenants — do not use it until delisted or replaced.

7. PowerMTA domain blocks: add or verify per-ISP domain blocks specific to the target audience's ISP composition. For EU infrastructure, ensure domain blocks for GMX, T-Online, Orange.fr, Free.fr, and Libero are present. For LATAM infrastructure, ensure regional provider domain blocks are present for the target market.

Warming New Regional IPs: The Modified Protocol

The warmup protocol for new regional IPs follows the same principles as standard IP warmup but with adjustments that account for the geographic baseline effects: more conservative volume ramp rates in the early weeks, careful monitoring of per-ISP deferral rates at regional providers that may apply geographic scrutiny, and longer patience before expecting ISP rate limits to open up to full-volume levels.

For Latin American or Asian regional IPs, the week-by-week ramp should be approximately 40% slower than the ramp for equivalent EU or US IPs. Where a US-based IP might ramp from 2,000 to 20,000 messages per day in 14 days, a Latin American IP should target 2,000 to 12,000 messages per day in the same period, with the pace increasing as Postmaster Tools data shows IP reputation establishing at Medium or above. This conservative approach avoids triggering geo-based spam filters that are more sensitive to volume spikes from less-established regional ranges.

The ISP-specific monitoring during regional warmup is more granular than standard warmup monitoring because the ISP composition is different. Standard warmup monitoring watches Gmail, Yahoo, and Microsoft. Regional warmup monitoring must also watch the top 3–5 regional ISPs for the target geography. For a Brazilian deployment, this means monitoring UOL, Terra, IG, and Hotmail.com.br deferral rates alongside the standard US ISP monitoring. A deferral rate problem developing at a regional ISP during warmup that is not detected because the monitoring only watches global ISPs produces a warm-and-broken situation — the IP is warmed at global ISPs but has poor reputation at regional providers where the actual audience is.

The Relationship Between Geographic Expansion and Reputation Architecture

Geographic expansion of sending infrastructure is an opportunity to revisit the overall reputation architecture — not just to add IPs in the new region, but to determine how the new regional infrastructure relates to existing infrastructure from a reputation perspective.

If the new regional infrastructure sends from the same domain as the existing infrastructure, it contributes to and draws from the same domain reputation. A domain that has High reputation at Gmail through years of clean sending from EU infrastructure retains that reputation when sending from new LATAM infrastructure — the domain reputation is domain-bound, not geography-bound. This is an advantage: the new LATAM IPs benefit from the established domain reputation, which accelerates their warmup compared to a completely new domain starting from scratch.

If the new regional infrastructure sends from a different domain (for a separate brand, a new market under a different brand identity, or compliance reasons), the domain reputation starts fresh. The new domain has no history — no positive engagement signals, no established relationship with ISPs. The warmup for a new domain is longer and more careful than for new IPs on an established domain, because domain reputation is more conservative to build than IP reputation.

Planning the reputation architecture before geographic expansion — deciding which domain each new regional IP sends from, how the regional infrastructure integrates with existing pool design, and what the long-term reputation maintenance model looks like for the combined infrastructure — produces a coherent design that evolves predictably. Ad-hoc geographic expansion decisions, made one region at a time without architectural planning, produce fragmented configurations that are difficult to monitor and maintain at the scale of a multi-regional sending programme.

Monitoring Multi-Region Infrastructure

Multi-region infrastructure requires monitoring that aggregates data across all regions while preserving region-level granularity. An aggregate delivery rate of 97% that averages together 99% from EU infrastructure and 93% from Asian infrastructure masks the region-specific problem. Monitoring dashboards for multi-region environments should show per-region delivery rates, per-region deferral rates, and per-region reputation signals from Postmaster Tools — with regional breakdown as the primary view, not an aggregate summary that requires drilling down to find regional problems.

FBL complaint processing in multi-region environments must aggregate to a single global suppression database regardless of which region received the complaint. A recipient who complaints about a message from the EU infrastructure must be suppressed from the LATAM infrastructure's sends as well. The suppression database architecture for multi-region deployments must be geographically accessible from all regional MTAs with acceptable latency — typically implemented through a database primary in one region with read replicas in each additional region, or through a globally distributed database service.

The accounting log from each regional MTA should be centralised for analysis. Comparing per-ISP delivery rates across regions for the same destination ISPs reveals whether geographic differences are significant: if Gmail deferral rates are consistently higher from the LATAM infrastructure than from the EU infrastructure, it suggests the LATAM IPs have lower Gmail reputation than the EU IPs — an actionable insight that requires either more aggressive LATAM warmup, a domain block configuration adjustment for LATAM Gmail traffic, or re-evaluation of which list segments are routed through the LATAM infrastructure.

Geographic Infrastructure as a Long-Term Asset

Regional email infrastructure, once established and warmed, is a durable asset. IPs in a well-managed EU datacenter that have been operating cleanly for two years have accumulated reputation history that cannot be transferred to new IPs — it is stored in ISP reputation databases associated specifically with those IP addresses and those domain names. This history makes the established regional infrastructure more valuable than new IPs could be in the short term, and it is one of the economic arguments for building and maintaining regional infrastructure rather than relying on shared or on-demand infrastructure that provides new IPs for each campaign.

The geographic footprint of sending infrastructure also affects the sender's ability to comply with evolving data residency and sovereignty requirements. GDPR has established a compliance model where EU resident data must be processed in the EU or in adequate jurisdictions. Similar frameworks are being adopted or considered in Brazil (LGPD), India (DPDP Act), and other markets. A sender with established regional infrastructure in each relevant geography is positioned to meet these requirements through architecture, not just through contractual mechanisms. A sender relying entirely on US-based infrastructure for all regions faces increasing compliance complexity as regional data requirements become more stringent.

The combination of deliverability, compliance, and operational resilience arguments makes geographic infrastructure diversification a sound long-term investment for senders with international audiences. The short-term costs — IP provisioning, warmup investment, per-region configuration work, and ongoing monitoring — are offset by the long-term benefits of regional reputation assets, compliance positioning, and the redundancy that multi-region infrastructure provides against single-region outages or regulatory actions. Approached with proper planning — pre-deployment checklists completed, warmup protocols followed, regional ISP configurations in place — geographic expansion of email infrastructure is operationally straightforward and strategically valuable.

Technical Checklist: Pre-Deployment Verification

The following verification steps should be completed and documented before the first message is sent from any new regional IP address. Each step has a specific verification method and a specific failure mode that it prevents.

FCrDNS verification: run host [IP_ADDRESS] to confirm PTR record exists and resolves to a hostname. Then run host [HOSTNAME] to confirm the hostname resolves forward to the same IP. If forward and reverse do not match, FCrDNS fails — causing reputation signals at every ISP that checks it. Fix by correcting either the PTR record or the A record so both directions resolve to the same IP/hostname pair.

DKIM DNS propagation: after publishing the DKIM public key TXT record, confirm propagation with dig TXT selector._domainkey.yourdomain.com @8.8.8.8. The record should return the v=DKIM1; k=rsa; p= record. If the record is not yet visible from external resolvers, wait and verify again before sending — DKIM failures on early sends damage the new IP's reputation before it has any positive history to buffer against.

SPF test message: inject a test message through the new regional IP to a test Gmail address. Retrieve the message and examine the Authentication-Results header. Confirm spf=pass. If spf=fail or spf=softfail, the new IP is not covered by the SPF record — sending before fixing this creates authentication failures on every message from the new IP until it is resolved.

DNSBL pre-check: query each new IP against Spamhaus ZEN using dig A [REVERSE_IP].zen.spamhaus.org where REVERSE_IP is the IP in reversed-octet format. A response of NXDOMAIN means not listed (clean). Any other response means listed — do not send from this IP until delisted or replaced. A pre-send DNSBL listing that is discovered only after sending begins produces immediate deliverability problems that require emergency remediation.

PowerMTA injection test: inject a small test batch (50–100 messages) to a controlled test list with recipients at the major ISPs relevant to the region. Review the accounting log for this test batch. Confirm 250 OK responses from each ISP at the expected rate. Any ISPs returning 5XX on the first send may have geo-based filtering that requires investigation before full campaign traffic is routed through the new IP. Identify and resolve ISP-specific rejection codes before scaling volume.

Completing this verification checklist takes approximately 2 hours — significantly less time than diagnosing and remediating the deliverability problems that occur when any of these steps is skipped. For organisations deploying regional infrastructure regularly, the checklist becomes a standard operational procedure that ensures consistent, problem-free regional deployments regardless of which team member completes the work.