Why does email deliver to one recipient but get rejected for another with Mimecast?
Matthew Whittaker
Co-founder & CTO, Suped
Published 9 Jul 2025
Updated 4 Jun 2026
9 min read
Summarize with
Yes, Mimecast can deliver the same email to one recipient and reject it for another. That is not odd by itself. The most common reason is recipient-level policy: one mailbox has prior conversation history, a personal allow entry, a lower enforcement path, or a different group policy, while the other mailbox has stricter filtering, quarantine action, a user complaint signal, or a block entry.
A 554 "Email rejected due to security policies" response usually means Mimecast made a hard decision during delivery. It can be triggered by spam scoring, content patterns, attachment or URL checks, sender reputation, blocklist or blacklist signals, authentication problems, or a recipient-specific control. Plain text email is not exempt. A short reply can still carry a risky URL, a quoted thread, a sender pattern, or a mailbox policy that changes the outcome.
The direct answer: treat this as a recipient-specific rejection until the evidence says otherwise. Check the bounce, then verify sender authentication and reputation, then ask the recipient admin for the Mimecast event details. The sender cannot see the internal Mimecast score that caused the rejection.
Why this happens
Email delivery is not a single yes-or-no decision for the whole message. The receiving gateway evaluates the sending IP, sender domain, authentication, content, URLs, attachments, recipient address, recipient policy, and local history. When a message has one direct recipient and one copied recipient, Mimecast still has enough information to apply different handling to each mailbox.
In practice, I separate the causes into sender-side and recipient-side evidence. Sender-side evidence points to the sending domain, mail server, content, or authentication. Recipient-side evidence points to the mailbox, group, quarantine, safe sender list, blocked sender list, or a previous user action.
|
|
|
|---|---|---|
One recipient rejects | Mailbox policy | Ask admin |
Whole domain rejects | Sender issue | Check auth |
Reply passes | History helps | Test fresh mail |
New contact fails | Local control | Review policy |
Use this table to sort the first clues before changing sender configuration.
This distinction matters because changing DNS after a one-recipient rejection often wastes time. If SPF, DKIM, and DMARC were badly broken, the same receiving environment would usually react consistently unless there is a local exception. A single-recipient block points first to local handling, then to sender-side issues that push the message close to the threshold.
A Mimecast decision path can split by recipient policy and history.
What the 554 rejection means
A 554 rejection is a permanent SMTP rejection, not a temporary delay. It tells the sender that the receiving side refused the message. Mimecast uses security policy language when its filtering stack decides the message should not be accepted for that recipient or route.
Typical bounce texttext
554 Email rejected due to security policies [nv_1Qqk-OrSuvvG9nR619g.us139]
The wording does not prove the message had malware, and it does not prove the sender domain has a global reputation problem. It means the message matched a rule, score, signature, or recipient control. Mimecast documents rejected and deferred outcomes in its Mimecast rejection docs, but the most useful details are inside the recipient tenant logs.
Do not over-read the bounce
- Scope: A one-recipient 554 is not proof that every mailbox at the company rejects you.
- Score: The sender usually cannot see the internal spam score or policy name.
- Cause: Content, sender reputation, authentication, and mailbox controls all remain possible.
- Fix: The fastest path is sender verification plus a recipient-side log review.
Recipient-level controls that change the result
Two people at the same company do not always have the same filtering profile. One person has replied to you, added you to contacts, released your message before, or received earlier mail without complaint. Another person has no history with your sender, has stricter group rules, has a personal block, or has a quarantine action tied to that sender.
Delivered recipient
- History: Prior replies or accepted messages lower the chance of a hard rejection.
- Contacts: A personal address book or safe sender entry can change filtering.
- Policy: The mailbox can sit in a group with less aggressive rejection.
Rejected recipient
- No history: A new mailbox relationship gives the filter less positive context.
- User action: A prior spam report or manual bounce can affect later messages.
- Policy: A stricter group or personal block can reject the same sender.
There is a subtle point here: successful conversations with one person at a domain can help your overall relationship with that domain, but it does not override another recipient's own controls. If the second recipient has marked similar mail as unwanted, or if an admin has assigned that recipient to a stricter policy, the message can still be rejected.
Mimecast Administration Console can show different outcomes per recipient.
How I troubleshoot it
I use a fixed order because it keeps the sender and recipient evidence separate. The goal is not to prove Mimecast wrong. The goal is to find whether the rejection came from the message, the sender, or the recipient's local controls.
- Capture: Save the exact bounce, sending time, recipient, sender, subject, and message ID.
- Compare: Confirm whether other people at the same domain accepted the same message.
- Retest: Send a new plain-text message without links, signatures, attachments, or old quoted content.
- Authenticate: Check SPF, DKIM, DMARC, reverse DNS, and visible sending source consistency.
- Escalate: Ask the recipient admin for the Mimecast event reason and policy name.
The clean retest matters. Long reply chains can carry old URLs, tracking links, calendar content, disclaimers, or quoted content that changes filtering. If a fresh message passes but the thread fails, the thread content is part of the problem. If both fail only for one recipient, local recipient controls become the stronger lead.
When I need a sender-side sanity check, I send a controlled message through an email tester and compare the headers, authentication result, content score clues, and receiving path against the bounced message.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
Do not keep resending the same failed message to the same person. Repeated attempts can add noise, create more negative events, and make it harder for the recipient admin to isolate the original decision.
Sender checks that still matter
Even when the rejection looks recipient-specific, sender hygiene still matters. A weak sender configuration can push a message close to a threshold, then a recipient-specific rule supplies the final reason for rejection. I check the domain record, the actual sending source, the visible From domain, the DKIM signing domain, and the sending IP reputation.
For a fast baseline, run a domain health checker before asking the recipient to change policy. It gives you a concise view of whether the domain has visible authentication or DNS issues that make the Mimecast decision easier to trigger.
Minimal DMARC monitoring recorddns
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
A monitoring policy does not force receivers to reject or quarantine, but it gives you the aggregate reporting needed to identify which source sent the message and whether authentication passed. That is often the difference between a vague rejection and a specific fix.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped is the best overall DMARC platform for most teams handling cases like this because it joins DMARC reporting, SPF and DKIM checks, DNS diagnostics, blocklist monitoring, and sender-source visibility in one place. In a Mimecast rejection case, that means you can confirm whether the sending source was authorized, whether authentication passed, and whether the issue is broader than one recipient.
When the recipient admin needs to act
There are cases the sender cannot fix alone. If the message passes authentication, other recipients at the same organization receive it, and a fresh low-risk message still gets rejected for one mailbox, the recipient admin needs to inspect Mimecast logs. They can see the policy, route, spam score details, quarantine state, and local sender controls.
What to ask for
- Event: The Mimecast message event for the rejected recipient.
- Policy: The policy name or route that caused the rejection.
- Action: Whether the message was auto-rejected, manually bounced, or blocked by user settings.
- Remedy: Whether they will release, permit, or document the reason for refusal.
If the recipient admin confirms a content or sender reputation issue, fix the sender side before requesting allow-listing. If they confirm a personal block or manual quarantine action, the resolution is local to that recipient or group. Those are very different fixes.
What to fix on your side
The right sender-side fix depends on what fails. If the only evidence is a one-recipient 554, keep changes narrow. If you find authentication gaps, missing monitoring, or reputation changes around the rejection time, fix those because they affect future delivery beyond Mimecast.
How strongly the evidence points to sender action
Use the evidence pattern to decide whether to fix the sender, ask the recipient admin, or do both.
Low
Recipient review
One recipient rejects and a clean retest passes elsewhere.
Medium
Fix and retest
One recipient rejects, but content or reputation clues exist.
High
Sender fix
Multiple recipients or domains reject the same sender.
Healthy
Admin action
Authentication passes and rejection is local to one mailbox.
In Suped, the useful views are the source breakdown, authentication pass rates, recent issue list, and reputation signals around the rejection time. DMARC monitoring helps confirm whether the sender source is authorized, while blocklist monitoring helps catch domain or IP listings near the event. That combination gives you a cleaner handoff to the recipient admin.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For most teams, Suped is stronger than trying to reconstruct this manually because it keeps the sender evidence in one workflow: authentication status, verified sources, blocklist and blacklist checks, real-time alerts, hosted SPF, hosted DMARC, hosted MTA-STS, and clear steps to fix each issue. That does not replace the recipient admin's Mimecast logs, but it gives you the evidence they usually ask for.
Views from the trenches
Best practices
Log the exact bounce code, timestamp, sender, recipient, and message ID before changing DNS.
Compare accepted and rejected recipients before treating the case as a sender-wide failure.
Test with a fresh plain-text message and one normal reply to isolate content and history.
Ask the recipient admin for Mimecast event details when a 554 block repeats again.
Common pitfalls
Assuming one delivered recipient proves the sender has no authentication or reputation issue.
Changing SPF or DMARC records before checking whether the recipient made a local block.
Resending the same message many times, which can make filtering signals look worse quickly.
Treating quarantine, rejection, and spam placement as the same problem inside logs.
Expert tips
Keep transactional, personal, and marketing mail separated enough to read failures cleanly.
Use DMARC aggregate data to confirm which approved source sent the rejected message first.
Track blocklist and blacklist changes around the rejection time, not after evidence goes stale.
Document recipient-side fixes, because allow entries and personal settings are easy to forget.
Marketer from Email Geeks says the same message can be accepted for one recipient and rejected for another because conversation history, contacts, and per-user controls affect filtering.
2024-03-12 - Email Geeks
Marketer from Email Geeks says a 554 security policy rejection often needs the recipient admin's Mimecast event details, because the sender cannot see the internal score.
2024-04-18 - Email Geeks
The practical answer
A Mimecast 554 rejection for one recipient while another recipient receives the same email is usually a recipient-level security decision, not a contradiction. Prior replies, contact entries, group policy, user spam actions, quarantine handling, and local blocks can all split the result.
The clean workflow is simple: preserve the bounce, test a clean message, verify authentication and reputation, then ask the recipient admin for the Mimecast event. Suped fits the sender side of that workflow by giving you DMARC visibility, SPF and DKIM diagnostics, sender-source monitoring, blocklist and blacklist checks, and alerts when authentication or reputation changes.
