Shopify Outreach Suppression Lists [713K-Contact Study]

TL;DR

• Our April 22, 2026 graph study contained 534,515 stores, 712,801 contact records and 657,428 filled-in email rows. These are historical records, not a current send list.
• 97,770 rows had a stored bounced status and 297,173 had found or matched status. Route them to suppression or verification rather than treating them as currently deliverable.
• Exact lowercase/trimmed-email deduplication removes 34,388 extra rows. Keep account relationships while preventing duplicate sends.
• 22,095 stores had a bounced row and no verified, found/matched or catch-all/guessed alternatives under the study's rule. Other statuses can remain, so this is not a strict every-email-bounced count.
• Sender opt-outs and campaign exclusions take precedence over a verified row, newer export or saved-list membership.

Account Exclusions and Address Exclusions

Suppress an address for an address-specific issue; suppress an account for an account-specific campaign decision. A relevant store with a bad email can remain in a research queue for another appropriate contact. A current customer, active opportunity or opted-out account needs the applicable sender/campaign exclusion even if its new contact data looks attractive.

Save the scope and reason of each rule. A temporary offer-fit or cooling-off decision differs from a marketing opt-out. Do not expire an opt-out simply because a campaign ends or a fresh export rediscovers the address.

What the April Study Measured

The extraction expanded stored contact email lists that had at least one entry. It normalized addresses with lowercase and trimming, and classified generic inboxes by an exact allowlist after removing dots, underscores and hyphens from the local part. This heuristic does not prove personhood or mailbox ownership.

Role flags use stored normalized roles and title patterns. LinkedIn is a stored, filled-in URL, not a verified current employer or buyer. Email status is stored evidence rather than a current campaign delivery outcome. The query has no active-store or maximum record-age filter.

A contact's last-verified timestamp can describe a person refresh rather than a check of each address. For a current export, require address-level verification time, source and result; do not transfer one row's status to a different address or assume the contact timestamp proves email freshness.

Status and Routing Counts

All percentages below use 657,428 email rows, not distinct addresses, people or stores. The eight routing rows partition the email rows under the script's precedence; generic classification is applied before the verified-role buckets.

The verified buckets sum to 257,139 rows (39.1%). Of these, 100,782 are non-generic. Across all statuses, 330,917 rows (50.3%) match the generic heuristic. A non-generic local part is not proof of a named person, and a generic address is not automatically invalid.

The underlying role count includes generic rows too, explaining why it can differ from the non-generic routing buckets. Do not rename the 85,259 fallback as “known other role” or the 15,150 group as automatically ready to send.

Exact-Email Duplication

657,428 − 623,040 = 34,388 extra rows. Exact normalization does not merge aliases, prove two addresses are the same person or resolve parent-company relationships.

Preserve every address's linked accounts and evidence history. Before choosing a preferred duplicate row, combine applicable opt-outs, sender blocks, bounce evidence and campaign history. A verified duplicate must not overwrite an opt-out or silently erase a newer bounce. Resolve status conflicts using address-specific dates and sources; hold unresolved conflicts.

Keep one send record per normalized address within the campaign. If the address belongs to several accounts, choose the account relevant to the offer while retaining the other relationships for coordination. Do not infer separate people merely from different storefront records.

Store-Level History Uses a Different Denominator

“No specified alternative” requires a bounced row and zero verified, catch-all/guessed, found or matched rows. It does not require every email row to be bounced; other statuses may coexist. These stores need review before an email export rather than a blanket assertion that every contact bounced.

The third row shows 7,419 accounts can have both a verified non-generic address and bounced history. Account history does not invalidate every address, and a valid-looking address does not remove other account exclusions. Assess both scopes.

Stored Bounced-Email History by Category

The denominator is stores with at least one filled-in email row in the category. The numerator is stores with any stored bounced row. This is not the future bounce probability of a deduplicated, currently verified campaign.

Address depth, data age and source coverage can affect this statistic, but the study does not isolate their effects. Apply suppression and current verification across categories rather than declaring a category safe or unsafe from historical shares.

Saved-List Overlap Is Platform-Wide

The April extraction reports 37 lists, 30,272 contact membership rows, 21,244 distinct contacts, 7,967 contacts in multiple lists and 9,028 extra memberships. It also reports 45,235 contact reveal rows for 32,158 distinct revealed contacts.

Those aggregates are platform-wide, without a workspace, sender or campaign restriction. Independent users can save the same contact legitimately. These counts do not prove repeated sends, duplicate exports by one agency or currently enforced suppression.

Within your own workspace/sender, compare both contact IDs and normalized addresses across relevant campaigns. List names or membership alone are not a central opt-out ledger. Confirm which exclusions the export and sending systems enforce; apply the remaining checks manually before import.

Proposed Include/Exclude Workflow

This is a manual operating procedure, not a product flow we executed in the study.

1. Define the offer and include cohort, with dated estimated traffic/category/vendor observations. Validate the task; public signals are not confirmed need or budget.
2. Apply current customer, active opportunity, sender opt-out and campaign/account exclusions.
3. Research the relevant contact and obtain current address-level status, source and check time.
4. Combine duplicate histories before selecting a row, preserving all applicable suppression.
5. Route uncertain statuses and role/channel mismatches to review.
6. Import only the resulting campaign records and verify the sending platform's exclusion/deduplication behavior.
7. Record the final export, responsible owner, campaign ID and subsequent opt-out/bounce events in the sender's suppression system.
8. Reapply that system on every future export; a refreshed research list does not reset contact history.

A saved exclusion list can support this workflow, but verify its current enforcement and scope. Do not assume saving a segment automatically prevents future sends. StoreInspect pricing, checked October 10, 2026, provides CSV on paid plans; Free has no CSV. Export access itself does not establish sender-side suppression.

Opt-Out and Sender Requirements

The FTC's CAN-SPAM guide, checked October 10, 2026, covers commercial email, including B2B. It requires a clear opt-out mechanism and honoring requests within 10 business days. A currently verified address does not override an opt-out.

Google's personal Gmail sender guidelines, checked the same day, require SPF or DKIM for all senders. Senders at about 5,000 or more messages per day to personal Gmail need SPF, DKIM and DMARC, with one-click unsubscribe for marketing/subscribed messages. Review the full linked scope and requirements; suppression does not replace authentication or establish permission to contact.

FAQ

Should I delete bounced records?

Preserve the historical reason and evidence while suppressing the address from sends. Reconsider only with documented later address-specific evidence; do not let a new import erase the history.

Should I exclude an entire store?

Use account exclusions for account-level decisions and address exclusions for address issues. A store with bounced history may have a separate appropriate contact, subject to account and sender rules.

Are verified non-generic rows executive contacts?

No. The prefix heuristic, stored status and role field need separate validation. The fallback verified group can include unknown roles.

Does overlap in saved lists prove duplicate outreach?

No. The reported overlap is platform-wide. Inspect the relevant workspace, sender, normalized address and campaign history, and verify actual exclusion enforcement.