Outbound Email Infrastructure: Build and Verify Each Layer

Outbound email infrastructure needs six responsibilities covered: domain authentication, mailbox identity, sending reputation, DKIM signing, queueing and retries, and feedback with suppression. Use them as a checklist for what you build, buy and verify. An accepted API request is only one step; it does not prove that the recipient server accepted the message or that it reached an inbox.

Contents

• The six responsibilities

• Domains and authentication

• Mailbox identity

• Sending reputation

• Queues and retries

• Feedback

• Suppression

• Routing

• Diagnosis

• Sendmux

• Security

• Templates

• Retry policy

• Compliance

• Rollout

• Sources

• FAQ

What does outbound email infrastructure include?

Outbound email infrastructure covers the path from an authorised application request to delivery attempts and their recorded outcomes. The following responsibilities need clear owners, whether they live in your application, a provider or a managed service. They do not require six separately deployed services.

Separate transactional and marketing workloads where their urgency, consent rules or failure budgets differ. That may mean separate queues and limits rather than separate physical IPs. The Vetora email-system template offers one architecture to examine; its partition counts and worker sizes are examples, not capacity measurements for your workload.

Prepare domains and authentication

A sending subdomain can organise authentication and traffic separately from your main website. It does not guarantee reputation isolation or make aggressive testing harmless. Google counts related subdomains towards the same primary domain when identifying bulk senders, so test with controlled recipients and verify the received message rather than treating DNS records as sufficient evidence.

Publish SPF for the envelope-sender domain using only the services authorised to send for that identity. This illustrative record combines Amazon SES and Google; it is not a copy-ready configuration and is appropriate only if both belong in that domain's sending policy. Check the providers' instructions and your complete existing record before making a change.

v=spf1 include:amazonses.com include:_spf.google.com ~all

DKIM signs selected message content and headers; the receiver checks the signature against a public key in DNS. Publish the actual key supplied by your signing system. The value below is a placeholder, not a usable key. During rotation, verify the new selector before retiring the old one and account for queued messages and DNS caching.

selector1._domainkey.mail.example.com TXT "v=DKIM1; k=rsa; p=REPLACE_WITH_ACTUAL_PUBLIC_KEY"

DMARC checks whether at least one successful SPF or DKIM authentication result aligns with the visible From domain. A policy such as the illustrative record below requests handling of failures and names an aggregate-report destination. Replace the domain and reporting address with ones you control, and check that reporting is configured correctly.

_dmarc.mail.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

An initial monitoring policy can help discover legitimate senders before enforcement changes. Move towards quarantine or reject only after examining alignment and legitimate traffic; an existing well-understood domain need not follow a new monitoring stage if its legitimate senders and alignment are already verified. Google's sender requirements distinguish all senders from bulk senders and allow a monitoring DMARC policy for the latter. Set DNS TTLs around your change process rather than assuming one universal value.

For Amazon SES, custom MAIL FROM is configured on a verified email or domain identity. Verify its required DNS records and alignment separately from DKIM. Complete and test authentication before increasing traffic; allow time to resolve failed checks before launch.

Choose mailbox identity and credentials

Decide whether messages should come from individual reps, application identities or a shared platform sender. Keep the relationship between your application user, sender address and reply destination explicit. An individual mailbox can preserve that identity and its message history, but it does not automatically create independent reputation or guarantee that every reply joins the intended thread.

Choose OAuth, SMTP credentials or an HTTP API key according to the provider's supported permissions and integration requirements. OAuth can authorise Gmail or Microsoft accounts; SMTP credentials can also be scoped by a provider. HTTP alone does not guarantee tighter permissions, batching or better rate controls. Check the actual credential contract, restrict access and make revocation part of the operating procedure.

For each integration, record which mailboxes and sending routes it can use, where its secret is stored and how to suspend it. Sender allow and block rules need an explicit direction: filtering incoming mail is different from suppressing outgoing mail to a recipient. Test those boundaries instead of assuming one policy covers both.

Choose sending IPs and control volume

Shared or dedicated IPs should be chosen using traffic consistency, provider guidance and your ability to manage reputation. Amazon SES documents the trade-offs: shared IPs suit variable patterns, while standard dedicated IPs require warmup and consistent volume. Increase volume gradually and review actual outcomes rather than applying a fixed warming calendar.

Set provider-specific warning and pause rules before a campaign starts. The email-service system-design example proposes a complaint-based pause, but its threshold is an illustrative design choice. For Gmail, Google recommends keeping user-reported spam below 0.1% and avoiding 0.3%. Those Postmaster Tools figures are not universal per-IP quarantine thresholds.

Where IP-level data is available, use it alongside domain, campaign and provider data. If abuse or poor list quality appears, pause the affected traffic and investigate. Moving the same harmful campaign to another IP does not solve its cause. Separate healthy traffic where the provider supports it, with a controlled recovery decision before resuming the affected stream.

Design queues for recovery

Validate and durably accept work before returning an asynchronous acknowledgement. A queue can separate an application request from later sending attempts, but it still needs capacity limits and backpressure. Give authentication messages and password resets enough capacity that a large campaign cannot consume their entire processing budget. Separate pools or queues are options to evaluate, not mandatory physical boundaries.

Rendering, signing, delivery and callback processing may have different failure and scaling needs. Measure those needs before choosing partitions and workers. Partitioning by recipient domain can help pacing, but a fixed partition count is not a substitute for load testing, monitoring queue age and checking whether one destination is dominating the workload.

An atomic claim and a visibility timeout help workers recover abandoned jobs. A reaper can make expired claims available again. They do not establish exactly-once delivery: a worker can send successfully and crash before recording that result. The claim-and-reaper walkthrough explicitly discusses this remaining duplicate window. Preserve attempt state and reconcile uncertain acceptance where the provider allows it.

Use a stable idempotency key for one sending intent, and keep it when retrying the same request. Bind that key to the request parameters and document its retention window and replay result. A duplicate may return the original result rather than an error. AWS's idempotent API guidance explains why durable recording and equivalent responses matter; the key alone is not an unlimited duplicate-prevention guarantee.

Collect feedback before increasing volume

Track bounce outcomes, complaints, latency and provider errors alongside accepted-message counts. Break them down by campaign, sender, recipient domain and IP where the provider exposes that data. A bounce spike is a reason to inspect addresses and diagnostics, not proof of one cause. Define warning thresholds using the provider's rules and your own measured baseline.

Where supported, receive events through webhooks instead of relying solely on periodic polling. Verify signatures using the provider's documented procedure and deduplicate event IDs before changing state. Acknowledge events only after recording the work you need to retain. Retry windows, permanent failures and event coverage vary, so keep a reconciliation path for missed or uncertain outcomes.

Review DMARC reports, available complaint feedback and campaign history together. Use those signals to find unauthorised senders, alignment problems or a deteriorating audience segment. Assign someone to investigate alerts and record decisions; dashboards without an owner do not establish a recovery process.

Classify bounces before suppressing

Treat the SMTP response, enhanced status code and diagnostic as separate evidence. A permanent transaction failure is not always an invalid recipient: 550 can mean a missing mailbox, denied access or a policy rejection. RFC 5321 defines those alternatives. Suppress confirmed invalid addresses under your recipient policy; fix authentication or policy problems at their cause.

Keep suppression durable and check it before expensive rendering, then enforce the current decision before sending. A cache may speed the check, but define freshness and failure behaviour; a probabilistic filter should not be the sole authority for a sending decision. The Sendmux bounce handling guide explains useful status-code classes and examples. It is a starting point for classification, not an exhaustive code-to-action policy.

Require a recorded reason and appropriate authority for any suppression override. Keep unsubscribe, complaint, invalid-address and provider-level safety decisions distinguishable. Their scope and restoration conditions differ, and some provider policies remain in force even when your application changes its own list.

Pace and route outbound email

Control concurrency and pacing by destination and provider, using the limits each service documents and the responses it returns. Gmail, Outlook and Yahoo can respond differently to the same traffic pattern. A slowdown is not necessarily an undisclosed volume limit. Reuse supported connections where appropriate, and reduce pressure on a destination that is temporarily rejecting traffic.

Weighted routing and quota checks can distribute eligible work across configured providers. Keep provider errors separate from recipient failures, honour credential and sender constraints, and preserve attempt identity during failover. Route changes must not evade policy enforcement or continue an abusive campaign. Check what was accepted before deciding another provider can safely try the message.

Maintain a stable, monitored sending configuration while testing changes deliberately. Audience quality still matters: the list-growth guide discusses growth and list-health practices. It does not establish that one IP strategy always outperforms another, so judge routing and reputation changes from your own delivery evidence.

Diagnose delivery problems

Start with a received test message's authentication results, then examine a representative sample of recent failures. Segment diagnostics by recipient domain, campaign, provider and sender. Compare policy errors, deferrals, queue age and latency before changing volume or routing. A sudden drop at one destination narrows the investigation; it does not prove a particular hidden limit.

SMTP.com's discussion of sending behaviour treats hard-bounce rates above 2% as a warning sign. Use that as attributed guidance, not a universal command to quarantine an IP. Review the current provider policy, list source, consent and actual failure reasons before selecting a response.

Use Google Postmaster Tools and Microsoft SNDS where available for their respective networks. Combine those views with your own event and message records. If you escalate to a provider, include timestamps, identifiers and representative diagnostics rather than assuming one dashboard explains every delivery problem.

Where Sendmux fits

Sendmux is an email API for AI agents and SaaS platforms, combining persistent inboxes with outbound sending. Custom-domain or shared-domain mailboxes can retain messages, threads, folders and attachments. Standalone Sending credentials also exist, so a sending identity is not automatically a persistent mailbox. Keep your application identities mapped to the appropriate mailbox or sending credential.

Use the Mailbox API for mailbox-scoped message access and sending, the Management API for account-level provisioning, and the Sending API for outbound workloads and provider routing. Mailbox permissions include mailbox.read, email.receive and email.send; grant only those the integration needs. A mailbox credential narrows access, but it does not guarantee independent sending reputation or eliminate every effect of a leaked secret.

Sendmux supports outbound accounts connected through Gmail, Outlook or custom SMTP, alongside managed Amazon SES. Delivery groups and configured quotas and weights govern eligible routes. Shared myagent.mx mailbox sending uses the managed route; it is not a free choice among every connected provider. Check account status and routing scope instead of assuming automatic failover can resolve every provider or reputation problem.

Webhooks report documented inbound and outbound events; SSE supports live inbound notifications. Verify webhook signatures and keep an event-reconciliation path. Clean message content offers controls for stripping quoted replies and signatures, with truncation and processing indicators. Retain message identifiers and thread state; these tools reduce repeated processing but do not guarantee perfect extraction or remove all need to reconcile state.

Secure credentials and mail submission

Require verified TLS for controlled authenticated submission and configured relays. Submission may use implicit TLS or required STARTTLS according to the service; Internet mail relay has different policy constraints. TLS protects a connection, not the message end to end. RFC 8314 addresses access and submission, while RFC 3207 describes SMTP STARTTLS and local policy.

Prevent unauthorised relay by requiring the right authentication and sender permissions; use network restrictions where the deployment supports them. Store retrievable secrets in an appropriate managed secret store, restrict access and plan rotation and revocation. Avoid exposing secrets in logs and limit who can retrieve provider credentials.

Alert on unusual sending patterns and compare them with expected workloads. An after-hours spike may be legitimate automation or compromise; investigate the context and apply a documented pause policy. Least privilege limits exposure, but test what a compromised credential could actually read or send rather than assuming its effects cannot cross operational boundaries.

Validate templates before enqueueing

Validate required fields, escape untrusted values and test empty, long and unexpected inputs before accepting a template job. Use fallbacks only for fields that can safely be omitted; a missing required field should stop that job with a useful error. Keep a rendering failure from repeatedly blocking unrelated work, whether through separate queues or deliberate error handling.

Check merge tags, visible sender details and dynamic links in the final rendered message. Cache reusable template structure without sharing personalised output across recipients. Keep plain-text and HTML versions consistent, and inspect both. These checks improve correctness and readability; they do not guarantee a particular spam-filter result.

Separate submission retries from delivery retries

Application retries and SMTP delivery retries solve different problems. For an application request, use bounded backoff with jitter, respect provider retry instructions and retain the original idempotency key. A timeout after submission can leave acceptance uncertain; reconcile it before creating another sending intent. Record exhausted attempts for investigation rather than silently discarding them.

An SMTP sender may retain responsibility for delivery attempts much longer. RFC 5321 describes configurable retry parameters, generally waiting at least 30 minutes between retries and a give-up period of at least 4 to 5 days. A fixed three-to-five-attempt application schedule is not that SMTP policy. The same RFC warns that a lost final acceptance reply can cause duplicates, which a job reaper alone cannot prevent.

Apply the right marketing and privacy rules

For US commercial email, the FTC's CAN-SPAM guide requires truthful routing and subject information, a valid postal address and a working opt-out, among other duties. Honour opt-out requests within 10 business days. The message's primary purpose matters when distinguishing commercial from transactional or relationship mail; this is not a complete rulebook for every country or recipient.

For European electronic direct marketing, consider ePrivacy Article 13, its limited existing-customer exception and the applicable national rules. A GDPR basis for processing personal data does not by itself settle permission to send marketing. Keep evidence of the relevant permission, make objections effective and minimise retained personal data. Support applicable access, correction and erasure rights, while checking the conditions and exceptions that apply to each request.

Apply marketing opt-outs to the relevant marketing scope rather than automatically blocking every necessary transactional message. Enforce provider safety restrictions as well as your application policies. Make suppression changes traceable, and set retention and access rules around the actual purpose and applicable obligations rather than keeping every event indefinitely.

Verify the layers before scaling

Roll out by dependency: authenticate the intended domains, authorise controlled sender identities, validate templates, accept durable work, then test delivery and feedback with recipients you control. Exercise retries, suppression and revocation before increasing volume. Use the evidence from these checks to determine whether the next step is safe.

For multi-tenant applications or agents, test more than one authorised identity and verify that one cannot read another's mailbox data. Provision through the appropriate account-level API, then use the mailbox and sending interfaces for their respective work. Check reply state, events and quotas with controlled traffic. Treat isolation and recovery as behaviours to verify, not conclusions drawn from an API label.

Sources

• Vetora architecture example

• Email-service design example

• Claim-and-reaper discussion

Recommended reading

• Bounce handling guide

• Cold email batching

• SPF, DKIM and DMARC

• Email for AI agents