A bounce report that says “8% bounced” is not enough to fix anything. The useful information is the SMTP response for each failed recipient, the mailbox provider that returned it, and the source of the address. Cold outreach can fail because an address does not exist, a domain has no mail service, a receiving server rejects your sender, a provider temporarily throttles traffic, or your authentication is broken. Those require different actions.
Split permanent failures from temporary failures
SMTP responses beginning with 5 are generally permanent failures; responses beginning with 4 generally indicate a temporary condition that may be retried. Save both the numeric code and the text because providers use extended status codes and explanatory wording.
An invalid-recipient response should move the address to permanent suppression. Repeatedly retrying a mailbox that the receiver says does not exist wastes sending capacity and can worsen list-quality signals.
A temporary rate-limit response belongs in a different queue. Your platform may retry automatically, but a rising count after a volume increase is evidence to stop ramping and examine cadence or reputation.
Group bounces by cause, not campaign
Create categories that are actionable: - recipient does not exist; - domain or MX problem; - mailbox full or temporary recipient issue; - rate limited or deferred; - policy/reputation block; - authentication failure; - content/security rejection; - unknown, requiring manual review.
Do not rely on the ESP’s label alone when the raw response is available. Save a sample of the actual SMTP text for each cluster.
Then add two dimensions: mailbox provider and lead source. If 60 invalid addresses all came from the same vendor export, the immediate fix is the source. If valid-looking contacts across several sources are rejected only by Gmail with policy errors, investigate the sender.
Validate the domain before blaming the mailbox
For a suspicious address, check whether the domain resolves and publishes MX records. A typo such as `compnay.com` can be caught without attempting delivery. Domain-level failure is different from a specific mailbox that no longer exists.
Email-verification services can help classify obvious problems, but their output is probabilistic. Catch-all domains intentionally accept mail for addresses that may or may not map to real users. Treat “catch-all” as uncertain rather than “verified.”
If a list came from public research, compare the company domain with the organization’s current website. Mergers, rebrands, and job changes make old business addresses decay even when the original research was accurate.
Authentication and policy bounces need sender-side repair
If the response mentions SPF, DKIM, DMARC, unauthenticated mail, or a policy requirement, send a test message to a mailbox you control and inspect headers. Confirm the actual CRM or sequencing tool passes authentication and alignment.
For a domain-wide reputation or policy block, pause attempts to that provider while you investigate. Cycling through alternate From addresses on the same domain does not repair the underlying reputation and can make your operation look evasive.
Use bounce rate by source as a procurement metric
Every lead record should carry a source and acquisition date. At the end of a campaign, calculate permanent invalid-recipient failures per source. Compare sources on the same campaign and same sending period.
A vendor that supplies twice as many rows may be worse value if a large share are stale. Keep an exclusion list of dead addresses so the same record cannot reappear through a later import.
For manually researched leads, use the failure to improve the research rule. If a common pattern such as `first.last@company.com` was guessed without evidence, stop labeling those addresses as verified. Store “pattern inferred” separately from “mailbox verified.”
A clean bounce-handling policy
Permanent invalid recipients should be suppressed automatically. Temporary failures can be retried according to your provider’s normal queue behavior, but repeated temporary failure should eventually move the address out of active sequencing. Policy or authentication failures should create an infrastructure incident, not an address-quality incident.
Review unknown codes manually until you have enough examples to classify them confidently. Do not build automation that converts every unfamiliar 5xx response into “bad lead”; a policy rejection can affect a perfectly real mailbox.
The best bounce troubleshooting outcome is not merely a lower rate next week. It is a feedback loop: SMTP evidence identifies the failure class, the failure class points to either the list or the sender, and the corrected source rule prevents the same bad records from entering the next campaign.
Read the SMTP class before changing the list
Turn bounce responses into an action queue instead of one “failed” bucket. A permanent recipient failure such as a nonexistent mailbox belongs in suppression. A temporary `4xx` deferral belongs in the sending platform's retry path while you investigate rate, reputation, or provider conditions. Authentication or policy failures belong to the sender owner, not the list-cleanup queue.
Keep the enhanced status text with the recipient and source batch because the leading class alone is not enough. A permanent recipient-address failure and a permanent sender-policy rejection can both be `5xx` but require completely different fixes. Use the mailbox provider's returned text and documentation when the meaning is unclear.
Weekly, count failures by source batch × receiving domain × reason family. That matrix shows whether a vendor supplied invalid addresses, one mailbox provider is deferring the stream, or a configuration change broke authentication. Suppress only the records that the evidence says should not be retried.