Ever gotten one of those emails bounced straight back with a cryptic line about content not being accepted? If you're running mail through Mimecast, you've probably seen it and felt a small spike of irritation. It's one of those errors that sounds vague on purpose — like the gateway is quietly judging your message and refusing to explain itself Nothing fancy..
The short version is this: a mimecast bounce message content not accepted isn't a single bug. It's Mimecast's way of saying "something in this email tripped a policy or filter, and we're not delivering it." But what that something actually is? That's where it gets interesting.
What Is a Mimecast Bounce Message Content Not Accepted
Mimecast sits between your mail server and the outside world. It scans, filters, and rewrites traffic based on rules your org (or your provider) set up. When an outbound or inbound message gets rejected with "content not accepted," Mimecast is blocking it at the content-inspection layer Easy to understand, harder to ignore..
Look, this isn't the same as a hard bounce because the address is wrong. Worth adding: the recipient exists. The mail just didn't pass muster. Sometimes it's a URL. Sometimes it's an attachment type. Sometimes it's a phrase that looks like a threat. And sometimes — honestly — it's a false positive that makes no sense until you read the headers.
The Difference Between a Bounce and a Reject
A bounce usually comes back as an NDR (non-delivery report). Day to day, you'll see it in your inbox as a failed message. In practice, a reject at the Mimecast level often happens before the message leaves the gateway, so the sender gets the bounce instantly. That's why it feels abrupt.
Where the Message Comes From
The bounce itself is generated by Mimecast's servers, not the recipient's. So if you're debugging, don't start with the other company's IT team. Start with your own Mimecast admin console or the logs your provider can see.
Why It Matters
Why does this matter? Because most people skip it and just resend the email three times until one version "magically" goes through. That's a terrible habit Still holds up..
In practice, a blocked message can mean a lost invoice, a missed contract, or a client thinking you ghosted them. I've seen sales threads die because a quote PDF got silently bounced and nobody checked the NDR for two days. Real talk: email is still where business happens, and a gateway that blocks you without clarity is a risk.
And here's what most people miss — these blocks aren't random. But the bounce text your users see is often stripped down to "content not accepted" because the full detail lives in the admin view. So the sender is left guessing. That's why mimecast logs the reason code. That gap costs time.
How It Works
Understanding the mechanics helps you fix it fast instead of praying. Here's how the content block actually fires.
Inbound vs Outbound Scanning
Mimecast scans both directions. Outbound, it's checking your users aren't leaking data or sending malware. Inbound, it's checking the world isn't sending you junk or exploits. And a "content not accepted" can fire on either side. In real terms, if your own staff can't email a file out, that's outbound policy. If a partner's mail won't reach you, that's inbound.
Short version: it depends. Long version — keep reading.
Content Inspection Policies
This is the big one. Admins set content inspection rules. Those rules look at:
- Attachment extensions (.exe, .
If a message hits a rule set to "reject," you get the bounce. Not a quarantine note. A flat reject Worth keeping that in mind..
URL Protection and Rewrite
Mimecast often rewrites links so they point through its proxy. If a URL is on a blocklist, or the rewrite service can't categorize it, some policies reject instead of rewrite. So a totally normal-looking link to a scheduling tool can kill the whole email.
Attachment Sandboxing
Newer Mimecast setups sandbox attachments. If the sandbox can't open the file, or the file behaves oddly in the virtual environment, the message gets bounced with content not accepted. I know it sounds simple — but it's easy to miss that a harmless-looking .zip is the problem Not complicated — just consistent..
The Role of Spam and Threat Feeds
Mimecast subscribes to global threat intel. If your email mentions a domain that was flagged an hour ago, and your policy is aggressive, the message is gone. No appeal at the user level No workaround needed..
Reading the Actual Reason
In the admin console, the message tracking log shows a code like RC: -1 or a policy name. That's the real story. Consider this: the user-facing bounce is just the cover letter. Here's the thing — without that code, you're guessing, and guessing wastes everyone's afternoon Easy to understand, harder to ignore. Took long enough..
Common Mistakes
This section is where most guides get it wrong, because they tell you to "check your spam folder." That's not the problem here.
One mistake: assuming the recipient blocked you. They didn't. In real terms, mimecast did, before the mail left your building. Another: forwarding the bounce to the client with a "did you get this?" — no, they didn't, and now you've sent them the error too.
And the classic — changing the subject line and resending. You'll bounce again. If the block is on the attachment or a link in the body, a new subject does nothing. I've watched teams do this five times in a row.
Another miss: not checking personal vs business accounts. Also, if you're sending from a personal Gmail to a Mimecast-protected company, their inbound filter might reject your content while your own provider shows "sent. On the flip side, " You never see the bounce. They just don't get it The details matter here..
Practical Tips
What actually works when you're staring at this error?
First, get the admin logs. Day to day, if you're not the admin, ping whoever is and ask for the message tracking result, not just "why did it fail. " The policy name is gold Easy to understand, harder to ignore. That alone is useful..
Second, strip the email to basics. Send a plain-text version with no links and no attachments. Consider this: if that goes through, add pieces back one at a time. Turns out the link to your invoicing portal was the culprit, not the contract.
Third, use Mimecast's allowed-sender or allowed-URL lists carefully. Don't blanket-allow a domain because of one bounce — that's how phishing gets in. But a specific known-good URL pattern? Worth a ticket Easy to understand, harder to ignore. That alone is useful..
Fourth, train users to read the NDR. The bounce often includes an ID. On the flip side, that ID lets support pull the exact rule. Without it, you're a ghost Which is the point..
Fifth, if you're a sender to Mimecast-protected orgs a lot, avoid macro-enabled docs. Think about it: send PDFs. Use link shorteners? Don't. They get blocked more, not less.
And look — if you're the admin, review your content inspection policies quarterly. Aggressive rules feel safe but they break real work. Tune them. A reject-only rule on "invoice" in the subject is how you lose client mail.
FAQ
Why does Mimecast say content not accepted but not tell me what content? Because the user-facing bounce is simplified. The detailed reason — file type, link, or phrase — is in the admin message tracking log. Users don't get it by design.
Can I stop Mimecast from blocking my own outbound mail? If you're the admin, yes, by adjusting content inspection policies or adding safe lists. If you're a user, you can't — you have to route the fix through your IT or provider.
Is content not accepted the same as a spam block? No. Spam blocks usually say something about reputation or spam score. Content not accepted means a specific policy on attachment, link, or body content fired a reject action.
Will resending the same email eventually work? Almost never. The policy will block it every time unless something changes — the content, the attachment, or the admin rule. Resending identical mail just creates more bounces.
How do I know if it was my link or my file? Send two test mails: one with the link and no file, one with the file and no link. The one that bounces tells you the trigger. Old trick,
still reliable.
Does Mimecast log these blocks even if the sender never gets a detailed error? Yes. Every content rejection is recorded in the administrator console with the policy name, timestamp, and triggering artifact. That log is the only authoritative source of truth for what actually fired.
Can a legitimate signature image cause a content not accepted reject? It can. Embedded images pulled from external URLs, especially from lesser-known CDNs, sometimes trip URL or reputation policies. Hosting the image inline or on a trusted domain usually resolves it It's one of those things that adds up..
Conclusion
"Content not accepted" is less a mystery than it appears — it is Mimecast doing exactly what its policies were configured to do, just without handing the sender the blueprint. Because of that, whether you are a user stuck in the loop or an admin owning the rules, the fix is rarely "try again" and almost always "look closer. The gap between a simplified bounce and the real trigger is where most frustration lives, and it is closed by admin logs, disciplined testing, and sensible policy tuning rather than repeated sends or blanket allowances. " Treat the reject as a signal, not a wall, and the mail that matters will get through.
