Deduplicate Contacts Before Applying Suppression

Start with the decision boundary: deduplication should choose a canonical record while preserving every relevant event and never treating a shared domain as proof that two people are the same. is evidence for a sending decision, not a guarantee of acceptance, inbox placement, relevance, permission, or replies. Keep the original value, the observation time, and the rule that converted evidence into an action. This makes a list change explainable when a later event disagrees.

A practical workflow

1. Choose a stable key

Use a documented normalized address key for exact matching, while storing the original value and source row. Do not merge on domain, company, name, or a fuzzy similarity alone.

2. Group exact duplicates

Create duplicate groups and select a canonical record using explicit rules: newest authoritative profile, strongest provenance, or an approved CRM ID. Preserve all source IDs and timestamps in the merge log.

3. Union suppression history

If any duplicate has an unsubscribe, complaint, hard bounce, manual block, or legal hold, carry that event into the canonical record. A newer “valid” row cannot erase a stronger suppression state.

4. Reconcile after merge

Run the candidate audience against the canonical suppression key, then report before/after counts, conflict groups, and rows requiring human review. Keep the process repeatable and reversible.

Decision table

Situation	Evidence to retain	Default action
Exact duplicate	Normalized address, source IDs	Merge; preserve strongest suppression
Same domain, different address	Full address and recipient context	Keep separate; no automatic merge
Conflicting statuses	Event source, timestamp, rule version	Apply precedence; route ambiguity
Malformed duplicate	Original value and parse error	Hold or repair with evidence

Edge cases and guardrails

Case normalization and trimming can support matching, but provider-specific alias behavior is not a universal rule. Plus-addressing, dot-folding, Unicode, and internationalized addresses require a tested policy. Never “fix” a value in a way that changes the recipient without retaining the original.

How this fits with list operations

Run this before the outbound suppression rules are evaluated, then use the email verification statuses model for remaining technical outcomes. The list hygiene checklist provides the broader release gate. Start with the lead-generation academy, then use the list hygiene checklist for the audience gate, the verification status model for technical outcomes, and the outbound suppression rules for cross-system enforcement.

A merge log should include the canonical ID, absorbed IDs, matching rule, reviewer, time, and resulting suppression state. If a merge is later reversed, the history still explains why the address was excluded and prevents a silent re-entry.

Sources

• UK ICO: Respect people’s preferences
• Amazon SES account-level suppression list