An email bounce is a notification or delivery response indicating that an email could not be accepted by the recipient’s mail system. A bounce may be permanent, such as an address that does not exist, or temporary, such as a full mailbox or a receiving server that is unavailable. Senders use bounce data to protect list quality and deliverability.

What does email bounce mean?

Email delivery is not a single event. When an application sends a message, its email provider or mail transfer agent attempts to hand that message to the recipient domain’s mail server using SMTP, the protocol used to transport email across the internet. If the receiving system refuses the message, cannot process it at that moment, or later reports that delivery failed, that outcome is generally called an email bounce.

A bounce is therefore both a technical event and an operational signal. Technically, it is often represented by an SMTP response code during delivery or by a Delivery Status Notification (DSN) after an attempted delivery. Operationally, it tells the sender whether to stop mailing an address, retry later, investigate infrastructure, or change sending behavior.

The term can be slightly misleading because not every failed delivery produces a traditional reply email in the sender’s inbox. Modern sending platforms typically capture SMTP responses directly, process DSNs automatically, and expose a structured event such as bounced, deferred, rejected, or failed. The implementation differs between providers, but the underlying question is the same: did the receiving system accept the message for delivery?

An email can also be accepted by the recipient’s server yet still fail to reach the primary inbox. It may be filtered to spam, quarantined, delayed, or placed in another folder. That is an inbox-placement issue rather than an SMTP bounce. Treating these as separate outcomes is essential: a low bounce rate does not guarantee that subscribers see or engage with your messages.

Why email bounces matter for deliverability

A small number of bounces is normal. People abandon old addresses, companies change domains, employees leave, and inbox providers retire inactive accounts. The concern is not that a sender has any bounces at all; it is whether bounce patterns show poor data quality, weak permission practices, broken authentication, or an infrastructure problem.

Mailbox providers use many signals when deciding whether to accept, limit, filter, or reject mail. Persistently attempting to send to nonexistent recipients is an avoidable negative signal. So is sending to a suddenly large number of invalid addresses after importing a list, changing signup logic, or launching a campaign to old contacts.

High bounce levels can affect performance in several ways:

  • Lower effective reach. Every invalid or unreachable recipient reduces the number of people who can receive a campaign or a transactional message.
  • Poorer sender reputation. Repeated invalid-recipient traffic can indicate stale acquisition data or weak list maintenance.
  • More provider restrictions. A receiving provider may slow connections, issue temporary deferrals, or reject future mail when it sees behavior that resembles abusive or poorly managed sending.
  • Misleading campaign reporting. Open rate and click rate can look artificially weak if the delivered audience is much smaller or less engaged than the original recipient count.
  • Lost customer actions. A bounced password reset, receipt, verification link, or account alert is not merely a reporting problem; it can interrupt a customer journey.

For marketing mail, bounce control is part of healthy audience management. For transactional email, it is part of application reliability. If a user cannot receive an email confirmation after creating an account, the product may appear broken even though the application successfully submitted the send request.

Gmail’s sender guidance states that senders should follow its requirements to avoid rate limiting, blocks, or spam placement. Yahoo likewise emphasizes permission-based sending, authentication, and sending mail recipients want. Those guidelines reinforce a practical rule: bounce reduction is not an isolated cleanup task. It is connected to authentication, consent, relevance, complaint prevention, and sensible sending volume.

How an email bounce happens in SMTP

SMTP delivery normally includes a conversation between the sending and receiving servers. In simplified form, a sending server identifies itself, supplies the envelope sender, provides a recipient, and transmits message content. The receiver returns a numeric status response at key points.

A simplified exchange might look like this:

S: EHLO sender.example
R: 250-mail.receiver.example
S: MAIL FROM:<bounce@mailer.example>
R: 250 2.1.0 OK
S: RCPT TO:<person@example.net>
R: 550 5.1.1 User unknown

In this example, the recipient server rejects the address during the RCPT TO stage. The response begins with 550, a permanent failure class, and includes the enhanced status code 5.1.1, which indicates an invalid or unavailable mailbox condition. A sending system would normally record the recipient as undeliverable and suppress future sends to that exact address unless there is a compelling, verified reason to believe the address has changed.

The three-digit SMTP reply code matters:

  • 2xx means success. The receiving system accepted that step of the SMTP transaction.
  • 4xx means a transient negative completion response. The sender may retry later because the problem could be temporary.
  • 5xx means a permanent negative completion response for that transaction. Retrying unchanged mail to the same destination immediately is generally not useful.

Enhanced status codes add detail in the form X.Y.Z. Their first digit broadly mirrors the outcome class: 2 for success, 4 for a persistent temporary failure, and 5 for a permanent failure. The middle digit identifies the subject area, such as address status, mailbox status, mail system status, network and routing, delivery protocol, message content, or security and policy.

For example, 5.1.1 often points to a mailbox/address issue, while 4.2.2 can indicate that a mailbox is over quota. But senders should not automate solely from a numeric pattern without retaining the full provider response and delivery context. Providers can use codes differently, text can provide crucial context, and a permanent response caused by policy is different from a nonexistent recipient.

A bounce is not always an SMTP response at RCPT TO

Some failures happen after the recipient server has accepted the SMTP transaction. A receiving system might accept mail, attempt local delivery, then generate a DSN if the final delivery cannot be completed. The DSN format was standardized so delivery systems can report machine-readable status information alongside human-readable diagnostic text.

That distinction explains why email systems track both immediate SMTP replies and asynchronous bounce notifications. A robust sender correlates either outcome back to the original message and recipient, then applies a clearly defined suppression or retry policy.

Acceptance is not the same as inbox placement

A 250 response means the recipient server accepted the message at that stage. It does not prove that a human received, opened, or even saw the email. The message might later be filtered, placed in spam, or routed according to the recipient’s organization-wide mail rules.

This is why delivery reporting should distinguish at least four concepts:

  1. Sent: your application or sending service accepted the message for processing.
  2. Delivered or accepted: the recipient’s mail infrastructure accepted the message.
  3. Bounced or failed: the receiving infrastructure rejected it or reported delivery failure.
  4. Engaged: the recipient opened, clicked, replied, or otherwise interacted, where those signals are available and meaningful.

Hard bounce vs. soft bounce

The familiar hard-bounce and soft-bounce labels are useful shorthand, but they are operational classifications rather than perfectly universal protocol categories. The SMTP standard defines response classes; each sender must decide how to classify and act on the details returned by mailbox providers.

Hard bounces

A hard bounce is usually treated as a permanent, recipient-specific delivery failure. The most common example is a recipient address that does not exist. Other examples can include a malformed address, an invalid recipient domain, or an account that has been permanently disabled.

Typical hard-bounce scenarios include:

  • person@company.example was mistyped at signup.
  • An employee has left a company and their mailbox was removed.
  • A customer’s old internet service provider mailbox has been closed.
  • The domain portion of an address no longer resolves for mail.
  • A recipient address was imported from an outdated CRM record.

The usual action is immediate suppression. Do not keep retrying a recipient merely because the campaign is important. Repeated attempts to a known-invalid address cannot create delivery and can make a list-quality problem worse.

That does not mean every 5xx response should be treated as an immutable hard bounce. A 5xx response may reflect a policy rejection, missing authentication, content issue, rate restriction, or provider-specific requirement. Suppressing the affected recipient in that situation may hide the real issue, because the address may be valid and the sender’s configuration is the problem.

Soft bounces

A soft bounce is usually a temporary or potentially recoverable failure. It often maps to a 4xx SMTP response, such as an overloaded receiving server, a temporary connection failure, a mailbox over quota, or a rate limit.

Common soft-bounce scenarios include:

  • The recipient’s mailbox is temporarily full.
  • The receiving server is undergoing maintenance or is temporarily unavailable.
  • The receiving provider has deferred mail because of connection volume or rate limits.
  • The sender has a temporary DNS, TLS, routing, or network problem.
  • The recipient provider has temporarily limited traffic while evaluating reputation.

The appropriate response is generally a controlled retry. Good mail systems use retry queues with backoff, rather than reconnecting repeatedly in rapid succession. A temporary failure that persists across multiple attempts or multiple campaigns may deserve escalation or suppression based on your policy and the exact response.

Why the labels require judgment

A mailbox-full response may be temporary today but can remain unresolved for weeks. A policy rejection may use a permanent 5xx code but can be fixed by publishing valid authentication, reducing complaint rates, correcting message formatting, or changing the sending pattern. A recipient can also be valid but unable to receive mail because their organization has blocked the sender domain.

For that reason, the best approach is not “delete every 5xx” or “retry every 4xx forever.” It is to classify failures using the SMTP code, enhanced status code, diagnostic text, recipient domain, previous delivery history, message type, and the duration of the failure.

Email bounce rate: definition and formula

Email bounce rate is the percentage of attempted messages that fail to be delivered or accepted, depending on the reporting definition used by your provider. It is commonly calculated as bounces divided by sent messages, multiplied by 100.

Bounce rate = (Number of bounced emails / Number of emails sent) × 100

The formula is simple, but definitions must be consistent. Before comparing reports, establish whether “sent” means messages submitted by your application, messages accepted for outbound processing, or messages for which an SMTP delivery attempt occurred. Also establish whether the numerator includes only permanent bounces, both permanent and temporary failures, or only failures after the retry window ends.

Worked email bounce rate example

Suppose a product sends 20,000 account-update emails. Of those messages:

  • 19,300 are accepted by recipient servers.
  • 400 are permanently rejected because the addresses do not exist.
  • 300 are temporarily deferred at first but are eventually delivered after retries.

If the final bounce metric includes permanent failures only, the calculation is:

Bounce rate = (400 / 20,000) × 100
Bounce rate = 2%

The campaign’s final bounce rate is 2%. The 300 temporary deferrals should be reported separately because they are meaningful operational data, but they should not be counted as final bounces if they later succeed.

Now consider a different outcome: 180 of those 300 temporary failures remain undelivered after the retry period expires. If your reporting definition counts final unresolved failures, the calculation becomes:

Final failed deliveries = 400 permanent bounces + 180 unresolved temporary failures
Bounce rate = (580 / 20,000) × 100
Bounce rate = 2.9%

Neither method is inherently wrong if it is documented. What creates confusion is using a bounce-rate number without saying which failure states it includes.

Segment the metric before acting on it

An overall bounce rate can conceal the actual problem. Break it down by factors that can explain the pattern:

  • recipient domain, such as Gmail, Yahoo, Microsoft-hosted domains, or corporate domains;
  • message stream, such as receipts, password resets, product notifications, newsletters, or re-engagement campaigns;
  • acquisition source, signup form, partner import, event list, sales CRM, or historical migration;
  • sending domain and IP pool, if your infrastructure uses more than one;
  • campaign, template, deployment, or release version;
  • failure class, enhanced status code, and diagnostic response;
  • time period, particularly before and after a list import or configuration change.

A 3% bounce rate spread evenly across a long-lived opt-in list suggests a different investigation from a 3% rate concentrated in a new CSV import. Likewise, temporary deferrals concentrated at one recipient domain usually call for a different response than invalid-address failures distributed across every domain.

Common causes of email bounces

The fastest way to reduce bounces is to identify the category of failure accurately. “The email bounced” is an outcome, not a diagnosis.

Invalid, misspelled, or retired recipient addresses

Invalid recipients are among the clearest causes of hard bounces. They occur when someone types an address incorrectly, changes jobs, closes an account, or when data is copied incorrectly between systems.

Common examples include missing characters, accidental spaces, a domain typo such as gmial.com, a bad import column, or a stale business contact. Some mistakes can be prevented at entry time with basic form validation. Others require ongoing hygiene because a once-valid address can become undeliverable later.

Stale lists and weak consent practices

An address collected years ago may no longer be active, relevant, or appropriately permissioned. Long periods of inactivity are risky because addresses decay and because recipients may forget a brand or subscription they once accepted.

Purchased, scraped, rented, or poorly documented lists are especially likely to contain invalid recipients and unwanted mail. They can also create spam complaints and trap-related risk. Bounce reduction begins before email is sent: collect addresses through clear consent, preserve the source and date of consent, and do not treat every address in a database as marketing permission.

Full mailboxes and recipient-side capacity problems

A recipient’s mailbox can be over quota or temporarily unable to store new mail. This often produces a temporary response, but it should not be ignored indefinitely. If a mailbox remains unavailable through repeated attempts over a meaningful period, the address may need to move into an inactive or suppressed state according to your sending policy.

The right action is to let your delivery system retry with backoff, record the outcome, and avoid turning temporary problems into a flood of duplicate delivery attempts.

Sender reputation, rate limits, and policy rejections

Receiving providers can defer or reject mail because of the sender’s behavior or reputation. A response can be triggered by high complaint rates, unusual sending volume, sudden traffic spikes, poor engagement, insufficient authentication, suspicious content, or connections that do not meet the provider’s technical expectations.

These bounces are important because they are not fixed by removing a single recipient. Instead, inspect whether the failures cluster by provider, IP address, sending domain, stream, or time window. Review authentication, recipient quality, message cadence, complaint signals, and volume changes.

Do not assume a rejection means you are on a public blocklist, and do not assume a generic “policy” response identifies a single root cause. Mailbox providers deliberately protect many details of their filtering systems. The actionable evidence is usually the pattern across responses and sending behavior.

SPF, DKIM, DMARC, and alignment problems

Authentication problems can lead to delivery failures, especially as mailbox providers enforce stronger requirements for senders. SPF authorizes servers to send on behalf of a domain through DNS policy. DKIM adds a cryptographic signature that allows a receiver to verify that signed message content has not been altered. DMARC tells receivers how to evaluate SPF and DKIM alignment with the visible From domain and how to handle failures.

Authentication should be configured deliberately for every sending domain and message stream. A message can pass a technical check yet still lack alignment with the domain shown to recipients. That distinction matters when diagnosing provider policy responses.

Use provider documentation and your DNS host carefully when publishing records. Avoid copying configuration from an unrelated service or assuming that one correctly configured subdomain covers every sending domain. If you need implementation references for SMTP and API delivery, see the email API setup guides.

DNS, routing, and infrastructure faults

Some bounces originate in the sender’s own infrastructure rather than the recipient list. Incorrect DNS records, broken domain configuration, a missing route, TLS negotiation trouble, an unavailable outbound host, or a malformed envelope can stop delivery before a message reaches the recipient’s mailbox provider.

A key clue is scope. If many recipient domains fail at the same time following a deployment or DNS change, do not delete subscribers. Pause the affected stream if necessary, investigate the sender-side change, and test with controlled addresses before resuming volume.

Message size, content, and formatting issues

Very large attachments, unsupported content, malformed MIME structures, unsafe links, deceptive formatting, or messages that violate provider rules can be rejected. These failures may appear as content- or policy-related SMTP responses rather than mailbox errors.

For transactional email, attachments deserve special attention. A receipt with a small PDF is different from an application trying to deliver large documents to thousands of recipients. When a message must include substantial files, consider whether a secure download link is more reliable and more appropriate than an attachment.

How to reduce email bounces

Reducing bounces is a lifecycle discipline. You need controls when an address is collected, rules when an email is sent, and feedback handling after a recipient server responds.

1. Validate addresses at the point of collection

Start with basic checks: require an @ sign, reject obvious whitespace errors, normalize accidental leading or trailing spaces, and confirm the domain has valid mail-routing records where appropriate. These checks will not prove that a specific mailbox exists, but they prevent simple data-entry errors.

For higher-confidence list hygiene, validate addresses before high-volume campaigns or bulk imports. An address verification tool can help identify malformed domains, disposable addresses, risky patterns, and likely undeliverable recipients without using a campaign as the test. Use a free email address verification tool before sending to newly imported or uncertain contacts.

Verification results should be handled conservatively. Some domains use catch-all routing, some providers limit verification behavior, and no external check can guarantee a recipient will accept a particular message at send time. Treat verification as one signal in a broader data-quality process, not a license to mail every technically plausible address.

2. Use confirmed opt-in where it fits the risk

Confirmed opt-in asks a subscriber to verify their address by completing an action from an email. It reduces typo-driven signups, makes consent evidence stronger, and confirms that the person can receive mail at that address at the time of signup.

The tradeoff is conversion friction. For a product account, a verification email may be necessary. For a low-risk newsletter, a team may choose another approach. The important point is to match the collection method to the cost of bad data and unwanted mail.

3. Process bounces automatically and maintain suppression lists

A suppression list is a record of recipients who should not receive specific future messages, usually because they hard bounced, unsubscribed, complained, or otherwise became ineligible. It should be applied before each campaign or send attempt, not only cleaned up after a campaign finishes.

A practical bounce-handling policy might be:

  1. Suppress an address immediately after a confirmed invalid-recipient or nonexistent-mailbox failure.
  2. Retry temporary failures using controlled exponential backoff.
  3. Escalate repeated unresolved temporary failures for review or temporary suppression.
  4. Separate recipient-specific bounces from sender-wide policy or infrastructure failures.
  5. Preserve the original response, timestamp, recipient domain, message stream, and classification decision for troubleshooting.

Do not overwrite valuable diagnostic information with a generic “failed” label. The SMTP response and history often reveal whether you have a list problem, a configuration problem, or a provider-specific volume problem.

4. Separate transactional and marketing streams

Transactional messages and marketing campaigns have different urgency, audiences, volumes, and recipient expectations. Sending them through logically distinct streams can improve reporting and troubleshooting.

For example, a password reset should not be delayed or evaluated the same way as a weekly promotion. If a newsletter list contains old addresses and produces bounces, that must not obscure the health of account-security messages. Separation also makes it easier to see whether a bounce spike is tied to a campaign audience or to the underlying sender configuration.

5. Authenticate your domains and keep configuration aligned

Publish and maintain the SPF, DKIM, and DMARC records required for your sending setup. Ensure the visible From domain and authenticated domains are intentionally aligned where needed. Use TLS for mail transport, maintain valid DNS, and configure a stable envelope sender or return path for handling delivery feedback.

Authentication does not eliminate bounces from invalid recipients, but it reduces avoidable policy and trust failures. It also makes it easier for mailbox providers to evaluate mail as coming from the domain that claims responsibility for it.

6. Warm up changes and avoid abrupt volume spikes

A sudden increase in volume—especially to unengaged or uncertain recipients—can produce deferrals, policy responses, and poor reputation signals. When introducing a new sending domain, IP, provider, or major audience segment, increase volume gradually and start with the most engaged, recently active recipients.

Warming is not a substitute for consent or list quality. It is a way to make sending patterns more predictable while mailbox providers observe your traffic. A perfectly warmed sender can still create bounce problems by mailing obsolete addresses.

7. Monitor bounce patterns, not just one total

Set alerts for abrupt changes in permanent failures, temporary failures, recipient-domain concentration, and policy responses. Compare current results with a historical baseline for the same type of mail.

A useful monitoring view includes:

  • total sent, delivered, deferred, bounced, and suppressed counts;
  • hard-bounce and temporary-failure rates;
  • top recipient domains by failure count and rate;
  • top SMTP and enhanced status responses;
  • bounce performance by acquisition source and list age;
  • changes after template, DNS, application, or provider configuration releases.

The goal is early detection. A problem found after 100 failed sends is easier to correct than one found after a million-recipient campaign.

How to troubleshoot a bounce spike

When bounces rise sharply, resist the urge to treat every failed address as bad data. Start by determining whether the failures are recipient-specific or systemic.

Step 1: Identify the failure class

Inspect the SMTP code, enhanced status code, and complete response text. A nonexistent-recipient response calls for suppression. A temporary 4xx response calls for retry and monitoring. A policy or authentication response calls for configuration and reputation investigation.

Keep in mind that human-readable diagnostic text is not standardized in the same way across providers. It can be useful, but it should be interpreted alongside the numeric response, message metadata, and broader trend.

Step 2: Check concentration

Ask whether failures are concentrated in one recipient domain, one message stream, one sending domain, one IP, one template, or one imported audience. Concentration is diagnostic.

For example, a surge of 5.1.1 failures immediately after importing leads from an old event is probably a data-quality issue. A surge of 4.7.x or policy-related responses at a major mailbox provider immediately after a volume increase is more likely a sending-pattern or reputation issue. A broad failure across all domains after a DNS change may be a configuration incident.

Step 3: Compare against recent changes

Review what changed before the spike: list upload, application release, sender-domain change, DNS update, template edit, new provider, campaign expansion, connection setting, or new acquisition source.

This step is simple but frequently overlooked. Delivery problems often correlate with a change that was considered unrelated, such as a new return-path domain, a modified From address, a broken unsubscribe implementation, or a release that accidentally mapped the wrong customer field into the recipient address.

Step 4: Apply the correct fix

For invalid addresses, suppress them and review collection quality. For temporary recipient-side failures, retry responsibly. For policy failures, verify authentication and examine volume, complaints, content, and engagement. For sender-side infrastructure errors, fix the underlying configuration before sending more mail.

Do not repeatedly resend a message simply because it is important. Retries should follow SMTP semantics and your provider’s queueing behavior. A repeated 5xx rejection is not solved by sending identical mail again moments later.

Step 5: Confirm recovery with a controlled send

After a configuration fix, test with a small, representative group rather than immediately returning to full volume. Check the response distribution, not just whether one seed mailbox received a message. Then scale carefully while monitoring temporary failures, permanent rejections, and engagement.

What not to do after an email bounce

Bounce management can create new problems when teams respond too aggressively or too simplistically.

Do not do the following:

  • Do not keep mailing hard-bounced addresses. A valid-looking address that repeatedly returns a clear invalid-recipient failure should be suppressed.
  • Do not permanently suppress every 5xx response without investigation. Policy and authentication rejections can affect valid recipients and require a sender-side correction.
  • Do not retry temporary failures forever. Use a defined retry window and escalation rule.
  • Do not hide bounces by changing reporting definitions. Separate deferred, failed, delivered, and suppressed states transparently.
  • Do not use a campaign to test an unverified list. Validate, segment, and begin cautiously.
  • Do not combine unrelated streams in one diagnosis. Marketing-list decay should not mask failures in receipts or account emails.
  • Do not treat a successful SMTP acceptance as proof of inbox placement. Monitor engagement, complaints, and provider feedback as well.

Email bounce best practices for developers

Developers often encounter bounce handling as an event-processing problem. The application sends a message, but the durable delivery outcome happens later. Designing for that reality prevents data loss and confusing customer experiences.

First, store a stable internal identifier for each outbound message and recipient. When your provider reports a bounce, associate it with the user, notification type, campaign, address, and original send timestamp. Avoid using only the recipient email address as the event key because a person can change addresses and a single address can receive several message types.

Second, make bounce processing idempotent. Providers can retry webhooks, events may arrive out of order, and a recipient may produce multiple delivery-related events. Your handler should safely process the same event more than once and should not reactivate an address because a late event appears after a suppression decision.

Third, keep marketing eligibility distinct from transactional necessity. A hard bounce should normally end marketing sends to that address. If an account uses that email as a login identifier, your product may also need to prompt the user to update it through an authenticated channel. Never assume the email itself is a safe place to deliver the update instruction if it is bouncing.

Fourth, use observability. Log the provider message ID, SMTP reply, enhanced status code when available, recipient domain, bounce category, and response time. Aggregate metrics help a deliverability team spot trends; individual event logs help engineers diagnose a single customer’s missing receipt or verification email.

Conclusion: treat email bounces as actionable feedback

An email bounce is a failed delivery signal, but it is not one single kind of problem. Some bounces mean a recipient address is permanently invalid and should be suppressed immediately. Others mean the receiver is temporarily unavailable. Still others reveal authentication, reputation, content, routing, or volume issues that affect valid recipients.

The strongest sending programs measure bounce rate consistently, preserve raw delivery responses, separate hard bounces from temporary and policy-related failures, and act on the underlying cause. Clean acquisition practices, address validation, automatic suppression, correct authentication, responsible retries, and detailed monitoring make email delivery more reliable for both campaigns and critical product messages.

FAQ

What is an email bounce?

An email bounce is a failed delivery outcome in which the recipient’s mail system does not accept an email or later reports that it could not be delivered. It can be permanent, such as a nonexistent address, or temporary, such as a full mailbox or server deferral.

What is a good email bounce rate?

There is no single universal threshold because list age, message type, acquisition source, and reporting definitions differ. The useful benchmark is your own healthy baseline. Investigate sudden increases, high rates in new imports, or failure patterns concentrated at one provider or message stream.

Should I remove hard-bounced email addresses?

Usually, yes. Suppress addresses that return a clear permanent invalid-recipient or nonexistent-mailbox failure. Do not keep sending to them. Review policy-related permanent rejections separately because the recipient may be valid and the sender configuration may need correction.

How many times should I retry a soft bounce?

Retry according to the temporary SMTP response, your provider’s queueing behavior, and a defined retry window. Use backoff rather than rapid repeated attempts. If a temporary failure remains unresolved over time, investigate the response and apply your suppression or review policy.

Can an email be delivered but still not reach the inbox?

Yes. A receiving server can accept a message while later placing it in spam, quarantining it, delaying it, or routing it elsewhere. SMTP acceptance is a delivery milestone, not proof of inbox placement or recipient engagement.