Email infrastructure: the sending stack layer by layer, and which layers you own

"Email infrastructure" gets used for everything from a DNS record to a data center, and the vagueness costs something, because the parts are owned by different people and fail in different ways. Between the code that creates a message and the mailbox that files it sits a stack: a submission point, transfer servers with queues, an IP address with a name, a domain that vouches for the mail, encryption on the wire, and a return channel of bounces and complaints. This page maps that stack, states what each layer has to do, and points to the guides that go deep on each one. Treat it as the index to our infrastructure guides.

The reference model

RFC 5598, the IETF's Internet Mail Architecture (an informational document from July 2009), names the roles. A Message User Agent creates mail. A Mail Submission Agent accepts it into the system and enforces local policy. A mail transfer agent relays it one hop at a time, and a Message Delivery Agent files it into the recipient's mailbox. Those roles are spread across independently administered domains: yours, your sending provider's, and the recipient's mailbox provider.

The boundaries matter because responsibility moves across them. Under RFC 5321, the SMTP specification, a server that accepts a message accepts responsibility for delivering it or reporting the failure. Every layer below is a place where your mail changes hands, and where you either control the outcome or choose who does.

Layer 1: submission

This is your application's first handoff. RFC 6409 reserves port 587 for message submission and says the submission server must, by default, refuse mail from sessions that have not authenticated, while server-to-server relay stays on port 25. RFC 8314 (January 2018) adds implicit TLS on port 465, asks clients and servers to support both during the transition, and encourages implicit TLS as the long-term model. Most sending providers also offer an HTTP API as a second doorway into the same pipeline. The trade-offs are covered in SMTP relay; in short, SMTP suits software you cannot change and an API suits code you are writing now.

Layer 2: transfer and queues

The MTA looks up the recipient domain's MX record, connects, and either hands the message over or queues it. RFC 5321 sets the manners. Mail that cannot be sent immediately must be queued and retried; the retry interval should generally be at least 30 minutes, the give-up time at least four to five days, and the retry parameters must be configurable. Servers must accept at least 100 recipients per transaction, and clients should be ready to send in 100-recipient chunks when a server takes no more.

What the RFC leaves open, receivers fill in. Mailbox providers meter how fast they accept each sender's mail and answer excess with a deferral. Sending systems answer back with email throttling: limits on connections and rate, set per destination. Queue depth and age are this layer's health signals, and they usually move before any placement report does.

Layer 3: network identity

Receivers see an IP address before they see a single header, and they check its name. Google's sender guidelines require a PTR record for every sending IP, with the hostname it names resolving back to the same address. Yahoo asks for valid, meaningful, non-generic reverse DNS on all sending IPs. The M3AAWG Sender Best Common Practices (version 3.0, February 2015) spell out the same discipline: one reverse DNS name per IP, a name that identifies a mail server rather than generic pool space, and a HELO name that resolves.

Then comes the question of who else uses the address. On a shared IP, a provider pools many senders so that their combined volume keeps the address's reputation steady; on a dedicated IP, the history is yours alone. The M3AAWG paper notes that consistency of volume, whether high or low, plays an integral part in IP reputation, which is the heart of the dedicated IP vs shared IP decision. A new dedicated address needs IP warming, and any address you inherit deserves a pass through the blacklist checker and the reverse DNS checker.

Layer 4: domain identity and authentication

The IP is often rented; the domain is always yours, and it is the identity mailbox providers increasingly grade. Three standards carry it, explained together in SPF, DKIM and DMARC:

• SPF (RFC 7208) lists the servers allowed to send for the envelope domain and caps evaluation at 10 DNS-querying terms, beyond which the result is a permanent error, the failure described in SPF too many DNS lookups.
• DKIM (RFC 6376) signs each message with a domain key. RFC 8301 sets 1024-bit RSA as the minimum, recommends 2048 bits, and forbids rsa-sha1.
• DMARC ties both to the visible From domain. RFC 9989 is the current standard; it obsoletes RFC 7489 and folds in a testing flag and a policy for non-existent subdomains.

Beyond the triad, the Return-Path domain decides where bounces go and which domain SPF checks, and each mail stream earns its own subdomain. Mailbox providers have turned all of this into entry requirements. Gmail requires SPF, DKIM and DMARC from senders of 5,000 or more messages a day to personal accounts, and Outlook.com began enforcing the same three for domains over 5,000 a day on 5 May 2025. The details live on the Gmail and Outlook requirement pages.

Layer 5: encryption in transit

Google lists a TLS connection among the requirements for everyone sending to personal Gmail accounts. Two newer standards protect the other direction, mail sent to your domain. MTA-STS (RFC 8461, September 2018) lets a domain publish a policy, through a DNS record and an HTTPS-hosted file, naming its mail servers and telling senders whether TLS failures should block delivery. TLS-RPT (RFC 8460) lets it collect daily aggregate reports on TLS negotiation, failures included, from those senders. For a sending operation the duty is reciprocal: negotiate TLS reliably, because an MTA that honors an enforce-mode policy will not deliver to that domain without valid TLS.

Layer 6: feedback

Infrastructure that only sends is half built. Bounces return as delivery status notifications, sent with an empty return path under RFC 5321 so they cannot loop, to the address in your Return-Path; parsing them into a suppression list is basic hygiene. Complaints return through feedback loops, typically in the Abuse Reporting Format defined in RFC 5965, and Yahoo's sender requirements call for an active complaint feedback loop on every DKIM domain. Reputation data comes from the receivers' own consoles: Google's Postmaster Tools and Microsoft's SNDS, covered in Microsoft SNDS. Authentication evidence arrives as DMARC aggregate reports, which the DMARC report analyzer parses.

Rent, run, or split

Almost nobody builds every layer. The realistic question is which layers you rent from an email service provider or relay, and which you operate yourself.

| Layer | When you rent it | When you run it | |---|---|---| | Submission | Provider's SMTP endpoint or API | Your own authenticated submission server | | Transfer and queues | Provider's MTAs, retries and per-receiver pacing | Your MTA, tuned per destination | | Network identity | Shared pool, or a dedicated IP the provider hosts | Your IPs, PTR records and blocklist monitoring | | Domain authentication | Still yours: the provider supplies SPF includes and DKIM keys, you publish them | Yours entirely | | Encryption in transit | Provider's TLS stack | Your certificates and TLS configuration | | Feedback | Provider collects bounces and complaints and exposes events | Your bounce parser, feedback-loop enrollment and suppression store |

The domain row is the one that never transfers. Your DNS vouches for your mail whoever sends it, which is why every provider change starts with authentication records. Renting the rest is the default for good reasons: warm, monitored IPs and tuned retry logic embody years of operating history. Running your own makes sense when volume, isolation or compliance needs justify owning that history, along with the obligations the mail transfer agent entry lists.

When comparing providers, our category listings for transactional email services, SMTP providers and email API services group the options; they are listings, not rankings. Checkable questions separate the candidates: does the provider document its IP pool policy, let you sign DKIM with your own domain, expose bounce and complaint events, and publish its sending limits? Application mail adds requirements of its own, collected in transactional email best practices.

Auditing a stack, in order

Cheapest checks first, each one ruling out a layer:

1. Domain records. Run the email DNS check, then confirm alignment with the email authentication checker.
2. Network identity. PTR and matching forward DNS for every sending IP, and a clean blocklist history.
3. Transport. Confirm TLS and authentication results on a delivered message with the email header analyzer.
4. Feedback. Confirm that bounces reach a parser, complaints reach suppression, and DMARC reports reach a person.
5. Behavior. Read a month of deferral and bounce rates per receiving domain; if something is already wrong, the deliverability troubleshooter orders the diagnosis.

Related guides

• SMTP relay — submission and relaying as a product you rent
• Mail transfer agent — the queue and retry software of layer 2
• Email subdomain — giving each mail stream its own domain identity
• Dedicated IP vs shared IP — choosing whose reputation layer 3 carries
• SPF, DKIM and DMARC — the authentication standards of layer 4
• Email DNS check — audit a sending domain's records in one pass

About this guide

Written by InboxRatio Editorial. The architecture model follows RFC 5598; submission follows RFC 6409 and RFC 8314; transfer and retry behavior follows RFC 5321; authentication follows RFC 7208, RFC 6376 with RFC 8301, and RFC 9989; transport policy follows RFC 8461 and RFC 8460; complaint report format follows RFC 5965. Reverse DNS and volume-consistency guidance follows the M3AAWG Sender Best Common Practices version 3.0 and Google's and Yahoo's sender requirements; the Outlook.com enforcement date follows Microsoft's postmaster documentation. The rent-versus-run table is editorial synthesis. No vendor sponsorship influences it.

Methodology

InboxRatio's benchmark sends real campaigns through the platforms we review to a controlled seed list and records where each message lands. This guide draws on protocol and provider documentation rather than our measurements; the protocol is in how we test and our source rules in sources.

Last updated

15 October 2026. RFC references and provider requirements reviewed quarterly.

Frequently asked questions

What is email infrastructure? The systems that move a message from the application that creates it to the recipient's mailbox: submission servers or APIs, mail transfer agents and their queues, sending IP addresses with reverse DNS, domain authentication records, transport encryption, and the bounce and complaint channels that report back.

What are the main components of email infrastructure? Six layers: submission, transfer and queuing, network identity (IPs and PTR records), domain identity (SPF, DKIM, DMARC and the Return-Path domain), encryption in transit, and feedback (bounces, feedback loops, postmaster data and DMARC reports).

Do I need to build my own email infrastructure? Rarely. Most senders rent submission, transfer and IPs from a sending provider and keep the domain layer, which cannot be outsourced because it lives in your DNS. Running your own MTAs and IPs makes sense when volume, isolation or compliance needs justify the operational load.

What is the difference between an MTA and an email service provider? An MTA is the software that relays mail between servers, queues it and retries it. An email service provider is a company that operates MTAs, IP pools, bounce processing and tooling as a service. Every provider runs MTAs; few senders who use a provider ever touch one.

Which parts of email infrastructure do mailbox providers check? The ones they publish as requirements: SPF or DKIM authentication, reverse DNS for sending IPs, TLS and a spam-rate ceiling for every sender, plus DMARC and one-click unsubscribe for bulk senders. Reputation built on the IP and domain layers then shapes filtering beyond those minimums.

Can I change email providers without rebuilding everything? Mostly. The domain layer stays yours, but it needs updating: the new provider's SPF include, new DKIM keys under a new selector, and aligned bounce domains. New IPs start cold and need warming, so overlap the providers rather than cutting over in one send.

Infrastructure is the part of email nobody notices until one layer breaks. Know who runs each layer of yours, keep the domain layer verified, and start every review with the email DNS check.