Skip to main content
An email account can drop into Error with nobody touching it. Two background checks do that on their own timing: one reads the account’s live connection state on a schedule and waits out a grace period before it acts, the other watches how recipients respond to what you actually send and blocks an account whose mail keeps coming back rejected. Neither ever clears an account it has flipped. A send that fails outright can flip an account too, without waiting for either of them, and that path is on this page as well.
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 closest thing to a trace of any of this is on the Email Accounts table. Hover an Active chip and its tooltip tells you when the account was last touched.
That date is the account’s general last-updated time, not the check’s own log: the timestamp the check actually writes is never sent to the browser. In practice the two agree closely, since every run saves the account, but so does pausing it, resuming it, or editing its settings.

​
How it behaves

​
Two mechanisms, watching two different things

Two independent checks move an Active account to Error on their own timing, and they catch different failures:
  • The connection probe asks the sending service what state your mailbox is actually in, on a recurring schedule, and only acts once a failure has persisted through a grace window.
  • The reputation block counts how recipients are responding to real sends, and flips the account the moment a streak crosses its threshold, with no schedule and no grace window at all.
A mailbox with perfect credentials can still be blocked by the second one, and a mailbox recipients are happily accepting can still fail the first. Sender statuses covers what Error means once either one fires; this page covers what makes each one fire.

​
The connection probe reads live state instead of opening a mailbox

Checking a connection normally means opening one. That is what happens when you fix an account by hand: the stored credentials are re-tested against the mailbox, over SMTP and over IMAP, or against your provider for a mailbox you signed in with. This automatic check is cheaper. It asks the sending service that already holds the mailbox’s connection what state that connection is in right now, without opening a new one. A healthy account becomes due for another look once 6 hours have passed since its last one. That is the shortest gap between two checks, not a promise about the longest: each run takes only a bounded slice of whichever accounts are due, stalest first, so a large fleet rotates through the set across that window rather than every mailbox being probed at once. An account already showing trouble comes back round sooner than a healthy one, which is what makes the grace windows below bite instead of leaving hours between one observation and the next. If a check times out, or the sending service answers with something we don’t recognize, we leave the account’s status and its error clock exactly as they were. The same goes for a mailbox the sending service does not recognize at all: that is a registration gap on our side, so it is logged for us to fix and the account is left alone. Only a clean read or a genuine provider-side failure moves anything; an inconclusive one never becomes an error, though it does count as a check having happened.

​
A failing connection has to survive a grace window

Two kinds of connection failure lead to Error when the scheduled probe is what sees them, and they get different amounts of patience:
  • A rejected sign-in (wrong or revoked credentials) is high-confidence, so it only has to persist for 1 hour before the account flips, with the message “Mailbox authentication failed — the account may have been deleted or its credentials revoked. Please reconnect.”
  • A connection that can’t be established at all is lower-confidence, since it could just as easily be a passing outage at the mailbox’s own server, so it gets 24 hours before the account flips, with the message “Could not establish a connection to the mailbox server. Please check the account settings and reconnect.”
A mailbox connected by signing in with your provider, rather than a host and password, gets a third path: a connection failure there is checked directly against your provider, bypassing our own sign-in server entirely. A grant the provider confirms is genuinely gone takes the same short 1-hour grace, with its own message: “OAuth authorization is no longer valid — the account may have been deleted or access revoked. Please reconnect.” A grant that still works clears the account’s grace clock outright, since the token itself is fine and whatever failed was something else. A provider that can’t be reached to check the grant at all leaves the clock exactly where it was: a provider hiccup should never be the reason your mailbox goes red. The clock only resets when the kind of failure changes. A mailbox stuck on the same failure the whole time keeps counting toward whichever window applies; a healthy read, at any point, clears the clock completely.

​
A correlated outage is read as an outage, not as a fleet of dead mailboxes

Every probe in a sweep is tallied against the sending instance it ran on. Both kinds of failure count here: a rejected sign-in and a connection that can’t be established. If one instance comes back failing for enough of its accounts in that same sweep, both as a raw count and as a share of what was probed, that pattern reads as a problem with the instance itself rather than with each mailbox individually. Every probe on it is then treated as inconclusive for the rest of that sweep, so nothing on that instance flips and nothing on it moves closer to flipping, and the incident is logged for us. The next sweep gets its own chance to reach the same conclusion, or not.

​
A failed send does not wait for any of that

The grace windows above belong to the scheduled probe. A real send is a different situation: it has already tried to use the mailbox, so when the attempt comes back with a definitive failure the account flips right there, on no clock and with no second observation. That covers a rejected sign-in, and a host, port, TLS, DNS or protocol problem the sending server reports back. Most of those get a plainer message of their own (“Authentication failed. Please check SMTP credentials.”, “TLS/SSL connection failed. Please check SMTP security settings.”, “DNS lookup failed. Please check SMTP host.”). For the two failures the probe also watches for, this path writes the same two messages quoted above, so seeing one of them on your screen does not prove a grace window elapsed first. Two failures deliberately do not flip an account here. A mailbox server that can’t be reached gets the account re-registered and the send retried once before anything happens to the account. And a sign-in the provider defers rather than refuses is a load signal, not a credentials problem, so that one message is parked for a later retry and the account stays Active.

​
The reputation block watches your outgoing mail, not your credentials

This one has nothing to do with the connection probe above. It runs off real sends: every time a recipient’s mail server comes back with a permanent policy rejection (the kind that means never try again, not try later), we count it against the account that sent it, in a rolling 6-hour window. Reach 5 of those rejections, spread across at least 3 different recipient domains, inside that window, and the account flips straight to Error, no grace period, with one message regardless of what actually happened underneath: “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.” The domain requirement is there on purpose. Five rejections from one strict company’s mail server is that company being strict, not your sender reputation failing, so a single-domain streak is only logged, never flipped. Only an Active account can be blocked this way; one you’ve already paused, or one already in Error, is left alone. And this block doesn’t wait for you to fix anything before it lets you try again: reconnect while the underlying problem is still there, and the very next rejection puts the account straight back into Error. This is also the one Error a mailbox on PipeLime managed infrastructure does not get out of by itself. The automatic re-test that recovers other managed mailboxes deliberately skips an account carrying this message, because that account still signs in perfectly and would be handed straight back to sending through the same blocked identity. Getting out of a reputation block is a person’s job on any mailbox, managed or not.

​
You’re told three ways, and they don’t reach the same people

The moment an account’s status changes to Error, whichever of these mechanisms wrote it, three things happen at once, automatically:
  • An email, to the workspace owner and only the workspace owner. There is no preference anywhere that turns this one off.
  • A notification in the bell, to every teammate whose Sender Errors preference is switched on, which it is by default. Notification preferences is where each person turns that off for themselves.
  • An entry in the workspace’s activity feed, which nobody has to be notified for and which is not gated by any preference. Activity Monitor is where you read it back.
All three are also written once. An account already in Error doesn’t get re-flagged and re-notified the next time a sweep happens to see the same failure again. And none of them fires for an account that starts life already in Error, a bad row in a bulk import, say: they are tied to an account actually changing into the state, not to the state itself.

​
What neither check ever does

  • It never clears an Error it wrote. Recovery is a person pressing Refresh sender, saving corrected settings, or, for a mailbox on PipeLime managed infrastructure that was not blocked for reputation, an automatic re-test elsewhere. Fix an email account in Error covers that side.
  • It never touches a Paused account. Paused is a choice you made, or one the product made while a managed mailbox finishes setup, and neither check second-guesses it.
  • It never re-probes an account that’s already Error. The connection probe only looks at Active accounts to begin with.
  • It never checks a mailbox that was never fully registered with the sending service, so a half-finished setup can’t be mistaken for a dead mailbox before it’s even live.

​
Limits

Fix an email account in Error

Every message an automatic flip can write, and what Refresh sender actually tests.

Sender statuses

Active, Paused and Error, and the chips that aren’t statuses at all.

Notification preferences

Turn the bell notification off, per person. The email has no such switch.

Active, but nothing is delivered

A green chip and no mail arriving is a different problem from anything on this page.