✓ Existing permissioned contact lists
✓ Small teams reviewing verification files
✓ Cross-vendor result and return decisions
— Cold outreach or purchased-list validation
— Guaranteed inbox placement
— Legal permission certification
— An email campaign builder
Write the precedence rule
Decide which system owns unsubscribe, complaint, permanent-bounce and other exclusion state. Preserve those fields in the source of truth. A verification file is not automatically authorised to change them. Review any import option that might overwrite subscription state before selecting it.
Test the conflict explicitly
Use synthetic records to represent an opted-out deliverable address, an active unknown address and an excluded invalid address. The mapping should preserve the exclusions and hold ambiguity rather than force all rows into a single generic “good” column. This is a local logic test, not a real subscriber test.
Stop condition
If you cannot demonstrate that the intended mapping preserves exclusions, do not perform the production return. Keep the original snapshot and request the exact import behaviour from the platform documentation or support. A reversible mapping is worth more than finishing the batch quickly.
Put it into practice
Before a production return, make a synthetic change table. Row A begins excluded and receives a favourable verification result: expected exclusion remains unchanged. Row B begins active and receives unknown: expected technical field becomes unknown, while the communication decision follows the reviewed hold policy. Row C begins excluded and receives an unfavourable result: both the existing exclusion and the new observation remain traceable. Then inspect the actual import configuration against these expectations. A mapping that writes a technical label into a subscription-status field should fail the review even if the file imports without errors. Keep the precedence rule with the mapping version so another operator does not accidentally reverse it later. If the platform's import semantics are unclear, hold the dependent write and resolve that exact uncertainty. Do not recreate or resubscribe excluded contacts to get around an inconvenient import restriction.
Where the safety evidence stops
This guide draws on Mailchimp cleaned contacts, Mailchimp audience requirements. Merchant-controlled records describe the provider’s own capabilities, terms or standards; they do not independently validate those claims. These records do not establish independent confirmation of the product claims.
Verify any current price, plan limit, label direction, compatibility rule, or commercial term that would materially change the decision. The dated source ledger shows the underlying records so this conclusion can be checked and updated.
Sources used for this page
These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.
- Mailchimp cleaned contacts — Merchant documentation · mailchimp.com · Merchant-controlled · checked 2026-09-27
- Mailchimp audience requirements — Merchant documentation · mailchimp.com · Merchant-controlled · checked 2026-09-27