Strategy
Part of The honest guide to email deliverability
Email deliverability best practices: an overview
Email deliverability best practices: an overview of sender identity, authentication, suppression, monitoring, and incident response.
What to take away
- Send mail people reasonably expect, from a recognizable identity, for the purpose and cadence they chose.
- Protect critical account and service streams from promotional risk through deliberate identity and operational separation.
- Monitor exact provider and internal evidence, then rehearse containment and recovery before a high-volume event.
Email deliverability best practices create a sending program that recipients expect and operators can explain. They do not guarantee inbox placement. Review current provider requirements by recipient scope, obtain qualified legal and security advice, and preserve the evidence behind every material decision.
Send expected mail
Document source, date, promise, topic, sender, frequency, market, and proof. Prevent abusive signups and block purchased, harvested, appended, deceptive, or unexplained promotional data. Make withdrawal easy.
Document Before You Send
- Source and date
- Promise and topic
- Sender and frequency
- Market and proof
- Block purchased or harvested data
- Make withdrawal easy
Know every sender
Inventory domains, From addresses, return paths, DKIM domains, IPs, platforms, vendors, streams, volumes, sources, and owners. Alert on unknown traffic and retire obsolete access, DNS, systems, and data.
Sender Inventory Fields
- Domains and From addresses
- Return paths and DKIM domains
- IPs and platforms
- Vendors and streams
- Volumes and sources
- Owners and access
- Alert on unknown traffic
Authenticate the live path
IETF RFC 8314 on TLS for email submission and access recommends TLS for message submission and mailbox access and treats cleartext as obsolete in those contexts. Verify the actual client, submission, relay, and provider path because a published policy does not prove every connection is protected as intended.
Verify SPF authorization, production DKIM signatures, DMARC alignment and reporting, forward and reverse DNS, TLS, host identity, and message format. SPF authorizes sending systems for a domain, DKIM adds a domain-linked signature, and DMARC checks whether SPF or DKIM aligns with the domain in the visible From address. DMARC policies can use p=none, p=quarantine, or p=reject; alignment can be relaxed or strict. Test representative mail after gateway, template, vendor, and routing changes.
Review Google and Yahoo bulk sender requirements and Microsoft sender requirements for the recipient provider and type of mail. Check current rules for authentication, alignment, complaint handling, and unsubscribe; do not assume one provider's requirements apply to another.
BIMI (Brand Indicators for Message Identification) is an optional way to display a brand logo in participating inboxes, not a substitute for authentication. MTA-STS lets a domain publish a policy for protecting inbound mail delivery with TLS, while TLS-RPT reports TLS delivery problems. Assess their fit and provider support before deployment.
Protect necessary streams
Separate security, receipt, account, service, marketing, sales, support, and user-generated risks where useful. Keep identities recognizable and maintain central ownership, suppression, monitoring, and incident authority.
Honor choices everywhere
Implement applicable one-click and visible unsubscribe mechanisms. Propagate withdrawals, complaints, hard failures, invalid addresses, preferences, and exclusions across platforms, imports, backups, and queued promotion.
For one-click unsubscribe, use the List-Unsubscribe and List-Unsubscribe-Post headers specified by RFC 8058, and test that the request reaches every relevant suppression system. Keep the visible unsubscribe mechanism as well.
For U.S. commercial email, review the CAN-SPAM Act and Federal Trade Commission guidance on message requirements and opt-outs. Do not treat CAN-SPAM as a blanket prior-consent rule; assess consent and data use under the rules applicable to the recipient and the data.
Change traffic gradually
Plan new domains, IPs, vendors, migrations, seasonal peaks, list sources, templates, headers, and tracking. Start a change with a small, recent, engaged audience; monitor provider responses and expand in stages only while signals remain stable. Pause and investigate worsening deferrals, rejections, complaints, or bounces before expanding further. Adjust each stage to actual provider responses rather than using a universal warm-up formula.
Be recognizable and honest
Use accurate display names, subjects, messages, claims, links, reply paths, accessibility, and destinations. Avoid fake replies, false urgency, hidden text, misleading redirects, and content that disguises commercial intent.
Monitor evidence, not one score
Define attempts, accepts, deferrals, rejections, bounces, complaints, and limited inbox diagnostics. Segment by provider and stream, preserve exact responses, state sampling limits, and pair technical signals with customer outcomes.
Use Google Postmaster Tools for Gmail-related domain and delivery signals, and Microsoft Smart Network Data Services (SNDS) for Microsoft network traffic and reputation signals. Track complaint and bounce rates by provider and stream against current provider guidance, and set internal alert and pause criteria from your own baseline; do not treat a single universal cutoff as safe.
Prepare for failure
The IETF's current TLS deployment recommendations in RFC 9325 cover protocol versions, cipher suites, certificate validation, and operational considerations. Apply the relevant recommendations through qualified engineering review and test compatibility, rollback, monitoring, and failure behavior in the email systems you operate.
Assign pause authority and runbooks for compromised credentials, missing signatures, suppression failure, volume anomalies, provider filtering, and vendor outage. Preserve evidence, correct root causes, validate a limited restart, and review recurrence.
Review the program after new infrastructure, streams, markets, acquisition methods, major volume, provider policy, or incidents. Good practice is visible in repeatable controls: the team can prove who sent, why, to whom, through which path, under which rule, and how the message can safely stop.
Best-practice evidence map
| Practice | Evidence | Owner action |
|---|---|---|
| Expectation | Source, purpose, cadence | Approve or suppress |
| Identity | Live headers and DNS | Correct and retest |
| Stability | Provider and stream time series | Stage material change |
| Incident | Alert, pause, recovery proof | Contain and review |
Assign the practice
The NIST Privacy Framework starting guide outlines a voluntary process for identifying and managing privacy risk. Use it to assign data and response owners for email deliverability best practices; it is not legal clearance.
The CISA business-system logging guidance explains how event records support security review. Preserve appropriate email deliverability best practices access, change, failure, and correction records without claiming that logging validates a metric.
Common questions
Which best practice matters most?
Recipient expectation is foundational, but it must operate with verified identity, safe systems, suppression, stable traffic, provider evidence, and incident control.
How often should authentication be tested?
Test on a risk-based cadence and after any domain, DNS, provider, routing, signing, tracking, forwarding, or infrastructure change.
Can best practices guarantee inbox placement?
No. They improve control and evidence. Mailbox providers and recipients still make decisions using signals the sender does not fully control or observe.
