Short answer
A permanent bounce is unlikely to resolve by resending the unchanged message; a transient failure may allow a later attempt. Read the complete code and diagnostic text rather than just hard or soft labels. A nonexistent address and a policy block require different corrections even though both prevent delivery.
Key verification: Each bounce retains its code, diagnostic text and decision without reactivating unsubscribed contacts.
Sources and limitationsSuspended contacts appear after quote emails are sent. Deleting the whole list hides the cause; resending the entire list may repeat it. Start with a record of recipient, campaign, date, code and server text. Separate a technical failure from an unsubscribe: resolving the former does not reverse the latter. This guide diagnoses the returned message; opens and clicks on emails that did arrive are interpreted in opens and clicks without assuming reading.
Read class, subject and detail
RFC 3463 defines enhanced status codes with three numbers. The first is the class: 2 means success, 4 a persistent transient failure (the message is valid, but a temporary condition has prevented or delayed delivery) and 5 a permanent failure, which the standard says is not likely to be resolved by resending the message in its current form. The second number is the subject: 1 concerns addressing, 2 the mailbox and 7 security or policy. The third specifies the diagnosis.
| Class | Subject | Detail | Meaning under RFC 3463 | Action before resending |
|---|---|---|---|---|
| 5 | 1 | 1 | The mailbox specified in the address does not exist | Verify the address through a known channel |
| 5 | 1 | 2 | The destination system does not exist or cannot accept mail | Check the domain; do not try random variants |
| 4 | 2 | 2 | Mailbox full due to quota or capacity | Let the retry policy run |
| 5 | 7 | 1 | Sender not authorised; message refused | Investigate policy, authentication and content |
Do not translate every class 5 failure into “mistyped email”: a policy rejection requires investigation, not letter changes. Retain the full diagnostic and ask the provider about inconsistent code and explanation. A permanent failure describes that attempt under those conditions, rather than proving the person is no longer a customer.
Three diagnostic examples
| Illustrative case | Diagnosis | Next step |
|---|---|---|
| Address | Destination mailbox does not exist | Verify the address through an authorised channel |
| Capacity | Mailbox temporarily full | Review provider retry policy |
| Policy | Delivery not authorised by policy | Investigate rejection without inventing another address |
For a policy rejection, start by checking that your domain authorises the CRM to send, with the guide to SPF and DKIM in the CRM. If authentication is correct, the server text usually indicates whether the block concerns the sender, the content or a sending limit.
What to review in EngageBay
The EngageBay bounce guide, checked on 27 October 2026, defines a hard bounce as a permanent reason an email cannot be delivered, with examples such as a nonexistent address or the destination server blocking delivery completely. Among soft bounces it includes a full or inactive mailbox, a server that is down, too many emails, an oversized message, blocking due to content or server policies, DMARC or anti-spam, and even a nonexistent domain name. It states that it retries delivery several times and that an address that keeps soft bouncing in later campaigns will eventually be considered a hard bounce, without saying after how many. EngageBay’s soft label may therefore accompany a class 5 code: decide on the code, not just the label.
Worked example: twelve bounces in one campaign
A fictional quote follow-up campaign with 200 sends and 12 bounces, grouped by code.
| Class | Subject | Detail | Count | Pattern | Decision |
|---|---|---|---|---|---|
| 5 | 1 | 1 | 5 | Different addresses across several domains | Verify each one; do not resend until corrected |
| 4 | 2 | 2 | 3 | Different mailboxes | Wait for retries and review in the next campaign |
| 5 | 7 | 1 | 3 | Same destination domain | Pause sends to that domain and investigate policy |
| 5 | 1 | 2 | 1 | Domain with a typo | Check with the person through another channel |
The bounce rate is 12 / 200 = 6%, and the permanent failure rate 9 / 200 = 4.5%. But the aggregate hides the decision: the three policy rejections cluster on one domain, which points to a rule at that receiver rather than mistyped addresses. Deleting those three contacts would fix nothing and lose valid customers. The five nonexistent mailboxes, by contrast, are individual cases corrected one by one.
Spanish context: correcting does not reactivate an unsubscribe
If a bounced contact had unsubscribed, correcting their address does not restore consent. Article 22.1 of the LSSI allows consent to receive commercial communications to be withdrawn at any time. Check the unsubscribe before resending and keep both data points separate: delivery status and commercial preference. For new sign-ups, confirmation is validated with double opt-in, not by the absence of a bounce.
Common mistakes and how to detect them
| Mistake | Symptom | Check |
|---|---|---|
| Deciding only on the hard or soft label | Retries to addresses with class 5 | Export the full code next to the label |
| Deleting bounced contacts in bulk | Valid customers disappear from the CRM | Group by code and domain before deleting anything |
| Correcting letters on a policy rejection | The “corrected” address bounces too | Read the subject: if it is 7, the address is not the issue |
| Resending the whole campaign after a transient failure | Duplicates to people who received the first send | Resend only to those affected, after their retry |
| Reactivating an unsubscribe when correcting the address | Complaints from people who had asked to stop receiving | Cross-check corrected bounces with the unsubscribe list |
Verifiable incident closure
Using fictional data, assign a cause and action to each row. For a real incident, record the owner’s correction and preserve any contact restriction. Evaluate the next delivery result separately from opens or sales. Illustrative closure: “5.1.1; address checked through known channel; correction confirmed; unsubscribe reviewed; next send subject to procedure”. Correction and later delivery resolve the technical incident without changing commercial preference. Manual review suits a few cases; EngageBay is relevant when these states must accompany campaigns and contacts. The tables do not come from sends performed by CallsIQ.
From the author's experience
I don't have my own breakdown of bounce codes by Spanish domains, so when facing a rejection I'd always read the full SMTP code and its description, not just the provider's summary label. If I came across a bounce labelled "soft" that was actually backed by a class-5 code, I'd review that classification to avoid pointless retries and keep the original diagnosis rather than trust the label.
When policy rejections cluster on one domain, my first move would be to review authentication, reputation and that recipient's specific policy, requesting the full rejection text before concluding the email address itself is the problem. That's precisely the most common mistake I'd try to avoid when cleaning up bounced contacts: deleting every bounced address without distinguishing causes, instead of separating permanent errors, temporary failures and policy blocks, each of which needs a different fix.
To investigate a bounce incident, the minimum data I'd ask for in a ticket is the message ID, the date with time zone, the sender, the recipient domain and the full SMTP response, adding the delivery path and available headers when they exist, while keeping any personal data not needed for the diagnosis out of it.
Sources and limitations
Documentary review: . Content type: Documentation-based guide with original exercise.
Linked sources describe the terms and capabilities each provider publishes. Examples that use fictional data are labelled in the text.
Scope: Documentation reviewed on 16 October 2026. Examples are fictional and tests are proposed; CallsIQ has not performed product tests.
- RFC 3463www.rfc-editor.org
- EngageBay bounce guidehelp.engagebay.com
- Article 22.1 of the LSSIwww.boe.es
Check current terms
Consider these options if they solve the problem described. Confirm features, limits and availability in your country.
EngageBayAffiliate linkThe labelled commercial links may earn CallsIQ a commission or referral reward. Our commercial policy.
Official sources, explained calculations and clearly labelled examples. Read about our methodology and use of AI in writing.