> ## Documentation Index > Fetch the complete documentation index at: https://help.pipelime.ai/llms.txt > Use this file to discover all available pages before exploring further. # Fix an email account in Error > Every Error message the product can show, what caused it, and what Reconnect actually does. export const Screenshot = ({id, alt, caption, frame = 'browser', url, marks = [], lang = 'en', workspace = 'northwind-outbound'}) => { const src = `/images/screenshots/${lang}/${id}.png`; const chrome = url ? `app.pipelime.ai/${workspace}${url}` : 'app.pipelime.ai'; return
{frame !== 'bare' &&
{chrome}
}
{alt} {marks.map(mark => )}
{caption &&
{caption}
}
; }; An email account marked **Error** is not sending. The sentence stored beside the chip is what tells you why.
Where
Integrations→Integrations→Email Accounts
Your role needs
Read access to Email Accounts read-senders. Admin, Member and Viewer have it by default.
To create or change
create-senders to add one, update-senders to change one, on top of the permission above.
If you cannot find this in your sidebar, your workspace may have a custom menu configuration. Contact support and we will check it for you.
## Where the message is, and what it is **Error** is one status with many possible causes. The chip tells you almost nothing; the sentence tells you everything. You can read that sentence in two places: on the **Email Accounts** list it is the tooltip on the Error chip (1), and on the account's own page it fills a red banner. The only status control the row offers on an errored account is the icon whose tooltip reads **Refresh sender** (2). No pause, no resume: pausing or resuming an account in Error is refused anyway. Read the sentence, not the heading. The banner's heading always reads "Connection Error:", whatever is written underneath, including a message about sending reputation, which has nothing to do with connecting. Read it fresh, too. The stored sentence is whatever was written most recently, not what went wrong first, and it can change while you are not looking: * A mailbox on PipeLime managed infrastructure is re-tested by a scheduled job. When the test still fails, the job replaces the sentence with the failure it just saw. * An account whose own address keeps bouncing warm-up mail has its sentence overwritten by that bounce, whatever it said before. ## How fast an account turns red It depends on which mechanism caught the problem, and they do not agree. * *The scheduled connection check waits.* A rejected sign-in has to keep being rejected before the status changes, and an unreachable server for considerably longer. A failure hitting most of the accounts on one of our machines at once is suppressed rather than passed on, so a bad hour does not burn a batch of accounts. * *A failed send does not wait.* When the mail server answers with a definitive configuration or authentication error, that single send flips the account immediately: no grace period and no second attempt. * *The reputation counter needs a streak.* Several permanent rejections, spread across several different recipient domains, inside one window. ## Reconnect it On the **Email Accounts** page, open the account carrying the Error chip. You can also press the refresh icon on the row itself: it runs the same reconnect and reports the result in a notification, without opening anything. A red banner sits at the top of the account's page with the full sentence in it (1), and the **Reconnect** button on the right (2). We re-test the credentials we hold: for sending and for receiving separately, because an account that can send but not receive would never see a reply. A mailbox you connected by signing in has its access re-checked instead. If the account has a custom tracking domain, its DNS record is re-checked as well, and a failing record keeps the account in Error even when the mailbox itself answered. Only when all of that passes is the account registered for sending again and set back to **Active**. Reconnect only tests what it has. The mailbox check runs only when the account holds a complete set of connection details: host, port, security, username and password for sending, plus host, port and security for receiving. If any one of them is blank, nothing is tested: the account is set to **Active** and reported as verified. An account that reports success on Reconnect and still sends nothing is the symptom; open it and fill in what is missing. The banner disappears and a notification reads "Connection verified successfully". On the list the red chip is gone: replaced by **Active**, or by **No Schedule** or **No Campaigns**, which the list shows in place of **Active** when the account has no sending hours or is not attached to a campaign. All three mean the account is Active again. If it did not work, the notification carries the new message instead and the account stays in Error with the sentence updated. That is deliberate: a reconnect that verified nothing never reports success. ## What each message is telling you "Mailbox authentication failed — the account may have been deleted or its credentials revoked. Please reconnect." is the scheduled check's wording, and a failed send writes it too when the mail server says the account cannot be authenticated. "Authentication failed. Please check SMTP credentials." is the other form a failed send writes. All of them mean the provider rejected the login we hold. Reconnecting with the same stored password cannot fix a password that changed. Enter the new one on the account's page and save. Saving connection details re-tests them and recomputes the status the same way Reconnect does. That second route is not available on a managed mailbox: its connection fields are owned by the infrastructure and are ignored if you send them. If the mailbox itself was deleted at the provider, there is nothing to recover: remove the account here, or connect a different mailbox. "Invalid SMTP credentials", "Invalid IMAP credentials" and "Invalid IMAP and SMTP credentials" are written by the credential test itself: by Reconnect, by saving connection details, by a row in a bulk import, and by the scheduled job that re-tests managed mailboxes. Each has the mail server's own reply appended, which is usually the more specific half of the message. Sending and receiving are tested separately, so an account can hold a perfect sending password and still land here because its receiving details are wrong. "Could not establish a connection to the mailbox server. Please check the account settings and reconnect." is the general form. A failed send writes a narrower one depending on where it broke: "Connection failed. Please check SMTP host and port.", "Connection failed. Please check SMTP host and network.", "TLS/SSL connection failed. Please check SMTP security settings.", "DNS lookup failed. Please check SMTP host." or "Protocol error. Please check SMTP port and security settings." These point at the server details rather than the password. Check the host, the port and the security setting against what your provider publishes, correct them on the account's page, and save. Only the general sentence is written after a retry. When the sending service reports that it cannot reach the mailbox (or is not connected to it), the account is registered again and the send retried once, and the message is written on the second failure. The five narrower sentences have no retry behind them: they are written by the first send that fails. "OAuth authorization is no longer valid — the account may have been deleted or access revoked. Please reconnect." comes from the scheduled check. "OAuth verification failed: …" comes from the sign-in being tested directly (when you first connect the mailbox, and again on every Reconnect), with the provider's own refusal appended. Reconnect re-checks the access we were granted. If it still works the account recovers; if it was withdrawn (the password changed, the account was removed, or access was revoked in the provider's security settings), the mailbox has to be connected again from scratch. "Failed to re-register account on the email service: …", "Credentials verified but re-registration on the email service failed: …" and "Failed to register with Email API: …" all mean the same thing: the credentials verified, but the account could not be handed to the sending service afterwards. A managed mailbox reports any failure in that same step as "Could not connect the mailbox to the sending service." That carries no detail, because the detail goes to our logs. The account is deliberately left in Error rather than shown as Active, because an account that looks healthy and sends nothing is worse than one that admits the problem. Try again in a few minutes; if the message persists, send it to [support@pipelime.ai](mailto:support@pipelime.ai). Reconnect re-checks the tracking domain too, if the account has one, and a failing check keeps the account in Error even when the mailbox verified. The message is the DNS check's own, so it names the record rather than the mailbox: "No CNAME records found", "CNAME record must point to …", "Invalid domain format" or "DNS lookup failed: …". Fix the record with whoever hosts your DNS, then reconnect again. "Email address is invalid or no longer exists. Warmup email to this address bounced too many times." is about the account's own address, not a lead's: the warm-up network could not deliver to it. This one overwrites whatever message the account was already carrying. Reconnect will clear it if the mailbox now accepts mail, because the credential test is what decides the status. If the address really is gone, connect a different mailbox. A managed mailbox that the infrastructure reports as failed is set to Error without a message. The banner then reads "Connection Error:" and stops, and the chip's tooltip falls back to the generic "Connection error". There is nothing for you to correct here. The mailbox never finished being built. Send the account's address to [support@pipelime.ai](mailto:support@pipelime.ai). ## The one Error reconnecting will not fix "Recipient mail servers are rejecting emails from this sender — likely a sending reputation issue with its domain or IP address. Please review the sender and reconnect it once resolved." Reconnecting an account in this state succeeds. The credentials are fine, which is exactly the point, and the next rejection puts it straight back into Error. Resolve the reputation problem first, then reconnect. This Error is written by a counter, not by a connection test. It needs a run of permanent rejections spread across several different recipient domains before it fires, so one strict receiving server cannot burn an account on its own. What it reports is that the receiving side is refusing your domain or your sending address, which is a deliverability problem to fix at the source. It is also the one Error the automatic recovery below deliberately steps over, for the same reason: an account whose credentials verify would be reactivated on the spot and blocked again on its next send. ## The Errors that clear themselves A mailbox on PipeLime managed infrastructure does not always need you. A scheduled job keeps re-testing managed accounts that are sitting in Error and, when the mailbox answers, registers it for sending again, clears the message and sets it back to **Active**, with nobody pressing anything. The same job picks up managed mailboxes whose setup never finished. It leaves the sending-reputation Error above alone, on purpose. So a managed mailbox can go red and green again without you, and its message can change in between. If one has just turned red, wait a few minutes before you do anything. An account you connected yourself (your own mailbox, or one you connected by signing in) is not covered by any of that. Nothing puts it back on a schedule: recovery is Reconnect, or saving corrected connection details. ## Things that look like this but are not * *A deferred sign-in.* When a provider defers a login because it is busy, the account is left alone and only that one message is parked; it is sent again automatically once the deferral clears. Nothing turns red. * *A paused account.* **Paused** means one of two things and the tooltip is the same for both. Either somebody paused it, and the row offers **Resume sender**; or the product parked it, because a managed mailbox is held at **Paused** until its setup finishes and it can actually send. The reason for a system-parked account is stored but never shown on any screen, so the two are indistinguishable in the interface. A managed mailbox you have just ordered showing **Paused** is not waiting for you. The same scheduled job puts it into service once the mailbox is ready. * *An account that is quiet.* An account can be **Active** and still send nothing right now: outside its sending hours, or resting for the day. That is a different question; see the statuses page below. ## Troubleshooting Reconnecting counts as changing an email account, so a role that can only read them sees the Error and the message but no control at all. It is hidden, not greyed out. Ask a workspace administrator to reconnect it, or to widen your role. Check Connection, at the top of the account's page, tests the values currently in the form, useful right after you have corrected a host or a password, before saving. It never changes the stored status. Reconnect re-tests what is saved, and does change the status. After editing anything, save first. A reconnect proves the mailbox answered at that moment; it cannot promise the next send will work. The usual cause of a quick relapse is the reputation block above: reconnecting it does succeed, and the next rejection returns it to Error. Read the message again: if it changed, so did the cause. ## Related Active, Paused and Error, and the chips that are not statuses at all. What the scheduled check looks at, and what it will and will not change. Every message the product can show you, in one place. The server details a mailbox needs, if yours turn out to be wrong.