Why was my email rejected?
A rejection is different from a bounce. A bounce is the receiving server saying no after Bird tried to deliver; a rejection means the message (or one of its recipients) never got that far — Bird stopped it before or during sending. Rejections always come with a reason you can inspect, so this page walks through the common ones and what to do about each.
The recipient is on your suppression list
The most common rejection by far. If an address previously hard-bounced, reported your mail as spam, unsubscribed, or was added to the suppression list manually, Bird won't deliver to it — that's the suppression list doing its job of protecting your sender reputation.
Two things worth knowing about how this shows up:
- Suppressed recipients are not silently dropped. They still appear in the message's recipient list, marked as rejected, with a reason you can inspect — so you can always see exactly which addresses were blocked and why. The rest of the recipients are unaffected and deliver normally.
- If every recipient of a send is suppressed, there's nothing left to deliver, so the whole send is refused with an all recipients suppressed error and no message is created.
If you believe an address shouldn't be suppressed, you can review and remove entries — the suppressions guide explains the different suppression reasons and how to manage the list. Be careful removing hard-bounce entries: if the address still doesn't exist, the next send will just bounce and re-suppress it.
The address is invalid
If an address is malformed, or it's on a placeholder domain that can't receive mail (like example.com or a test domain), Bird rejects it rather than attempting a delivery that's guaranteed to fail. The fix is at the source: validate addresses when you collect them, so typos never make it into your list.
You hit a rate limit
Bird limits how many send requests you can make per minute, based on your plan. If you exceed it, requests are refused until the window resets — the response tells you how long to wait. This is temporary by design: wait a moment and retry, or if you're regularly bumping into the limit, batching your sends or moving up a tier raises the ceiling. Rate-limit errors are covered in more detail in Common error messages.
A policy block
Sends can be refused by sending policy — for example, sending from the shared onboarding domain to someone who isn't a verified member of your workspace, or sending from a domain that isn't verified yet. Policy rejections always name what was blocked and why, so the error message itself points at the fix.
If your sending has been paused for reputation reasons (high bounce or complaint rates), sends are also refused — that's a different situation with its own recovery path, covered in Why was I throttled or paused?.
A content or generation error
If the message itself couldn't be built — a template problem, broken content, a field that didn't validate — the recipient is rejected with a generation or validation error. These are problems with the send, not with the recipient's address, so they never affect the recipient's standing: fix the content and resend.
How to find out which one happened
Open the message's detail view in the dashboard: each recipient shows its outcome, and rejected recipients carry the specific rejection reason. If the whole request was refused (rather than individual recipients), the error response names the exact problem — the Common error messages glossary translates the ones people hit most often.
Related pages
- Common error messages — plain-language explanations of the errors behind rejections
- Why was I throttled or paused? — when sending is refused for reputation reasons
- Suppressions — the developer guide to the suppression list and how rejected recipients are reported