What an MTA actually does
MX resolution — looks up the recipient domain's mail servers in DNS.
SMTP delivery — opens a connection to the receiving MTA, performs HELO/EHLO/STARTTLS, transfers the envelope and body.
DKIM signing — signs the outgoing message with the customer's private key before transfer.
Retry on transient failure — 4xx replies cause the message to re-queue with exponential backoff for some period (typically up to 72 hours).
Bounce + complaint feedback — translates SMTP-level failures into structured events your application can act on.
Self-hosted vs managed
Running your own MTA (Postfix, Exim, OpenSMTPD, Haraka) is well-documented and cheap on paper. The hidden cost is reputation management: a fresh IP needs weeks of warmup, suppression must be hand-built, bounce parsing varies per ISP, and TLS-RPT / MTA-STS observability is yours to wire up.
Managed MTAs (SNDR's pool, Postmark, Mailgun, SendGrid) abstract all of that. The trade-off is per-message cost vs engineer hours — break-even is typically well under a million messages per month for most teams.
Why SNDR runs a multi-MTA pool
A single MTA has a single IP-reputation profile. If that IP gets greylisted at one ISP, your entire send rate at that ISP suffers.
SNDR routes traffic across a pool of MTAs we operate, sticky-by-recipient-ISP: Gmail consistently sees you from one IP, Outlook from another, Yahoo from a third. Reputations build in parallel. A circuit-breaker drops misbehaving pool members automatically. The customer-visible dashboard shows per-MTA delivery curves so a single bad box surfaces before it affects aggregate metrics.