The email service you forget exists: engineering for tail risk

Almost every email delivery service looks good on a quiet Tuesday. Your application connects, the API returns 202 Accepted, Gmail accepts the message, the dashboard stays green, and the password reset arrives before the user finishes refreshing their inbox. Nobody opens a support ticket.

We process more than 100 million messages a day for hosting providers and platforms, including 25% of the world’s top 100 hosting companies, and we can tell you that the quiet Tuesday is not where email services are won or lost. The normal path is relatively easy. The hard part of email delivery lives in the tail: the rare, correlated, adversarial events that determine whether email stays invisible or becomes a company-wide incident.

In this post we explain what tail risk means for a multi-tenant email system, why the average message tells you almost nothing about it, and the seven layers of coverage we have built to manage it. We will also admit something: like most of the email industry, we have not always explained this part of the product well, because the whole point of doing it right is that customers never see it.

What the tail looks like

Consider a few events we deal with in production. A widely deployed WordPress plugin is compromised overnight and thousands of sites start relaying phish before breakfast. Credentials from hundreds of customer accounts are harvested at once. A phishing campaign mutates its content faster than static signatures can track it. A major mailbox provider quietly changes its throttling behaviour. A customer’s perfectly legitimate traffic starts to resemble an emerging abuse pattern. A queueing failure lands in the same hour as an abuse incident. A bulk SPF migration works for 99% of domains and breaks the unusual 1%. Several high-volume customers have incidents at the same time.

None of these is frequent. None of them is minor. They are correlated, they are often adversarial, and they can produce losses far out of proportion to their duration. That is email delivery’s tail risk, and for hosting providers, SaaS platforms, and other multi-tenant systems, managing it matters far more than the SMTP endpoint itself.

The average is not the product

Email providers publish average delivery latency, API availability, monthly message allowances, and feature checklists. Those numbers describe the centre of the distribution, and the centre is not where damage happens.

A platform does not usually suffer because its median message took 1.3 seconds instead of 900 milliseconds. It suffers when password resets stop arriving for four hours, when one compromised tenant contaminates the reputation of an entire IP pool, when the support team cannot identify which customer generated a phishing campaign, when a false positive blocks an important sender and nobody can investigate until the next business day, or when a provider suspends the parent account because one downstream user was abusive.

A useful way to think about the economics:

total email cost = provider fees
                 + routine operations
                 + expected incident losses
                 + cost of catastrophic risk

The provider fee is visible every month. The other terms are often invisible until something goes wrong.

Expected-value analysis also understates the problem, because email incident losses are fat-tailed: most events are small, and a few are extremely expensive. The more useful question resembles conditional value at risk, the measure financial risk managers use for exactly this shape of distribution: given that the system is having one of its worst hours, how bad does that hour get? That is a very different question from whether the API is pleasant to use.

Hosting email is an adversarial system

A conventional application has a small number of trusted sending systems. A hosting provider may have hundreds of thousands of independently managed websites, mailboxes, applications, and customer accounts, and any one of them can become hostile without warning.

The customer does not need to be malicious. A legitimate account becomes an abuse source through credential theft, a vulnerable plugin, a compromised CMS, an insecure contact form, malware, a stolen API key, or simply a customer importing a purchased mailing list.

This means the email provider is not moving data from point A to point B. For every message, it is deciding who is actually sending, whether this behaviour is normal for that sender, whether the content resembles an emerging threat, whether receivers are starting to reject the traffic, whether the message should be delivered, delayed, rate-limited, or blocked, and, if enforcement is needed, how to limit it to the offending sender and let the legitimate customer recover. That is closer to payment-fraud prevention or network intrusion detection than it is to operating a message queue.

Attackers also adapt. Once we learn to stop one technique, adversaries change domains, payloads, recipient patterns, sending rates, encodings, and account-acquisition methods. A policy that worked last month gets deliberately probed this month. We are not solving a stationary engineering problem; we are participating in an ongoing contest.

A worked example: 72 hours in the life of one phishing campaign

Here is what that contest looked like in our production traffic during a single week in August 2026.

Our daily abuse investigation flagged a German-language credential-phishing campaign impersonating Raiffeisen, the Swiss bank. The lure was the classic security pretext (“important update to your security preferences”), sent from a dedicated typosquat domain and aimed almost entirely at Swiss consumer ISP mailboxes. We assessed it as high confidence, built signatures against the subject line and the sending domain, and the campaign went to zero. It stayed dead for two days.

On day three it came back, mutated on both axes at once. Same actor, same Swiss victim set, but a fresh typosquat (raiffeisana.com, replacing the earlier raiffeisea.com) and a rewritten German subject line (“important information about your security settings”). The traffic was also shaped to evade detection: roughly 38,000 messages a day split across about 30 rotating random-labelled subdomains at roughly 1,000 messages each, with the sending mailbox rotating too. That snowshoe shape is exactly what you would choose to stay under any per-sender volume threshold, which is why our discovery sweeps aggregate by subject and count the number of distinct senders and domains behind each one. A campaign can hide its sending identity or its content, but hiding both from a cardinality sweep is much harder.

What we did next is the part we think is worth copying. Before enabling any block, we validated both candidate patterns against seven days of full production traffic, not just the actor’s traffic: the domain pattern matched 3 legitimate messages out of 85,998 total matches (a 0.0035% false-positive rate), and the subject pattern 3 out of 79,984 (0.0038%). Both patterns are held loaded, ready to enable the moment the campaign’s volume crosses our enforcement threshold, with the domain block preferred because a dedicated typosquat survives further subject rotation and the attacker cannot mutate away from it without abandoning the brand impersonation itself.

Notice what this discipline buys. We measure the blast radius of a block before we ever fire it, so enforcement never trades one incident (a phishing campaign) for another (legitimate mail silently rejected). And the same investigation that surfaced this campaign separated it cleanly from the sending account’s other traffic, a couple of thousand messages of ordinary shared-hosting noise, so the eventual enforcement hits the campaign rather than the tenant. One more detail from the same day’s report: the single largest content category in our accepted traffic was not a campaign at all but NDR backscatter, including one mailbox receiving over 85,000 bounce messages a day because an attacker had forged its address into a spam run. We do not block that mailbox, because doing so would punish the victim of the joe-job. Volume thresholds find candidates; judgment decides.

Visible features can be built quickly

Modern cloud infrastructure makes it possible to assemble an impressive email product in surprisingly little time: SMTP and REST endpoints, API keys, a dashboard, message logs, webhooks, templates, scheduling, per-user quotas, dedicated IPs. These are real capabilities, and feature velocity is valuable.

But a feature-complete dashboard is not the same thing as mature risk coverage. The hardest properties to evaluate are the ones that never appear in a product demo. How much hostile traffic has the system actually encountered? How quickly does it recognize a newly compromised sender, and how many malicious messages escape before containment? Does enforcement hit one sender or an entire customer account? Who responds at 3:00 a.m., and what happens when several incidents overlap? Has the architecture survived incidents substantially larger than the prospective customer’s traffic?

Visible feature parity can be achieved in months. Confidence in the tail has to be earned in production.

Scale is an input into risk management

We handle roughly three billion messages in an ordinary month. We do not view that as a throughput trophy. Scale matters because every large stream of traffic is an opportunity to observe new compromise patterns, phishing infrastructure, previously unseen content mutations, receiver-specific rejection signals, false-positive edge cases, and attacks distributed across apparently unrelated accounts.

We track senders individually and combine spam signatures, short-window behavioural statistics, external reputation data, and feedback from receiving mail systems to identify compromised senders. That volume does not make us infallible, and no serious security provider should claim to be. It does mean our controls are exercised continuously against real traffic, real compromises, and real adversaries.

Scale becomes valuable when it feeds a loop: observation leads to detection, detection to containment, containment to investigation, and investigation to better policy. Without that loop, scale is merely a larger blast radius. With it, scale is accumulated defensive experience.

Seven layers of email risk coverage

A reliable multi-tenant email service needs more than a spam classifier. Here are the layers we have found necessary, and how each one fails when it is missing.

1. Attribution

Before an abusive sender can be stopped, you have to know who it is. “Traffic came from server 12” is useless when server 12 hosts thousands of users. The identity that matters may be a hosting account, an authenticated mailbox, a website, a script, an API credential, or a particular message stream.

Poor attribution forces coarse enforcement: throttle the whole server, suspend the whole customer, or let a shared IP pool take the damage. Good attribution makes precise containment possible.

2. Behavioural detection

Content scanning is necessary but insufficient. A legitimate invoice and a phishing message can contain similar words, a compromised account may start with only a handful of messages, and an attacker can vary content on every attempt.

So the system must also watch behaviour: message velocity, historical sending patterns, recipient quality, failure rates, sudden geographic or application changes, repeated URL infrastructure, and how receivers respond. We evaluate dozens of per-minute statistics for individual senders, alongside signatures and receiver feedback. The objective is not merely to classify a message. It is to recognize that a sender’s behaviour has changed.

3. Containment

Detection without containment is observability, not protection. Once a sender appears compromised, we need a controlled response: reject a message, rate-limit a sender, temporarily suspend an identity, require remediation, notify the platform, preserve evidence, and give the legitimate customer a path back.

The containment boundary matters as much as the detection decision. We use both sub-accounts and sender IDs as isolation mechanisms. Sub-accounts carry separate credentials, limits, suppressions, webhooks, reporting, and suspension states; sender IDs provide a further reputation boundary within an account. The architectural goal is simple to state: one compromised sender should not become everyone’s incident.

4. Reputation isolation

Email reputation is shared state. A mailbox provider never sees your internal account hierarchy; it sees sending domains, authentication, traffic patterns, complaints, and IP addresses. Put unrelated senders into the same reputation boundary without adequate controls and one sender’s behaviour affects all of them.

Risk-aware delivery architecture therefore has to keep deciding which senders can safely share reputation, when traffic should be moved or isolated, how transactional mail is protected from promotional or high-risk traffic, how new senders are introduced, and what happens when a pool starts receiving negative feedback. This is not a one-time configuration. It is a continuous allocation problem.

5. Fleet-level observability

A hosting provider does not need another dashboard that lists messages. It needs to get from “customers are reporting email problems” to a precise diagnosis quickly: which sender is causing the problem, whether this is an isolated account or a coordinated campaign, when the behaviour began, what receiving systems reported, which legitimate users are affected, and whether the threat is already contained.

We provide fleet-wide log search, top-sender reporting, sender profiles, monitoring alerts, and automated shutdown webhooks for exactly this. The metric is not how attractive the dashboard looks. The metric is time to a safe, precise response.

6. Human operational depth

Automation should handle the ordinary cases, and ours does. But automation eventually meets ambiguity: a receiver changes its behaviour, a legitimate sender resembles a new attack, a classifier starts producing false positives, two independent incidents overlap. At that point the product includes the people behind it.

True 24×7 coverage requires more than forwarding alerts to one highly motivated engineer. It requires enough depth to cover nights, weekends, illness, incident overlap, specialist escalation, deliverability analysis, abuse investigation, and customer communication, all at once when necessary. We maintain 24×7 operations coverage with a team that has spent years inside email abuse. This capacity is invisible in a feature comparison and immediately visible during a severe incident.

7. Institutional learning

The final layer is memory. Every incident should leave residue: detection rules, reputation models, runbooks, monitoring, test corpora, architectural safeguards, and staff experience. The goal is that the organization never has to rediscover the same lesson twice.

Software holds part of this memory, people hold another part, and operational process connects the two. A competitor can reproduce the visible output of a policy without the history that explains why it exists, which exceptions matter, and what secondary effects appear under stress. That history is part of the service.

Measuring the tail: service levels for risk

Most email SLOs measure availability and latency. Those are necessary, but multi-tenant platforms should also measure risk outcomes. These are the questions we think a tail-risk service level should answer:

Tail-risk measure	What it asks
Detection latency	How long can a compromised sender operate before being recognized?
Containment latency	Once detected, how quickly is harmful traffic stopped?
Blast radius	How many innocent tenants are affected by one sender’s behaviour?
Escaped-message count	How much abusive traffic leaves before containment?
False-positive recovery time	How quickly can a legitimate sender be investigated and restored?
Concurrent-incident capacity	Can the provider manage several serious incidents at once?
Reputation recovery time	How long does legitimate delivery remain degraded after an incident?
Queue recovery integrity	Are messages lost, duplicated, or excessively delayed during recovery?
Migration error containment	Can configuration or DNS mistakes be caught before a fleet-wide cutover?
Human escalation time	How quickly can a qualified operator own an ambiguous problem?

A service can have excellent median latency while performing poorly against every row in this table. The Raiffeisen example above puts real numbers against several rows: detection latency measured in hours through daily cardinality sweeps, blast radius constrained by pre-validated false-positive rates below 0.004%, and enforcement scoped to a campaign rather than a tenant.

Migrations are tail-risk events too

Tail risk does not come only from attackers. It also appears at system boundaries and during change.

Consider a hosting provider updating SPF records across an entire customer fleet. The change may be correct for the majority of domains, but some customers use Microsoft 365 or Google Workspace, route mail through another provider, manage DNS externally, have hit the SPF lookup limit, rely on forwarding or unusual subdomain arrangements, or depend on undocumented legacy behaviour. A change that is valid for 99% of 100,000 domains still disrupts 1,000 customers.

A safe migration therefore requires more than technically correct documentation: inventory the exceptions, segment the population, test representative edge cases, run in parallel where possible, watch receiver responses, keep a rapid rollback path, and staff the cutover and the hours that follow. Migration engineering is part of risk coverage. The question is not whether the destination platform works. It is whether the transition can happen without transferring hidden risk to the customer.

Why the cheaper relay can become the expensive choice

Suppose Provider A costs $1,000 per month and Provider B costs $5,000. The apparent annual saving is $48,000, and if the two services offer comparable risk coverage, taking it is the right call.

The calculation changes if the cheaper service produces more abuse investigations for your staff, more delivery support tickets, a serious blocklisting event, hours of failed password resets, a fleet-wide configuration incident, or a growing dependence on one key individual who understands email. The correct comparison is never $1,000 versus $5,000. It is $1,000 plus retained risk versus $5,000 plus retained risk.

A mature managed service should absorb more of the risk. The price difference is, in effect, an insurance premium: the customer is paying not only for delivery but for a smaller probability of severe loss, and a smaller blast radius when loss happens anyway.

The paradox of invisible infrastructure

Our ambition is to be a service our customers can forget exists. Email should simply work. Their customers should not see unexplained rejections, their support teams should not spend mornings on blocklists, and their operations teams should not have to become experts in phishing campaigns and compromised WordPress sites.

This creates a paradox. When the service succeeds for long enough, the underlying problem appears to have disappeared. A hosting provider sees a monthly invoice, very few email incidents, very few escalations, and no need for an internal email-abuse team, and it is easy to conclude that the invoice is expensive because little visible work is occurring. The opposite may be true. The absence of visible incidents may be the output.

We have not always explained this well. Like much of the email industry, we have described the product in terms of message volume, filtering features, IP reputation, APIs, and dashboards, because those are easy to demonstrate and easy to put on a pricing page. They do not describe the risk being absorbed. If a customer can forget that we exist, we owe them legibility about the invisible work: how many compromised senders were contained, how much abusive traffic never escaped, how many unrelated customers stayed unaffected, how many incidents were handled outside their business hours, and how quickly false positives were restored. Reliability should not require a catastrophe to become visible.

Questions to ask any email delivery provider

If you are evaluating a multi-tenant email service, including ours, look past the feature matrix and ask:

1. What is the largest adversarial incident your system has handled in production?
2. How many independently attributed senders do you protect, rather than merely how many messages your infrastructure can relay?
3. How quickly do you typically detect and contain a compromised sender?
4. What is the maximum blast radius when one downstream customer becomes abusive?
5. Who responds to a complicated incident outside business hours, and how many incidents can they handle concurrently?
6. How are false positives investigated and reversed?
7. What receiver feedback is incorporated into policy decisions?
8. How are lessons from prior incidents preserved in software, monitoring, and runbooks?
9. How would you safely migrate a large, heterogeneous domain fleet?
10. What happens when your automation is uncertain, and what part of the risk remains with me?

These questions are harder to answer than “Do you support webhooks?” That is precisely why they are more useful.

Boring is an engineering achievement

The best email infrastructure is boring. It does not generate executive escalations, wake the customer’s operations team, or turn one compromised website into a fleet-wide delivery problem. That kind of boring is not the absence of engineering. It is the result of scale, isolation, observability, automation, adversarial experience, operational depth, and institutional memory, compounding over years.

An SMTP transaction lasts a fraction of a second. The system behind it represents years of accumulated decisions about what can go wrong.

When you evaluate an email delivery provider, do not look only at what happens to the average message. Look at what happens during the worst hour of the year. That is where the product is. If you want to see how we answer the questions above, ask us; we would rather be evaluated on our worst hour than on our dashboard.