--- title: "Bounce vs Complaint: Impact on Email Deliverability | SendHQ" description: Understand the difference between email bounces and spam complaints, and how each affects your sender reputation and deliverability. canonical: https://sendhq.cc/blog/bounce-vs-complaint-deliverability last-updated: 2026-09-21 --- # Bounce vs Complaint: What Actually Hurts Deliverability Bounces are technical failures, but complaints are reputation killers. Learn how to handle both to keep your sending reputation intact and your emails landing in the inbox. ## The Core Difference Bounces are technical failures where the receiving server rejects the email. Complaints are user actions where the recipient marks your email as spam. While high bounce rates signal poor list hygiene, complaints signal a lack of consent or relevance. Complaints hurt your reputation significantly more because they are a direct signal to ISPs that your content is unwanted, leading to faster blacklisting and lower delivery rates across your entire IP range. ## Understanding Bounces A bounce occurs when an email cannot be delivered to the recipient's mailbox. From an engineering perspective, this is a failure of the delivery attempt. Bounces are categorized into two types: hard and soft. ### Hard Bounces A hard bounce is a permanent failure. The email address does not exist, the domain is invalid, or the receiving server has permanently blocked your IP. You must stop sending to these addresses immediately. Continuing to send to hard-bounced addresses is a primary signal to ISPs that you are using an old or purchased list, which is a hallmark of unsolicited bulk email. Common SMTP error codes for hard bounces include: - 550: User unknown - 554: Transaction failed - 550 5.1.1: Bad destination mailbox address ### Soft Bounces A soft bounce is a temporary failure. The mailbox might be full, the server might be temporarily down, or the message size exceeds the limit. These are not immediate reasons to purge a contact, but repeated soft bounces should eventually be treated as hard bounces. Common SMTP error codes for soft bounces include: - 421: Service not available, closing transmission channel - 450: Requested mail action not taken: mailbox unavailable - 451: Requested action aborted: local error in processing ## Understanding Complaints A complaint happens when a user clicks "Report Spam" or "Mark as Junk" in their email client. Unlike a bounce, the email was successfully delivered to the mailbox. The failure here is not technical, but behavioral. ISPs (Internet Service Providers) like Gmail or Outlook track the ratio of complaints to total volume. If your complaint rate exceeds a very low threshold (often as low as 0.1 percent), your reputation drops. This doesn't just affect the specific campaign you are running; it affects every email sent from that IP or domain. ## The Deliverability Hierarchy It is critical to separate three distinct concepts: provider acceptance, delivery, and inbox placement. 1. **Provider Acceptance**: The receiving server accepts the connection and the message. If this fails, you have a bounce. 2. **Delivery**: The message is successfully placed in the recipient's mail store. 3. **Inbox Placement**: The message is placed in the Inbox rather than the Spam folder. Complaints directly impact this stage. If you have a high complaint rate, your emails may still be "delivered" (accepted by the server), but they will be routed straight to the spam folder for all users, regardless of whether those specific users complained. ## Engineering the Response As an engineer owning the incident queue, you cannot rely on manual cleanup. You need an automated pipeline to handle delivery events. ### The Suppression List Every professional sending setup requires a suppression list. This is a database of addresses that should never be emailed again. When you receive a `bounce` or `complaint` event via webhook, your system must add that address to the suppression list immediately. If you are using SendHQ, these suppressions are handled at the API level, ensuring that even if your application logic attempts to send to a suppressed address, the system blocks it before it hits the wire. ### Handling Webhooks Your webhook handler should look something like this (conceptual Node.js example): `app.post('/webhooks/email', async (req, res) => { const event = req.body; switch (event.type) { case 'bounce': if (event.detail.category === 'permanent') { await suppressionService.add(event.detail.email, 'hard_bounce'); } break; case 'complaint': await suppressionService.add(event.detail.email, 'spam_complaint'); break; case 'delivered': await trackingService.markAsDelivered(event.detail.messageId); break; } res.sendStatus(200); });` ## The AI Agent Problem: Idempotency and Approval When AI agents are tasked with sending emails, the risk of deliverability disasters increases. An agent in a loop could accidentally send 1,000 identical emails to a single user, triggering a flood of complaints. ### Idempotency Keys To prevent duplicate sends, always use an [idempotency key](https://sendhq.cc/terms/idempotency-key). This ensures that if an agent retries a request due to a timeout, the email is only sent once. ### Human-in-the-Loop (HITL) For agents sending high-stakes communication, implement an approval queue. The agent generates the draft, but a human must trigger the final API call. This prevents the "hallucinated spam" scenario where an agent sends irrelevant content to a large list, spiking your complaint rate. ## Infrastructure and Cost Tradeoffs Choosing a provider often involves a tradeoff between ease of use and cost. When scaling, the difference in pricing for high volumes is stark. According to the [Amazon SES pricing page](https://aws.amazon.com/ses/pricing/), SES costs 0.10 USD per 1,000 emails a la carte. For a volume of 50,000 emails, this costs approximately 5 USD. In contrast, using [Postmark's pricing](https://postmarkapp.com/pricing), 50,000 emails would cost roughly 66 USD (15 USD base for 10,000 plus overages between 1.20 and 1.80 USD per 1,000). Other options include: - **Resend**: Free tier is 3,000 emails per month (capped at 100 per day). Pro is 20 USD per month for 50,000 emails, with overages at 0.90 USD per 1,000 ([Resend Pricing](https://resend.com/pricing)). - **SendGrid**: Free tier is now a 60-day trial; Essentials starts at 19.95 USD per month ([SendGrid Pricing](https://sendgrid.com/pricing)). - **Mailgun**: 15 USD per month for 10,000 emails, with overages from 1.10 to 1.80 USD per 1,000 ([Mailgun Pricing](https://www.mailgun.com/pricing)). While SES is cheaper, the operational burden of managing your own suppression lists and reputation is higher. SendHQ bridges this gap by providing verified-domain transactional sending and built-in suppression management without the complexity of raw AWS configuration. ## Deliverability Checklist for Engineers To minimize both bounces and complaints, follow this technical checklist: - **DNS Validation**: Ensure your [SPF](https://sendhq.cc/terms/spf), DKIM, and DMARC records are correct. Use the [SendHQ DNS Checker](https://sendhq.cc/tools/email-dns-checker.md) to verify. See our [guide on DKIM, SPF, and DMARC](https://sendhq.cc/guides/email-dkim-spf-dmarc.md) for setup details. - **Double Opt-In**: Never add emails to a list without explicit confirmation. This is the only way to keep complaint rates near zero. - **One-Click Unsubscribe**: Implement the `List-Unsubscribe` header. It is better for a user to unsubscribe than to mark you as spam. - **Real-time Suppression**: Ensure your webhook handler updates your database in under 5 minutes. - **Monitoring**: Set up alerts for when your bounce rate exceeds 2 percent or your complaint rate exceeds 0.1 percent. ## Summary Table: Bounce vs Complaint Feature | Bounce | Complaint **Cause** | Technical failure (Invalid email, full box) | User action (Marked as spam) **Signal** | Poor list hygiene / Old data | Irrelevant content / No consent **Immediate Action** | Remove hard bounces immediately | Remove immediately **Reputation Impact** | Moderate (unless very high) | Severe **Primary Metric** | Bounce Rate | Complaint Rate **Goal** | Maintain a clean list | Maintain user trust ## Final Thoughts Bounces are a nuisance, but complaints are a crisis. A high bounce rate tells an ISP that you are sloppy; a high complaint rate tells an ISP that you are a bad actor. By automating your suppression logic and implementing strict opt-in flows, you can protect your sending reputation. For product teams needing a reliable way to handle transactional mail and agent-driven communications, check out [SendHQ](https://sendhq.cc/index.md). ## Keep reading - [How to Receive Email with Amazon SES: S3 and Lambda](https://sendhq.cc/blog/receive-email-amazon-ses-s3-lambda): Build a production-ready inbound email pipeline with Amazon SES, S3, and Lambda, including MIME safety, tenant routing, idempotency, retries Read article → - [Amazon SES Pricing Tiers Explained (July 2026)](https://sendhq.cc/blog/amazon-ses-pricing-tiers-2026): Amazon SES shifted from a simple a la carte model to tiered plans (Essentials, Pro, Enterprise) on July 21, 2026. Here is the cost breakdown Read article → - [DMARC p=none vs Quarantine vs Reject: An Operator's Guide](https://sendhq.cc/blog/dmarc-policy-p-none-quarantine-reject): Choosing the right DMARC policy is a balancing act between security and deliverability. Learn the safe rollout path from p=none to p=reject Read article →