Email deliverability is the ability of a sender’s legitimate email to reach the intended recipient’s inbox rather than being rejected, bounced, quarantined, or filtered into spam. It is not a single protocol or one dashboard number: email deliverability reflects authentication, sending reputation, recipient engagement, list quality, content, and sending behavior over time.

“Deliverabilty” is a common misspelling of deliverability. In email sending, the correctly spelled term matters because it describes a distinct outcome: whether recipients can realistically see and act on your message. A successfully handed-off email is not necessarily an inboxed email, and an inboxed email is not necessarily a wanted email. Strong deliverability means consistently sending wanted, authenticated, technically sound mail to people who expect it.

Email deliverability vs. email delivery

The first source of confusion is the difference between delivery and deliverability.

Email delivery usually describes what happened at the SMTP handoff stage. Your sending system attempted delivery and the recipient server accepted the message, deferred it, or rejected it. A receiving server returning a successful SMTP response means it took responsibility for the message; it does not promise a placement in the primary inbox.

Email deliverability goes farther. It considers where a message lands after acceptance and whether mailbox providers continue to trust the sender. A message can be accepted by Gmail, Yahoo, Microsoft, or a corporate mail gateway and then routed to spam, placed in a lower-priority area, quarantined by a security policy, or hidden from ordinary inbox view.

That distinction changes how teams investigate problems:

  • A high hard-bounce rate is primarily a delivery and list-quality issue.
  • A sudden rise in temporary deferrals may be a sending-volume, infrastructure, or reputation issue.
  • A campaign that is accepted but earns weak opens, clicks, replies, and conversions may have an inbox-placement, relevance, or audience problem.
  • A transactional password-reset email that arrives late can be operationally delivered yet still fail its real purpose.

SMTP uses different response classes to distinguish a permanent failure from a temporary one. In broad terms, a 5xx response indicates that the current attempt cannot succeed without a meaningful change, while a 4xx response is temporary and can be retried according to the sender’s retry policy. (datatracker.ietf.org)

For developers, this means a webhook event named delivered, a provider event log, or a 250 SMTP acceptance response should not be treated as a complete measure of recipient experience. It is a useful operational checkpoint, but email deliverability is evaluated after that checkpoint by the receiving system and, ultimately, by the recipient.

Why email deliverability matters

Email deliverability affects revenue, product reliability, support workload, security, and the credibility of your brand. It matters for marketing campaigns, but it is equally important for product email such as account verification, receipts, alerts, invoices, magic links, and password resets.

Campaign performance depends on visibility

A campaign cannot produce a conversion if the recipient never sees it. Lower inbox placement reduces the reachable audience before subject line, design, offer, and call to action have a chance to perform. This is why a team can see a falling open rate even when its creative work has not changed: the denominator may include recipients whose mail is being filtered away from the inbox.

Deliverability also affects the quality of performance data. If a sender keeps mailing inactive or unengaged addresses, aggregate engagement becomes less representative of current customers and subscribers. That can lead a team to make poor content decisions when the actual issue is stale audience composition.

Transactional messages have a time value

For transactional email, timing is often part of the product requirement. A receipt that arrives an hour late creates uncertainty. A sign-in code that arrives after it expires causes abandonment. A security alert that is filtered to spam defeats its protective purpose.

Transactional messages should therefore be measured by more than acceptance rate. Track how long it takes from application event to provider submission, from provider submission to SMTP acceptance, and—where observable—from acceptance to user action. A healthy email system preserves both reliability and predictable latency.

Poor deliverability creates compounding costs

A deliverability issue rarely stays isolated. Repeated mail to invalid addresses produces bounces. Mail to people who did not ask for it produces complaints and disengagement. Those signals can reduce trust in a domain or IP, causing more filtering and fewer useful recipient actions. Lower engagement then makes future campaigns less effective.

The second-order effect is important: trying to compensate for a weak campaign by mailing more often or expanding to colder recipients can make the underlying reputation problem worse. The solution is typically more disciplined sending, not more volume.

How email deliverability is measured

There is no universal inbox-placement percentage available for every mailbox, recipient, and provider. Mailbox providers do not expose every filtering decision, and privacy protections limit what senders can infer from pixel-based opens. Instead, email deliverability is assessed through a collection of metrics, provider feedback, technical authentication results, and controlled testing.

Delivery rate

A common operational metric is delivery rate:

Delivery rate = (Accepted messages ÷ Sent messages) × 100

Depending on the reporting system, “accepted messages” may mean messages accepted by receiving servers after attempted sends, excluding hard bounces and other definitive rejections. Read the definition in your provider’s reporting carefully; some systems count accepted mail differently when a message is suppressed before an SMTP attempt.

A high delivery rate is necessary, but it is not proof of good deliverability. A sender with a 99.5% delivery rate can still have serious spam-folder placement or engagement problems.

Bounce rate

Bounce rate is often calculated as:

Bounce rate = (Bounced messages ÷ Sent messages) × 100

It is useful to split bounces into hard and soft categories rather than treating them as one problem.

  • Hard bounces are generally permanent failures, such as a non-existent recipient address or an invalid domain.
  • Soft bounces are generally temporary failures, such as a full mailbox, a temporary receiving-server problem, a policy throttle, or a transient reputation-related deferral.

SMTP responses can be nuanced, so do not classify solely from a human-readable error string. Store the enhanced status code, SMTP response, recipient domain, sending domain, and timestamp. Then group patterns by recipient provider and campaign type.

Complaint rate

Complaint rate measures how often recipients mark a message as spam or junk, where a feedback mechanism exposes that signal:

Complaint rate = (Spam complaints ÷ Delivered messages) × 100

A complaint is stronger evidence of unwanted mail than a non-open. It may indicate that the recipient did not consent, no longer recognizes the sender, finds the frequency excessive, or cannot easily unsubscribe. Yahoo’s Complaint Feedback Loop is domain-based and requires DKIM-signed mail so Yahoo can identify the sender; complaint reports should lead to prompt suppression of the recipient from future promotional sends. (senders.yahooinc.com)

Engagement and conversion signals

Opens, clicks, replies, purchases, logins, and in-product actions are not direct deliverability metrics, but they help diagnose deliverability. A falling click-to-delivered rate among a stable, opted-in segment can be more useful than open rate alone. For transactional mail, completion rates—such as account verification completed within 15 minutes—can be especially meaningful.

Interpret engagement by segment. A newsletter sent to recently active subscribers should not be compared with a reactivation campaign sent to contacts who have not interacted for a year. Their expected response patterns and deliverability risk are different.

Authentication and reputation signals

Mailbox-provider tools and aggregate reports can help reveal whether messages authenticate correctly and whether a sender is meeting requirements. Google’s Postmaster Tools includes dashboards for SPF and DKIM authentication, delivery errors, spam rate, and other sender-facing signals for eligible domains. (support.google.com)

DMARC aggregate reports add another perspective. They show which sources are sending mail that claims to be from your domain, whether SPF and DKIM pass, and whether the authenticated identities align with the visible From domain. Use these reports to find forgotten vendors, unauthorized traffic, and configuration gaps—not as a standalone inbox-placement score.

A worked email deliverability example

Suppose a retailer sends a promotional campaign to 100,000 recipients.

  • 1,200 messages hard bounce because addresses no longer exist or domains are invalid.
  • 800 messages receive temporary failures and are ultimately not accepted after the retry window closes.
  • 98,000 messages are accepted by recipient servers.
  • 110 recipients mark the campaign as spam through providers that report complaints.
  • Of the accepted messages, 14,700 recipients click at least one tracked link.

The basic calculations are:

Delivery rate = 98,000 ÷ 100,000 × 100 = 98.0%

Bounce rate = (1,200 + 800) ÷ 100,000 × 100 = 2.0%

Hard-bounce rate = 1,200 ÷ 100,000 × 100 = 1.2%

Complaint rate = 110 ÷ 98,000 × 100 = 0.112%

Click-to-delivered rate = 14,700 ÷ 98,000 × 100 = 15.0%

At first glance, 98.0% delivery may appear acceptable. But the next questions matter more:

  1. Did the hard bounces concentrate in one acquisition source, country, form, or older list segment?
  2. Were temporary failures mostly from one mailbox provider, suggesting a provider-specific block or throttle?
  3. Did complaints come from subscribers who were recently added, long inactive, or mailed after a frequency increase?
  4. How does the 15.0% click-to-delivered rate compare with similar campaigns to recently engaged subscribers?
  5. Did the sender’s authentication and domain alignment pass consistently?

A campaign can have a solid delivery rate and still deserve intervention. If the 1,200 hard bounces came from an imported list that has not been mailed for two years, the sender should stop sending to that source, validate remaining addresses, and create a permission-based reactivation path rather than continuing ordinary campaigns.

What determines email deliverability

Mailbox providers use their own systems and do not publish a complete filtering formula. Still, reliable sending follows recurring technical and behavioral principles.

Authentication proves sending authorization

Authentication does not guarantee inbox placement, but weak or broken authentication makes legitimate mail harder to trust. Modern sender requirements make this foundational rather than optional.

Google requires all senders to Gmail personal accounts to set up SPF or DKIM and use valid forward and reverse DNS for sending domains or IPs. For senders above 5,000 messages per day to Gmail accounts, Google requires SPF, DKIM, and DMARC. (support.google.com) Yahoo similarly emphasizes authentication, DMARC alignment, low complaint rates, and easy unsubscribe paths for bulk mail. (senders.yahooinc.com)

The principal controls are:

  • SPF (Sender Policy Framework): a DNS-based policy that authorizes hosts to use a domain in the SMTP envelope-sender identity. SPF lets a receiver check whether the sending host is permitted by the domain’s published policy. (datatracker.ietf.org)
  • DKIM (DomainKeys Identified Mail): a cryptographic signature tied to a domain. The receiver retrieves a public key from DNS to verify the signature and assess whether signed content remained intact. (datatracker.ietf.org)
  • DMARC (Domain-based Message Authentication, Reporting, and Conformance): a protocol that applies domain alignment to SPF and/or DKIM, publishes handling preferences for failed validation, and enables reporting. The current core specification is RFC 9989. (datatracker.ietf.org)

A representative SPF record might look like this:

example.com. TXT "v=spf1 include:spf.email-provider.example -all"

A representative DMARC record in monitoring mode might look like this:

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

Those examples are illustrative, not copy-and-paste instructions. Your SPF record must authorize every legitimate sender using the applicable envelope domain, and your DMARC policy must be deployed carefully after reviewing reports. SPF has DNS-lookup limits and forwarding limitations; DKIM alignment is often more resilient when mail passes through intermediaries, provided the signature survives changes.

Alignment connects technical identity to the visible brand

A message can technically pass SPF or DKIM without satisfying DMARC. DMARC evaluates whether an authenticated SPF identity or DKIM signing domain aligns with the domain in the visible From: header.

For example, a message displayed as From: notices@example.com but signed only by an unrelated vendor domain may have a valid signature yet fail DMARC alignment. This is why teams should verify the actual values used in production: visible From domain, envelope-sender domain, DKIM d= domain, and the DMARC record published for the visible From domain.

Reputation reflects historical behavior

Sending reputation is the accumulated trust associated with identities and behavior. Depending on the mailbox provider, that can include the sending domain, subdomain, IP address, DKIM domain, content pattern, recipient response, and sending consistency.

Reputation cannot be repaired with a single clever campaign. It is earned by repeatedly sending expected mail to interested people, making opt-out easy, avoiding abrupt unexplained volume changes, and promptly stopping mail to recipients who bounce or complain.

List quality determines whether mail is wanted

A permission-based list is not merely a legal or marketing concept; it is deliverability infrastructure. A recipient who knowingly asked for a specific type of email is more likely to recognize the sender, engage, and use unsubscribe rather than spam reporting when their preferences change.

List quality declines naturally. People change jobs, abandon inboxes, use temporary addresses, and lose interest. A good list-management program treats email addresses as data with a lifecycle: collection, confirmation where appropriate, regular engagement, suppression, and eventual removal or re-permissioning.

Content and identity must match expectations

Content is not just about avoiding suspicious words. Mailbox providers and recipients evaluate the whole experience: recognizable From name, coherent domain identity, useful subject line, consistent cadence, accessible message design, functioning links, and a clear explanation of why the recipient is receiving the email.

Misleading subject lines, unexpected attachment types, link-shortening patterns that obscure destination domains, or dramatic changes in sender identity can all reduce trust. Even technically perfect mail performs poorly if the recipient sees it as irrelevant or unrecognizable.

Common causes of poor email deliverability

Poor email deliverability is usually a system problem rather than a single bad email. The following causes often overlap.

Sending to unverified, purchased, or stale lists

Purchased lists are risky because the sender cannot reliably establish recipient expectation, acquisition quality, or freshness. Even a list marketed as “opted in” may include addresses that never consented to hear from your brand. Old internal lists create a similar issue when subscribers have not received mail for a long time and no longer recognize the sender.

Address validation can catch syntax errors, invalid domains, and some likely-undeliverable addresses before sending, but it cannot prove ongoing consent or interest. Use an email address verification tool before major list imports, then combine that check with source-level permission records and a conservative re-engagement strategy.

Broken SPF, DKIM, or DMARC configuration

Configuration failures are common during provider migrations, domain changes, and multi-vendor setups. Typical problems include forgetting to authorize a new sender in SPF, publishing more than one SPF record, using a DKIM selector that has no corresponding DNS key, signing with a domain that does not align, or publishing DMARC before all legitimate sources are mapped.

Do not assume dashboard green checks are enough. Send test messages to inboxes you control and inspect headers. Confirm the Authentication-Results header, the visible From: domain, envelope sender, and DKIM signing domain. Also inspect DMARC aggregate reports after every infrastructure change.

Sudden volume or cadence changes

A domain that sends 500 emails per day and abruptly sends 500,000 may trigger scrutiny, even if the recipients are real. The risk increases when the sudden spike targets inactive addresses, a new geography, or a mailbox provider that has little history with the sender.

Warm-up is not a magic calendar schedule. It is the practice of increasing traffic gradually while prioritizing the people most likely to expect and engage with the mail. Start with active, recently opted-in users; monitor bounces, complaints, deferrals, and engagement; then expand only when the signals remain healthy.

Blending transactional and promotional traffic indiscriminately

A password reset and a weekly sale serve different purposes, have different urgency, and often generate different recipient signals. Combining them under one sending identity can make troubleshooting difficult and may expose essential messages to promotional reputation problems.

A practical structure is to use distinct subdomains or clearly separated streams for transactional and marketing mail, while preserving recognizable branding and correct authentication. The goal is not to evade filtering; it is to create observable, accountable traffic categories with appropriate sending rules.

Ignoring complaints and unsubscribes

When people cannot quickly stop promotional email, some will mark it as spam. That is bad for the recipient and for future delivery. Unsubscribe requests should update suppression data immediately enough to prevent subsequent mail, including automated campaign steps.

For subscription messages, one-click unsubscribe is a standards-based mechanism. RFC 8058 defines how the List-Unsubscribe-Post header signals one-click functionality in conjunction with List-Unsubscribe; Google requires correctly implemented one-click unsubscribe for subscription messages covered by its guidelines. (datatracker.ietf.org)

An illustrative header pair is:

List-Unsubscribe: <https://example.com/unsubscribe/opaque-token>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Use a recipient-specific opaque token, process the request without forcing a login or additional confirmation, and keep a visible unsubscribe link in the message body. Do not add these headers to transactional messages merely to imitate promotional mail; classify mail honestly.

Treating every non-open as a reason to resend

Open tracking is incomplete, especially when privacy features, image blocking, or client behavior interfere with pixels. Resending aggressively to “non-openers” can inflate volume and annoy people who did see the message but did not load images.

Use stronger signals where possible: clicks, replies, visits, purchases, account activity, explicit preferences, and time since last interaction. If you resend, do it selectively, with a meaningful change in timing or content, and exclude recipients who have recently complained or unsubscribed.

How to improve email deliverability

Improvement begins with diagnosis. Do not make five unrelated changes at once and hope for a result; you will not know what helped or harmed. Establish a baseline by domain, message stream, mailbox provider, acquisition source, and engagement segment.

1. Inventory every sender and domain

List every system that sends mail for your organization: application servers, CRM platforms, help desks, billing tools, form tools, hiring systems, product-notification services, and agencies. For each one, record:

  • visible From domain and From name;
  • envelope-sender or return-path domain;
  • DKIM signing domain and selector;
  • sending IP or provider;
  • message category: transactional, lifecycle, marketing, or operational;
  • expected audience and consent source;
  • unsubscribe and suppression behavior.

This inventory is the foundation for authentication, DMARC reporting, incident response, and vendor change management. Without it, a failed authentication check or unexpected complaint spike cannot be assigned to the right source quickly.

2. Authenticate and validate production traffic

Configure SPF, DKIM, and DMARC for domains that send mail. Ensure reverse DNS is valid where you operate sending IPs. Check alignment for the actual From domain that recipients see, not just a parent domain or an unused test domain.

Begin DMARC with monitoring if you need visibility into unknown sources, then use reports to fix authorized senders and investigate unauthorized ones. A strict policy is valuable only after the organization understands its traffic. The practical objective is durable alignment and fraud resistance, not checking a box.

3. Make permission clear at collection time

Use forms that tell people what they are signing up for, how often they may hear from you, and which sender identity to expect. Store the source, timestamp, form version, and relevant preference choices. For high-risk acquisition paths or valuable brands, consider confirmation flows that reduce typos and demonstrate control of the mailbox.

Do not hide marketing consent inside a transactional flow. A person who makes a purchase expects a receipt; that does not automatically mean they expect weekly promotions. Separate consent choices make later segmentation and compliance much easier.

4. Segment by recency and engagement

Send your most regular campaigns first to recipients who recently interacted, purchased, logged in, or explicitly updated preferences. Reduce frequency for less active groups and design re-engagement campaigns that ask people to confirm continued interest.

If a segment stays inactive, suppress it instead of repeatedly forcing volume through it. A smaller list of people who expect your email usually creates better deliverability and better economics than a larger list filled with dormant addresses.

5. Build reliable suppression handling

Maintain a centralized suppression system that applies to every campaign tool and automated workflow. At minimum, suppress hard bounces, unsubscribe requests, complaint reports where available, and addresses identified as invalid by your provider or verification process.

Be careful with soft bounces. A temporary failure can recover, so it should not always cause immediate permanent suppression. But repeated temporary failures at the same recipient or provider should trigger a defined review rule. Retrying indefinitely wastes capacity and can look like abusive behavior.

6. Separate streams and monitor them independently

Track transactional and promotional traffic separately. Monitor delivery, deferral, bounce, complaint, unsubscribe, and conversion metrics by stream and major recipient domain. If a marketing campaign causes an issue, you need to know whether account-security email remains healthy.

A transactional email API should give developers event visibility and predictable sending controls. Review the email API setup guidance before implementing a new stream so your application handles failures, idempotency, recipient suppression, and message classification deliberately.

7. Test changes like production changes

Before a major launch, test the exact production From address, authentication configuration, links, headers, and unsubscribe behavior. Validate the recipient experience in common mailbox providers and inspect raw headers. Then release in stages rather than sending the entire audience at once.

For a new sending domain or a large list reactivation, start with a small segment of active recipients. Pause expansion if bounce, complaint, or deferral patterns worsen. This approach protects reputation while giving you useful evidence about which part of the audience or configuration needs work.

A practical deliverability troubleshooting workflow

When inbox placement or acceptance declines, use a disciplined sequence.

  1. Define the incident. State what changed: a higher hard-bounce rate, increased Gmail deferrals, a lower click-to-delivered rate, a complaint spike, or delayed transactional mail.
  2. Compare against a baseline. Break results down by sending domain, recipient provider, message type, campaign, source list, and date.
  3. Check technical identity. Inspect SPF, DKIM, DMARC alignment, DNS records, return-path domain, sending IP behavior, and recent provider or DNS changes.
  4. Check audience quality. Identify new imports, inactive segments, purchased data, form changes, affiliate sources, or lists that skipped validation.
  5. Check message expectations. Compare From name, subject, content, frequency, offer, and unsubscribe behavior with the recipient’s original consent.
  6. Reduce risk immediately. Pause the worst segment, slow volume, suppress invalid and complaining recipients, and protect transactional traffic.
  7. Make one measurable correction at a time. For example, remove a bad acquisition segment, repair alignment, or move a campaign to engaged subscribers.
  8. Monitor recovery over time. Reputation responds to sustained better behavior, not a single clean day.

The temptation in an incident is to change subject lines or template colors. Start instead with the highest-impact variables: recipient expectation, authentication, complaint handling, list source, and sending pattern.

Email deliverability myths to avoid

“A 99% delivery rate means our deliverability is excellent.”

Not necessarily. The receiving server may accept nearly all mail while placing a meaningful share in spam. Combine delivery metrics with complaint data, engagement trends, provider feedback, and inbox-placement testing.

“Authentication guarantees the inbox.”

Authentication establishes legitimacy and supports trust, but it does not make unwanted email wanted. A fully authenticated sender can still be filtered for poor engagement, high complaints, unsafe content, or suspicious behavior.

“The best fix is a new IP address.”

Changing IPs can be appropriate during infrastructure migration, but it does not erase bad list quality, unwanted content, poor consent, or a damaged domain reputation. New infrastructure without changed sending practices often recreates the same problem.

“Deleting everyone who does not open is always the answer.”

No. Opens are imperfect and do not capture every type of customer value. Use a thoughtful engagement definition that considers clicks, purchases, product use, replies, preferences, and message category. But do stop treating indefinitely inactive recipients as ordinary campaign targets.

“Unsubscribes are bad.”

An unsubscribe is often healthier than a spam complaint or silent disengagement. It gives the recipient control and improves the relevance of future sends. Make it easy, respectful, and fast.

The long-term view of email deliverability

Email deliverability is best treated as a product and operations practice, not a campaign rescue tactic. Engineering owns reliable integration, event handling, DNS, authentication, and sending controls. Marketing owns permission, relevance, segmentation, cadence, and clear preferences. Support and compliance teams contribute by identifying customer confusion, honoring opt-outs, and maintaining auditable processes.

The most resilient senders make deliverability part of routine decision-making. Before adding a form field, importing a list, changing a From domain, launching a new vendor, or increasing frequency, they ask whether recipients will recognize, expect, and value the resulting email.

That approach has a practical payoff. It improves the odds that critical messages arrive when needed, preserves the audience’s attention, makes campaign metrics more trustworthy, and reduces the likelihood that a growth initiative creates a long-lived reputation problem.

FAQ

What is email deliverability in simple terms?

Email deliverability is the ability of legitimate email to reach recipients’ inboxes instead of being rejected, bounced, quarantined, or sent to spam. It depends on sender trust, authentication, list quality, recipient engagement, and sending practices.

Is email deliverability the same as delivery rate?

No. Delivery rate measures whether receiving servers accepted messages. Email deliverability includes inbox placement and ongoing sender trust after acceptance. A message can be delivered technically while still landing in spam.

What is a good email deliverability rate?

There is no universal rate because inbox placement is not fully visible and varies by mailbox provider, audience, and message type. Aim for low hard bounces and complaints, correct SPF/DKIM/DMARC alignment, stable sending behavior, and healthy engagement among recipients who opted in.

How long does it take to improve email deliverability?

Technical fixes can take effect as soon as DNS changes propagate and new messages are sent. Reputation recovery usually takes longer because mailbox providers assess patterns over time. The timeline depends on the severity of the issue, list quality, volume, complaint behavior, and consistency of the corrective action.

Does using a new domain improve deliverability?

A new domain is not a shortcut for sending to an unengaged or non-consenting list. It has no established reputation and still needs authentication, gradual sending, clear recipient expectations, and disciplined suppression. Use a new domain only when there is a legitimate brand or operational reason, not to avoid fixing sender behavior.