Seven operational tests for your email infrastructure

Introduction

Every new customer or operational requirement has to work across customers, domains, delivery routes, and traffic types while the service keeps running. That puts the burden of change squarely on a sender’s email infrastructure. Meanwhile, the environment keeps changing. Mailbox providers tighten requirements, authentication standards evolve, customer traffic patterns shift, and abuse can appear without warning. Recent examples include:

• February 2024: Google and Yahoo introduced new requirements for bulk senders, including authentication, DMARC, and one-click unsubscribe.
• May 2025: Microsoft began enforcing SPF, DKIM, and DMARC requirements for domains sending more than 5,000 messages per day to Outlook.com consumer addresses.
• November 2025: Gmail introduced temporary and permanent rejections for non-compliant traffic.
• May 2026: The revised DMARC standard was published as RFC 9989 with RFC 9990 and 9991 covering reporting.
• Today: For the first time in nearly two decades, the Internet Engineering Task Force (IETF) is undertaking a major redesign of one of email's foundational authentication standards, DKIM2.

For a platform that sends on behalf of many customers, the requirements are only the starting point. Problems can develop even while the service appears to be running normally. One tenant's campaign fills the queues. A receiving provider slows acceptance. A second tenant asks why its login codes are late. Then a customer account starts sending email nobody intended to send.

A multi-tenant sender should be able to decide how its email service behaves as customer needs and conditions change. Modern, composable email infrastructure makes customer-level control, delivery insights, and safe change part of daily operations. The seven decisions below are a practical way to test whether your team controls the service, or whether inherited MTA limitations and workarounds control it for you.

Test 1

Shared IPs, shared exposure: deciding where customers need isolation

A shared IP pool can be the right choice for many of an ESP’s customers. It simplifies operations and may suit customers without the consistent traffic needed to establish a dedicated IP's sending history. But a shared pool also creates shared exposure for the ESP. If one customer's audience or sending practices generate complaints, other customers using the same IPs may feel the consequences unless effective counter-measures are in place.

Treat isolation as an enforceable policy across IPs, queues, and delivery priority, matched to each customer’s traffic and risk. If a transactional stream must remain responsive during a bulk campaign, its delivery path also needs protected resources or enforceable priority. A dedicated IP with the same constrained queues is an incomplete answer. At the other extreme, adding a pool for every request without a governing policy creates complexity the team will eventually struggle to operate.
 
A cloud email service may give you some control over how customer traffic is configured, while keeping deeper controls over queuing, prioritization, and tenant isolation within the limits of the platform. When trouble starts, your customers still hold you accountable for the outcome, even if you cannot isolate or change the affected traffic at the level you need.

Treat tenant identity and historical pool membership as essential operating data. That identity should follow email into the queue, so operators can investigate and act on one customer’s traffic without treating the entire queue as a single problem. An operator should be able to see who shares an IP now and who shared it when a reputation signal changed. Review pool assignments against current traffic rather than preserving old exceptions indefinitely. If a sender damages a pool, fix its sending practices or contain its traffic first; moving it to a healthy IP merely spreads the risk.

Share resources where it makes sense, but decide in advance how you will identify and contain the customer creating risk. If your only options are to move that customer to another IP or pause an entire pool, one customer’s mistake becomes everyone else’s service problem.

Test 2

How do you currently handle growth and sudden traffic peaks?

Picture two customers launching major campaigns on the same morning. At the same time, one receiving provider slows its acceptance rate. Your servers may have plenty of capacity to take in more email, yet a small queue of password resets could be waiting behind a much larger promotional send. Total throughput will not tell you whether the service is meeting either customer's needs.

Peaks require both processing capacity and control over delivery. An asynchronous sending engine can handle tens of thousands of concurrent transactions to keep email moving to healthy destinations while connections to slow or unresponsive destinations wait. Where the deployment supports autoscaling, capacity can grow with demand without the team adding servers by hand. Neither overrides a receiving provider's limits. Your delivery policy must decide what gets capacity, when to pace submissions, and how to release queued email as conditions improve.

You should also protect time-sensitive traffic with enforceable rules, not a label every tenant can apply to every message. Inspect queue age by customer and message type, test simultaneous bursts and unresponsive destinations, and set intake limits before backlogs become unmanageable. A recovering receiver should return to normal sending in a controlled way, not dump the entire backlog at once. This is how a shared service keeps one customer's campaign from delaying another customer.

Judge scaling by what happens to delivery when traffic peaks. A higher accepted-message count is a weak victory if the email that cannot wait is still waiting.

Test 3

Can you see what’s happening and act on it?

An aggregate delivery chart can look healthy while one tenant's traffic to a major mailbox provider is slowing down. An alert that says “deferrals increased” is technically correct. It still leaves the team to find the destination, affected customers, receiver responses, and queue state.

An operational view should connect every important change to the tenant, destination, IP, time window, receiver response, and queue state. Include email still waiting; completed-message reports alone can conceal the worst delays. Keep historical delivery data and transaction logs available, so the team can see whether the problem is new, recurring, or linked to a change in sending behavior. Put the evidence where deliverability and operations teams can inspect it without rebuilding a timeline across disconnected systems.

An alert is useful when it narrows the next decision. It should show who is affected, what changed, and which control the operator can apply at the right scope. Keep the limits of each signal visible: customer submission is not receiver acceptance, and receiver acceptance is not inbox placement. An external reputation warning against a shared IP identifies exposed customers, but it doesn't identify the cause. Once the team has identified the affected traffic, an authorized operator should be able to pause it or adjust its sending behavior without waiting for a code deployment.

Set a higher bar than 'we have dashboards.' Measure how long it takes to go from a signal to a justified customer-level action, with the underlying evidence available to the person making it.

Test 4

When your email service needs an expert

Your customers do not care whether a delivery problem sits in your code, your MTA, or a receiving provider’s systems. They expect your team to explain what happened and know what to do next. Give support and deliverability teams access to message status, receiver responses, queue state, and relevant policy decisions so a routine question doesn't start with a request for engineering to find the logs.

Some questions do need an email expert. A customer wants a new sending setup. You need to change routing without affecting other tenants. A migration behaves differently from the test. At those moments, direct access to people who understand email delivery and your implementation, whether in-house, or at your email infrastructure provider, can determine whether you move forward confidently or leave the customer waiting. Meanwhile, a ticket works its way through a queue.

Look at the product behind that support, too. When did your email infrastructure provider last release a capability your team could use? Regular, meaningful releases, clear documentation, and help applying new features show whether the provider helps your service evolve or leaves your team to build around its limits.

Great support helps you deliver a better service to your customers. It gives your team answers when something goes wrong and the expertise to act when you want to improve what you offer.

Test 5

How email infrastructure sets your speed to market

A customer asks for a new submission route, a tailored delivery policy, or an integration with an existing workflow. The capability is possible in theory. The practical question is what your team must build, review, and maintain before it can go live.

You may be able to move the layers you have built around your MTA to another sending setup. But moving them also means maintaining and extending them as new customer requirements, standards and delivery conditions emerge. Separate the logic that makes your service better for customers from the workarounds your team builds because the MTA cannot do what you need. Preserve the first; question whether you want to keep building the second.

There is a meaningful difference between 'you can script it' and 'your team can build it quickly and maintain it confidently.' An email-specific scripting language such as Halon’s Scripting Language (HSL) and ready-made components let engineers express routing, authentication, and delivery policy without first assembling layers of general-purpose code around a basic MTA. Compare the code needed for an actual customer requirement, including integration, testing, and rollback. Less code gives reviewers less to inspect, reduces risk, and builds confidence in the code's viability.

That's also what makes the infrastructure yours: the sending core is shared, the behaviour on top of it is shaped to your customers and your business.

Favor email infrastructure that supplies a dependable sending core and lets your team compose customer-specific behavior around it. A change should be testable, deployable in a controlled scope, observable in operation, and reversible when necessary. That combination lets engineers use flexibility without turning every request into a permanent exception. It also makes email infrastructure an enabler of the service roadmap rather than a gate the product team must work around.

Hold the provider's roadmap to the same practical standard as you do yours. Ask when the email infrastructure last gained a capability that let your team remove a workaround or launch something customers wanted. A regular release cadence  means little if the engineering work around the MTA keeps growing. A provider that maintains the core and develops useful email-specific building blocks gives your team more room to differentiate.

Speed to market comes from shortening the path between a customer need and a safe production change. That is where purpose-built email infrastructure can create a competitive advantage for a large-scale sender.

Test 6

Are you keeping pace with the latest email standards?

Authentication is not a one-time setup for a multi-tenant sender. Customers have different domains and DNS arrangements; signing keys must be rotated; requirements from standards bodies and mailbox providers change. A policy that works for one route must work consistently across the paths that the customer actually uses.

Make routine authentication changes repeatable for customers. A DKIM key rotation should include protected key handling, DNS checks, deployment across every relevant route, and a planned retirement of the old selector. Where appropriate, a customer-managed DNS alias can let the ESP rotate keys behind a stable record after initial onboarding. Design the process so routine rotation doesn't become a fresh DNS project for every customer, or a hidden dependency when you later change email infrastructure.

You should expect your email infrastructure provider to track standards work, ship supported changes, and give operators a safe way to learn before a new mechanism becomes a requirement. The DMARC revision often called 'DMARCbis' was published as RFC 9989 in May 2026, and DKIM2 remains an Internet-Draft with experimental implementations. It makes sense to observe DKIM2 alongside current DKIM and DMARC processing; it would be premature to let its results enforce production policy. Staying ahead requires disciplined testing and an email infrastructure provider who is engaged and up to date on the latest standards.

The real advantage is readiness: current authentication stays reliable while your team tests, understands, and implements the next requirement without disrupting every tenant.

Test 7

What is your last line of defense against customer abuse?

A customer can send legitimate email for months and become a risk in minutes. Credentials can leak, an application can be compromised, or a customer can upload an audience that should never have been used. The account may be authorized, and its email may pass DKIM. Authentication doesn't prove the traffic is wanted.

You should build abuse detection and enforcement close to the sending path. An alert in a separate dashboard is too slow if harmful email keeps leaving while teams work out which customer is responsible. Attribute each message to the tenant and credential behind it, combine behavioral and delivery signals with appropriate review, and give operators controls they can apply at that same scope. A seasonal campaign can look unusual, so the response must match the evidence.

Define containment before an incident. Your team should be able to pace, hold, or stop the responsible stream without shutting down unrelated senders. It must also decide what happens to email already accepted into queues and to traffic held during the investigation. Blocking new submissions alone isn't a complete stop; restoring access shouldn't automatically release the backlog. Design those choices into policy so confirmed abuse can trigger a proportionate response automatically, without a chain of manual handoffs.

Your last line of defense should be a controlled action in the email flow, with a known tenant and a known scope. No system can promise immunity from reputation harm, but every unnecessary minute between detection and containment increases the exposure shared by legitimate customers.

What these seven operational tests reveal about your email infrastructure

These seven operational tests reveal where your email infrastructure may be limiting your operations. There are other factors to consider when evaluating your service, but these questions give you a clearer understanding of how much your choice of MTA or email infrastructure shapes what your team can do.
 
Your email setup might be able to handle today’s volume and still slow the business down. How long does it take to put a new customer capability into production? To adjust delivery policy when a receiving provider changes its behavior? To reach an email expert who knows your setup when your team needs one? To trace a spike in deferrals to the affected tenants, queues, and delivery routes? 

If email keeps working, you might overlook these. But that has a cost. They consume engineering time, slow the product roadmap, increase operational effort, and affect the service your customers receive. Evaluating email infrastructure means looking beyond throughput and uptime to its broader operational and economic impact for your business as a whole.
 
If the same constraints keep appearing, your MTA or email infrastructure sets the pace for your roadmap and the service your customers receive. Your email infrastructure should give your team the control to launch customer capabilities faster, apply policy at the right scope, and understand what’s happening across tenants when delivery problems arise.