Recover access to your email provider¶
Zerohive depends on your organization's email service for mailbox reads and outgoing sends. A saved connection can exist while that service is unavailable, its configuration has changed, or Zerohive cannot establish an approved secure connection.
This page explains what those failures mean. Follow the mailbox connection guide for the intended connection and reconnection steps, and the sending guide when an email may already have been submitted. The current interface remains a preview; its sample connection and retry controls do not prove a live provider operation.
Understand the failure before repeating an action¶
| What you see | What it can mean | What to do |
|---|---|---|
| The provider cannot be reached | The server address cannot be resolved, the destination is blocked by policy, connection attempts failed, a timeout occurred, or another provider/transport problem prevented access. | Check the service and organization configuration with your administrator or support. The message alone does not prove that your password is wrong or that the provider has a company-wide outage. |
| Reconnection is required | Credentials or authorization may need attention. Some authentication or mail-protocol failures also use this result. | Follow the supported reconnect flow when appropriate. If the problem persists, ask support to identify the cause before changing credentials again. |
| The sign-in method is not allowed | The configured method or the provider's supported authentication does not match what this connection requires. | Ask the administrator to check the organization's selected provider and permitted methods. |
| Provider sign-in fails on return | The token exchange or later connection validation could not complete; earlier consent or an earlier attempt may still have changed state. | Reconcile the saved connection and follow return-flow recovery. An error does not prove that every earlier step was undone. |
| Mailbox reads appear empty | A read failure can be returned as empty or partial data in the inspected implementation. | Use reading recovery; do not conclude that the mailbox contains no messages. |
| Sending stops showing progress | The interface may have lost the result while background processing continued. | Reconcile the original send. Reconnecting or trying again as a new message can leave the first attempt unresolved. |
A failed access check is separate from an already-started send. Repairing a connection does not recall a message, establish recipient receipt or prove that an uncertain attempt should be repeated.
What the organization manages¶
The organization selects the provider, incoming and outgoing mail settings, permitted sign-in methods and provider authorization details. Operators manage the service's network policy. A person's mailbox sign-in does not change those organization-wide controls.
The mail connection requires an approved encrypted transport. Some private-network email services need explicit operator configuration. A server address can be rejected even when the same address works from someone's laptop, because the running service has its own DNS, routing and destination rules. A configuration check also does not establish successful sign-in, mailbox access or delivery.
Ask the responsible administrator to correct the approved configuration. Do not work around a failure by choosing an unrelated server, switching off encrypted transport or sharing credentials with support.
When profile details and mailbox status disagree¶
Your work profile, saved mailbox connection and email provider can change at different times. A new name or work address appearing elsewhere in the platform does not prove that an existing mailbox connection has been updated or signed in again.
If the connection page shows the wrong work address, stop before entering a password or approving provider access. Ask your administrator and support to reconcile the intended work identity and saved connection. Repeated sign-ins or changing an unrelated provider setting may leave the underlying mismatch unresolved.
A service can be running while a particular mailbox still cannot read or send. Check the saved state, then the operation you actually need. Treat sample synchronization times and health figures in a preview as examples. They do not promise that mailbox content is being continuously synchronized.
Information that helps support¶
If a connection or secret change has an uncertain result, let support reconcile the saved state before repeating it. Disconnection can finish before background credential cleanup. It does not revoke access already granted at the email provider, delete provider messages or prove that all retained credential copies have been erased. Your administrator and the responsible operator can establish which action completed and whether a separate provider-side action is needed.
Provide the organization, affected work email, the operation attempted, approximate time, visible error and whether reading, sending or provider sign-in was affected. For a possible send, retain the original send reference and relevant recipients. Mention whether the problem affects one person or several, without assuming that scope identifies the cause.
Use the approved support channel. Passwords, authorization PINs, provider tokens and sign-in return links are not needed in an ordinary support description. If a protected credential step is required, use the product's connection flow.
Managers should account for provider and network interruptions in email-dependent work. A saved connected badge, successful configuration check or completed retry does not establish a service-level commitment or recipient acknowledgement.