> ## 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. # Sender statuses: Active, Paused, Error and the chips > Three states, who can set each one, and the extra chips that outrank the status on a row. 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 is always in exactly one of three states: **Active**, **Paused** or **Error**. Two of them are a choice you make. **Error** is a verdict: the product writes it after a check, and you cannot set it.
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.
The **No Campaigns** chip (1) is not a fourth status. It is an **Active** account wearing a different label. The **Error** chip (2) is the only one you cannot set, and the only one that stops the account being changed at all. | State | What it means | How it gets there | How it leaves | | ---------- | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | **Active** | Eligible to send | A check that passed: when the account is added, when you save corrected settings, on a reconnect, or (for a managed mailbox) when the product re-tests it for you | You pause it, or a check fails | | **Paused** | Held back, sending nothing | You pause it, on the row or from the selection bar. A mailbox on PipeLime managed infrastructure also starts here while its setup finishes | You resume it. For a managed mailbox, the product may also resume it once setup completes | | **Error** | The account cannot be used | A failed connection check, a rejected tracking domain, recipients rejecting the mail, or a mailbox that verified but could not be registered for sending | **Refresh sender**, saving corrected connection settings, or (for a managed mailbox) an automatic re-test | ## How it behaves ### Only an Active account is picked to send When the product goes looking for a mailbox (campaign email, warm-up, or an email block in a workflow), it selects from **Active** accounts only. **Paused** and **Error** are excluded before anything else is considered, so no schedule, limit or campaign setting can bring one back into the rotation. **Active** means allowed to send, not sending right now. An account taking a [resting day](/en/email-accounts/resting-days-and-schedule), sitting outside its sending hours, or still warming up is **Active** the whole time. Those are markers next to the account name (a **Resting today** chip, a dimmed moon, a crossed-out calendar), and none of them is a status. ### The state a new account starts in is a result, not a default There is no rule that a new account begins **Active**. When an account is added, the server runs the connection check first and stores whatever that check decided. It passes, and the account is **Active**. It fails, and the account is created in **Error**, with the reason already attached, before anyone has touched it. Which of those you see depends on how the account was added: * *Through the connect flow in **Add senders**.* It verifies before it saves, and only stores the account once the check passes. A mistyped app password keeps you in the wizard with a diagnostic, rather than adding a broken row to the list. * *Through the account settings form, or a bulk import.* Nothing holds the account back. The row appears in the list already in **Error**, and the message says why. A CSV of mailboxes is the usual way to end up with several at once. * *By restoring an account you deleted.* The same check runs on the way back in, and lands the same way. A tracking domain counts too: if the account carries a custom one and its DNS record cannot be verified, the account is created in **Error** even though the mailbox itself answered. Mailboxes on PipeLime managed infrastructure are the exception to all of this. They are created **Paused**, and they stay paused until their setup finishes and they are registered for sending, at which point the product turns them **Active** itself. Until that happens, activating one by hand is refused, with a message saying it will connect automatically once its setup finishes. ### You can set two of the three Creating or updating an account accepts **Active** or **Paused** and nothing else. **Error** is not a value anyone can send; it is computed from a check and written by the server. Each row carries one control next to its chip, and the chip decides which. They are icon buttons, so what names them is a tooltip: a pause button on an **Active** account, **Resume sender** on a **Paused** one, and **Refresh sender** on one in **Error**. The pause tooltip is also the plainest statement in the product of what pausing does: while an account is paused it sends no campaign and no warm-up email. A role without change access to email accounts sees all three chips and none of the buttons. ### Pausing holds until you resume it, with one exception Pause an account you connected yourself and nothing in the product will unpause it. There is no timer, no daily reset and no recovery job that picks it back up. Mailboxes on PipeLime managed infrastructure are looked after by a background sweep, and that sweep can resume one. It runs several times an hour without anyone starting it. It takes a managed mailbox in either of two situations: * The status message on the mailbox is one the product itself wrote when it parked it mid-setup. * The mailbox is not registered for sending at all. This case ignores the status, so a managed mailbox that you paused yourself is in scope. In both cases the sweep re-reads the mailbox from the provisioning side, and if it comes back ready it sets it **Active** and sending resumes. Pausing and resuming changes the status and nothing else: the status message stays where it was. So a managed mailbox that the product parked during setup, that you then resumed and later paused by hand, still carries the product's own message and is still eligible for that sweep. If you need a managed mailbox to stay off for good, delete it: the sweep skips deleted accounts. Resuming by hand is the play button on the row (**Resume sender**), or **Activate** on the selection bar after you tick some rows. ### Error is a verdict, and it carries the reason Five things put an account into **Error**, and each writes its own explanation: * *The connection test failed.* For an account that connects with a host, a port and a password, saving connection settings and reconnecting both open an SMTP and an IMAP session. When one or both refuse, the account is flipped and the message names which, with the receiving server's own error text appended, which is why no two look alike. * *The provider sign-in failed.* An account connected by signing in with your provider instead (the Outlook route) is checked against that sign-in, and no SMTP or IMAP session is opened at all. Its message starts with `OAuth verification failed` and carries the provider's own reason. * *A custom tracking domain does not resolve.* If the account carries one and its CNAME cannot be verified, the DNS failure becomes the status message, even when the mailbox itself is fine. * *Recipients are rejecting the mail.* A run of permanent policy rejections across several recipient domains is a reputation problem rather than a connection problem. The account is flipped, and its message says so and asks you to reconnect it once the underlying issue is resolved. * *The account verified but could not be registered for sending.* A mailbox that passes its check and then fails to register with the sending service is left in **Error** with that as its message, rather than being reported healthy while sending nothing. Periodic health checks can flip an account too; what they look at is on [sender health checks](/en/email-accounts/sender-health-checks). Hovering the **Error** chip shows that message exactly as the server stored it, falling back to **Connection error** when there is nothing stored. The account's own settings page shows the same text in a red banner at the top, with a **Reconnect** button in it. These messages are written by the server and are shown in English on every language setting. You do not have to be watching the page. When an account moves into **Error**, the workspace owner is notified by email and in the app. An account that is *created* in **Error** (a bad import row, say) sends no notification; it simply appears in the list with a red chip. ### While an account is in Error, its status is frozen Any attempt to set the status of an errored account is refused: pausing it and resuming it both fail. That holds for the selection bar too: tick an errored account along with healthy ones and **Pause** or **Activate** counts it among the failures rather than doing anything to it. Two things do work. **Refresh sender** on the row re-tests the credentials already stored and rewrites the status from the result. Or open the account, correct the connection settings and save: changing any connection field runs the same check on the way through, which is the route to take when the stored credentials are the thing that is wrong. Health checks never clear an **Error**. They only detect. For an account you connected yourself, that makes clearing it a person's job: **Refresh sender**, or a corrected settings save. Managed mailboxes recover without you. The same sweep that unparks them re-tests errored managed mailboxes several times an hour and sets them **Active** again as soon as the stored credentials work: the common case is a freshly provisioned mailbox whose domain was not ready when it was first checked. The exception is a managed mailbox flipped for recipient rejections: that one still passes a connection test, so the sweep deliberately leaves it alone and it waits for you. Reconnecting always lands on **Active** when the check succeeds. It does not restore whatever the account was before. An account that was paused before something put it into **Error** comes back sending. Reconnecting does not assume it worked, either. The row re-reads the recomputed status and, when the account is still failing, shows you the reason rather than a confirmation. ### Two chips take the Active chip's place An **Active** account that cannot do anything useful yet shows why instead of showing **Active**: * **No Schedule**: the account has no sending schedule. Clicking it opens that account's schedule section. * **No Campaigns**: no campaign uses this account. Clicking it opens your campaigns. They replace the **Active** chip rather than joining it, and they are checked in that order, so an account with neither a schedule nor a campaign shows **No Schedule** only. Both are conditional on the account being **Active**, so a **Paused** or **Error** account never shows either. The status always wins. The small crossed-out calendar next to the account name is separate, and it appears on any account with no schedule whatever its status. That is how a paused account with no schedule still tells you about the missing schedule. ### The counters count chips as Active **Active Senders** counts every account that is neither **Paused** nor in **Error**, which means an account showing **No Schedule** or **No Campaigns** is counted as active there. **Daily Limit Capacity** adds up the daily limits of that same set, so pausing a mailbox lowers the workspace's stated capacity and an errored one contributes nothing. **Senders with Errors** is the plain count of the third state. ### Deleting is not a fourth status Deleting an account archives it and removes the mailbox from the sending service. It leaves the list rather than taking a status, and its in-flight leads are moved onto accounts that are still sending. ## Limits | | | | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | | How many statuses | Three: **Active**, **Paused**, **Error**. Everything else on a row is a chip or a marker | | What a new account starts as | Whatever its first check decides: **Active** when it passes, **Error** when it fails. A managed mailbox starts **Paused** | | Which ones you can choose | **Active** and **Paused**. **Error** is computed | | What sends | **Active** accounts only | | Changing a status while in **Error** | Refused, on the row and in bulk | | Ways out of **Error** | **Refresh sender**, a corrected settings save, or the automatic re-test for a managed mailbox | | Where reconnecting lands | **Active** on success; **Error**, with a new message, on failure | | Automatic recovery | Managed mailboxes only, several times an hour. Nothing automatic touches an account you connected yourself | | Language of the **Error** message | English, in every locale | | Who can change a status | Roles with change access to email accounts. Everyone who can open the page sees the chips | ## Related What **Refresh sender** actually does, and what to try when it comes back still failing. The periodic probe behind an account that errored without you touching it. The **Resting today** chip and the moon: why an **Active** account is quiet today. When the chip is green and the mail still is not arriving.