Back to articles

What To Do When A Small Email List Shows Bounces

A small-list bounce review that separates permanent failures, temporary delivery problems, and sender-side issues before the next campaign.

What To Do When A Small Email List Shows Bounces editorial image for Email Squid.

When a small email list shows bounces, do not react to the percentage alone. Ten failed deliveries in a list of 200 looks dramatic, but the useful question is what failed and why. Export the provider’s bounce reasons, separate permanent address failures from temporary delivery problems, check whether the failures cluster by domain or signup source, and pause only the affected addresses while you investigate.

Start with counts and bounce categories

Write down the total messages attempted, delivered, and bounced. Keep the raw count beside the rate because small denominators exaggerate movement: four bounces out of 100 sends is 4%, while four out of 1,000 is 0.4%. Then use the categories and diagnostic text supplied by the sending platform. A permanent failure commonly points to an address or domain that cannot receive the message. A temporary failure may reflect a full mailbox, a receiving-server delay, a size limit, reputation filtering, or another condition that could change.

Provider labels are not perfectly consistent, so preserve the original status code and message. Do not convert every temporary failure into a permanent deletion, and do not keep repeatedly mailing an address your platform has classified as permanently undeliverable. Follow the suppression behavior documented by your email service provider.

What To Do When A Small Email: Decision Evidence Table

PatternEvidence to collectNext action
One or two invalid recipientsPermanent-failure code, signup source, recent address editSuppress the failed address and correct only from verified first-party information
Many failures at one receiving domainShared status text, sending time, authentication result, provider incident noticesPause that segment and investigate a domain-specific delivery problem
Failures spread across older contactsLast engagement, acquisition date, consent record, prior bounce historyReview list age and acquisition quality before the next broad send
Sudden failures across the listCampaign change, sender domain, SPF/DKIM/DMARC results, platform statusStop the next campaign until sender-side configuration is checked

Check where the addresses came from

For each failed address, identify the signup form, import, checkout, event, or manual entry that created it. A cluster from one form may reveal a typing problem, bot submissions, or weak validation. A cluster from an old import may indicate addresses that were never confirmed or have gone stale. Never guess a corrected address or append a purchased replacement. Use a verified customer channel if a genuine business relationship requires contact, and keep consent and suppression records intact.

Review the list-hygiene routine before sending again. Remove duplicates, honour unsubscribes, preserve permanent-bounce suppressions, and inspect role accounts or obvious input errors according to your policy. Email Squid’s monthly list-hygiene guide gives this work a repeatable cadence.

Rule out sender-side changes

If bounces rose suddenly, compare the campaign with the last normal send. Did the From domain, sending platform, IP pool, message size, link domain, or authentication configuration change? Check SPF, DKIM, and DMARC results in the provider’s message diagnostics rather than assuming a DNS record is correct because it exists. Google’s email authentication guidance and DMARC setup guide describe the controls for Google Workspace senders; use the documentation for your actual provider as the operational source of truth.

Authentication is necessary but does not guarantee inbox placement. Complaint history, sending volume, recipient engagement, content, infrastructure, and receiving-domain policy can also affect delivery. Review domain reputation basics when the pattern extends beyond a few invalid addresses.

Worked example: eight bounces from 240 recipients

A local association sends a monthly update to 240 opted-in contacts and sees eight bounces. Six are permanent address failures spread across contacts added more than three years ago. Two are temporary failures at the same company domain. The operator suppresses the six permanent failures, keeps their original diagnostic records, and checks whether the old signup process captured confirmation consistently. The two company addresses are paused while the sender reviews the shared status text and asks its provider whether the receiving domain deferred the messages.

The team does not delete all eight contacts, resend immediately to the entire list, or change DNS based on a percentage. It documents the counts, category, source, and action for each failure. Before the next newsletter, it sends through the normal authenticated setup and checks that the company-domain issue has cleared. The result is a smaller, explainable correction rather than a list-wide reaction.

Decide whether to send again

  • Do not resend to addresses classified as permanent failures unless the address has been independently corrected and your platform permits it.
  • For temporary failures, follow provider retry behavior and investigate repeated failures before another campaign.
  • If failures cluster by domain, signup source, or sender configuration, hold that affected group while the cause is checked.
  • If the evidence is incomplete, run a controlled provider-supported test rather than using the full list as a diagnostic tool.

Record the review date, campaign, attempted count, bounce count, provider category, affected domain, acquisition source, action, owner, and next check. Compare the same fields after the next send. That short log makes it possible to distinguish a one-off address cleanup from a recurring acquisition or infrastructure problem.

Know when to escalate

Ask your email service provider for help when diagnostic codes are unclear, failures repeat after documented corrections, or a receiving domain appears to block legitimate authenticated mail. Involve the person responsible for DNS before changing authentication records. Seek qualified legal guidance for consent, retention, or communications obligations in the jurisdictions that apply to your organisation. General deliverability advice cannot determine those account-specific or legal facts.

For the next campaign, pair this review with the newsletter preflight checklist. The goal is not a universal zero-bounce promise. It is a list where failures are classified, suppressions are respected, sender configuration is verified, and each next action follows evidence rather than alarm.