A Sending Mailbox Loses Authorization: Verify Sender Identity Before Resuming

When a sending mailbox loses authorization, restore access to the intended account and reconcile its existing work before permitting normal outreach. A successful login does not prove that the correct sender was connected, that pending messages retained their intended state, or that previously attempted messages are safe to send again.

The right evaluation asks three separate questions: who may restore the connection, which identity will represent the sender, and what will happen to each affected enrollment or message. This guide provides a proposed acceptance procedure for answering them with configuration records, event history, and controlled receiving-mailbox observations. It is not a report of a completed recovery test or a guarantee of automatic resumption.

This is especially important when choosing software for several sending inboxes. A platform can make adding mailboxes straightforward while leaving important recovery behavior unclear. Evaluate the interruption and restoration of an existing sender alongside the initial connection experience.

Separate lost authorization from an intentional disconnection

An unauthorized connection and a deliberate mailbox removal are different events. The former means the application cannot use the required authorization. The latter is a product action that may also change enrollment, scheduling, synchronization, and routing records. Do not use the terms interchangeably in a test plan.

Unify’s mailbox operations documentation distinguishes an unauthorized work mailbox, which requires reauthorization, from a managed connection that needs Unify support. It also documents consequences of explicitly choosing Disconnect: email syncing stops, the mailbox leaves play routing, affected people are unenrolled, and scheduled emails are canceled. That action therefore cannot stand in for every form of authorization loss.

Before testing, name the event precisely: provider access revoked, an application reporting an authorization error, administrator policy preventing connection, or an intentional product disconnection. Record what actually occurred. If the test changes several things at once, it will be harder to tell which action changed the pending work.

Provider behavior also varies. Google’s OAuth documentation explains that access and refresh tokens serve different purposes and that refresh authorization can cease to be valid. Microsoft’s refresh-token documentation describes expiration and revocation conditions. Neither document establishes how a particular outbound application reconciles its queue. That must be documented or observed in the application being evaluated.

Identify the mailbox and the person allowed to restore it

Start with the exact sending address, provider, workspace, mailbox type, and assigned user. Record the account that will appear in the provider’s authorization flow. A familiar display name is insufficient: people may have multiple signed-in accounts, and the intended outbound address may differ from their everyday work address.

For a connected work account, Unify’s Connect a mailbox guide requires access to the email account and organizational permission to connect it. It directs users to Reconnect when reauthorization is needed and to review affected enrollments afterward. An email administrator may need to approve the requested access. Treat the provider’s consent decision and the workspace’s ability to manage the mailbox as separate permissions.

For Unify-managed mailboxes, Unify handles the dedicated sending setup, and each address is assigned to a user. Managed connection problems should go through Unify support. Do not assume that the assigned seller has the provider credentials or that their personal Google or Microsoft login can restore the managed address.

Review workspace members and roles before assigning recovery responsibilities. A person who can manage workspace settings is not automatically authorized to grant provider access for another person’s mailbox. The evaluator should identify the account holder, the organization’s email administrator, the workspace operator, and any managed-service contact who must participate. One person may hold several roles, but the required authority should remain explicit.

Capture the preexisting work before changing access

Create a snapshot of the work that already depends on the mailbox. Record the snapshot time and timezone, the filter used to identify the mailbox, and whether the view contains enrollments, email steps, messages, or tasks. Those objects are related but not interchangeable. An enrollment can contain a completed step and additional work that has not happened.

Use the sequence enrollment documentation to interpret the current statuses. In Unify, queued means no step has completed; started means at least one step has completed and more work remains. A blocked enrollment has an issue preventing progress. Those labels help locate records, but the next step and its activity history still matter.

Capture identifiers for the sequence, version, enrollment, recipient, sender, and pending step wherever the product exposes them. Keep the displayed state and next scheduled action alongside the time of observation. If the interface does not expose a message-level identifier before sending, record that limitation rather than inventing an identity for the future message.

Keep already-sent work distinct from scheduled work and work whose outcome is uncertain. An email may have reached the sending provider while the application has not yet displayed a final result. A missing event in one dashboard is not sufficient evidence to replay that message. Ask what logs or support records can resolve this boundary before choosing a retry action.

Define the test population as the affected work present at the snapshot. Work added afterward belongs to a separate cohort. This prevents a growing queue from obscuring whether the original records were retained, canceled, reassigned, or sent. Include records that cannot yet be reconciled; they are part of the result, not exceptions to hide.

Establish a controlled hold before reconnecting

The proposed evaluation should use a dedicated test mailbox and receiving addresses controlled by the team. Arrange the test with the relevant account owner or administrator. The purpose is to observe sender recovery, not to expose real prospects to uncertain replay behavior.

Before changing authorization, establish which supported controls hold the affected work and which actions can still occur. Check whether pausing a sequence holds every relevant email step, whether new enrollments can continue to enter, and whether other workflows use the same mailbox. Record the scope of the hold. A paused sequence does not imply that every other route to that sending address has stopped.

Use the application’s documented controls rather than changing access blindly. If the vendor cannot explain whether restoring authorization immediately makes existing work eligible to send, treat that as an unresolved release condition. Keep the evaluation restricted to controlled recipients until the behavior is understood.

Capture the status and error after authorization is lost. Record whether the interface marks the mailbox, enrollment, pending step, or several of them. Also record whether an operator can locate the affected work from that error. Useful recovery design makes it possible to trace the connection failure to the work it affects without relying only on a general notification.

Verify the restored sender across configuration and an actual message

Reconnect the intended work account through the supported flow, or have the managed-service operator restore the managed connection. At the provider account picker, verify the full account address and organization. After authorization returns, inspect the mailbox record again. Do not stop at the successful consent screen.

Compare the restored connection with the baseline: sending address, provider, assigned user, mailbox identifier if exposed, and membership in any sending group. Check whether recovery repaired the existing connection or created a separate mailbox record. If that distinction is unclear, resolve it before assuming that old enrollments now reference the restored account.

Unify’s mailbox group documentation says that mailbox selection occurs for a new enrollment and that the enrollment keeps its sending mailbox as it progresses. Changes to group membership affect choices for new enrollments. Consequently, adding a healthy mailbox to a group is not evidence that existing work has moved to it.

Review the sender name and signature as well as the address. The person assigned to the mailbox can influence how outreach represents the sender. A technically valid sending address with an unintended person’s name or signature still fails an identity check. Review the rendered message, not only the template variables from which it was generated.

With the hold and test scope confirmed, send a permitted test message to a controlled receiving mailbox. Inspect the actual From address, display name, Reply-To behavior where present, and visible signature. Save the message identifier and a secure reference to the inspected message. A preview alone cannot establish the identity used by a real send.

Then reply from the controlled recipient and verify where the response becomes available. Check the intended handling destination and the operator who can act on it. Use sequence reply documentation to review the conversation and sending mailbox. Receiving a forwarded copy and having a reply correctly attached to the relevant outreach are separate observations.

Reconcile each original enrollment before allowing it to continue

After access is restored, revisit the snapshot rather than selecting every visible queued item. Compare each original record with its current state and activity. The relevant question is not simply whether the mailbox is active; it is whether the next permitted action for that particular recipient is still correct.

Check current eligibility. A person may have replied, opted out, changed ownership, or become associated with an account that should be excluded while the connection was unavailable. Unify’s sequence exclusions documentation explains that exclusions can affect active enrollments and that upstream changes must reach Unify before they can affect matching. Inspect the current source information and the applied restriction instead of assuming the old audience is still eligible.

Review the next step and timing independently of authorization. The send schedule guide explains that sending windows, delays, and mailbox limits work together. A restored connection does not establish that an email should send immediately. Conversely, a past scheduled time does not by itself authorize a catch-up send.

Classify the original work using the proposed dispositions below. These are review categories, not claims about literal product status labels. Preserve the product’s displayed state separately so an operator can trace the decision back to its evidence.

Test continuation without assuming replay or reassignment safety

For each eligible test record, inspect the supported continuation action and its scope. Does it resume an existing enrollment, create a new enrollment, retry a step, or start a new sequence? Similar-looking controls can represent different business actions. Read the confirmation and record the chosen operation before applying it.

Check the next actual action against the snapshot and the approved disposition. Verify the sender again on the resulting controlled message. Compare its content and sequence step with the intended continuation. Look for an unexpected restart, a missing pending step, a duplicate action, or a sender change. These are acceptance checks to perform, not outcomes this article claims have occurred.

If no message arrives, inspect the application event, sending-provider record if available, and relevant hold before concluding that recovery failed. If a message does arrive, that alone does not prove that every pending record resumed correctly. Review the complete test population and retain unresolved records until their outcomes are explained.

The distinction between a sending event, server acceptance, and recipient placement is covered in Accepted Email Is Not Guaranteed Inbox Placement. For this evaluation, an inspected message in a controlled mailbox can establish what identity and content that message carried. It does not prove delivery behavior for the full prospect population.

Reassignment requires a separate decision. Moving work to another sender can change the relationship represented by the email, reply ownership, and thread continuity. Verify that the platform supports the specific existing-enrollment state before proposing a move. Do not infer supported migration from the ability to choose a different sender for a new enrollment.

Keep a recovery record that another operator can review

Use the blank record below as a proposed worksheet. Keep private account details and message contents in the appropriate internal system. The article provides fields to collect, not a completed incident log. Link each conclusion to the actual record that supports it.

If you summarize the review quantitatively, define the population as the original affected records captured at the snapshot, and state the record type. The numerator for a reconciliation share is the number of those records assigned an evidence-supported disposition. The denominator is the full original population, including unresolved records. Report unresolved records separately and keep later additions outside that denominator.

When the original population is empty, report the reconciliation share as not applicable rather than a successful percentage. A resolved record can legitimately remain held or be canceled; reconciliation is not the same as permission to resume. This proposed method is for accounting for work, not a deliverability or recovery-performance benchmark.

Decide whether the tool passes your recovery evaluation

Judge the tool on the evidence it lets your team produce. The account operator should be able to identify the failed connection, restore the intended identity through an authorized route, inspect original work, and explain what happened after release. A vendor demonstration that reconnects an empty mailbox does not answer questions about preexisting queued messages.

Ask the vendor to explain any missing boundary directly: explicit disconnection versus lost access, managed versus connected accounts, existing versus new enrollments, and sent versus uncertain outcomes. Require a documented explanation or an observed controlled test for the behavior that matters to your workflow. Do not convert an unanswered question into a presumed guarantee.

Unify’s managed deliverability offering describes the sending infrastructure available to teams. Use that context to choose who owns recovery, then evaluate the mailbox and enrollment behavior itself. Infrastructure management and an inspectable release decision solve different parts of the problem.

Permit normal sending only when the intended identity is verified, original work has an appropriate disposition, and the responsible owner has reviewed remaining exceptions. Retain the recovery record so the next operator can distinguish a repaired connection from a new authorization to contact someone. That is the practical standard for a repeatable recovery process.

Frequently asked questions

Does reconnecting a mailbox automatically resume every queued email?

Do not assume it does. Restore the intended account, then inspect affected enrollments, their next steps, current eligibility, and any holds. Verify the continuation behavior with controlled recipients before allowing normal sending.

Who should restore an unauthorized Unify-managed mailbox?

Unify’s current mailbox documentation directs managed connection problems to Unify support. For a work mailbox connected by your team, use the supported reconnection flow with the authorized account holder and any required email-administrator approval.

Is choosing Disconnect the same as losing provider authorization?

No. An explicit product disconnection can change routing, syncing, enrollments, and scheduled work. Unify documents those consequences separately. Record which event occurred and avoid using deliberate removal as a substitute for every authorization-loss test.

Can another mailbox in the same group take over existing messages?

Group membership alone does not establish that existing work moved. Unify documents group selection for new enrollments and retention of the selected sender as the enrollment progresses. Review supported reassignment for the particular existing state before moving work.

What is the minimum evidence before normal sending resumes?

Verify the restored address, assigned sender identity, an actual controlled message and reply path, and the disposition of the original affected records. Keep unresolved prior sends and eligibility questions outside the approved release set until they are explained.