Email Deliverability: What It Is and How to Improve It
Email deliverability is the ability to reach recipients’ inboxes. Amazon SES describes deliverability in terms of the share of messages that arrive there. Improving it requires authenticated sending, wanted email, reliable infrastructure, and close attention to rejection reasons and recipient complaints.
Email deliverability vs. email delivery
Email delivery measures whether a receiving system accepts a message. Deliverability concerns what happens beyond that handoff, especially whether the message reaches the inbox. In Amazon SES delivery event data, a delivery event records transfer to the recipient’s mail server and the server’s SMTP response; it does not report the recipient’s inbox folder.
Keep these outcomes separate when reading a sending report:
| Outcome | What it establishes | What remains unknown |
|---|---|---|
| Accepted by the sending service | The service has taken the submission | Whether the recipient’s server will accept it |
| Accepted by the recipient’s server | The receiving server has accepted responsibility for the message | Final folder placement and whether it will be read |
| Deferred or rejected | The attempted transfer has failed temporarily or permanently | The correction needed, until the response is examined |
| Observed in an inbox | The message reached that observed mailbox’s inbox | Placement for other recipients and whether they will read it |
These distinctions follow the SMTP specification’s separation of acceptance and failure responses. A high server acceptance rate therefore cannot establish a high inbox placement rate.
Inbox placement also differs from placement in Gmail’s Primary tab. Gmail’s inbox categories include Promotions, Updates, Social, and Forums. A promotional message in Promotions is still in an inbox category; it has not been placed in Spam.
Authenticate every service that sends email
SPF, DKIM, and DMARC provide different checks on the sending identity. Configure them for each legitimate sending service, including newsletter software, account notifications, billing systems, and support platforms.
| Method | What it checks | What to verify |
|---|---|---|
| SPF | Under the SPF standard, whether the sending host is authorized for the domain used in the SMTP identity | Include authorized sending services; do not publish multiple competing SPF records for the same domain |
| DKIM | A domain signature over message content, verified using the signing domain’s public key | Enable signing and publish the corresponding public key in DNS |
| DMARC | Whether passing SPF or DKIM aligns with the domain in the visible From address, as defined by DMARC identifier alignment | Verify that at least one passing method aligns; publishing a policy alone does not establish a pass |
Under DMARC’s alignment rules, relaxed alignment permits the same organizational domain while strict alignment requires an exact match; a passing signature from an unrelated provider domain therefore does not establish alignment with the visible sender.
Inspect a received message from each sending service. Google’s authentication checking instructions identify the Authentication-Results header and values such as spf=pass and dkim=pass. Check the associated domains and DMARC result as well. A DNS record that exists is different from a message that passes the intended check.
Authentication establishes domain authorization and message integrity checks. It does not establish recipient consent or guarantee inbox placement.
Gmail, Yahoo, and Outlook.com sender requirements
Mailbox providers set their own requirements. The following comparison concerns personal Gmail accounts, Yahoo-hosted consumer mail, and Outlook.com. It should not be treated as a policy for every business mailbox hosted by Google or Microsoft.
| Provider | Authentication requirements | Other requirements to check |
|---|---|---|
| Gmail | Google requires SPF or DKIM for all senders. Bulk senders need both, plus DMARC with at least p=none and From-domain alignment | Valid forward and reverse DNS, TLS, compliant message formatting, and low user-reported spam rates. Bulk marketing and subscribed mail needs one-click unsubscribe and a visible body link |
| Yahoo | Yahoo requires SPF or DKIM for all senders. Bulk senders need both, a valid DMARC policy with at least p=none, and a DMARC pass | Valid forward and reverse DNS, standards-compliant messages, spam complaints below 0.3%, and one-click unsubscribe headers plus a visible body link for bulk marketing and subscribed mail, honored within two days |
| Outlook.com | Microsoft’s high-volume policy requires passing SPF and DKIM, plus DMARC with at least p=none and alignment, for domains sending more than 5,000 messages daily | Microsoft documents authentication rejection code 550 5.7.515 and recommends functional unsubscribe links, valid sender addresses, permission, and list hygiene |
The bulk classifications differ. Gmail’s sender FAQ describes bulk sending as close to 5,000 messages or more to personal Gmail accounts in 24 hours. It combines traffic from the same primary domain and its subdomains, and the classification is permanent once assigned. Yahoo’s FAQ does not publish a numerical bulk threshold.
Follow Google’s spam-rate guidance: keep the Postmaster Tools rate below 0.1% and avoid reaching 0.3% or higher. Those are provider-specific user-report thresholds, not a universal bounce benchmark or inbox success score. Review the linked policies before changing domains, infrastructure, or sending volume.
Improve permission, list quality, and unsubscribe handling
Send subscription email to confirmed subscribers
Google’s subscription guidelines recommend confirming an address after signup before sending subscription messages. This confirmation is commonly called double opt-in.
State the sender, subject matter, and expected frequency at signup. Send the subscription described there. Yahoo’s recommendations specifically discourage purchased lists and warn against changing a weekly or monthly subscription into daily email without matching the original expectation.
Treat address validation as a separate technical check, and retain subscription confirmation as the evidence for permission.
Handle invalid addresses, temporary failures, and complaints separately
Amazon SES distinguishes hard and soft bounces: a nonexistent mailbox is a persistent failure, while a full mailbox, throttling, or a timeout may be temporary. SES recommends avoiding repeated attempts to hard-bouncing addresses and addresses that generate complaints.
Suppress confirmed invalid addresses. Let the sending service manage temporary retries according to its documented policy, and investigate repeated deferrals. Keep complaint and unsubscribe suppressions connected to the systems sending the affected subscription.
Read the reason before suppressing an address as invalid. Microsoft’s authentication rejection policy demonstrates that a permanent rejection can concern the sending configuration rather than a nonexistent mailbox. Correct the sending problem instead of deleting valid recipients merely because the message was rejected.
Implement one-click unsubscribe correctly
A footer link and a one-click unsubscribe header serve different functions. For RFC 8058 one-click unsubscribe, provide an HTTPS URL in List-Unsubscribe and the value List-Unsubscribe=One-Click in List-Unsubscribe-Post. A valid DKIM signature must cover both headers. The endpoint must process the unsubscribe through an HTTPS POST without requiring another user confirmation.
Retain a clearly visible unsubscribe link in the message body. Test both the visible link and the header-based process, then verify that a subsequent send excludes the unsubscribed address from the relevant list. Google’s subscription guidance calls for honoring requests within 48 hours; Yahoo’s requirements specify completion within two days.
Gmail’s FAQ excludes transactional messages, including password resets and reservation confirmations, from its bulk one-click requirement. Classify messages by their actual purpose, and keep subscription preferences separate from requested account or purchase notifications.
Protect reputation with consistent sending and clear messages
Control volume increases
Google’s sending guidance recommends consistent sending volumes and gradual increases. Rapid growth can cause delivery problems; when bounces or deferrals rise, reduce the affected volume and inspect the errors before increasing it again.
For new dedicated IPs, Amazon SES describes warm-up as a gradual increase in sending volume. Set the pace from provider responses and the actual sending pattern. Avoid applying a fixed calendar as proof that a domain or IP is ready for unrestricted volume.
Keep message types distinct
Google’s subscription guidance recommends different From addresses for subscription and transactional mail; Yahoo recommends separation by IP or DKIM domain.
Track those streams separately so complaints about promotional mail and delays in requested notifications remain visible. Document which sender identity, signing domain, and sending infrastructure each stream uses before a migration or configuration change.
Use recognizable identity and accurate content
Use a consistent sender name, an accurate subject, and content that matches the subscription. Google warns against deceptive display names and subjects, including Re: or Fwd: when the message is not a reply or forward.
Amazon SES describes content filtering that examines headers and message bodies for spam characteristics. Evaluate copy alongside authentication, complaints, and list quality. A subject-line edit alone does not establish that a rejection or reputation problem has been fixed.
Choose shared or dedicated IPs by sending pattern
A dedicated IP isolates its sending history from other customers, but it requires establishing and maintaining that history. Amazon SES’s IP comparison recommends shared IPs when regular, predictable high-volume sending is not planned. Its managed dedicated option automates parts of allocation and warm-up.
Assess actual volume, consistency, provider support, and operational capacity before changing IP arrangements. A dedicated IP is an infrastructure choice; it does not supply permission or repair an unwanted mailing list.
How to measure email deliverability
Keep transport outcomes and inbox observations in separate reports. A useful reporting convention is:
- Server acceptance rate: accepted recipient deliveries divided by attempted recipient deliveries, multiplied by 100.
- Bounce rate: bounced recipient deliveries divided by attempted recipient deliveries, multiplied by 100; specify which bounce types and reporting window are included.
- Observed inbox placement rate: messages observed in inboxes divided by messages included in the placement test, multiplied by 100; state whether missing messages remain in the denominator.
These are reporting definitions, not interchangeable platform metrics. Confirm the sending platform’s denominator, retry treatment, and handling of later failures before comparing its reported delivery rate with another system. Label mailbox-test results with the providers, account sample, and message stream tested; they describe that observation rather than every recipient’s mailbox.
Use Google Postmaster Tools dashboards for Gmail compliance, authentication, reputation, spam reports, and delivery errors, with data that concerns personal Gmail traffic, updates after a delay, and may be incomplete at low volumes. Yahoo’s Complaint Feedback Loop requires enrollment of the DKIM signing domain; confirm whether the sending provider handles enrollment and feedback.
Interpret complaint rates using the provider’s denominator (Yahoo bases its spam rate on inbox-delivered mail). Google’s dashboard also uses inbox-delivered mail and warns that the rate can look low when many messages are automatically sent to Spam. Low reported complaints alone cannot prove healthy inbox placement.
Open tracking is also an incomplete placement signal. Apple’s Mail Privacy Protection downloads remote content in the background regardless of engagement when Protect Mail Activity is enabled. Consequently, a tracking-image load does not necessarily represent a person opening the message. Use opens as supporting context alongside transport logs, provider feedback, and observed placement.
How to troubleshoot delivery and spam-folder problems
Start by identifying the affected provider, sending domain, message stream, and time window. Then follow the evidence:
- Determine the failed stage. Separate sending-service failures, receiver deferrals, permanent rejections, and accepted mail observed in Spam. Preserve the message identifier and the full response text.
- Interpret the SMTP response. The SMTP reply rules distinguish temporary
4xxfailures that may be retried from permanent5xxfailures that need correction before an identical retry. The accompanying reason identifies what needs attention. - Verify the actual sending path. Inspect received headers and sender logs for SPF, DKIM, and DMARC alignment. Compare the affected path with the intended DNS configuration, TLS connection, and sending IP’s forward and reverse DNS. Check recent vendor or routing changes.
- Investigate accepted mail separately. Review provider reputation and complaint information, signup source, subscription frequency, invalid-address failures, and sender or template changes. Compare the affected stream with its own earlier performance, rather than a blended total.
- Correct the identified cause and limit affected traffic. Repair configuration errors, suppress confirmed invalid addresses and relevant opt-outs, and stop sends to sources that lack the required permission. Google’s gradual-volume guidance supports reducing volume when delivery errors rise.
- Verify recovery using the same measures. Recheck actual message authentication and receiver responses before expanding volume. Review inbox observations separately. Allow for Postmaster’s data update delay when assessing the correction.
Keep a record of the correction and compare the same provider, domain, and stream before and after it. This makes it possible to determine whether the change addressed the observed failure.
Frequently asked questions
Do SPF, DKIM, and DMARC guarantee inbox placement?
Authentication cannot guarantee inbox placement (Google explains that spammers can authenticate email too). Passing authentication establishes technical checks; recipient expectations, complaints, infrastructure, and filtering still matter.
Is Gmail’s Promotions tab a deliverability failure?
Promotions is an inbox category for deals and promotional messages. Measure Spam placement and rejection separately from category placement. Reaching Primary is a different objective from reaching the inbox.
Do small senders need email authentication?
Gmail’s requirements for all senders include SPF or DKIM, valid forward and reverse DNS, TLS, message-format compliance, and low spam rates. Being below a bulk threshold does not remove these baseline requirements.
Is a dedicated IP always better for deliverability?
The appropriate choice depends on volume and sending consistency. Amazon SES recommends shared IPs when regular, predictable large-volume sending is not planned. Dedicated infrastructure provides isolation but requires a sending history and ongoing reputation management.
How long does it take to fix email deliverability?
The failure determines the recovery process. Configuration corrections need verification on actual messages; reputation-related filtering may take longer to respond (Google warns that improved spam rates do not immediately change spam classification). Monitor the affected provider and stream rather than promising a fixed recovery deadline.