{"schema_version":"2.0","record_type":"article","canonical_url":"https://marketingwiki.ai/articles/email-contact-address-change-handoff","id":"email-contact-address-change-handoff","slug":"email-contact-address-change-handoff","title":"Treat a Contact Email Change as an Identity Handoff","description":"Reconcile address ownership, collisions and historical references before editing. A two-address change ticket and collision decision tree.","dek":"Reconcile address ownership, collisions and historical references before editing. A two-address change ticket and collision decision tree.","category":"Audience Operations","topics":["Migma","email marketing","audience operations"],"publishedAt":"2026-09-17","updatedAt":"2026-09-17","lastVerifiedAt":"2026-09-17","readingMinutes":5,"author":"Marketing Wiki Research Automation","reviewer":null,"featured":false,"sources":[{"title":"Migma: Manage contacts","url":"https://docs.migma.ai/audience/manage-contacts?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-contact-address-change-handoff"},{"title":"Migma: Suppression list","url":"https://docs.migma.ai/sending-domains/suppression-list?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-contact-address-change-handoff"},{"title":"Migma: Webhooks","url":"https://docs.migma.ai/webhooks?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-contact-address-change-handoff"}],"wordCount":823,"body":"Treat changing an email address in Migma as a handoff of delivery identity. Before editing the field, establish who requested the change, whether the destination already belongs to another contact, and which downstream records must continue to refer to the same person.\n\n> **Editorial disclosure:** Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Product capabilities are vendor-documented unless labeled otherwise; sources were refreshed on September 17, 2026.\n\n**Affiliation disclosure:** Marketing Wiki’s commissioning maintainer also maintains Migma. Prepared by Marketing Wiki Research Automation under standing direct-publication authorization; not independently reviewed.\n\n[Migma's contact guide](https://docs.migma.ai/audience/manage-contacts?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-contact-address-change-handoff) documents editing an address and using email-based conflict handling in imports. It does not establish a universal merge policy, automatic transfer of history or preservation of every external reference. We recommend using Migma's contact detail view as the working record while explicitly reconciling those boundaries.\n\n## An address correction is not always the same operation\n\nThere are at least three different requests hidden inside “change this email.” A person may correct a typo before receiving anything. An existing subscriber may move to a new mailbox. Or two records may appear to represent the same person and an operator may want to combine them.\n\nThe third is a merge decision. It should not be disguised as a routine field edit. Matching names, shared company domains or similar purchase histories are insufficient on their own to establish that two records should be combined.\n\nUse the organization's approved identity-confirmation procedure. Do not place verification tokens, private correspondence or the full customer history in a general marketing ticket. Keep a reference to the evidence and restrict access appropriately.\n\n## The two-address change ticket\n\nUse synthetic placeholders during rehearsal. The production version belongs in the restricted system that owns contact administration.\n\n| Question | Required decision |\n| --- | --- |\n| What identifies the existing person? | Stable contact or customer reference, not just the old address |\n| Why is the address changing? | Correction, verified mailbox move or separately approved merge |\n| Does the new address already exist? | Search every relevant destination before mutation |\n| What permission scope exists? | Preserve the actual recorded scope; do not invent a fresh opt-in |\n| Is either address suppressed? | Investigate the reason and retain appropriate exclusions |\n| What external keys refer to this contact? | CRM, commerce, support and automation mappings |\n| What proves completion? | Read-back plus downstream reconciliation, with unresolved differences noted |\n\nThe ticket makes uncertainty visible before it is spread to other systems. An empty collision result should identify where the search was performed; it is not proof about systems that were never checked.\n\n## Route collisions before editing\n\nIf the target address does not exist in the systems checked, proceed through the approved correction path and verify what the platform actually changes. If it already identifies the same verified person, decide which record will remain authoritative and what merge facilities the systems support.\n\nIf it identifies a different person or ownership is unclear, stop the change. Do not overwrite the destination record or copy the source person's segments and purchases into it.\n\nMigma documents upsert behavior for an email already present during import. That is useful for updating known records, but it does not prove that importing a new address will rename an old record. Treat import, edit and merge as different operations until the documented contract and a controlled test show otherwise.\n\n## Follow the references, not only the displayed field\n\nAfter an authorized change, read the contact back by stable identity and inspect the address, status, lists and relevant fields. Check whether scheduled work refers to a current contact or a previously captured recipient value. Do not assume editing the address rewrites already prepared or delivered messages.\n\n[Migma's webhook catalog](https://docs.migma.ai/webhooks?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-contact-address-change-handoff) includes subscriber updates. An integration should reconcile the event with its identity mapping rather than assume the event contains a complete old-to-new migration history. Store the handoff in the owning application when that history is needed.\n\n[Migma's suppression list](https://docs.migma.ai/sending-domains/suppression-list?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-contact-address-change-handoff) is address-based in the cited guide. Do not infer that exclusions automatically move, disappear or become appropriate for a new address. A mailbox correction must not quietly undo an unsubscribe or complaint decision.\n\n## Test the uncomfortable cases\n\nRehearse a typo correction, a verified mailbox move, a target-address collision and a source record that is unsubscribed. Keep sending disabled. For each case, specify the expected contact identity, delivery address, permission state and downstream mapping before making the test change.\n\nAlso check what happens if the downstream sync fails after the primary edit succeeds. The recovery should reconcile the same handoff, not create an additional contact simply to make the counts match.\n\nNo contacts were edited for this article. The [validation and permission matrix](/articles/email-validation-permission-state-matrix) explains why a valid address does not establish permission; this handoff adds the identity decision that must come before using a changed address."}