Managed SMTP relay
for the rest of us.

The SMTP path is the universal one. Almost every framework or language or CMS or helpdesk tool already speaks SMTP — Nodemailer in Node.js, the email module in Python, ActionMailer in Rails, the WordPress core, every Laravel install in existence. You give the framework a hostname plus a port plus a username and password, and your application sends mail through us as if we were any other SMTP server. Setup time is usually under 5 minutes. The credential string we issue is per-application, so you can have separate credentials for transactional and marketing streams.

# Standard submission, STARTTLS upgrade
host: smtp.eu.bigboxhosting.com
port: 587
auth: PLAIN
username: your-app.transactional
password: [issued via dashboard, rotates on request]

# Implicit TLS for legacy clients
host: smtp.eu.bigboxhosting.com
port: 465

# Plain port for legacy MTA-to-MTA submission
host: mx.eu.bigboxhosting.com
port: 25

The HTTP API path is preferable for teams building greenfield, for high-volume injection where the per-message SMTP handshake adds meaningful latency, or for cases where your application needs synchronous delivery status (the API returns a message ID and a status code; SMTP just acknowledges receipt). The endpoint takes JSON, returns JSON, and supports batch submission of up to 1,000 messages per request.

# curl example
curl -X POST https://api.eu.bigboxhosting.com/v1/messages \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "[email protected]",
    "to": "[email protected]",
    "subject": "Your order has shipped",
    "text": "Tracking: 1Z999AA10...",
    "html": "<p>Tracking: 1Z999AA10...</p>",
    "stream": "transactional",
    "tag": "order-shipped",
    "webhook_url": "https://yourapp.com/webhooks/email"
  }'

# Response
{
  "id": "01HKQR4...XYZ",
  "status": "queued",
  "accepted_at": "2026-04-25T14:32:08Z"
}

The webhook layer fires delivered plus bounced plus complained plus deferred plus opened events back to whatever endpoint you configure, with retry on failure for 24 hours. Most clients wire the webhook into their suppression list and their analytics in equal measure — the bounce events drive list hygiene automatically, the delivery and open events drive the dashboard.

Latency between the relay and the recipient mailbox is the operational variable that nobody quotes and everyone discovers in production. A 50ms handoff from your application to our SMTP relay matters less than the 280ms from our outbound MTA to a Yahoo MX in São Paulo. Both numbers compound across the message lifecycle. The chart below shows actual median latency from our five PoPs to the major receiver clusters, measured continuously through January and February 2026. The numbers are not marketing claims — they are the same RIPE Atlas probes we use internally for capacity planning.

The radar chart maps connection setup time from each of our five PoPs — Frankfurt, Amsterdam, Stockholm, Reykjavík, Ljubljana — against five recipient clusters chosen by sending volume share: Gmail US, Microsoft consumer, Yahoo, Apple iCloud, and a composite EU regional bucket. Lower is better. Frankfurt holds the best aggregate latency profile because of dense peering at DE-CIX, but Amsterdam edges it for Gmail traffic specifically because of how Google routes EU traffic through their AMS-IX presence. Reykjavík is the surprise — submarine cable diversity makes it competitive for transatlantic delivery despite being geographically further. The numbers most operators get wrong by an order of magnitude are not the EU ones. They are the Asia-Pacific paths, where routing decisions inside the receiver's network dominate over physical distance.

Three things to take from this. First, latency variance across PoPs is smaller than competitors imply when they sell "global edge networks" with 30 PoPs — most of those PoPs sit on the same upstream peering anyway, and the marginal improvement per added PoP after the first five is in the single digits of milliseconds. Second, latency to Yahoo from any EU PoP is consistently higher than to Gmail or Microsoft because Yahoo's routing has not invested in EU peering at the same level. This shows up in deliverability windows during peak hours. Third, none of these numbers matter if your sending volume is under 100,000 messages per month — the difference between 18ms and 47ms median is operationally invisible at small scale. We publish them anyway because larger senders ask, and the data is the data regardless of whether the prospect can act on it.

Transactional email is what your application emits when a user does something. Password reset. Order confirmation. Account verification. Shipping notification. Two-factor code. The recipient is expecting it; engagement rates run 80-85%; complaint rates run effectively zero. Mailbox providers reward this profile heavily — transactional traffic from a clean IP lands in the primary inbox almost without exception.

Marketing email is what you send to users without a triggering action. Weekly newsletters. Promotional campaigns. Re-engagement sequences. Recipients did opt in (or should have), but engagement rates run 20-40% and complaint rates climb above 0.1% on bad sends. Mailbox providers treat this profile with much more suspicion. A poorly executed marketing send has the power to torch the IP it was sent from for 30 to 60 days.

The expensive mistake is sending both classes through the same IP pool. The complaint events from a marketing campaign tank the IP's reputation. The transactional traffic that flows through the same IP an hour later inherits the damaged reputation, and password resets start landing in spam. The product breaks, support tickets spike, and nobody connects the dots back to the marketing campaign that was sent from the same infrastructure.

Every plan we sell, including the €89/month entry tier, separates the two streams by default. The credentials we issue are per-stream — your application gets one set for transactional and one set for marketing. The HTTP API takes a stream parameter on every request. We route them through separate IP pools with separate reputation, separate suppression lists, and separate complaint thresholds. The cost of the second stream is zero. The cost of not having it is, eventually, the entire deliverability of your transactional channel.

The Validity 2026 benchmark backs this up directly: Real Estate sits at 97.1% inbox placement because transactional traffic dominates the category. Business Services sits substantially below the global 83.5% average because they routinely co-mingle the two streams. The category is not destiny — the architecture is.

Amazon SES is the cheapest at the per-message line — USD 0.10 per 1,000 emails when sending from EC2, USD 1.00 per 1,000 from elsewhere. For an AWS-native team running 100K+ transactional sends a month, the maths is hard to argue with. The trade-offs are real, though: shared infrastructure with reputation that fluctuates with AWS's other tenants, no native separation of transactional and marketing, manual SPF/DKIM/DMARC setup, dedicated IPs as a paid add-on (~USD 25 each), and your subscriber data sitting on a U.S.-controlled hyperscaler covered by the CLOUD Act. SES is the right answer if cost is the only constraint and you have AWS engineers on staff.

SendGrid is the legacy default. Acquired by Twilio in 2019, the PHP SDK alone has 44+ million Packagist installs. The API is mature, the integrations are everywhere, the documentation is exhaustive. The downsides at this point are well-documented: no native separation of transactional and marketing streams, customer support response is a frequent G2 complaint, and the pricing crosses over our €89 entry tier somewhere around the 50K/month volume band. SendGrid is the right answer if you need an integration that already exists and you cannot wait for us to build it.

Postmark is the gold standard for pure transactional traffic. They separate transactional and marketing streams natively, deliver fast, and run a clean focused product. The pricing is the highest in the segment — USD 138/month for 125K — but you get what you pay for on transactional reliability. Postmark is the right answer if you are doing only transactional, you do not need the operational depth, and you are happy to pay the premium for sub-second delivery on every single send.

Mailtrap is the newest serious entrant. Free tier of 4,000 emails/month, paid plans start at USD 15/month for 10,000 emails. Streams are separated by default. Authentication is automated. The Business tier at USD 85/month for 100K includes a dedicated IP and automatic warmup — which is genuinely competitive with our €89 entry tier on raw value. The trade-off is that Mailtrap is U.S.-controlled (Anaheim, California), so the CLOUD Act exposure is the same as SES.

Where we land in 2026: under 50K/month, SES is cheapest if you are AWS-native. 50K to 500K/month, our €89 entry tier wins on operational depth and EU sovereignty — especially if you have any European customer data in your subscriber list. Above 500K/month, the conversation shifts to dedicated MTA — PowerMTA or KumoMTA at €449-529/month, with all the operational and per-domain control that comes with it. We will tell you straight which side of those thresholds your situation falls on during the sales call.

Pricing comparisons in this category are usually presented at a single volume tier, which hides the curve. SES looks cheap at 1M messages per month and stays cheap. Postmark looks reasonable at 100k and gets expensive fast. SendGrid's pricing flattens differently than its marketing implies. We charge €89 at 100k and €599 from 500k — the curve below shows where each provider sits across four volume points, with the cost normalised per million messages so the comparison is direct. Numbers are euros at January 2026 published rates.

The cost-per-million curve crosses in interesting places. At 100k volume Postmark wins at roughly €15 per million effective rate. At 500k, SES has overtaken everyone at €4 per million on pure send-cost. We sit competitively per million at volume, with SendGrid at €748 and Mailgun at €670 — the second cheapest after SES, but SES is so far below everyone else that it is in its own category. At 5M the dynamic flips again. Bulk providers earn their reputation at this scale, with SES at €0.10 per thousand putting them well below us. We do not compete with SES at 5M+ volume on price alone. What we compete on is what is bundled at our price — dedicated IP, configuration access, real engineers reachable by ticket. SES is cheaper per message and gives you none of those.

The takeaway is that price-per-message is the wrong question for senders below 5M monthly volume. The right question is total operational cost — message price plus dedicated IP rental plus engineering hours when something breaks. SendGrid bills €748 per million at 1M and charges separately for dedicated IPs at €80 per month each. Mailgun bundles less. Postmark caps out before you would even consider them at 5M. Our top tier includes the IP, the warmup, and the operational support that a self-managed SES setup would cost ten engineering hours per month to replicate. The decision is not price. The decision is what you want to spend your team's time on.

Four operational realities specific to SMTP relay deployments at the 100k-to-1M volume range. The vendor space optimises documentation for either the get-started case or the enterprise case, leaving a gap in the middle where most buyers actually live. These are the failure modes we see across that middle range, with the numbers from real client incidents we resolved in the last eighteen months. None are exotic. All of them surface around month two or three after onboarding, when the operator stops watching the dashboard daily and starts trusting the service.

1 — Connection limits hit silently

The first thing that breaks is the connection limit at most ESPs. SMTP relay providers cap concurrent connections per customer somewhere between 10 and 50 depending on tier and load. SES caps at 50, SendGrid at 100 with their dedicated tier, Postmark at 50 across plans. The number that matters is not the cap itself but the queue behaviour when you hit it. SES rejects with a 421 deferral and your sender retries. SendGrid silently delays. Postmark queues internally and starts emitting bounce notifications that look like recipient-side issues but are not. We have audited senders who spent six weeks chasing what they thought was a Yahoo deliverability problem and was actually their own SendGrid account hitting the 100-connection cap during overnight batch sends. The fix is parallelism in the application layer, capped at 75 percent of the provider's published limit, not 100 percent.

2 — DKIM key rotation during silent provider migrations

Second is DKIM key rotation failures during silent provider migrations. SMTP relays rotate their DKIM signing keys on schedules they publish but rarely warn customers about. SendGrid rotates quarterly. Mailgun rotates twice a year. SES leaves the cadence to the customer but the documentation suggests it. The failure mode is that the relay rotates, your DNS still points at the old selector for a brief window, and authentication results turn from dkim=pass to dkim=neutral on the messages signed during the gap. Most operators never notice because the rotation is fast and the gap is small. The senders who notice are the ones whose downstream DMARC reporting flags the spike in neutral results during the rotation week, and even those operators usually misdiagnose it as a transient issue rather than a synchronised provider event. We schedule rotations to client maintenance windows specifically because most relays do not.

3 — Bounce processing latency burns reputation

Third is bounce processing latency. Cloud relays process bounces asynchronously and report them through webhooks or pulled APIs. The webhook delivery itself is usually fast, but the relay's internal categorisation and the propagation to your suppression list have lag built in. SendGrid takes 30 to 90 minutes to mark a hard-bounced address as suppressed. SES is faster but only if you have configured the SNS topic correctly — most do not. Postmark is the fastest at under 60 seconds. The operational consequence is that during a campaign send to a list with 2 percent invalid addresses, you can keep injecting messages to the same dead recipients for an hour before the suppression catches up, and that traffic counts against your reputation. We pre-suppress on inject by checking the address against a synchronised local cache, which adds 4ms to the request path and removes the issue entirely.

4 — Suppression list staleness during provider migration

Fourth is suppression list staleness when migrating between providers. The operator believes their suppression list is portable. It usually is not. SendGrid exports a CSV. SES exports a JSON paginated through an API call that nobody runs. Mailgun exports through a UI feature that times out at 100k entries. Postmark exports cleanly. The migration that goes wrong is the one where the list ships clean from the old provider but the new provider does not honour bounce categorisation in the same way — a SendGrid 5.7.1 Spam Detected arriving at the new provider gets re-categorised as a soft bounce and the address keeps receiving until it bounces again on the new infrastructure. We rebuild the suppression list during migrations from scratch using authentication-style probing on a sample of the list before turning on production traffic. The two days that adds to the migration save the four weeks of cleanup that the alternative produces.