Why shared SMTP relays hurt deliverability once you scale

You start with a shared SMTP relay because it is simple, sign up, configure your app, and emails go out without thinking about IPs or reputation. At 500 sends per day it works. At 5,000 it starts to wobble. At 50,000 you are fighting spam folders, silent bounces, and providers that throttle your connection while the relay dashboard shows "all green." The root cause is almost never your content. It is the shared sending infrastructure and how it interacts with receiving mail servers once your volume no longer fits in the noise.

How a shared SMTP relay works, and where it breaks

A shared SMTP relay pools your outgoing mail with other customers behind the same set of outbound IPs. Your email shares an IP address with tens or hundreds of other senders that the relay's abuse team has not screened thoroughly. Gmail, Outlook, and Yahoo evaluate reputation per IP, not per sender. If one tenant on the IP sends a spam campaign, the whole block loses standing. Your next perfectly formatted transactional message goes to the spam folder because of a neighbour you have never met.

The problem compounds with scale. A shared relay imposes per-connection and per-hour sending limits to protect itself, throttling that feels proportional to a small sender but becomes a bottleneck when you need to flush a queue. Common shared relays cap you at a few hundred connections per IP per hour, and support will not raise that limit without a business-class plan. Meanwhile your application queues grow, retries pile up, and some providers interpret the retry burst as suspicious behaviour.

A deeper issue is feedback loop absence. When you send through a shared relay, bounce handling and complaint feedback go to the relay operator, not to you. You never see the raw delivery logs or the exact SMTP rejection message. That blind spot means you cannot distinguish between a temporary deferral (4xx), a hard bounce (5xx), and a greylisting, three states that need three different responses. Blind retries make everything worse.

共享 SMTP 中继在发送量增大后难以维持高送达率，邻居 IP 的不良信誉会拖累你的邮件。

A shared SMTP relay cannot sustain high deliverability once you scale, your neighbour's poor reputation drags down your mail alongside their own.

Neighbour reputation is the silent killer of shared SMTP relay deliverability

The term "neighbour reputation" describes the effect of one sender on the IP block that other senders share. Receiving mail servers, especially Gmail, Microsoft 365, and Yahoo Mail, evaluate not just the individual IP but the whole /24 subnet. That means one spammy tenant on your relay can sink deliverability for everyone on that Class C range.

You can test this yourself. Extract the outbound IP from your relay's SMTP banner, then look it up on services like MXToolbox or BarracudaReputationBlockList. A clean record today does not guarantee a clean record tomorrow, because the IP's reputation changes the moment another tenant misbehaves. Shared relay operators do clean their pools and remove abusive customers, but the damage is already done, your mail is deferred until the new sender proves their IP is safe, a process that takes days or weeks depending on the provider.

At volume, neighbour reputation becomes a statistical certainty. The more mail you send from a shared IP, the more likely a bad tenant lands on it. The receiving server's algorithm sees a jump in volume from an IP with a mixed history and weighs that against your sender score. You lose.

Throttling and suspension without warning

Shared SMTP relay services protect themselves from abuse by rate-limiting every customer. The limits vary by plan, a low-end relay might allow 300 emails per hour per account, while a mid-tier plan gives you 10,000 per day before requiring manual review. What the dashboard does not show you is the per-connection throttling that kicks in during peak hours. Your MTA (Mail Transfer Agent) opens ten concurrent connections to the relay; the relay accepts five and delays the other five with a 4.7.0 "try again later" code. Your retry logic spins its wheels while the queue grows.

More problematic is the sudden suspension. Shared relays maintain automated traffic analysis that flags unusual sending patterns, a sudden volume spike, a high bounce rate from a new campaign, a burst of connections from a single source IP. The relay's automatic safeguard blocks your account before a human reviews it. Recovery means opening a ticket, explaining your sending patterns, and waiting hours or days for the block to lift. During that time, every email your application generates either queues locally or disappears into a black hole.

This is not malice from the relay provider. It is the inevitable consequence of running a multi-tenant infrastructure where one compromised account can damage the reputation of every customer. The provider is protecting their business. You are collateral damage.

When to move from a shared relay to a dedicated IP

The breakpoint varies by use case, but the pattern is consistent. You should consider a dedicated sending IP when any of these conditions apply:

• You send more than 10,000 emails per day consistently. At this volume, the statistical noise from neighbour reputation starts to produce measurable deliverability differences between shared and dedicated IPs.
• You run transactional email (password resets, order confirmations, billing receipts). These are time-sensitive. A throttled or suspended account means lost revenue and angry users.
• You operate a newsletter, announcement list, or marketing sequence. Any bulk sending pattern triggers additional scrutiny on a shared IP. A dedicated IP gives you a clean slate that you control.
• You send from a custom domain and need full DKIM, SPF, and DMARC control. Shared relays often impose their own signing headers, which can create alignment issues with your domain's authentication records.

When you move to a dedicated IP on your own infrastructure, you gain three things immediately: full log access (every SMTP response, every bounce code, every deferral), control over sending speed (you set the connection and rate limits), and insulation from neighbours (your IP's reputation reflects only your mail). The trade-off is responsibility, you must warm the IP gradually, manage bounces yourself, and keep your sending patterns consistent. A "rent a VPS in Vietnam" with a dedicated IPv4 is a common starting point for self-managed email infrastructure, particularly when your recipients are in Vietnam or Asia and low latency to local mail exchanges matters.

What a dedicated IP on a Vietnam VPS looks like in practice

A dedicated sending setup typically runs on a Linux VPS with an MTA like Postfix or a purpose-built delivery solution. The VPS receives your outbound mail via SMTP submission (port 587 or 465), applies your domain's DKIM signature, and relays it directly to the recipient's MX server. No intermediate relay, no shared pool, no mystery. You pick the OS, Linux VPS with full root access on Ubuntu 24.04, Debian 12, or AlmaLinux 9, and configure it for email with SPF, DKIM, and DMARC records pointing to your domain.

The infrastructure for a SMTP VPS that handles a few thousand to a few hundred thousand emails per day does not need a lot of hardware. A basic 2GB RAM VPS (VNx2 or similar) is sufficient for Postfix with rate limiting and logging. The critical resource is the dedicated IPv4, a clean IP that belongs only to you, with rDNS (PTR record) set to match your sending domain. This setup eliminates neighbour reputation entirely. Your IP's score is the direct result of your sending practices and no one else's.

A Vietnam-based VPS is specifically useful when your email recipients are in Vietnam's major ISPs, VNPT (Vietnam Posts and Telecommunications Group), Viettel (Viettel Telecom), FPT (FPT Telecom), and CMC Telecom. These providers operate their own mail servers and apply local content filters. A Vietnamese IPv4 in the same country reduces routing hops and improves delivery speed. The domestic bandwidth on a Vietnam VPS is 100 Mbps on a 1 Gbps port, enough for sustained email throughput even during peak local hours. International bandwidth is a shared pool of roughly 4 to 10 Mbps, which is adequate for email relay traffic that crosses borders.

IP warming and reputation management on a dedicated IP

Switching to a dedicated IP does not fix deliverability overnight. A fresh IP that has never sent mail has no reputation, receiving servers treat it as unknown and may defer or throttle mail until they see consistent behaviour. This is the "cold IP" problem, and the solution is gradual warming.

The standard approach is to ramp volume over 3 to 4 weeks. Start with 50 to 100 emails per day from the new IP, all to your most engaged recipients (recent openers and clickers). Increase volume by about 25% per week. Monitor bounce rates and feedback loops from major providers. If you see a spike in deferrals, hold the current volume for a few extra days before increasing. Never send cold IPs to old or unengaged lists, the resulting bounces damage the reputation before it builds.

A key advantage of a dedicated IP is that you see every bounce in your MTA logs. You can distinguish hard bounces (address does not exist) from soft bounces (mailbox full, greylisting) and suppress the hard ones immediately. This cleanliness feeds back into your sender score. On a shared relay, that feedback loop is opaque.

Monitoring deliverability at a glance

Once your dedicated IP is live, measure delivery rates with real SMTP logs rather than dashboard metrics. Key signals in your MTA logs:

• Deferral rate (4xx codes): A rising deferral rate from a specific provider indicates they are throttling or greylisting your IP. Hold volume and check your PTR record and DKIM alignment.
• Bounce rate (5xx codes): More than 3% hard bounces means your list hygiene needs attention. Remove invalid addresses and use double opt-in for new signups.
• Complaint rate: If your feedback loop shows more than 0.1% complaints, review your content and frequency. Gmail uses complaint rate as a primary signal in their spam filter.

Postfix logs record each delivery attempt with the exact SMTP response. Tools like pflogsumm aggregate these into daily reports. No shared relay gives you this level of transparency.

FAQ

Related articles

• SPF DKIM and DMARC on a self hosted SMTP server
• Warming up a new sending IP a realistic 30 day schedule
• Moving a WordPress site from shared hosting to a VPS