Email bounces and spam complaints are two of the most important email deliverability signals a sender can monitor. A bounce means a receiving mail system could not deliver a message; a spam complaint means a recipient used their mailbox provider’s reporting controls to mark a delivered message as unwanted.

They can look similar in a high-level dashboard because both reduce the value of your email program. But they occur at different stages, mean different things, and require different responses. A hard bounce usually calls for an immediate address-level suppression. A spam complaint usually calls for suppression too, but it also demands a broader investigation into consent, message expectations, frequency, content, and audience targeting.

This guide explains what email bounces and spam complaints are, how they appear in SMTP and API-based sending workflows, why mailbox providers care about them, and how to build reliable handling around them.

The short version: bounces versus complaints

A bounce is a delivery failure. Your sending service attempted to hand a message to the recipient’s mail server, but that server rejected it or could not accept it at that time. The failure may be permanent or temporary.

A spam complaint happens after delivery is accepted far enough for the recipient to see the message in a mailbox interface. The recipient then selects an action such as “Report spam,” “Mark as junk,” or “This is phishing.” Depending on the mailbox provider and available feedback-loop mechanisms, the sender or sending provider may receive a complaint event or aggregate complaint data.

The practical distinction is simple:

Bounces answer: “Could this mailbox receive this message?”
Complaints answer: “Did the recipient consider this message unwanted or abusive?”

A message may avoid bouncing and still be a serious deliverability problem. In fact, complaints are often more concerning than a routine invalid-address bounce because they are direct negative feedback from real recipients.

What is an email bounce?

An email bounce is a non-delivery result returned by a receiving mail system. It is commonly surfaced through an SMTP reply during delivery, a later delivery status notification (DSN), or an event generated by your email provider after it processes the remote server’s response.

SMTP has both three-digit response codes and, in many cases, enhanced status codes. The three-digit code tells you the broad outcome: 2xx means success, 4xx means a temporary failure, and 5xx means a permanent failure. Enhanced status codes add diagnostic detail in the form class.subject.detail, such as 5.1.1 for an address-related permanent failure. (rfc-editor.org)

A bounce is not always a bad address

It is tempting to interpret every bounce as “the email address does not exist.” That is sometimes true, but it is far from the full picture. A bounce can be caused by:

A misspelled, disabled, or deleted mailbox.
A domain with no usable mail service.
A recipient mailbox that is temporarily full or unavailable.
A receiving server that is overloaded or rate-limiting your traffic.
A message that exceeds a size limit.
A policy or authentication failure.
A sender reputation, content, or abuse decision made by the receiving provider.
A configuration problem in the sender’s own domain, such as broken authentication alignment.

The response code and diagnostic message are evidence, not an absolute explanation. Mailbox providers may intentionally provide vague SMTP text to avoid exposing account existence or filtering logic. That is why your sending system should store the raw SMTP response alongside its normalized event type.

Where a bounce happens in the delivery path

A simplified delivery path looks like this:

Your application submits an email through an SMTP relay or REST API.
Your provider queues the message and resolves the recipient domain’s MX records.
The provider connects to the destination mail exchanger over SMTP.
The recipient server accepts or rejects the envelope recipient, message content, or both.
Your provider records the result and may emit a delivery, deferred, bounced, or rejected event.

A rejection can occur before the receiving system accepts message data. For example, the remote server can reject the recipient during RCPT TO, often producing an address-oriented result. It can also accept the recipient and reject later, after DATA, because of message size, policy, authentication, or spam-filter decisions.

That timing matters. A message that is accepted by the remote SMTP server is not necessarily guaranteed to land in the inbox, and a message placed in spam may not produce a traditional bounce at all.

Hard bounces and soft bounces

The usual operational categories are hard bounces and soft bounces. These labels are useful, but they are simplifications. Your suppression policy should rely on the actual SMTP status, enhanced code, provider classification, and repeated behavior—not just the words “hard” or “soft.”

Hard bounces: permanent delivery failures

A hard bounce indicates that retrying the same message to the same recipient is unlikely to succeed without a material change. The classic example is a mailbox that does not exist.

Typical examples include:

550 5.1.1 User unknown
550 5.1.1 The email account that you tried to reach does not exist
550 5.1.0 Invalid recipient
553 5.1.3 Bad recipient address syntax

RFC 5321 specifically describes a 550 response as appropriate when the recipient is known not to be deliverable, often with text such as “no such user.” (rfc-editor.org)

Other permanent examples can involve a domain that explicitly does not accept email. A domain can publish a Null MX record using an MX target of a single dot, for example:

example.invalid.  IN  MX  0 .

A Null MX tells senders that the domain does not accept email. RFC 7505 recommends a 550 reply and enhanced code 5.7.27 when mail is rejected because the sender or recipient domain has such a record. (rfc-editor.org)

For a clear hard bounce, immediately stop sending to that exact address. Retrying a known-invalid address wastes sending capacity, increases bounce rates, and can make your list quality look worse to mailbox providers and email infrastructure vendors.

Soft bounces: temporary delivery failures

A soft bounce indicates that delivery may succeed later. SMTP 4xx replies are the classic example because the leading 4 means the sender may retry.

Examples include:

421 4.7.0 Temporary system problem
450 4.2.0 Mailbox temporarily unavailable
451 4.3.0 Requested action aborted: local error in processing
452 4.2.2 Mailbox full
451 4.7.1 Please try again later

A responsible email service normally retries temporary failures on a schedule for a limited period. Your application should not bypass that process by continuously resubmitting the same message. Doing so can turn a temporary recipient-side issue into excess traffic or an avoidable reputation problem.

However, “temporary” does not mean “ignore forever.” If an address repeatedly generates transient failures across multiple campaigns or transactional sends, it may be abandoned, blocked, or otherwise unhealthy. Establish a policy for when repeated soft bounces become suppressible—for example, after a defined number of failures over a reasonable period—while considering the business importance of the address and the nature of the message.

Why a 5xx response is not always an invalid mailbox

A 5xx failure is permanent from the perspective of that specific SMTP transaction, but it does not always mean the email address is invalid. For example:

550 5.7.1 Message rejected due to policy reasons
554 5.7.1 Message rejected as spam
550 5.7.26 Unauthenticated email from example.com is not accepted
552 5.3.4 Message size exceeds fixed maximum message size

These examples call for different remedies. Suppressing the recipient may be wrong if the rejection was caused by your authentication, content, sending IP reputation, or attachment size. Treat policy-related bounces as a signal to inspect the sending domain, message class, headers, and recent sending behavior before deciding whether the recipient should be permanently suppressed.

Reading SMTP status codes without overinterpreting them

SMTP responses have two layers: the basic response code and the enhanced status code. Use both when available.

The first digit: success, retry, or failure

The first digit provides the most important retry signal:

2xx: The receiving server accepted the command or message.
4xx: Temporary failure; retry later according to your provider’s queueing policy.
5xx: Permanent failure for this transaction; do not blindly retry unchanged mail.

For example, 250 2.0.0 OK means the destination server accepted the message. It does not prove inbox placement, opening, or reading. By contrast, 550 5.1.1 strongly suggests an address problem, while 550 5.7.1 often points to a policy or security decision.

Enhanced codes: the useful detail

Enhanced codes commonly follow this structure:

class.subject.detail

The class corresponds to success, persistent transient failure, or permanent failure. The subject identifies a broad category such as address status, mailbox status, mail system status, network or routing, protocol, content, or security/policy. RFC 3463 defines this framework so diagnostics can be interpreted in a more machine-readable, language-independent way than free-form SMTP text alone. (rfc-editor.org)

Useful examples include:

5.1.1: Bad destination mailbox address.
5.1.2: Bad destination system or domain name.
4.2.2: Mailbox full.
5.2.3: Message length exceeds administrative limit.
4.7.0: Temporary security or policy issue.
5.7.1: Delivery not authorized; policy rejection.
5.7.26: A receiving system’s authentication-related rejection code may be used differently across providers, so preserve accompanying diagnostics.

Do not build a parser that relies only on text such as “mailbox unavailable.” Text varies by provider, language, and anti-abuse policy. Normalize common status families, retain raw evidence, and allow for provider-specific handling when your event data makes that possible.

What is a spam complaint?

A spam complaint is negative feedback from a recipient. It generally occurs when someone marks a delivered email as spam or junk in their mailbox interface. The mailbox provider can use that action to move the message, train filtering systems, adjust sender reputation, and—in some cases—send a feedback report to the sender or sending platform.

Unlike a bounce, a complaint is not a transport failure. The message reached a mailbox provider and was sufficiently visible to generate recipient feedback. That is why complaints are often a stronger indicator that your sending practices are misaligned with recipient expectations.

Complaints can be caused by legitimate email

A complaint does not automatically prove that a message was malicious or unlawful. Users mark messages as spam for many reasons:

They do not remember signing up.
They expected a receipt but received promotional content.
They no longer want the email but cannot quickly find an unsubscribe option.
The sender increased frequency without clear notice.
The message appears suspicious because branding, sender identity, or links changed.
The email was sent to an old, shared, role-based, or reassigned address.
The recipient received a transactional message they did not trigger, such as a password reset or account invitation.

For transactional systems, complaints can reveal an application-level issue. Repeated password reset requests, an invitation flow that sends to the wrong person, a noisy notification default, or an exposed form that can be abused may all create complaint patterns even when the sending infrastructure is technically configured correctly.

Complaint feedback loops and aggregate reporting

Some mailbox providers and email ecosystems expose feedback through complaint feedback loops (FBLs), direct reports, or aggregate dashboards. The standardized Abuse Reporting Format (ARF) provides a machine-readable format for feedback reports, including abuse reports. (rfc-editor.org)

A complaint report may include fields identifying the feedback type, the original message headers, and data that helps the sender find the recipient or campaign. Privacy rules and provider policies mean that you should not expect to receive every individual complaint. Some providers offer aggregate metrics instead of recipient-level data, and complaint rates may be calculated over a specific eligible-message population rather than every message you submitted.

Treat every individual complaint event you do receive as a suppression event. Do not send further promotional or subscription mail to that recipient unless they later take a clear, affirmative action to resubscribe and your compliance requirements permit it.

Why email bounces and spam complaints hurt deliverability

Mailbox providers decide whether to accept, place, defer, filter, or block mail using many signals. These include domain authentication, IP and domain reputation, recipient engagement, sending patterns, content, infrastructure quality, and user feedback. Bounces and complaints affect different parts of that picture.

Bounces expose list and routing quality

A rising hard-bounce rate suggests that your addresses are stale, malformed, purchased, scraped, incorrectly imported, or collected without adequate validation. It can also reveal broken application logic, such as sending to placeholder addresses, not handling account deletions, or treating an unverified address as confirmed.

High transient bounce rates may indicate that you are sending too quickly, that a receiving provider is throttling your traffic, or that your own sending reputation has deteriorated. They may also be a sign of a temporary recipient-side outage, which is why trend analysis matters more than a single event.

Complaints expose expectation and trust problems

Complaint rate is a particularly meaningful measure because it reflects recipients saying they do not want your email. Even a technically perfect message—correct DNS, clean HTML, valid recipient—can attract complaints if it surprises people or makes opting out difficult.

Google’s sender guidance says to keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching 0.30% or higher. It also defines bulk senders, for its requirements, as senders that reach approximately 5,000 or more messages to personal Gmail accounts in a 24-hour period. (support.google.com) Yahoo likewise advises senders to keep spam complaint rates below 0.3%, and requires authentication and easy unsubscribe handling for bulk sending. (senders.yahooinc.com)

These thresholds are not targets to operate near. A complaint rate is a lagging outcome, and reported metrics can be delayed, sampled, or scoped differently from your internal delivery count. Build for a much lower baseline by sending only useful, expected mail to people who actually asked for it.

Authentication and DNS: preventing avoidable policy bounces

Authentication will not make unwanted email welcome, but missing or misaligned authentication can cause rejections, spam placement, and recipient distrust. For most production senders, SPF, DKIM, and DMARC are foundational controls.

SPF authorizes envelope senders

SPF is published as a DNS TXT record and identifies hosts or services permitted to send mail for a domain used in the SMTP envelope sender (MAIL FROM) or HELO/EHLO identity. RFC 7208 defines SPF as a mechanism that lets domain owners authorize sending hosts. (rfc-editor.org)

A simplified example might look like this:

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

The exact include: domain must come from your email provider’s documentation. Do not guess it, and do not publish multiple independent SPF TXT records for the same domain. SPF evaluation has DNS lookup limits, so consolidate authorized mechanisms into one valid record and audit it whenever you add a new sending system.

For example, this is usually incorrect because it creates two SPF policies:

example.com.  IN  TXT  "v=spf1 include:service-a.example -all"
example.com.  IN  TXT  "v=spf1 include:service-b.example -all"

Instead, combine the mechanisms into one record after verifying each provider’s required syntax:

example.com.  IN  TXT  "v=spf1 include:service-a.example include:service-b.example -all"

DKIM signs the message

DKIM adds a cryptographic signature to the email. The recipient retrieves the public key from DNS using the selector in the message signature. A typical DNS record uses a name such as selector._domainkey.example.com.

A representative DKIM record looks like this:

s1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

The public key in a real record is much longer than this abbreviated example. DKIM lets a signing domain take responsibility for a message, separate from the visible author identity alone. (rfc-editor.org) Use the exact selector, hostname, and value your sending provider supplies. If your DNS provider splits long TXT values automatically, verify the published result rather than editing key material by hand.

DMARC connects authentication to the visible From domain

DMARC is published at _dmarc and tells receivers how to evaluate alignment between the visible From: domain and SPF and/or DKIM identities. It also supports aggregate report delivery through the rua tag.

A monitoring-oriented record might look like:

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

A stricter policy can use p=quarantine or p=reject, but do not raise enforcement until you have reviewed report data and verified every legitimate sender for the domain. DMARC reports can show the policy evaluated, the SPF and DKIM outcomes, and the disposition applied. (rfc-editor.org)

Authentication alignment is especially important when your application sends through a REST email API or SMTP relay. Your provider may supply signing and return-path infrastructure, but you remain responsible for confirming that the domain you show users in From: is authenticated and aligned as intended.

For implementation references and provider-specific sending examples, consult your platform’s email API setup documentation, then verify DNS results independently with tools such as MXToolbox, dig, or nslookup.

How to handle bounces in an application

Do not treat bounces as an email-provider dashboard problem. They should update your product data and sending decisions.

Build an address suppression model

Maintain a suppression record keyed by normalized recipient address. At minimum, store:

The email address.
Suppression reason: hard bounce, complaint, unsubscribe, manual block, or policy decision.
The first and most recent event timestamps.
SMTP response code, enhanced status code, and raw diagnostic text when available.
The sending stream or message type involved, such as marketing, product notifications, receipts, or password resets.
A provider message identifier or your own idempotency/correlation identifier.

For an obvious invalid recipient such as 550 5.1.1, suppress immediately. For an ambiguous policy bounce, quarantine the event for review or use a narrower rule. For temporary 4xx responses, let the sending provider retry, then decide based on the final outcome and the pattern over time.

Use webhooks or event ingestion, not manual exports

A production application should consume delivery events through authenticated webhooks, provider event streams, or periodic APIs where supported. Validate webhook signatures, deduplicate events using stable event IDs, and make the handler idempotent. A retry from your provider should not create duplicate suppression rows or send duplicate alerts.

The conceptual event flow is:

email provider event -> signature verification -> durable queue -> event processor
-> recipient lookup -> suppression/update decision -> metrics + alerting

Keep the original event payload in durable storage with access controls. It is useful when debugging a false positive, comparing provider classifications, or explaining why a customer stopped receiving email.

Separate message streams

Do not let marketing-list quality damage account-security mail. Use distinct streams, subdomains, or logical sending categories where your provider supports them. At a minimum, tag messages internally so you can compare bounce and complaint rates for:

Authentication and password reset email.
Receipts, invoices, and account notices.
Product notifications.
Onboarding sequences.
Newsletters and promotional campaigns.

If a newsletter import creates a hard-bounce spike, you want to isolate that problem without obscuring the performance of receipts and password resets. Separation also makes root-cause analysis much faster.

How to reduce spam complaints

The best complaint-prevention strategy is not clever copywriting or a hidden technical setting. It is ensuring that every message is expected, recognizable, useful, and easy to stop.

Set expectations at collection time

When collecting an email address, explain what the person will receive and how often. “Get product updates” is not equivalent to “receive a daily promotion and weekly newsletter.” If you collect consent during checkout, account creation, or a lead form, keep a record of the source, timestamp, language shown, and any checkbox state.

Confirmed opt-in is especially valuable for promotional mail because it reduces typos, malicious signups, and confusion. It is not a substitute for relevance, but it gives you a stronger basis for believing the person expects future mail.

Make unsubscribe immediate and obvious

For marketing and subscription email, include a clear visible unsubscribe link in the message body. Do not require a login, use dark patterns, or make recipients answer a survey before you stop mail. A preference center can be useful, but it must not become an obstacle to unsubscribing.

Also implement list-unsubscribe headers. A standard example is:

List-Unsubscribe: <https://email.example.com/unsubscribe/eyJhbGciOi...>, <mailto:unsubscribe@example.com?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

RFC 8058 defines the List-Unsubscribe-Post mechanism for signaling one-click unsubscribe behavior, while RFC 2369 defines the broader List-Unsubscribe header convention. (rfc-editor.org) The endpoint should authenticate the recipient through an opaque, signed token and process the unsubscribe without requiring an interactive login.

Treat unsubscribe events as high priority. They are a safer alternative to a spam complaint. When someone asks to stop marketing messages, update suppression data promptly and ensure every sending path checks it before submitting mail.

Match the message to the trigger

Transactional email should be tightly connected to an action or account state. If a user requested a password reset, send a password reset. Do not add a promotional block that overwhelms the security purpose, and do not use transactional classification to bypass marketing consent.

For recurring notifications, offer sensible defaults and frequency controls. A product that sends separate emails for every comment, status change, and minor update may turn engaged users into complainers even though they originally opted in.

Make sender identity stable

Use a recognizable display name and a consistent From domain. Avoid sudden changes from updates@example.com to an unrelated domain, especially if your message asks recipients to sign in or take a security-sensitive action. Stable identity reduces suspicion and helps recipients distinguish legitimate email from phishing.

Before a significant campaign or template change, send tests to seed inboxes and inspect the raw headers. Tools such as mail-tester.com can help identify common authentication and formatting problems, while MXToolbox can help inspect DNS records and mail-server configuration. Use these tools as diagnostics, not as guarantees of inbox placement. You can also run addresses through an email address verification tool before adding them to a high-value sending workflow.

Investigating a sudden spike

A sudden increase in bounces or spam complaints should trigger a structured incident response. Do not immediately blame the email provider, the recipient domain, or a single template.

Start by slicing the data. Compare the affected events by time, recipient domain, sending domain, message type, API key or application, template version, signup source, geographic segment, and sending IP or stream if available.

Then work through this checklist:

Confirm the event type. Is this a hard bounce, deferred delivery, policy rejection, spam complaint, or inbox-placement problem being mislabeled as a bounce?
Read raw responses. Group SMTP results by both code and diagnostic text. A spike of 5.1.1 means something very different from a spike of 4.7.0.
Check recent changes. Review DNS edits, DKIM selector rotation, From-domain changes, template deployments, attachment changes, list imports, and application releases.
Check authentication. Query SPF, DKIM, and DMARC records directly. Review DMARC aggregate reports for unexpected senders or alignment failures.
Inspect recipient-domain concentration. If one mailbox provider dominates, look for throttling, policy responses, or provider-specific requirements.
Pause risky traffic. Stop or reduce the stream associated with the spike, particularly newly imported marketing audiences or messages that are generating complaints.
Preserve evidence. Keep sample message headers, SMTP replies, provider event IDs, and a timeline of changes.

For Gmail-specific diagnosis, Postmaster Tools provides dashboards for spam rate, reputation, message authentication, and delivery errors. (support.google.com) Treat those metrics as one input alongside your own event logs, not as a replacement for address-level suppression and application telemetry.

Common mistakes that make the problem worse

Several reactions to bounces and complaints reliably create more trouble.

Retrying permanent failures repeatedly

If the recipient server says 550 5.1.1, do not keep submitting the address every day. The address is not going to become valid because your job scheduler tries harder. Suppress it and fix the list source or application behavior that introduced it.

Deleting all bounced addresses without classification

A broad “delete on any bounce” rule can remove good users after a temporary mailbox-full event or a provider outage. Preserve the category, code, and response. Use hard-bounce suppression for clear permanent address failures; use a review or retry policy for temporary and ambiguous failures.

Treating complaint rate as a marketing-only metric

Complaints can originate from account notifications, receipts, invitations, or security messages. If transactional complaints rise, investigate whether recipients actually initiated the trigger and whether your application has abuse controls.

Hiding the unsubscribe path

Making unsubscribe difficult does not preserve a valuable audience. It shifts dissatisfied recipients toward spam reporting, which is worse for deliverability and trust.

Assuming delivery equals inbox placement

A 250 response means the receiving server accepted the message. It does not mean the recipient saw it in the primary inbox. Monitor complaints, engagement where appropriate, spam-folder placement through controlled testing, and mailbox-provider diagnostics.

A practical operating policy

Every sender should document decisions before volume makes them urgent. A lightweight policy might be:

Suppress immediately on confirmed spam complaints and explicit unsubscribes.
Suppress immediately on clear invalid-recipient hard bounces, especially 5.1.1 responses.
Allow the provider’s standard retry process for 4xx temporary failures.
Review repeated soft bounces and policy-related 5xx responses with context rather than treating all of them as invalid addresses.
Stop sending promotional mail to inactive or unengaged recipients according to a defined sunset policy.
Monitor metrics by message stream and recipient domain at least weekly, and more frequently during major sends.
Require a review of authentication, consent source, unsubscribe behavior, and list quality before importing a new audience.

The right numeric thresholds differ by message type and volume, but your policy should aim to find changes early. A small transactional sender may notice an issue from five related bounces; a high-volume sender may need automated anomaly detection by domain and campaign.

Conclusion

Bounces and spam complaints are not interchangeable email errors. A bounce is evidence that delivery failed or was deferred; a complaint is evidence that a recipient did not want the message. Both should influence your sending logic, but the corrective action must match the cause.

Handle clear hard bounces with immediate address suppression. Let infrastructure retry genuine temporary failures, while watching for repeat patterns. Treat complaints as both a recipient-level opt-out and a product-level warning: something about consent, frequency, content, targeting, or message triggering needs attention.

The most resilient email programs combine accurate SMTP event handling, clean DNS authentication, durable suppression data, clear unsubscribe controls, and disciplined audience management. That approach protects recipients, improves deliverability, and makes both SMTP relay and REST API email sending more reliable as your volume grows.

FAQ

Is a bounced email the same as a spam complaint?

No. A bounce is a delivery failure or deferral reported by mail infrastructure. A spam complaint is recipient feedback after a message is delivered or displayed in a mailbox context. Both are negative signals, but a complaint is generally more directly tied to recipient dissatisfaction.

Should I retry a hard bounce?

Usually not. For a clear permanent invalid-recipient response such as 550 5.1.1, suppress the address immediately. Do not repeatedly retry unchanged mail. For policy-related 5xx errors, investigate the message and authentication before deciding whether the address itself should be suppressed.

What is a safe spam complaint rate?

Aim for the lowest practical rate rather than treating a published limit as a goal. Google advises keeping reported spam rates below 0.10% and avoiding 0.30% or higher; Yahoo also advises staying below 0.3%. (support.google.com) A rising trend matters even when the absolute rate remains below those figures.

Can SPF, DKIM, and DMARC prevent spam complaints?

They can reduce authentication-related rejections and help mailbox providers trust that your mail is legitimately associated with your domain. They cannot make unwanted, excessive, or confusing email welcome. Consent, relevance, frequency, and easy unsubscribe controls remain essential.

Should transactional email include an unsubscribe link?

Purely transactional messages such as receipts or password resets usually should not be suppressed through a marketing unsubscribe mechanism when they are necessary to provide the requested service. However, notification and promotional components should respect user preferences, and marketing mail should provide a clear unsubscribe path.

What Are Email Bounces and Spam Complaints? A Developer’s Guide