# Sending standards (/security) Sendly sends your mail through shared infrastructure. One sender with a bad list can damage delivery for everyone on it, so there are limits, and crossing them can stop your project from sending. This page says exactly where those limits are and what happens at each one. It describes what the platform actually does today, including the parts that are blunt. ## Two different systems, two different behaviours [#two-different-systems-two-different-behaviours] They are worth separating, because they treat you very differently. **Reputation** — bounces and spam complaints — is a gradual, measured signal. It has a warning stage, and the numbers are published below. **Content** — mail that scans as phishing — is not gradual. There is no warning stage, the thresholds are not published, and one bad result can stop every project you own. ## Reputation: the published ladder [#reputation-the-published-ladder] Two bands. Crossing the first flags your project. Crossing the second stops it sending. | Signal | Window | Flagged at | Sending stops at | | ------------------- | -------------- | ---------- | ---------------- | | Hard bounce rate | Rolling 7 days | 4% | 7% | | Hard bounce rate | All time | 3% | 6% | | Spam complaint rate | Rolling 7 days | 0.05% | 0.08% | | Spam complaint rate | All time | 0.025% | 0.08% | Neither band applies until a project has sent at least 100 emails, and a project is never stopped on a rate alone — the absolute count has to be meaningful too, so a handful of bounces on a small list cannot trip it. These are deliberately stricter than our upstream provider's. Amazon SES warns at a 5% bounce rate and suspends at 10%; it warns at a 0.1% complaint rate and suspends at 0.5%. Sendly stops a project before that happens, because a suspension at the provider level would take every Sendly customer down with it, and because a sender who reaches those numbers is going to end up in spam folders long before the provider intervenes. There are also absolute ceilings — a flat number of bounces or complaints in 24 hours or 7 days — which catch a high-volume sender whose rate stays low simply because they send a lot. Those numbers are not published, because publishing them would tell someone exactly how much bad mail they can send without tripping anything. New projects have tighter ceilings than established ones. ## What you are actually told, and when [#what-you-are-actually-told-and-when] This is the part most platforms leave vague. Ours, precisely: ### When you are flagged (the first band) [#when-you-are-flagged-the-first-band] * Your project's **Settings → Security** page shows a Warning state, with each metric's band, its rate, and the counts behind it. * Our operations team is paged. * **No email is sent to you.** There is no "you are approaching a limit" notice in your inbox today. If you are not looking at the dashboard, you will not know. We would rather write that down than imply a warning email exists. If you want to catch this early, check Settings → Security, or watch your bounce and complaint rates on your campaign reports. ### When sending stops (the second band) [#when-sending-stops-the-second-band] * The project is disabled. New sends are refused; so is every other change to the project. * **Reading stays open.** You keep full access to the dashboard, your contacts, your campaign history and your reports — deliberately, so you can see what happened, export your data, and appeal. * You get a notification in the app and an email to the project's members. * The reason is shown on the Security page. ## Content: what happens with no warning [#content-what-happens-with-no-warning] Outbound mail is sampled and scanned for phishing. New projects are scanned far more heavily than established ones. If a message scans as phishing with high enough confidence — or if enough messages do inside a short window — the project is disabled immediately. There is no flagged stage, no notice first, and no opportunity to correct it before it happens. Three further things are true here, and none of them are accidents: 1. **The reason you are shown is generic.** It reads "A policy violation was detected. Please contact support for more details." It does not name the message, the score or the rule. A precise reason is a debugging tool for whoever is abusing the platform. 2. **It applies to every project you own.** A phishing verdict is treated as a judgement about the account, not about one project, because nothing limits how many projects one signup can create and containing only one of them would contain nothing. 3. **On a very new project, we do not email you about it.** Operators are paged and the dashboard shows it, but the outbound notice is withheld. The notice would travel through Sendly's own sending pipeline, which tells an active abuser they have been caught, in the same second, using our infrastructure. Projects past their first week keep the email. If you are a legitimate sender who has been caught by this, that third point is why the first you may hear of it is a dashboard that has stopped working. We are sorry about it, it is a real cost of the design, and it is why appeals exist and why we answer them fast. ## The thresholds we do not publish [#the-thresholds-we-do-not-publish] The phishing confidence score, how many detections it takes, and the window they are counted over are not on this page and will not be given out. Publishing them would let someone pace their sending to stay just underneath — which converts a safety limit into a budget. We publish the reputation ladder because it is not gameable in the same way: the only way to stay under a 7% bounce rate is to have a list that does not bounce, which is the behaviour we want anyway. ## If your project has been stopped [#if-your-project-has-been-stopped] You can still sign in, read everything, and export it. Two things to do: * [File an appeal](/appeals). A person reads it, and we commit to a first response within 24 hours. * [Export your data](/trust/portability) if you want a copy regardless of the outcome. ## Related [#related] * [Acceptable use](/security/acceptable-use) — what you may and may not send. * [Appeals](/appeals) — the process and the response time we commit to. * [Portability](/trust/portability) — taking everything with you, at any time.