How to Check an Email List for Bounces Before You Send

Start your list check with the people you can send to: remove unsubscribed and suppressed contacts, then verify the remaining addresses. Verification can catch unusable addresses, although sender or delivery problems can still cause the message to bounce.

By the end, you should be able to explain why each contact is included, excluded or waiting for a result. Keep uncertain checks out of the send, and don't let a fresh import bring back someone who unsubscribed.

Prepare the list before verification

Export the audience you intend to use, including a stable contact ID, email address, subscription status and any existing suppression or bounce reason. Work on a copy so you can compare the reviewed list with the original.

Exclude unsubscribed contacts, complaints and addresses already suppressed for a confirmed permanent recipient failure. A new verification result does not establish permission to email someone or erase a previous decision to stop sending. During a platform migration, transfer suppression records before activating imported contacts.

Next, trim accidental surrounding whitespace and validate the address format. Preserve the local part: do not remove +tags, strip dots or lowercase the whole address as a universal cleanup rule. Use a consistent comparison policy and deduplicate exact addresses after your approved normalization. OWASP's email canonicalization guidance explains the risks of provider-specific transformations.

Retain the original row IDs when several contacts share an address. Verification needs to run once for that address, but its result may need to update several records without changing their separate subscription history.

Verify the eligible addresses with MailSlurp

For a large list, the work is in checking batches and reconciling every result. MailSlurp is an email testing platform with an address-validation API that returns valid and invalid address lists, plus a boolean result for each checked address. You can use those results in an import or pre-send process without sending a campaign to discover obvious recipient failures.

The list validation endpoint accepts POST https://api.mailslurp.com/email-verification/email-address-list, authenticated with your x-api-key header and Content-Type: application/json. Each request accepts between 1 and 50 addresses. Its request body has this shape:

{
  "emailAddressList": [
    "first-recipient@example.com",
    "second-recipient@example.com"
  ]
}

Replace these example addresses with contacts you are authorized to check. Validation is billed per unit; check your account's allowance before processing a list.

1. Split the eligible, deduplicated addresses into batches of no more than 50 and retain the addresses submitted in each batch.
2. Submit a batch and wait for a successful response. A request error or timeout leaves that batch unchecked.
3. Read validEmailAddresses, invalidEmailAddresses and resultMapEmailAddressIsValid. Match results by address, not by array position.
4. Compare the submitted addresses with the returned map. If an address is missing or the result is inconsistent, hold it for investigation rather than silently passing it.
5. Save the result and check time against your contact records. Keep validation status separate from subscription status and permission to send.

The boolean map is an address-validation result. Your own process must still track unchecked batches, existing suppressions and the final decision to include a contact. For the meaning of syntax, DNS, mailbox and catch-all checks, see how to interpret email verification results.

Review the results before rebuilding the audience

Keep invalid results out of the upcoming send. Where you have an active relationship with a contact, ask for a correction through an existing channel; do not guess a replacement address. Keep the original record and reason so a later import does not undo the exclusion.

For incomplete checks, retry according to the service's guidance or leave the records pending. If your verification service reports a catch-all or unknown outcome, review it separately from confirmed invalid addresses. A server accepting a recipient does not establish that the named person has a dedicated mailbox there.

Reconcile the counts before export: every eligible address submitted should have a result or an explicit pending status. Then apply current unsubscribes, complaints and suppressions once more, since those may have changed while the list was being processed. Only the resulting eligible audience should go to the sender.

Suppress bad recipients, and investigate sender failures

After sending, read the full bounce response before changing the contact record. A permanent failure means that resending unchanged is unlikely to help; it does not always mean the recipient address is invalid. RFC 3463 distinguishes the failure class from the address, system, content or policy reason.

Reported failure	What to do with the contact and send
5.1.1, nonexistent destination mailbox	Suppress the address until the contact supplies a correction.
5.1.2, invalid destination domain	Exclude it and investigate the domain or a possible input error.
5.7.1, delivery not authorized	Stop retrying the unchanged send and investigate the provider's policy response. Do not label the mailbox nonexistent.
4.x.x, temporary failure	Let the sender manage its bounded retry schedule; review persistent failures when that schedule ends.

These are examples, not a substitute for the provider's diagnostic text. The address-status definitions and policy-status definitions explain why the same broad permanent-failure class can require different repairs.

If previously successful recipients all start failing at one provider, check for a shared sender issue before altering hundreds of contact records. Authentication failures, content rejection and rate limits need different repairs from a misspelled address. Use the email bounce diagnosis guide to investigate the actual response, and preserve any suppression your sending provider requires while resolving the cause.

Check that later sends respect the updated list

Test your list-handling logic with controlled records before relying on it for a campaign. Include an eligible contact, an unsubscribed contact, an address with a permanent recipient failure and a pending verification. Confirm that only the eligible record enters the outgoing audience and that a repeated import leaves the exclusions in place.

Use bounce simulation to test how your application reacts to a failure. A simulated bounce proves how the handler behaves; it does not verify an external address. Likewise, a successful message to a controlled inbox checks your send path, not every contact in a list.

During the real send, record attempted messages, bounces and provider reasons by campaign and recipient domain. Investigate a new concentration of failures, and apply confirmed recipient suppressions before the next send. Keep sender-policy incidents separate in reporting so a delivery configuration problem does not become a mistaken list-cleaning rule.