SMTP Relay with dedicated IPs from the entry plan

For when the application already does its job. The delivery is what's broken.

SMTP Relay is the shape that fits when your software already knows how to send mail — it just isn't landing well. That covers a long list of operational sending: password resets, two-factor codes, order confirmations, billing notices, receipts, account alerts, support replies, all the boring stuff your product depends on. The point isn't to make you adopt a new integration model. The point is to fix the delivery side without touching the application that already works.

For most teams it's the shortest path to a real improvement — no rewriting, no replacing the billing system, no refactoring legacy code paths nobody wants to revisit. The application keeps sending exactly the way it sends now. The mail leaves through a relay with dedicated IPs, clean authentication, real reputation maintenance behind it. And once that layer is settled, the bigger decisions get easier — Email API, Managed Deliverability, more isolated sending environments — because the relay piece has stopped being a moving variable.

What's in every plan

Three plans plus a Custom quote

The pricing is built around dedicated IPs and clean per-domain isolation, not raw daily volume. There's a real reason for that. Ten thousand emails a day from an IP that's exclusively yours is a different product, commercially, than ten thousand emails a day from a shared pool with a few thousand other senders on it. The €399 starting point reflects what dedicated infrastructure actually costs to run well — no padding for features you wouldn't use, no margin on a $5/month tier you'd outgrow in a quarter.

Each plan caps sending volume to keep IP reputation healthy under realistic operational loads. Beyond the cap, requests either queue with backoff, or — if you're anticipating sustained higher throughput — the right move is the next tier up or a Custom plan. Sustained sending well above the published daily volume on dedicated IPs is the single fastest way to damage reputation, which is why we keep the published limits conservative rather than letting them tell a more flattering story than the work supports. Annual prepay knocks 10% off all three plans.

How this stacks up against the alternatives

The 2026 transactional email market has shifted enough to make headline-vs-headline comparisons misleading. SendGrid retired its permanent free tier in late 2025. Mailgun doubled its pay-as-you-go rates in December 2025. Several of the premium providers charge for dedicated IPs as add-ons rather than including them. So the only honest comparison is at equivalent ten-dedicated-IP configurations, with the math fully done. The table reads like this:

Once the math is done at equivalent configurations the shape becomes obvious. SendGrid and Mailgun headline numbers are for shared-pool plans where your reputation depends partly on what other senders do. Postmark, SMTP2GO and Mandrill all charge for dedicated IPs as paid add-ons. Amazon SES is genuinely cheap but it's raw AWS infrastructure rather than a managed service — different product, different in-house cost. Our Starter is built around the dedicated-IP bundle as the central thing, which is why €399 reflects what you actually get instead of starting low and adding back the parts most senders end up needing.

Where the relay sits between your app and the inbox

SMTP relay architecture — application to inbox

The teams who actually use this

The protocol is generic but the buyers fall into a pretty consistent set of categories. The pattern across nine of them, in roughly the order they show up in our scoping calls:

When it's the right answer — and when one of the others is

SMTP Relay is the right call when your application already speaks SMTP and the priority is keeping that integration while fixing the delivery side. Email API fits better when sending belongs in product code with proper webhooks for opens, clicks, bounces and complaints; when template management with variable substitution should live inside the platform; when developer ergonomics matter more to you than universal SMTP compatibility. PowerMTA Servers become the answer at the throughput end — sustained sending past 100,000 messages an hour, multi-stream architectures with per-vMTA IP strategy, the operational depth that comes with running a full commercial MTA. If you're not at that scale yet, you're not at PowerMTA yet.

Most teams searching for SMTP relay for applications or SMTP relay for billing systems aren't trying to redesign anything. They want a known-good SMTP integration to keep working while delivery quietly gets better. That's the workload this service is shaped for.

Technical specifications, briefly

What we don't do, on purpose

The relay covers the sending-infrastructure layer cleanly, but a few adjacent things sit outside it and the boundaries should be explicit. We don't write your email content — that's still the application's job. Suppression beyond bounce data and FBL signals isn't part of the service. There's no campaign builder here, no drag-and-drop template editor, no audience segmentation; that's a marketing platform's job, and putting marketing campaigns onto a transactional relay is one of the fastest ways to torch the reputation it took weeks to build. And we don't replace the deeper deliverability work — authentication review, IP warmup discipline, ongoing reputation monitoring. That's what Managed Deliverability is for, and it stacks on top when the sending profile actually warrants it.

Migrating in from SendGrid, Mailgun, Postmark or Amazon SES

Most teams arriving here are migrating off something else, not starting cold. The pattern is consistent enough to flag, because it shapes how the first billing cycle should look. Short version: dedicated IPs need to warm up before they carry full production load, no matter how clean the previous provider's reputation is. Going cold from a healthy SendGrid Pro account directly into 10,000/day on a fresh dedicated IP is the single most common operational mistake we see — and it produces exactly the deliverability collapse the dedicated infrastructure was supposed to prevent.

The right way is parallel sending during the warmup. Keep the existing provider live for the first 14 to 21 days. Route a small fraction of traffic through the new dedicated IPs, starting with your most-engaged recipients (that's the cohort least likely to mark anything as spam). Ramp gradually. By the end of week three the new IPs have positive reputation at the major receivers and the cutover from the old provider is operational rather than a leap of faith. Our onboarding is built around this — the relay starts with conservative limits that expand on schedule across the warmup window, and the dashboard shows per-IP placement so the warming progress is visible instead of guessed at.

Some specifics by source. Migrating from Postmark or SMTP2GO, the reverse-DNS configuration on the new IPs typically completes in hours rather than days because both providers use clean address blocks the major receivers already trust. From SendGrid or Mailgun shared pools, the variable that matters most is whether your sending domain has a clean DKIM and SPF posture; if it does, the new dedicated IPs inherit that domain reputation immediately and per-IP warmup is the only outstanding work. From Amazon SES, the move from AWS-allocated IPs (which carry mixed regional reputation) to clean dedicated allocations is usually a net gain from day one once warming completes.

The numbers worth watching

The dedicated-IP relay surfaces the operational signals that matter for keeping reputation healthy over time. The dashboard tracks per-IP placement against the major receivers, per-domain bounce classification, complaint rate from FBL ingestion, hard versus soft bounce ratios, and connection-level rejection patterns. Concrete benchmarks for what good looks like: complaint rate below 0.1% — that's Google's published upper bound before reputation starts to slide. Inbox placement above 95% across the major receivers. Hard bounce ratio below 2% on any 30-day window means your list is clean. DKIM-pass at 100% — anything below that is an authentication problem to find and fix. None of these are stretch targets. They're the operating envelope a dedicated-IP relay is built to hold, and the visibility into them is part of what makes a managed service different from running your own SMTP server.

Common questions about SMTP Relay