> ## 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. # Automatic health checks and the reputation block > The background probe that moves a mailbox to Error, its grace periods, and the rejection streak that blocks a sender. 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

; }; 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](/en/email-accounts/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](/en/email-accounts/reconnect-a-sender): 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](/en/workspaces-account/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](/en/analytics/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](/en/email-accounts/reconnect-a-sender) 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 | | | | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | What the connection probe reads | Live connection state from the sending service, not a fresh SMTP or IMAP session | | How stale before an **Active** account is due again | At least 6 hours since its last check | | Grace before an authentication failure flips the account | 1 hour, when the scheduled probe is what sees it | | Grace before a connection failure flips the account | 24 hours, when the probe sees it on a mailbox that isn't signed in through a provider | | A provider-signed-in mailbox's connection failure | Re-checked directly against the provider first: a live grant clears it, a genuinely dead one takes the 1-hour grace, a provider that can't be reached is left alone | | A correlated failure across one sending instance | Every probe on it is treated as inconclusive for that sweep, so nothing flips and no error clock advances. Logged, not flipped | | Grace when a real send fails instead | None. A definitive credential, host, port, TLS, DNS or protocol failure flips the account on that attempt | | What a failing send does not flip the account for | A mailbox server it can't reach (re-registered and retried once first) and a deferred sign-in (the message is parked, the account stays **Active**) | | What flips an account for reputation | 5 permanent policy rejections, across at least 3 different recipient domains, inside a 6-hour window | | Which accounts the two checks can flip | **Active** only. **Paused** and already-**Error** accounts are left alone | | What clears an **Error** by itself | Nothing, for an account you connected yourself. Nothing at all for a reputation block, on any mailbox | | Who is emailed when an account flips | The workspace owner only, with no opt-out, whichever mechanism flipped it | | Who sees the bell notification | Every teammate whose **Sender Errors** preference is on, which it is by default | | Who sees the activity entry | Anyone who can open Activity Monitor. No preference gates it | ## Related Every message an automatic flip can write, and what Refresh sender actually tests. Active, Paused and Error, and the chips that aren't statuses at all. Turn the bell notification off, per person. The email has no such switch. A green chip and no mail arriving is a different problem from anything on this page.