Short answer
A bounced email is the one that comes back to you with an error instead of reaching the person you wrote. Somewhere between your outbox and their inbox, a mail server decided it couldn't deliver the message, and it sent you a report saying so. Read in order, it tells you who turned the message away, whether the failure is permanent or only for now, and what to do next. Most bounces are a simple mistyped address that you fix and re-send in under a minute. The rest fall into a short list of reasons, and once you can name the reason, the fix is usually obvious.
One boundary up front, because two very different problems both get called my email didn't get there. This page is about the rejected message: you got an error back, so you already know it never arrived. If instead your message left cleanly, with no error at all, and simply landed in someone's junk folder, then nothing bounced and there's nothing here to decode; that silent misfiling is a separate diagnosis, covered in why your emails go to spam. And when a bounce points at the address itself, the shapes a working address takes are in professional email address. Everything below is for the message that came back.
What the bounce message actually says
A bounce is a letter from a machine. It shows up in your inbox looking like an ordinary email, but it came from an automated system rather than anyone you wrote to, and the sender name usually says so outright: a mailer daemon, a postmaster, a delivery subsystem. Nobody sits on the other end of it reading a reply, so there's no point writing back to it. It exists for one purpose, to tell you what became of the message you sent.
Under that machine wrapper, three parts carry the meaning. There's a line of almost-plain English, the reason the system offers for giving up: the address wasn't found, the mailbox is full, the message was too large. There's often a short code sitting near that line, and you only need one thing from it, which is the first digit. A code that starts with 5 means a permanent failure, and a code that starts with 4 means a temporary one. And there's your own message quoted back underneath, which is how you tell which of your sends bounced when you've fired off several close together.
Permanent against temporary is the split that decides your whole response, so it's worth getting straight. A permanent failure, the five, means the server has decided: the message won't be delivered as it stands, and re-sending the identical email accomplishes nothing. Something has to change first, and usually that something is the address. A temporary failure, the four, means the server couldn't deliver right now but hasn't given up. It keeps retrying on its own for a while, and most temporary bounces clear without you doing anything at all. The costly mistake is treating the two alike, either hammering the re-send button at a permanent failure or worrying over a temporary one that would have sorted itself out.
Match the bounce to the fix
Nearly every bounce you'll read is one of five messages wearing different wording. The exact sentence changes from one system to the next, but the underlying reason is one of a short list, and the reason is what tells you whether to fix something, wait it out, or reach the person a different way.
Find the reason that matches your bounce below. Each row pairs what the wording actually means with the move that fits it.
| What the bounce says | What actually happened | What to do about it |
|---|---|---|
| Address not found | The mailbox on the receiving side doesn't exist. Either the address is mistyped, or it was real once and has since been closed: someone who left a company, an account shut down. The server looked for somewhere to deliver, found nothing, and gave up for good. This is a permanent failure. | Read the address back one letter at a time, because a single wrong character causes this far more often than a truly dead mailbox. If the spelling is genuinely right, the address is gone, and you'll need another route to the person: a different address, a phone call, a mutual contact who can pass along the correct one. |
| Mailbox full | The address is real and your message reached the right server, but the recipient's inbox is over its storage limit, so there's no room to accept anything new. This one is usually temporary and entirely on their end. | Let the server keep retrying, since space often frees up on its own. If the message is time-sensitive, reach the person another way and mention their inbox is full. There's nothing to correct on your side, the address is right and the message is fine. |
| Message too large | The message exceeds the size the receiving server will accept, almost always because of an attachment. The address is fine; the weight of what you sent is what got refused. | Don't re-send the same thing, because it'll fail the same way. Put the large file behind a link instead of attaching it, or compress it first, and send a lighter message that the server will take. |
| Blocked by policy | The receiving server refused the message on purpose, following a rule rather than reacting to a bad address. It may object to something about where the mail originated, or the content may have tripped a filter. The address exists; the message was turned down by choice. | This is the bounce most likely to trace back to your own sending setup, especially when it repeats across recipients. A single instance can sometimes go through if you re-send later; a pattern across unrelated people is the signal to look at how you send rather than who you're writing to. |
| Temporary failure keeps retrying | The server couldn't deliver at the moment, maybe a busy or briefly unreachable destination, so it's holding your message and trying again on a schedule. This is the four-code failure, and nothing has failed for good yet. | Do nothing at first, because this is the bounce that most often resolves itself. If the retries run on for a long stretch and then turn into a permanent failure, handle it as whatever that final report says. A copy you re-send by hand only risks two messages arriving once the server gets through. |
Address not found
- What actually happened
- The mailbox on the receiving side doesn't exist. Either the address is mistyped, or it was real once and has since been closed: someone who left a company, an account shut down. The server looked for somewhere to deliver, found nothing, and gave up for good. This is a permanent failure.
- What to do about it
- Read the address back one letter at a time, because a single wrong character causes this far more often than a truly dead mailbox. If the spelling is genuinely right, the address is gone, and you'll need another route to the person: a different address, a phone call, a mutual contact who can pass along the correct one.
Mailbox full
- What actually happened
- The address is real and your message reached the right server, but the recipient's inbox is over its storage limit, so there's no room to accept anything new. This one is usually temporary and entirely on their end.
- What to do about it
- Let the server keep retrying, since space often frees up on its own. If the message is time-sensitive, reach the person another way and mention their inbox is full. There's nothing to correct on your side, the address is right and the message is fine.
Message too large
- What actually happened
- The message exceeds the size the receiving server will accept, almost always because of an attachment. The address is fine; the weight of what you sent is what got refused.
- What to do about it
- Don't re-send the same thing, because it'll fail the same way. Put the large file behind a link instead of attaching it, or compress it first, and send a lighter message that the server will take.
Blocked by policy
- What actually happened
- The receiving server refused the message on purpose, following a rule rather than reacting to a bad address. It may object to something about where the mail originated, or the content may have tripped a filter. The address exists; the message was turned down by choice.
- What to do about it
- This is the bounce most likely to trace back to your own sending setup, especially when it repeats across recipients. A single instance can sometimes go through if you re-send later; a pattern across unrelated people is the signal to look at how you send rather than who you're writing to.
Temporary failure keeps retrying
- What actually happened
- The server couldn't deliver at the moment, maybe a busy or briefly unreachable destination, so it's holding your message and trying again on a schedule. This is the four-code failure, and nothing has failed for good yet.
- What to do about it
- Do nothing at first, because this is the bounce that most often resolves itself. If the retries run on for a long stretch and then turn into a permanent failure, handle it as whatever that final report says. A copy you re-send by hand only risks two messages arriving once the server gets through.
Check the typo first
Before you reach for any exotic explanation, check the address, because a typo causes more bounces than every other reason put together. Addresses are unforgiving in a way that sentences aren't: one transposed letter, a dot in the wrong spot, a .co where you meant .com, or a name your inbox autocompleted to the wrong person, and the whole message bounces. The fix is to read the address slowly, character by character, against a reliable source for the real one, a business card, their signature, the company website. Autocomplete is the quiet culprit, since it drops in an address that looks right at a glance and belongs to someone else entirely.
The re-send carries a small etiquette, since a bounce costs you a little time and occasionally the recipient sees two versions. Keep it light. If you were the only one who saw the bounce, just correct the address and send the same message again; there's no reason to mention that the first attempt failed. If some time has passed and the note was time-sensitive, one plain line at the top covers it, saying the first attempt didn't go through and here's the note. Skip the elaborate apology. A bounced address is a normal, minor thing, and the same light touch that runs through email etiquette applies here: don't let a small mechanical hiccup read larger than it is. If you're genuinely unsure you have the address right even now, it's fine to include it in the body so the person can correct you if it's still off.
When the problem is your side
A single bounce to a single person is almost always about that one address. But when several messages bounce around the same time, to different people who have nothing to do with each other, look past the individual addresses. The common thread is your own sending setup, and a blocked-by-policy bounce that repeats across unrelated recipients is the clearest version of it. The receiving servers have no shared typo to reject; each one is reacting to something about where your mail is coming from.
That's a different problem from a lone bounce, and it sits right next to another one worth naming. A bounce at least gives you something to read, an error came back. The quieter failure leaves you nothing: the message goes out cleanly, never bounces, and still never reaches the person, because it landed in their spam folder instead. No report, no error, just a silence you might mistake for being ignored. When your sends vanish without a bounce, or bounce in clusters for policy reasons, the sending-side signals a filter weighs are laid out in why your emails go to spam. This page stops at the bounce you can actually read.
One bounce, decoded
The quickest way to read a bounce is to watch someone read one. Odile is reaching out to Gunnar, a supplier she's never emailed before, and she typed his address in from memory. A minute after she hits send, this arrives in her inbox:
"Mail Delivery Subsystem"
"Delivery to the following recipient failed permanently:"
"gunar.holt@northreef.com"
"The mail server responded: 550, the address does not exist."
The first thing Odile registers is who it's from, a Mail Delivery Subsystem and not Gunnar. That alone tells her Gunnar never saw the message; a machine turned it back before it ever reached him, so there's no half-delivered version out there to worry about.
Then the two words that set her response. Permanently, and the 550 beside it, say the same thing from two directions: this is a hard failure, and re-sending the exact message will only bounce again. The reason line spells out why, the address does not exist. So she's either got the wrong address or the right one is closed, and since Gunnar is a brand-new contact she's never successfully reached, a shut-down mailbox is unlikely. A typo is the heavy favorite.
She reads the bounced address against Gunnar's signature from the note that introduced them. The bounce shows gunar.holt; his signature shows gunnar.holt, with two n's. One dropped letter, the kind of slip autocomplete wouldn't have made because she typed it fresh. That's the entire fault.
The fix takes half a minute. She corrects the spelling and sends the same message again. Because she caught the bounce herself within a minute and Gunnar never saw the first attempt, she says nothing about it; there's no failure for him to be aware of. Had a day gone by on a time-sensitive note, she'd have added a single plain line, that the first try bounced off a typo and here's the message, and left it there. Either way, the bounce stops being a mystery the moment she reads its three parts in order: who sent it, whether it's permanent, and what the reason really was.
dreamif.ai
How dreamif.ai fits
A bounce is a sending event, and sending is the one thing dreamif.ai never does for you. It drafts; you send. So a bounce is always the product of your own send, and always yours to read, judge, and answer. Nothing sits between your outbox and the mail server to catch an error for you or quietly correct an address, which is the honest shape of it: the decoding above stays your job.
Where a drafting step actually helps is the re-send. It drafts in Gmail using thread history, saved notes, and connected sources when settings allow, with review before send. A bounce means you're about to write the same person twice in a row, and a draft you can read and approve keeps that second attempt from costing as much as the first did.
- Nothing leaves your outbox unless you press send yourself, and drafts stay parked in Gmail waiting for that click, so a tool never puts a message on its way that could bounce back without you
- A corrected re-send builds on the message that bounced, so a fixed address is nearly the only thing that changes and you're not writing the note again from an empty window
- Saved contact notes hold the details you've confirmed about a person, so the address that finally delivered is on hand the next time you write them, not retyped from memory
- Saved drafting-style instructions keep the re-send short and human in your own voice, instead of a stiff, over-apologized do-over
Questions, answered.
It means a mail server couldn't deliver your message and sent you an automated report instead of the message reaching the person you wrote. That report comes from a system rather than a human, and it names a reason: the address wasn't found, the inbox was full, the message ran too large, and so on. Reading the reason tells you whether to fix something and try again or simply wait it out. A bounce is really a short set of instructions, and once you know how to read it, it points straight at the fix.