Managing email bounces and rejections in Mimecast comes down to understanding why the platform blocked or returned a message, then adjusting the right setting to prevent it from happening again. Mimecast sits between the outside internet and your mail server, inspecting every inbound and outbound message against a stack of security policies, authentication checks, and content rules. When something trips one of those filters, the message gets rejected or held, and a bounce notification goes back to the sender. The challenge is that Mimecast’s rejection reasons range from straightforward address errors to subtle authentication misconfigurations that can take real detective work to sort out.
Hard Bounces Versus Soft Bounces
Email bounces fall into two broad categories, and Mimecast handles them differently. A hard bounce means permanent delivery failure. The recipient address does not exist, the domain is invalid, or the receiving server has explicitly refused to accept mail from you. Mimecast logs these and will not keep retrying. A soft bounce, on the other hand, is temporary. The recipient’s mailbox might be full, the receiving server might be briefly overloaded, or a rate limit might have been hit. Mimecast typically retries soft bounces for a period before giving up and converting them into a permanent failure notification.
The practical difference matters because your response should be different. Hard bounces call for list cleanup on the outbound side or configuration fixes on the inbound side. Soft bounces usually resolve themselves, but if the same soft bounce recurs for the same recipient over days, something deeper is wrong and you should investigate.
Where to Find Rejection Details in Mimecast
Mimecast’s Administration Console provides message tracking that lets you search for any email by sender, recipient, subject, or date range. When you pull up a rejected message, the tracking log shows the rejection reason, the policy that triggered it, and the stage at which the message was stopped. This is your starting point for every bounce investigation.
The rejection reason typically includes an SMTP response code and a short description. Codes in the 4xx range indicate temporary failures (soft bounces), while 5xx codes indicate permanent rejections. Within Mimecast, you will also see internal reason codes that point to specific policies, such as content examination failures, attachment restrictions, or authentication problems. Getting comfortable reading these logs saves enormous time because most bounce issues follow recognizable patterns once you know what to look for.
For organizations with high email volume, Mimecast also offers reporting dashboards that aggregate rejection data over time. These reports can reveal trends you would miss looking at individual messages, like a sudden spike in rejections from a particular partner domain that suggests their mail server changed its configuration.
Authentication Failures That Cause Rejections
A large share of Mimecast rejections trace back to email authentication problems. Three protocols work together here: SPF, DKIM, and DMARC. Each verifies a different aspect of a message’s legitimacy, and Mimecast checks all three on inbound mail.
SPF (Sender Policy Framework) tells receiving servers which IP addresses are authorized to send mail on behalf of a domain. If someone sends you an email claiming to be from example.com but their sending server’s IP is not listed in example.com’s SPF record, Mimecast can reject or quarantine it. The tricky part is that SPF records have a lookup limit of ten DNS queries. Organizations with many third-party services sending on their behalf frequently exceed this limit without realizing it, which causes SPF checks to fail for perfectly legitimate mail. If you are seeing SPF-related rejections from a known sender, ask them to audit their SPF record for lookup overflows.
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to outgoing messages. The receiving server checks this signature against a public key published in DNS. DKIM failures in Mimecast usually mean the sending domain’s DNS has a missing or misconfigured DKIM key, or the message was altered in transit by another email gateway that broke the signature. Forwarded emails are a common culprit because the forwarding server may modify headers or body content, invalidating the original DKIM signature.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together and tells receiving servers what to do when both fail. A domain owner publishes a DMARC policy that says “reject,” “quarantine,” or “none.” When Mimecast receives a message that fails both SPF and DKIM alignment and the sender’s DMARC policy says “reject,” Mimecast will bounce the message. This is the sender’s own policy at work, not something you configured. If a legitimate partner’s mail is being rejected due to their DMARC policy, the fix is on their end. You can temporarily add them to a permitted senders list as a workaround, but the real solution is for them to align their authentication records.
Policy-Based Rejections
Beyond authentication, Mimecast applies a layered set of content and security policies that can reject messages. Understanding which policy triggered a rejection is the key to deciding whether to adjust your configuration or leave it alone.
- Content examination: Mimecast scans message bodies and attachments for malware, phishing links, and other threats. A rejection here usually means the message contained something genuinely dangerous, but false positives happen, especially with password-protected attachments or links to uncommon but legitimate domains.
- Attachment management: Policies can block specific file types outright. If your organization blocks .exe files and a vendor sends a self-extracting archive, it gets rejected. The message tracking log will show the attachment type that triggered the block.
- URL protection: Mimecast rewrites URLs in inbound emails and checks them against threat intelligence feeds. If a URL in a message points to a known phishing domain or a recently registered domain with no reputation, the message can be held or rejected.
- Impersonation protection: This feature looks for emails that appear to come from internal executives or known contacts but originate from external, unauthorized sources. It is designed to catch business email compromise attacks, but it can occasionally flag legitimate external senders whose display names match internal users.
- Spam detection: Messages scoring above a configured spam threshold get rejected or quarantined. Overly aggressive spam settings cause legitimate newsletters and bulk communications to bounce.
Each of these policies is independently configurable. When you identify which policy caused a rejection, you can adjust its sensitivity, add exceptions for specific senders or domains, or move the action from “reject” to “quarantine” so you can review flagged messages before deciding.
Managing Permitted and Blocked Senders
Mimecast gives administrators granular control over which senders are trusted and which are blocked. Permitted sender lists bypass certain security checks for specified email addresses or domains. Blocked sender lists do the opposite, rejecting mail from those addresses regardless of content.
The temptation with permitted senders is to add anyone who gets flagged, but this undermines your security posture. A better approach is to permit senders only at the narrowest scope necessary. If a single address at a partner company keeps getting caught, permit that address rather than the entire domain. And review your permitted sender list periodically. Organizations accumulate entries over months and years as employees request exceptions, and old entries for defunct vendors or former partners create unnecessary gaps in your filtering.
Blocked sender entries are more straightforward but come with their own maintenance burden. If you block a domain that later gets acquired by a legitimate company, mail from that domain will silently disappear until someone notices. Mimecast’s managed sender lists, which are curated by Mimecast’s own threat intelligence team, handle much of this automatically, but your custom entries need occasional review.
Outbound Rejections and Delivery Failures
Most discussions of Mimecast bounces focus on inbound mail, but outbound rejections are equally disruptive and often harder to diagnose because the problem lives on someone else’s infrastructure. When your organization sends mail through Mimecast and the recipient’s server rejects it, the bounce comes back through Mimecast and shows up in your tracking logs.
Common outbound rejection scenarios include your domain being listed on a public blocklist, your SPF record not including Mimecast’s sending IP ranges, or the recipient’s server enforcing strict DMARC checks that your outbound authentication does not pass. If you recently started routing outbound mail through Mimecast, the most common mistake is forgetting to update your SPF record to include Mimecast’s IP ranges. Without that update, every receiving server that checks SPF will see your mail as unauthorized.
Mimecast also enforces outbound content policies. If your organization has a data loss prevention policy configured, emails containing sensitive patterns like credit card numbers or social security numbers can be rejected before they leave. These rejections protect you, but they confuse end users who simply see a bounce notification without understanding that their own company’s policy stopped the message. Clear internal communication about what triggers outbound rejection can reduce support tickets significantly.
Dealing with False Positives
False positives are the most frustrating aspect of any email security platform, and Mimecast is no exception. A legitimate email that gets rejected or quarantined disrupts business and erodes user trust in the system. The goal is not zero false positives, because that would require disabling the security features that catch real threats, but rather keeping them rare enough that users trust the system and report exceptions quickly.
Start by monitoring your held and rejected message queues regularly. Mimecast’s quarantine contains messages that were not delivered but were not permanently rejected either. End users can check their own quarantine through Mimecast’s personal portal or digest emails, but administrators should also review the organizational quarantine for patterns. If a specific sender or content type keeps landing in quarantine, that is a signal to create a targeted exception rather than broadening your policies.
When investigating a false positive, check the message tracking log for the specific rejection reason, then trace it to the policy responsible. Sometimes the fix is a permitted sender entry. Sometimes it is adjusting a policy’s sensitivity threshold. And sometimes the rejection was technically correct because the sender’s authentication was misconfigured, in which case the fix is to contact the sender rather than weaken your own defenses.
One pattern worth watching for is forwarded email chains. When an external contact forwards a message originally sent by a third party, the authentication chain often breaks. The original sender’s DKIM signature may not survive the forward, and the SPF check now evaluates the forwarder’s server rather than the original sender’s. DMARC alignment fails, and Mimecast rejects the message. This is technically correct behavior, but it frustrates users who just want to receive the forwarded content. Educating frequent external collaborators about this limitation, or using Mimecast’s ability to treat certain forwarding services as trusted, can help.
Keeping Your Own Domain’s Reputation Healthy
Mimecast’s effectiveness on the outbound side depends partly on your domain’s sending reputation. If your domain ends up on public blocklists, recipients outside your organization will reject your mail regardless of what Mimecast does. Reputation damage typically comes from compromised accounts sending spam, poorly managed marketing lists with high bounce rates, or misconfigured applications that send large volumes of automated mail without proper authentication.
Mimecast provides outbound sending limits and anomaly detection to catch compromised accounts before they do serious damage. If an account suddenly starts sending hundreds of messages per hour, Mimecast can throttle or block that account’s outbound mail. Make sure these limits are configured appropriately for your organization’s normal sending patterns.
For marketing and bulk email, the best practice is to use a separate subdomain with its own authentication records rather than sending through your primary domain. This isolates your transactional and interpersonal email reputation from the higher bounce rates that bulk sending inevitably produces. Mimecast can route different types of outbound mail through different policies, making this separation straightforward to implement.
DNS Configuration Mistakes That Create Persistent Bounces
Many stubborn Mimecast bounce problems trace back to DNS rather than to Mimecast’s own policies. Your MX records must point to Mimecast’s servers if you want inbound mail to route through the platform. If an MX record is misconfigured, some sending servers may bypass Mimecast entirely and try to deliver directly to your mail server, which may reject the connection because it expects traffic only from Mimecast’s IP ranges.
Similarly, if you use Mimecast for outbound mail, your SPF record must include Mimecast’s sending infrastructure. An SPF record that lists your on-premises mail server but not Mimecast will cause authentication failures at every recipient that checks SPF. DKIM signing through Mimecast requires publishing the correct DKIM public key in your DNS, and DMARC records need to reflect your actual mail flow, not the flow you had before deploying Mimecast.
DNS changes propagate on their own schedule, and TTL (time to live) values determine how long old records persist in caches worldwide. After making a DNS change to fix a bounce issue, allow at least 24 to 48 hours before concluding the fix did not work. Testing tools that query DNS directly rather than relying on cached results can give you faster confirmation, and Mimecast’s own DNS checking tools within the admin console can validate your records against their expected configuration.
When to Escalate to Mimecast Support
Some bounce and rejection issues are not solvable through policy adjustments or DNS fixes alone. If you see rejections with internal error codes that do not map to any of your configured policies, or if message tracking shows a message was accepted by Mimecast but never delivered to your mail server, the problem may be on Mimecast’s infrastructure side. Service outages, routing issues between Mimecast data centers, and bugs in policy evaluation all happen occasionally.
Before contacting support, gather the specific message IDs from tracking, the exact rejection codes, and timestamps. Mimecast’s support team can trace a message through their internal systems far more efficiently when you provide this data upfront. Also check Mimecast’s status page for any ongoing incidents that might explain the behavior. A surprising number of “mysterious” bounce problems resolve themselves when a platform-side issue is fixed, and knowing an incident is in progress saves you from chasing configuration ghosts.