How to Evaluate Email Infrastructure Providers

• April 2022

Selecting an email infrastructure provider is one of the most consequential technical decisions a commercial email programme makes. This note documents the evaluation framework and the questions that matter most.

The email infrastructure provider decision determines what operational capabilities are available to the programme, what monitoring depth is achievable, how quickly incidents can be diagnosed and resolved, and what deliverability ceiling the programme can reach with its current list quality and reputation. Most programmes evaluate providers primarily on price — per-message costs, monthly minimums, IP hosting fees — without adequately evaluating the operational capability differences that determine whether the infrastructure investment produces its intended deliverability outcomes. This note provides the evaluation framework that makes the infrastructure provider decision evidence-based rather than price-led.

Evaluation Dimension 1: Accounting Log Access

The most important infrastructure capability to evaluate is accounting log access: what delivery event data does the provider make available, in what format, and at what granularity? The correct answer is per-event structured data with full SMTP response text — the PowerMTA accounting log format that enables the monitoring practices documented in this library. The incorrect answer is API-based aggregate delivery statistics (total delivered, total bounced, per-domain summary) that lack the per-event granularity needed for accurate bounce classification, per-ISP deferral rate analysis, and delivery pattern diagnostic work.

Evaluation questions for accounting log access: Can I query individual delivery events with the full SMTP response text? Can I filter delivery events by recipient domain, bounce classification, and response code? Can I export raw accounting log data for processing in my own analytics infrastructure? Is the accounting log data retained for at least 90 days and available in real time (not batched with 24-hour delay)? A provider that cannot answer yes to all four questions cannot support the operational monitoring practices that professional deliverability management requires.

Evaluation Dimension 2: Per-ISP Configuration Control

Per-ISP configuration control determines whether the provider can calibrate connection limits, retry sequences, and message rates separately for each major ISP destination. Without this control, a single set of connection parameters applies to all ISP destinations — which means the configuration is sub-optimal for every specific ISP because no single configuration can be optimal for Gmail's rate limits, Microsoft's per-session behaviour, Yahoo's burst sensitivity, and EU ISPs' aggressive greylisting simultaneously.

Evaluation questions for per-ISP configuration: Can connection limits be set independently for Gmail, Yahoo, Microsoft, and individual EU ISPs? Can retry sequences be customised per ISP? Can message rate limits be set at different values for different ISP destinations? Can these settings be changed without service disruption when reputation levels change? Providers that manage multiple customers on shared infrastructure typically cannot offer per-customer per-ISP configuration — their configuration serves the pool, not the individual programme.

Evaluation Dimension 3: IP Reputation Isolation

IP reputation isolation determines whether the programme's reputation is built exclusively from its own sending behaviour or shared with other senders on the same IP pool. Dedicated IPs, warmed by the specific programme and used exclusively for the specific programme's traffic, provide complete reputation isolation. Shared IPs, used by multiple senders simultaneously, provide no reputation isolation — a co-tenant's poor campaign can damage the pool's reputation and affect the programme's delivery performance.

Evaluation questions for IP reputation isolation: Are the IPs dedicated to this programme exclusively? Who controls the reputation management practices for the sending pool? If a co-tenant generates a reputation event, what impact could it have on this programme's delivery? What is the process for emergency IP rotation if a pool IP is listed on a major DNSBL? The correct answer to the first question is "yes, dedicated IPs used only for this programme." Any answer that includes "shared pool" represents the co-tenant risk that dedicated infrastructure eliminates.

Additional Evaluation Dimensions

Traffic type isolation (VMTA): Can different traffic types (transactional, promotional, cold email) be isolated on separate VMTAs with separate IP pools and domain configurations? Traffic isolation prevents the reputation contamination that commingled traffic produces. A provider that cannot offer VMTA-level traffic isolation forces all traffic types to share a single reputation pool — which is operationally limiting for any programme with multiple traffic types of different quality levels.

Warmup support and experience: Does the provider include IP warmup planning and execution in its service? What warmup schedules do they recommend? Do they monitor warmup progress through Postmaster Tools and adjust volume based on reputation signals, or do they follow a fixed schedule regardless of reputation outcomes? A provider with genuine warmup expertise calibrates the warmup schedule to the programme's specific audience and reputation signals; one without warmup expertise applies a generic schedule regardless of what the data shows.

Incident response: What is the provider's process when a sending IP is blocklisted or when a reputation event occurs? Can they respond within hours, or does incident response take days? Do they proactively monitor for reputation events, or do they wait for the customer to report a problem? A managed infrastructure provider should be detecting incidents before the customer notices them — through daily Postmaster Tools monitoring, SNDS review, and accounting log anomaly detection.

Evaluating infrastructure providers on operational capability rather than price alone produces a selection decision that serves the programme's long-term deliverability interests rather than its short-term cost minimisation interests. The cheapest infrastructure option that lacks per-event accounting log access, per-ISP configuration control, and dedicated IP reputation isolation will cost more in incident investigation time, co-tenant risk exposure, and sub-optimal throughput than the difference in price between that option and a correctly capable provider. Evaluate the full capability stack; make the selection on capability first, price second; and the infrastructure investment will deliver the deliverability performance that the programme's commercial objectives require.