​

Reconcile suppression across email and phone

A contact record can hold several ways to reach the same person. The suppression ledger still evaluates the address and scope on each entry; it does not infer that an opt-out for one address applies to every other address on the contact. Use this guide when reconciling an email address and a phone number, including WhatsApp ID, after a contact merge or consent update.

​

The double-address problem

An email entry blocks email sends to that email address. An E.164 phone entry with scope all blocks phone-based SMS, voice, and WhatsApp sends to that number. A WhatsApp ID row is also phone-based and should use all when the signal applies to every channel reachable on that identifier. The Preference Center presents the configured per-channel choices for the address associated with the signed link. Opting out of email changes the email preference; it does not silently opt the phone number out. A contact’s other address is not automatically suppressed, even if both addresses appear on one contact record. This separation is intentional: the recipient may have a different permission or relationship on each address. Treat the ledger as address-level evidence, not as a single contact-level flag. A phone row cannot block an email address it does not contain, and an email row cannot block calls or messages to a phone number. For scope meanings and CSV defaults, see Opt-Out & Suppression Lists.

​

Reconciliation patterns

Choose the operation that matches the event and the evidence you hold:

• Consent API — extend one revocation across known addresses. For a contact-level revocation that your tenant policy applies to every known address, submit one Consent API revocation event listing all current identifiers for that contact, including each email and E.164 phone or WhatsApp ID. Include the channels and event details required by your Consent API request schema. Do not submit only the address that happened to receive the signal when your decision covers the whole contact. See Consent Management for the endpoint contract.
• Bulk CSV — import each address as its own row. Set channel=all on phone and wa_id rows when the suppression applies to every channel reachable on that identifier. Set channel=email on email rows. The address-type defaults are the same when no channel column is supplied, but explicit values make a reconciliation file easier to audit. A row carrying both a phone and email shares one scope across both addresses, so use separate rows when their scopes differ.
  phone,email,wa_id,channel,reason
  +14155550101,,,all,contact-level opt-out
  ,jordan@example.com,,email,contact-level opt-out
  
  Import the file through POST /compliance/suppression-list/import. Preview with dry_run=true before writing, then check the per-row results and export the active ledger to confirm both addresses landed with the intended scopes.
• Contact merge — reconcile during identity cleanup. When you merge duplicate contact records, review the active suppression entries associated with both records and compare them with the merged record’s known addresses. A merge can bring identifiers together in your contact view; it does not itself mean that an address-specific suppression should be copied to every other address. Use the contact merge surface to perform the merge, then use your tenant’s chosen consent or import path to add any missing address-level entries.

For a multi-address contact, reconcile by identifier and scope together. In the CSV convention above, the phone row’s all covers phone-based channels; the separate email row blocks the email address. all on a phone row does not reach a different email address.

​

Why suppression does not automatically extend

An opt-out is evidence about the address and purpose named by the event. Automatically copying it to every address on a contact could remove someone from a channel where they still have a legitimate interest or a separate permission. Orbit therefore does not infer cross-address intent from a shared contact record. Your tenant owns the scope decision. Use the closest-fit lawful basis for the event and purpose, keep the source and timing in your consent records, and extend a block only when your policy and the recipient’s signal support it. This guide is operational information, not legal advice.

​

Three worked examples

​

1. Email spam complaint; phone remains available

Jordan reports a marketing email as spam. Your email process records a suppression for jordan@example.com with scope email. Jordan’s phone, +14155550101, remains unchanged: the email complaint did not itself suppress SMS, voice, or WhatsApp on that number. If your tenant policy treats the complaint as a contact-wide opt-out, explicitly extend the revocation to the phone address through the Consent API or a separate CSV row; do not assume the email entry did that.

​

2. SMS STOP; extend the decision to the known email

Jordan texts STOP from +14155550101. The phone entry uses scope all, which blocks SMS, voice, and WhatsApp on that number. If the event and your tenant policy also mean Jordan should no longer receive email, record a separate email-address suppression as part of the same contact-level reconciliation. With CSV, use a phone row with channel=all and an email row with channel=email; with the Consent API, list both known identifiers in the revocation event supported by your request schema. The email is blocked by its own ledger entry, not because the phone’s all scope spans a different address.

​

3. Preference Center email link; only the email is opted out

Jordan clicks the Preference Center link in an email and turns off email while leaving SMS enabled. The email address is suppressed for email, while the phone remains opted in. The signed link lets the page apply the selected preferences to the associated contact; it does not turn an email-channel choice into an opt-out for the contact’s other address. If Jordan later asks to stop all contact, reconcile the phone separately.

​

Tenant-owned scope decisions

Before adding or changing entries, decide whether the event applies to one address, every channel reachable on that address, or all known addresses for the contact. Preserve that distinction in your records: After an import or merge, export the active suppression ledger and verify each address and scope. Keep the consent history alongside that export when you need to understand why an entry exists.

​

Related guides

• Opt-Out & Suppression Lists — channel scopes, CSV format, import, and export.
• Choose your suppression entry point — compare CSV, Consent API, and Preference Center inputs.
• Preference center: the public opt-in/opt-out page — configure the hosted page and understand its channel choices.
• Contact merge — merge duplicate contact records.