Email Deliverability for Product Teams

Email delivery has several success states that are too often collapsed into one. An application can hand a message to its provider, the provider can receive a successful response from the destination, and the destination can still place the message in spam or suppress it later. Inbox placement depends on authenticated identity, sending history, recipient behaviour, content, infrastructure and the receiver's private rules. Product teams control only part of that system, but the controllable part is substantial. Domains and streams must be designed, recipients must be legitimate, failures must change future sending behaviour, and operational mail must remain observable independently from campaigns.

Treat email as a distributed system

A message passes through application code, queue, template renderer, sending provider, domain name system, receiving server and mailbox filtering. Each boundary can delay, reject, duplicate or alter the result. Generate a stable application message ID and retain the provider ID, message class, recipient reference, template version and timestamps. Queue workers should be idempotent so a retry does not create a second password reset or invoice. Provider webhooks need signature verification, deduplication and replay handling. Delivery events should update a state machine rather than overwrite one status field, because a delivered event can be followed by a complaint or delayed bounce.

The operational definition of success varies by message. A password reset is useful only if it arrives before the token becomes irrelevant. A verification message needs a secure reissue path that does not flood the recipient. A marketing newsletter may tolerate queue delay but must respect withdrawal before send time. Invoices and account notices may have retention and channel obligations beyond marketing preference. Define service behaviour for each class: expiry, retries, fallback, suppression exceptions, support visibility and user-facing status. Do not promise inbox arrival, which no sender controls. Report accepted, deferred, bounced, complained and unsubscribed states precisely.

SPF authorises sending infrastructure

Sender Policy Framework publishes which systems may send using a domain in the SMTP envelope sender, also called the return path. The receiving server evaluates that domain, not simply the address visible in the From header. A record usually includes authorised providers and ends with an explicit policy. It must remain within the protocol's DNS-lookup limit, which nested include mechanisms can exhaust as vendors accumulate. Multiple SPF TXT records for one domain do not combine and can cause permanent error. Inventory every legitimate sender, remove obsolete includes and use provider-specific return-path subdomains where supported to keep ownership and bounce handling clear.

SPF passing is not visible identity alignment

DMARC requires the authenticated SPF or DKIM domain to align with the visible From domain. A provider can produce a valid SPF result for its own bounce domain while the message displays the product's domain, leaving SPF unaligned. Custom return paths resolve that relationship when correctly configured. Forwarding can also break SPF because the forwarding system is not authorised by the original envelope domain, which is one reason DKIM matters. Diagnostics should preserve authentication results from representative receiving systems and inspect the exact domains evaluated. A green mark in a provider console is not proof that production messages align after all routing and rewriting.

DKIM signs the message identity

DomainKeys Identified Mail adds a cryptographic signature whose public key is published under a selector in DNS. The signature covers selected headers and a canonicalised body, allowing a receiver to verify that signed content was not modified in transit and that the signing domain takes responsibility. Use a signing domain aligned with the visible From domain. Selectors permit key rotation and separation between providers or streams. Keep private keys within the sending platform or controlled key infrastructure, publish keys of a currently supported strength and rotate by introducing a new selector before retiring the old one. Test modifications by mailing lists and gateways because some transformations invalidate signatures.

SPF identifies authorised envelope infrastructure, DKIM signs a domain identity, and DMARC connects either result to the address a recipient actually sees.

DMARC turns alignment into policy and evidence

Domain-based Message Authentication, Reporting and Conformance evaluates alignment and tells participating receivers how to handle mail that fails. Deployment should begin with valid SPF and DKIM on every legitimate stream, followed by a monitoring policy and analysis of aggregate reports. Reports reveal sending sources claiming the domain, authentication results and alignment, but source IPs and provider labels still require interpretation. Once legitimate traffic is accounted for, policy can move deliberately towards quarantine or rejection. Percentage and subdomain settings allow staged control, yet indefinite monitoring leaves spoofed mail without an enforcement request. Policy changes need ownership, change records and rollback criteria.

DMARC aggregate reports are XML summaries, not recipient-level delivery logs. Process them into a store that preserves reporting organisation, date range, source, disposition, evaluated domains and authentication results. Avoid assuming every unknown source is malicious; it may be an overlooked support, finance or recruitment tool. Conversely, authentication success does not prove wanted mail because an attacker may use another aligned domain or a compromised legitimate system. Forensic reporting has limited availability and greater privacy implications. The purpose of DMARC is domain abuse resistance and alignment visibility. Inbox placement still depends on reputation and recipient response after authentication passes.

• Inventory every system using the visible domain before moving DMARC from monitoring to enforcement.
• Give each provider or sending stream a distinct DKIM selector and, where supported, an aligned return-path subdomain.
• Rotate signing keys by overlapping selectors so cached DNS and queued messages continue to verify.
• Parse aggregate DMARC reports and assign unresolved sources to an owner rather than collecting unread XML files.
• Test SPF lookup count and alignment from received message headers, not only from DNS configuration screens.
• Protect domain and DNS changes with the same review and access controls as production infrastructure.

Separate transactional and marketing reputation

Transactional mail is triggered by a product event and expected by a specific recipient. Marketing mail is sent for promotion or nurture and depends on an appropriate subscription state. They should use separate sending subdomains, streams, queues, templates and provider configurations while retaining clear organisational identity. Separation limits the chance that a campaign complaint surge delays password resets and makes reputation diagnostics intelligible. It also permits different retry and suppression rules. A dedicated IP is not automatically an improvement; it creates a reputation that must be established and maintained with consistent legitimate volume. Shared infrastructure can be appropriate when the provider governs it well.

Separation must not become an excuse to ignore a recipient's explicit complaint. A global do-not-contact state may need to cover promotional streams, while essential account or legal notices follow a separately documented basis. Model these preferences by purpose and channel rather than one ambiguous subscribed flag. Templates should identify the sending organisation and explain why the message was received. Marketing mail needs a working, prompt unsubscribe mechanism that does not require authentication or additional data. Transactional templates should not be padded with promotional material that changes their character and recipient expectations. Product, marketing and legal owners need one agreed classification catalogue.

List hygiene is recipient state management

A legitimate list records how and when an address became eligible, the purpose described at collection and subsequent changes. Purchased, scraped or inferred addresses lack that relationship and generate complaints, traps and poor engagement. Validation at entry can catch malformed domains and obvious mistakes, while confirmation can prove mailbox control where risk warrants it. Do not treat an address as permanently valid. Role accounts, abandoned mailboxes and recycled domains change. Long-inactive recipients should not receive escalating volume merely because they never found the unsubscribe link. Re-engagement must remain restrained, consented and easy to decline.

Hard bounces should normally suppress further attempts promptly. Soft bounces require reason-aware handling because a temporary mailbox problem differs from a permanent policy rejection. Repeated transient failures need a ceiling and cooling period. Complaints demand immediate promotional suppression and investigation by acquisition source, template and stream. Unsubscribes must propagate before the next eligible send, including scheduled batches and vendor replicas. Suppression lists are critical operational data and should survive provider migrations; exporting only active subscribers discards the evidence that prevents harmful resending. Keep suppression reasons and timestamps while applying retention and access controls appropriate to personal data.

Reputation is earned through expected mail

Receivers infer reputation from domain and infrastructure history, authentication, volume patterns, bounce and complaint signals, engagement and content characteristics. The exact weighting is private and differs by receiver. Sudden volume from a new domain, irregular bursts, stale recipients and misleading identity create risk even when every DNS record is correct. Warm-up is not a ritual schedule that guarantees trust; it is the gradual establishment of a consistent stream among recipients likely to expect and value it. Segment by consent quality and recent relationship. Do not conceal weak list acquisition by distributing it across domains or providers, because the underlying recipient response remains adverse.

Content affects filtering, but there is no durable list of forbidden words that repairs poor reputation. Use valid multipart messages, a sensible text alternative, accessible markup, absolute secure links and a visible identity. Keep link domains aligned with the organisation's recognised web properties and avoid unnecessary redirect chains. Image-only messages hide meaning and perform poorly under blocking. Templates must render safely with missing optional data and should never expose template variables or internal identifiers. URL shorteners and attachment-heavy campaigns can add uncertainty. Test major mailbox clients, but understand that seed accounts measure those test mailboxes, not the placement experienced by an entire audience.

Observe the complete feedback loop

Provider acceptance rate is an infrastructure metric, not inbox placement. Build dashboards by stream, sending domain, provider, recipient domain and template, with counts for queued, attempted, deferred, accepted, bounced, complained and unsubscribed events. Track queue age and webhook lag so apparently low bounce volume is not mistaken for quality while feedback is delayed. Retain standard SMTP response codes and enhanced status codes, then group them without discarding the original. Correlate changes with releases, DNS edits, provider migration and campaign launches. Access to recipient-level detail should be restricted; aggregate diagnosis usually suffices until support investigates a specific message.

Mailbox-provider postmaster tools and DMARC reports add external views, while application records establish whether a message was generated correctly. Synthetic monitoring can verify DNS, authentication and receipt through controlled accounts, but it must not create unrealistic engagement signals. Alert on configuration disappearance, signature failure, unexpected sending sources, queue backlog and sharp changes in deferrals or complaints. Runbooks should identify who can pause each stream, change DNS, contact the provider and communicate with product support. Deliverability incidents cross organisational boundaries, so an unexplained “sent” label in an administration screen is not enough for diagnosis.

Deliverability is maintained, not configured once

Reliable email begins with aligned identity: SPF for authorised envelope senders, DKIM for signed domain responsibility and DMARC for visible-domain policy. It continues through stream separation, explicit recipient eligibility, prompt feedback handling and controlled sending patterns. Product engineering supplies idempotent queues, event lineage and support visibility; marketing owns responsible audience and campaign practice; security and domain owners protect identity. No authentication record guarantees an inbox, and no provider can override recipient response indefinitely. The defensible objective is expected mail from a recognisable domain, sent through observable systems that stop when evidence says the relationship or mailbox is no longer valid.