Offshore SMTP Hosting
is mostly about whether the infrastructure can actually send email.

The gap between "offshore hosting" and "offshore SMTP hosting"

The gap is operational, not marketing. Offshore hosting is a real category with many providers in it. Offshore SMTP hosting is supposed to be a subcategory but in practice most providers in the broader category do not deliver the email-specific infrastructure that the name implies.

When a customer signs up for a budget offshore VPS expecting to send email from it, they discover several obstacles in the first week. Port 25 outbound is blocked at the provider level. The IP has a long history of past abuse and is on Spamhaus' XBL or PBL list. The rDNS is set to a generic hostname the customer cannot change. The provider has no support staff with email deliverability expertise, so when the inevitable first complaint arrives they handle it by terminating the customer rather than helping resolve the underlying issue.

By the time the customer understands all of these obstacles, they have either invested several weeks of work into a setup that cannot succeed, or they have switched providers and started over. The provider has collected several months of payment for a service the customer cannot actually use. Both parties end up frustrated.

We built our SMTP service with the opposite assumption. The infrastructure is for sending email. Everything that is hostile to email sending was removed or addressed from the beginning. Port 25 is open. The IPs are clean. The rDNS is configurable per customer. The team has years of deliverability operational experience. When complaints arrive, we triage and help resolve rather than terminating.

What email-grade infrastructure actually requires

The operational checklist for email-grade infrastructure is specific. Each item matters individually and together they form a baseline below which mail simply will not deliver reliably.

Requirement	Why it matters	Our implementation
Port 25 open outbound	SMTP cannot function without it	Open by default, no throttling
Dedicated IPv4 address	Reputation tied to your operation only	Min 1 per customer, more on higher tiers
Custom rDNS (PTR)	Receivers check sender legitimacy	Configured to your sending hostname
Clean IP reputation	Spamhaus listing = mail rejected	Pre-flight check before customer assignment
SPF record support	Required by Gmail/Yahoo Feb 2024	Guided setup at onboarding
DKIM signing (2048-bit)	Microsoft rejecting 1024-bit in 2026	2048-bit by default, rotated quarterly
DMARC capability	Required by all major receivers	Starter record published, aggregate reports monitored
FBL processing	Spam complaints must reach suppression list	Microsoft, Yahoo, Comcast, Cox FBLs integrated
Postmaster Tools enrolled	Gmail compliance visibility	Per-customer enrollment supported
SNDS access	Microsoft IP reputation visibility	Per-customer SNDS enrollment
MTA-STS publication	TLS enforcement for inbound	Optional setup, encouraged for high-volume
TLS-RPT capability	Receiver TLS failure visibility	Optional, parser tooling provided
One-click unsubscribe	RFC 8058, required since June 2024	Header support + endpoint processing
List-Unsubscribe-Post	RFC 8058 mechanism	Implemented in PowerMTA config

The IP problem in detail

The single most important factor in offshore SMTP hosting is the cleanliness of the IPv4 addresses the customer is assigned. An IP that has been used for spam in the past, even by a previous tenant, carries reputation damage that new customers inherit when they receive that IP.

The reputation damage manifests in several ways. Spamhaus' SBL and XBL lists contain ranges where past abuse was significant; mail from these ranges is rejected by any receiver consulting Spamhaus, which is most major receivers. Microsoft's reputation systems track IP history independently of Spamhaus. Gmail does the same. Yahoo and Apple have their own internal scoring. An IP may pass one of these systems and fail another. The customer discovers the failures empirically when their mail starts going to spam at specific receivers.

Our IP acquisition process is deliberate. When we add new IPv4 space to our infrastructure, we audit the history through Spamhaus' MAPS database and similar tools to identify any past abuse. We delay activation of an IP for the abuse window to clear if needed, sometimes 60-90 days. We do not assign IPs with recent damage to customers until we have rehabilitated the reputation through controlled use.

The 14-check pre-flight we run on every IP before assigning it to a customer includes specific tests against Spamhaus, SURBL, the Microsoft SNDS, Gmail Postmaster Tools, and similar reputation feedback sources. An IP that fails any of these checks is not assigned. The check is rerun before every new customer assignment because reputation moves over time.

This is unlike most offshore hosts who assign IPs from their pool with no history check and no rotation policy. The customer in those setups inherits whatever the previous tenant did with the IP, good or bad. In a budget offshore hosting pool, the previous tenant statistically did something bad.

The port 25 question and why it matters

Port 25 is the standard TCP port for SMTP, the protocol email servers use to talk to each other. To send email from your server to any other email server on the internet, you need port 25 open outbound. This is not optional. There is no workaround.

Most cloud providers block port 25 outbound by default. The block is well-documented and the providers will unblock it on request in some cases. The historical reason is to prevent compromised instances from being used as spam relays. The operational consequence is that any customer expecting to send legitimate email from these providers has to either work around the block or accept that they need a different host.

Budget offshore hosts inherit this restriction from their upstream providers in many cases. When they advertise "SMTP hosting" they often mean SMTP-via-relay rather than SMTP-outbound-directly. The customer discovers this when they try to make outbound connections on port 25 and they time out.

We own our IP space at the AS level in our primary jurisdictions and have control over the firewall posture. Port 25 is open by default. We do not impose per-customer rate limits below the volume tier the customer purchased. We do not throttle specific destinations. Outbound mail flows the way SMTP was designed to.

The reason we can do this is that we screen our customer base. We have an acceptable use policy. We have a relationship with each customer during onboarding. We do not have anonymous-instant-VPS deployment where a compromised credit card can spin up infrastructure and start spamming within minutes. The trade-off between abuse prevention through port blocking versus through customer relationship is a deliberate choice. We chose customer relationship.

What FBL setup actually does

Feedback Loop is the mechanism by which mailbox providers report user spam complaints back to the originating sender. When a Gmail user clicks "report spam" on a message, Gmail's system identifies the originating IP and domain and ships a complaint message back to a designated mailbox the sender (or their hosting provider) operates. The complaint mailbox processes the complaints and removes the recipient from future campaigns to prevent the same recipient from receiving more mail they do not want.

The FBL setup is mostly invisible to customers but operationally critical. Without it, complaint signals do not reach the sender, the sender keeps sending to recipients who flagged them as spam, the complaint rate climbs, and the IP reputation degrades. With it, complaints feed into a suppression list, the sender removes the complainers, and the complaint rate stays low.

We operate FBL relationships with all major mailbox providers that offer them: Microsoft (SNDS), Yahoo, AOL (defunct but still referenced), Comcast, Cox, and several smaller providers. Gmail does not have a public FBL but provides feedback through Postmaster Tools, which we ingest. The complaint signals route to our FBL processing pipeline, which applies the suppressions on a per-customer basis without leaking complaint information across customer accounts.

For customers on shared SMTP infrastructure, the FBL processing happens at our layer with results visible to the customer in their panel. For customers on dedicated SMTP servers, the customer can choose to operate their own FBL or use our managed FBL processing.

Authentication setup that is correct from the first day

A new SMTP customer has to set up SPF, DKIM, and DMARC for their sending domain. The setup is mechanically simple (DNS records) but operationally finicky. The records have to be correct, the values have to match the infrastructure, the alignment has to work for the use case, and the policy progression has to be planned.

We provide a guided setup for new customers. The customer provides the sending domain. Our system generates the recommended SPF record, the DKIM key pair with the public key formatted for DNS publication, and a starter DMARC record at p=none with our reporting mailbox in the rua= tag for monitoring. The customer publishes the records through their DNS provider. We verify the records resolve correctly before enabling outbound mail.

The DKIM key is 2048-bit, which is the minimum acceptable size in 2026. Microsoft has begun rejecting 1024-bit signatures in production traffic. We do not generate 1024-bit keys even for legacy compatibility, because the legacy compatibility window has closed.

The DMARC record starts at p=none for the first month while we collect aggregate reports and verify all mail streams are authenticated. The customer can then progress to p=quarantine and eventually p=reject as confidence in the authentication setup builds. We do not push the progression on a fixed timeline; we let the customer drive it based on what the reports show.

For customers who already have an established sending domain with existing SPF and DKIM, we can adopt the existing setup if it is correct or recommend remediation if it is not. The audit at onboarding usually surfaces something worth fixing. Inherited setups from previous providers are often suboptimal in specific ways that affected deliverability without the customer realizing it.

What customer growth looks like operationally

A typical customer journey through our SMTP service has predictable phases.

Phase 1: Onboarding and authentication setup (week 1)

The customer provides their sending domain and desired infrastructure profile. We provision the IP and configure the PowerMTA VMTAs. The customer publishes DNS records. We verify and activate. The customer sends test messages and verifies they are authenticating correctly at major receivers.

Phase 2: Warmup (weeks 2-8)

For customers with new IPs, the warmup takes 30-60 days depending on intended steady-state volume. The customer ramps their sending volume gradually. Our managed warmup option uses engaged seed list traffic to build initial reputation. The customer's actual production traffic is sent only after the warmup baseline is established.

Phase 3: Steady-state operation

The customer is sending at their full intended volume. Our role is to maintain the underlying infrastructure, monitor for any reputation issues, handle FBL processing, and respond to operational changes (new receiver requirements, deliverability regressions, network issues). The customer handles their own list hygiene, content, and campaign cadence.

Phase 4: Growth or change

As the customer's volume grows, they may need additional IPs, additional sending domains, or different infrastructure profiles. The expansion is incremental. New IPs go through warmup before being used at full volume. New domains get their own authentication setup. The original infrastructure continues serving the original volume.

Phase 5: Incident response (when needed)

Something goes wrong at the infrastructure level (upstream network issue, datacenter incident, abuse complaint that affected a shared resource) or at the reputation level (sudden spam rate spike, IP blacklist event). Our role is to triage, remediate, and communicate. The customer's role is to identify what changed on their side that might have contributed. Most incidents are resolved within hours; some take days.

Jurisdictions for SMTP: when each one makes sense

The seven jurisdictions we operate in have different strengths for SMTP use cases. The choice is not "which is best" but "which fits your audience and operational requirements."

Bulgaria (Sofia)

Best EU network connectivity, highest IPv4 cleanliness, strong jurisdictional posture toward email. Our most popular pop for newsletter publishers and cold outreach agencies with primarily EU and US audiences.

Romania (Bucharest)

Strong network into Western Europe, second EU pop for redundancy, slightly cheaper bandwidth than Bulgaria. Often used in active-active pairs with Bulgaria for high-availability sending.

Moldova (Chisinau)

Non-EU, cheaper, more permissive for higher-risk content categories. Lower-cost option for customers whose audience is less sensitive to source jurisdiction.

Panama (Panama City)

Best legal separation from US infrastructure, ideal for crypto-related sending, no EU data sovereignty implications. Strong for Latin American audiences.

Hong Kong

Best network connectivity to mainland China, Korea, Japan. Used by customers with primarily Asian audiences. Complex jurisdictional environment that requires attention to mainland-adjacent considerations.

Singapore

Alternative Asian pop with stronger jurisdictional stability than Hong Kong. Used by customers in southeast Asian markets and as a secondary Asia-Pacific pop.

Ukraine (Kyiv)

Wartime operational risk (we monitor and have failover procedures). Used by customers with specific reasons to be in this jurisdiction, including some journalism and activist customers.

Related operational reading

• SMTP relay service — commercial details, pricing, signup
• PowerMTA managed servers — dedicated PowerMTA option
• IP warming service — managed warmup details
• PowerMTA (wiki) — operational glossary
• DKIM (wiki), DMARC, SPF — authentication protocols
• Feedback Loop (wiki) — FBL mechanics
• Postmaster Tools, SNDS — receiver-side visibility
• Spamhaus (wiki) — IP reputation mechanics
• Datacenter locations — pop-by-pop technical details