The honest guide to email deliverability

What to take away

Email deliverability describes whether legitimate messages reach the part of a recipient's mailbox where they can reasonably be found, rather than being rejected, deferred, quarantined, or filtered into spam, and it differs from delivery rate.

A server can accept a message that later appears outside the inbox. An honest rejection can be easier to diagnose than silent filtering.

There is no switch that guarantees inbox placement. Mailbox providers evaluate their own signals, policies, security controls, recipient behavior, and changing abuse patterns. Google, Yahoo, and Microsoft publish requirements for some traffic, but their scopes and thresholds differ. Treat those pages as current provider rules, review them regularly, and separate their claims from universal assumptions.

Start with permission and expectations

Send messages people requested or reasonably expect; keep records of source, date, language, topics, sender, frequency, market, and proof, and make withdrawal easy. For U.S. commercial email, the CAN-SPAM Act, enforced by the Federal Trade Commission (FTC), requires truthful header information, nondeceptive subject lines, a valid postal address, and an opt-out mechanism; honor opt-outs. CAN-SPAM generally does not require prior opt-in, and other requirements can depend on recipient location and message type, so check applicable rules.

Do not buy, harvest, append, or quietly repurpose addresses; technical authentication cannot fix an audience that did not want the mail.

Permission records anchor the email list building work that keeps deliverability stable.

Inventory every sending stream

The Australian Cyber Security Centre's guide to combating fake email explains SPF, DKIM, DMARC, alignment, reporting, phased enforcement, sender discovery, testing, and change control. It supports the need to identify every legitimate sending path before enforcing domain policy.

Use a practical operating cycle

Give the program accountable owners

Assign business, technical, data, content, security, privacy, legal, and incident responsibilities. State who can approve a new sender, change DNS, pause traffic, suppress recipients, investigate provider responses, contact a vendor, and retire infrastructure. Store current diagrams, credentials, runbooks, decisions, and escalation routes in controlled systems.

Separate traffic by purpose and risk

Protect necessary account, receipt, security, and service mail from avoidable marketing risk. Use understandable domains and consistent identities, with separation appropriate to the organization's size and architecture. Yahoo recommends segregating email types by IP or DKIM domain; Google also advises consistent identities and thoughtful separation. Do not create so many fragments that ownership and monitoring disappear.

Configure SPF deliberately

Sender Policy Framework identifies systems permitted to use a domain in the SMTP envelope. Build records from a verified sender inventory, remove obsolete services, control nested includes, and test the effective result. Forwarding can also change how SPF behaves, so interpret results in context.

Forwarding can cause SPF or DKIM authentication and alignment to fail. ARC (Authenticated Received Chain) lets intermediaries preserve authentication results across forwarding, but receiving providers decide how to use those results; ARC is not a substitute for correct sender authentication.

Sign mail with DKIM

DomainKeys Identified Mail uses a domain signature that receivers can validate. Control selectors, keys, signing domains, rotation, vendor delegation, and failure monitoring. Test that meaningful traffic is actually signed after template, gateway, and forwarding changes. A DNS record without a valid message signature is not a working implementation.

Deploy DMARC from evidence

Domain-based Message Authentication, Reporting, and Conformance evaluates alignment with SPF or DKIM and publishes a domain policy. Identify legitimate failures, correct alignment, and increase enforcement through controlled stages when appropriate. A typical rollout moves from p=none to p=quarantine to p=reject over weeks or months, once reports show that legitimate senders align.

The core standards references are RFC 7208 for SPF, RFC 6376 for DKIM, and RFC 7489 for DMARC. BIMI (Brand Indicators for Message Identification) is a separate logo-display specification; it does not replace authentication or guarantee inbox placement.

A strict policy applied before all legitimate senders are understood can block wanted mail.

Verify DNS, TLS, and message format

Check forward and reverse DNS for sending IPs, hostnames, HELO or EHLO identity, TLS support, time synchronization, routing, and standards-compliant headers and bodies. Google and Yahoo specify forward and reverse DNS and Internet message format expectations. Microsoft also publishes transmission policies and response handling. Test the actual message path, not a diagram.

Implement one-click unsubscribe correctly

For traffic covered by provider requirements, support the specified List-Unsubscribe headers and processing method, keep a visible body link, and honor requests promptly. Gmail's bulk sender requirements call for unsubscribe requests to be processed within 48 hours. Google and Yahoo describe requirements for marketing or subscribed messages, with details that are not identical.

Do not confuse provider mechanics with every legal requirement or apply promotional headers blindly to essential security messages.

Maintain one suppression truth

Propagate withdrawal, complaints, hard failures, invalid addresses, policy exclusions, and relevant preferences across platforms, imports, backups, and queued sends. Define which signals suppress which streams. Protect necessary communications while stopping unwanted promotion. Test that an address cannot return through a stale CRM sync, vendor upload, or restored automation.

Control acquisition and list changes

Validate the signup experience, not merely address syntax. Prevent automated abuse, malicious signups, typos, hidden co-registration, prechecked consent, and unsupported imports. Reconcile source volumes and confirmation patterns. Sudden acquisition changes can alter complaints, invalid addresses, engagement, and risk long before a campaign dashboard explains why.

Keep volume and identity predictable

Plan launches, seasonal peaks, migrations, new domains, new IPs, and major template or header changes. For a staged warm-up, start with a few hundred messages a day to the most engaged segment, hold that level for several days while reviewing provider responses and complaints, then increase gradually only while results remain acceptable. Repeat the hold-and-review cycle at each stage, and pause or step back if signals worsen.

Google explicitly recommends gradual volume increases and watching server responses, spam rate, and reputation. Warm-up is not permission to send unwanted mail, and fixed daily schedules are not universal rules.

Write messages recipients recognize

Use an honest From identity, accurate subject, expected topic, useful content, and a working reply/help path. Use accessible layout and trustworthy destinations, and avoid deceptive display names, fake reply cues, hidden text, false urgency, and misleading links.

Avoid disguised sender content; content cannot compensate for poor consent, but misleading content creates complaints. Content choices fit a larger email marketing strategy setting audience, offer, and measurement.

Govern links, tracking, and domains

Inventory branded, redirect, image, tracking, shortening, and vendor domains. Secure DNS and accounts, monitor certificates, minimize unnecessary redirects, and verify final destinations. Understand what changes when tracking is enabled. A compromised or unfamiliar domain can damage trust even when the visible message appears normal.

Choose infrastructure and hold vendors to the same controls

Examples to assess include Mailchimp and Klaviyo for marketing campaign and journey operations, and Twilio SendGrid and Amazon Simple Email Service (Amazon SES) for email sending; their product scopes and configurations differ. Compare the actual offerings on shared or dedicated resources, throughput, queue control, logging, bounce parsing, feedback loops, portability, incident support, and exit terms. A dedicated IP is not automatically superior. It gives the sender more direct responsibility and may be unsuitable when volume is low or irregular.

A provider can operate infrastructure, but the organization still needs visibility and authority. Require a current sending inventory, named support routes, role-based access, secure authentication, change notice, usable logs, exact response data, suppression guarantees, incident cooperation, data retention terms, export, and tested offboarding. Verify subcontractors and shared-resource exposure.

Define who changes DNS, rotates keys, interprets provider feedback, pauses queues, and contacts affected customers. Test those responsibilities before a crisis. If a vendor supplies a proprietary reputation or inbox score, require its population, method, latency, coverage, and limitations before using it for a business decision.

Monitor provider and internal evidence

Collect SMTP responses, accepted, deferred, rejected, bounced, complaint, unsubscribe, authentication, alignment, reputation, and provider dashboard data. Reconcile them with sent and eligible populations. Segment by provider, domain, stream, IP, campaign, journey version, acquisition source, and time only when denominators remain sufficient and privacy controls allow it.

Google Postmaster Tools provides provider-specific evidence for Gmail. For additional monitoring, dmarcian and MXToolbox offer DMARC reporting tools, Validity Everest supports deliverability monitoring, and Microsoft's Smart Network Data Services (SNDS) provides data about mail sent to Microsoft's consumer network. Their coverage and methods differ, so treat each as one evidence source rather than a universal measure of inbox placement.

Interpret metrics with precise denominators

Define attempted, accepted, delivered, inbox, spam, opened, clicked, complained, and unsubscribed before reporting rates. Provider dashboards may use different populations and sampling. Privacy features and image loading limit opens. Seed tests are diagnostic samples, not a census of real recipients. No single percentage proves inbox placement across all providers.

Diagnose changes as incidents

When performance shifts, preserve the timeline and compare provider, stream, identity, volume, acquisition, content, link, DNS, vendor, and response-code changes. Determine whether the problem is rejection, deferral, spam placement, missing telemetry, or customer disinterest. Avoid changing domains, IPs, content, cadence, and lists at once because that destroys causal evidence.

Respond without evasion

Pause harmful traffic, stop retries after permanent failures, reduce unsafe volume, correct authentication or data, suppress affected recipients, secure compromised systems, and follow provider remediation routes. Do not rotate domains or infrastructure to evade filtering. Record the defect, affected scope, correction, validation, phased restart, and accountable approval.

Good deliverability is an operating capability, not a one-time score. The team should know who is sending, why recipients expect it, how the domain proves identity, how customer choices propagate, what each provider response means, and how to stop unsafe traffic. That discipline improves the chance that useful mail remains trustworthy and diagnosable as systems change.

Deliverability operating record

Run the pre-release check inside the operating cycle

Before release, confirm the sender inventory is current and the live path passes. In Google Postmaster Tools, hold the spam rate below 0.10% and treat 0.30% as a stop condition. Send seed messages to Gmail, Yahoo, Microsoft, and a corporate domain, then confirm one-click unsubscribe and suppression.

Record the tested data, roles, product versions, exceptions, and approval date. Repeat the review after a material source, model, access, contract, or decision change.

Common questions

What is email deliverability?

It is the practical ability to send expected, authenticated, technically sound email that recipient systems accept and recipients can find and use. Acceptance alone does not prove inbox placement.

Does authentication guarantee the inbox?

No. Authentication proves bounded facts about identity and authorization. Providers can still filter mail based on recipient feedback, traffic, reputation, content, security, and local policy.

What should a team fix first?

Fix the highest-consequence verified failure first, usually unknown senders, failed authentication, unwanted acquisition, broken suppression, compromised credentials, or an uncontrolled volume change.