Why does email deliver to one recipient but get rejected for another with Mimecast?
Published 9 Jul 2025
Updated 18 Oct 2026
12 min read
Summarize with
Updated on 18 Oct 2026: We clarified how to investigate recipient-specific Mimecast rejections and confirm what happened after gateway acceptance.
Yes, Mimecast can deliver the same email to one recipient and reject it for another. A common reason is recipient-level handling: one mailbox has a permitted or Auto Allow entry, while the other has a personal block, a different group policy, or no recipient-specific bypass. The first check is still the exact non-delivery report, because the failure can also occur after Mimecast accepts the message and tries to hand it to the recipient's mail server.
A 554 "Email rejected due to security policies" response is a permanent SMTP rejection. If the reason includes MCSpamSignature, Mimecast says the trigger can be a virus signature or a spam score above the maximum threshold. Other 554 reasons cover malicious QR code detection, message size, mail loops, geographical restrictions, and configuration errors. Plain text email is not exempt because URLs, quoted content, sender reputation, and recipient policy can still affect the decision.
The direct answer: identify which server issued the final response, preserve the complete bounce, verify sender authentication and reputation, then ask the recipient admin to match the event in Mimecast. The sender cannot see Mimecast's internal spam score for an MCSpamSignature rejection.
Why Mimecast treats recipients differently
Email delivery is not one decision for every recipient. The receiving path can evaluate the sending IP, sender domain, authentication, content, URLs, attachments, recipient address, recipient policy, and routing target. Mimecast also keeps recipient-specific Managed Senders entries, so one internal recipient can permit, block, or automatically permit a sender while another recipient has no such entry.
Separate sender-side evidence from recipient-side evidence. Sender-side evidence points to the sending domain, mail server, content, IP reputation, or authentication. Recipient-side evidence points to the mailbox, group policy, Managed Senders list, Auto Allow entry, held-message action, or the downstream route used for that recipient.
|
|
|
|---|---|---|
One recipient gets 5xx | Recipient policy or address validation | Read the exact SMTP reason |
Whole domain rejects | Sender or tenant policy | Check the reason and authentication |
4xx then delivery | Temporary deferral | Review retries |
Mimecast accepts, mailbox fails | Downstream route | Check mail server |
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 authentication fails for an approved direct sending source, investigate that source and its DNS records. If authentication passes and another recipient in the same tenant accepts the same message, check recipient-specific controls and routing before changing DNS.
Mimecast recipient filtering flowchart with policy, sender history, and delivery decisions.
What the 554 rejection means
A 554 rejection is a permanent SMTP failure. When Mimecast rejects the message during the SMTP conversation, it logs the connection in the Rejection Viewer and does not retain the message for release. After the cause is addressed, the sender must send the message again.
Typical bounce texttext
554 Email rejected due to security policies [nv_1Qqk-OrSuvvG9nR619g.us139]
Read the complete reason text rather than the number alone. The wording does not by itself prove malware or a global sender reputation problem. Mimecast lists policy-specific causes in its SMTP error code guidance. For MCSpamSignature, the spam score is not available in the Administration Console, so the rejection record and exact reason string are the useful recipient-side evidence. A personal block commonly has a 550 reason such as "Envelope blocked - User Entry"; do not assume it is an MCSpamSignature rejection.
Do not over-read the bounce
- A one-recipient 554 is not proof that every mailbox at the company rejects you.
- A 554 is permanent, so normal SMTP retries will not turn it into delivery.
- A protocol-rejected message is not a held message and cannot be released.
- The exact reason string determines which policy or check to investigate.
Confirm which system rejected the message
A message can fail at the Mimecast gateway or after Mimecast accepts it for delivery. The non-delivery report should show the reporting server, remote response, status code, and retry history. Those fields identify the troubleshooting path more reliably than the recipient's description that Mimecast blocked the email.
|
|
|
|---|---|---|
Mimecast returns 5xx | Permanent gateway rejection | Rejection Viewer and policy |
Mimecast returns 4xx | Temporary gateway deferral | Retry log and deferral reason |
Mimecast retries downstream | Gateway accepted the message | Recipient mail server and route |
Connection reset or timeout | Transport or server failure | Connector, firewall, and server logs |
Match the failure evidence to the system that needs attention.
Do not ask for quarantine release when the NDR shows a protocol-level 554. Ask the admin to find the rejection, correct the policy or recipient entry if appropriate, and confirm when the sender should resend. If logs show repeated downstream attempts instead, the recipient's mail server, connector, firewall, or mailbox state needs investigation.
A successful Mimecast delivery event confirms handoff to the next-hop mail server, rather than inbox placement. Check Remote Server and Receipt Acknowledgment in Transmission Data using Mimecast's receipt and delivery guidance. If that server accepted the message, ask the recipient admin to trace it there and check subsequent mail flow rules or mailbox filtering. For Exchange Online, message trace shows whether the service received, rejected, deferred, or delivered it.
Recipient-level controls that change the result
Two people at the same company do not always have the same filtering profile. Mimecast gives each user a Managed Senders list containing blocked, permitted, and Auto Allow entries. When enabled by policy, an Auto Allow entry can be created when the internal user sends mail to an external address. Group policies and routing can also target an individual address or group.
Delivered recipient
- The recipient previously sent mail to the external address.
- A personal or policy entry bypasses applicable spam checks.
- The mailbox belongs to a group with a different action or route.
Rejected recipient
- The sender receives the normal spam and reputation checks.
- The sender address or domain is blocked for that recipient.
- A stricter group rule or different route applies to the mailbox.
A permitted or Auto Allow entry can explain why one recipient receives the message, but it does not guarantee acceptance for another recipient. It also does not bypass every protection layer. A configured Blocked Senders policy and default virus checks can still take precedence, depending on the policy involved.
Releasing a held message delivers that message without changing future treatment. Permit for Recipient also adds the sender to that recipient's personal allow list, bypassing applicable spam, greylisting, and IP reputation checks for that pair. It does not create an organization-wide permit or disable virus scanning. Mimecast's Permit for Recipient guidance explains the scope of each action.
Mimecast Administration Console showing delivered and rejected recipient statuses.
Check recipient validation and aliases
A 550 "Invalid Recipient" points to address validation rather than an MCSpamSignature verdict. Mimecast can validate recipients against known addresses, directory users, or an SMTP call-forward route. Its recipient validation documentation explains these options. Check the exact envelope recipient, including any alias, before requesting a spam-filter bypass.
- Confirm the complete recipient address with the recipient and correct typos or an outdated autocomplete entry.
- Check that the mailbox address and any alias are present under Users & Groups > Internal Directories and match the intended mailbox.
- For a newly created or renamed mailbox, verify the latest directory synchronization and whether the address satisfies the domain's configured validation method.
- If validation uses SMTP call-forward, check that its delivery route reaches the correct server and that the server recognizes the recipient address.
Use Mimecast's user address documentation to check directory entries and alias relationships. If the primary address works while an alias fails, compare those entries and the validation result. Correct the address or recipient configuration before resending.
How to troubleshoot recipient-specific Mimecast rejections
Use a fixed order that keeps sender-side, gateway, recipient-policy, and downstream evidence separate. The goal is to determine whether the failure came from the message, the sender, a Mimecast policy, or the recipient's mail environment.
- Save the full NDR, reporting server, exact SMTP response, Mimecast reference, timestamp with time zone, sending IP, and envelope recipient. Include the message ID if available.
- Determine whether Mimecast rejected the SMTP session or accepted the message and failed downstream.
- Confirm whether other recipients in the same tenant accepted the same message, and compare the actual sending IP and delivery time so different sending paths do not distort the result.
- After preserving the original, send a new plain-text message without links, attachments, signatures, or quoted content.
- Check SPF, DKIM, DMARC, reverse DNS, and the actual sending source.
- Give the evidence to the recipient admin and request the matching rejection, deferral, or delivery event.
The clean retest matters. Long reply chains can carry old URLs, tracking links, calendar content, disclaimers, or quoted text that changes filtering. If a fresh message passes but the thread fails, compare the content. If both fail only for one recipient, recipient-specific controls or downstream delivery become stronger leads. After a clean message passes, reintroduce the original elements one at a time to identify the trigger.
For a sender-side sanity check, send a controlled message through the email tester and compare its headers, authentication results, content clues, and sending path with the bounced message.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Avoid manually resending an unchanged message after a permanent rejection. A correctly configured sending server should retry a 4xx response automatically. Greylisting checks the sending IP together with the envelope sender and recipient, so one recipient can be delayed while another passes. For a greylisting deferral, Mimecast documents a retry window after 60 seconds and before 12 hours in its default policy guidance. Other 4xx reasons need their own investigation.
Sender checks that still matter
Even when the rejection looks recipient-specific, sender configuration still matters. A weak configuration can push a message over a policy threshold for a recipient who has no bypass. Check the domain records, actual sending source, visible From domain, DKIM signing domain, SMTP envelope sender, reverse DNS, and sending IP reputation.
For a fast baseline, run a domain health checker before asking the recipient to change policy. It shows visible authentication and DNS issues that can contribute to filtering.
Example DMARC monitoring recorddns
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
A p=none monitoring policy requests no DMARC-based change to message handling; receivers still apply their own filtering. Keep an existing enforcement policy while diagnosing a recipient-specific rejection. Aggregate DMARC reports show sources and authentication patterns across reporting periods, but they do not trace an individual message ID or establish whether a source is approved. Compare observed sources with your approved sender inventory and check the relevant source's DMARC results. See the DMARC aggregate reporting specification for the report contents.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped is our DMARC and email authentication platform. For a Mimecast rejection, use it to identify sending sources and review authentication or DNS issues around the failure. A blocklist (blacklist) listing is another sender-side clue when the rejection cites reputation. These checks help establish whether the issue extends beyond one recipient.
When the recipient admin needs to act
There are cases the sender cannot fix alone. If authentication passes, another recipient in the same organization receives the message, and a fresh plain-text message still fails for one mailbox, the recipient admin needs to inspect the matching Mimecast or downstream event. Open Message Center > Rejected and Deferred Messages, select the event, and compare the exact reason with the recipient's policy and Managed Senders entries. Export the evidence promptly: this view retains metadata for up to seven days. See Mimecast's rejection investigation guidance.
What to ask for
- The rejection, deferral, or delivery record for the exact recipient and time.
- The complete SMTP reason and Mimecast reference string.
- The applicable policy, route, and personal Managed Senders entry.
- Whether to correct a policy, permit the sender, repair downstream delivery, or request a resend.
If the admin confirms a sender reputation or content issue, fix the sender side before requesting an exception. A personal block needs correction for the affected recipient. A held message can be released by an authorized user; a protocol-rejected message requires a resend after remediation. A message rejected after acceptance and archive indexing can still be recoverable by an administrator with Protected Content Administrator permissions, as described in Mimecast's rejected message documentation.
Match sender-side fixes to the evidence
The right sender-side fix depends on the evidence. If the only evidence is a one-recipient rejection caused by a confirmed personal block, keep changes narrow. If you find authentication gaps, an unauthorized source, or reputation changes around the rejection time, fix those because they affect future delivery beyond Mimecast. Multiple recipients within one tenant can share the same blocking policy; use the bands below as triage prompts and confirm the cause with matching logs.
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, review the relevant source and authentication results around the rejection period. DMARC monitoring helps compare observed sources with your approved senders. If the SMTP reason cites reputation, blocklist monitoring helps investigate domain or IP blacklist listings. Include the findings in the handoff to the recipient admin.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Include the source, reporting period, and relevant DNS findings when handing evidence to the recipient admin. Sender-side reports do not identify which Mimecast policy applied to an individual recipient; that requires the recipient's logs.
