Reconnect a mailbox without duplicating uncertain sends

Define the decision

During an outage, some messages may have been accepted while others never reached the provider. A connection error can occur between those stages. Do not assume the entire affected period is safe to replay or that a new campaign is a clean workaround.

Work through the procedure

1. Identify the outage interval, selected account and affected enrollments.
2. Repair the supported connection and verify both sending and incoming access using owned test addresses.
3. Classify historical attempts with provider and application evidence: accepted, rejected or unresolved.
4. Review replies and suppression during the gap, then resume only the work whose next action has been determined.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Outage cohort
Contact A: acceptance confirmed → do not resend step
Contact B: rejection confirmed → repair and review retry eligibility
Contact C: outcome unknown → reconcile before restart
A passing reconnect test does not collapse these three cases into one.

Read the result

The split preserves the actual history. A may already have replied, B may need a legitimate retry, and C needs evidence. Treating all three as unsent creates duplicate risk; treating all three as completed leaves work unresolved. The right restart plan can contain several different actions.

Check before moving on

1. Keep the same enrollment identifiers during investigation.
2. Do not clone contacts to bypass an unresolved state.
3. Inspect the first post-repair progression and reply sync result.

Limits and next action

Zintara tracks attempts and pauses uncertain outcomes, but provider evidence may still be needed. This guide does not promise exactly-once delivery across network failures. Use supported recovery controls and involve the service operator when the interface does not expose enough history.

Source: Zintara unified inbox product context