Mimecast accepted domains configured but brand-new subdomain mail is rejected

Minimal guidance for messy support realities.

Issue Summary

This article covers a Mimecast email-security issue where Mimecast accepted domains configured but brand-new subdomain mail is rejected. Use the path below to confirm scope, separate mail-flow from policy and identity causes, and move from safe user checks into deeper administrative remediation without weakening protection broadly.

Symptoms and Scope

  • The reported problem matches the article title: Mimecast accepted domains configured but brand-new subdomain mail is rejected.
  • At least one message, sender, recipient, or policy event can be identified and reproduced or traced.
  • A comparison with one known-good message path, user, or mailbox helps show what is failing and what still works.

Tier I: Basic Checks

  1. Confirm the exact impact: who is affected, whether the issue is inbound, outbound, quarantine, portal, or policy related, and whether there is a safe workaround.
  2. Capture the sender, recipient, approximate timestamp, subject, and any user-facing error or notification before changing policy.
  3. Check the obvious path first: user quarantine, digest behavior, portal access, and whether the message can be found in the vendor trace or event view.
  4. Compare the failing message or workflow against one known-good example so you know whether the problem is isolated or systemic.

Tier II: Admin Investigation

  1. Review Mimecast policy hits, message trace, identity or directory sync state, and any recent administrative changes tied to the affected workflow.
  2. Determine whether the issue is caused by rule order, quarantine behavior, SSO or identity mapping, downstream Microsoft 365 handling, or integration timing.
  3. Test the narrowest safe policy or routing change first and verify whether the result survives a fresh delivery, release, reauthentication, or retry.
  4. Document the exact event, log evidence, and policy path so other technicians do not have to infer what actually happened.

Tier III: Advanced Remediation

  1. Move to advanced remediation only after lower-tier checks are documented and reversible.
  2. If multiple security layers are involved, validate the full control chain across Mimecast, Microsoft 365 or Google Workspace, and any downstream relay, DLP, or SIEM integration.
  3. Rebuild or re-authorize sync, connector, SSO, API, or routing components only when the evidence points there and the rollback path is clear.
  4. Validate the final state from both the end-user view and the administrator view so the fix is operationally real and not just cosmetically improved.

Escalation Guidance

  • Escalate when the issue affects multiple users, critical mail flow, executive or finance workflows, or security actions that cannot be safely bypassed.
  • Include sender, recipient, timestamps, message identifiers, policy names, screenshots, and the exact Tier I / Tier II / Tier III checks already completed.
  • State clearly whether the current blocker is policy logic, mail routing, identity, quarantine behavior, or vendor-side processing so the next technician can pick up cleanly.

Prevention and Documentation

  • Document the confirmed root cause, stable fix, and any allow, bypass, or exception rule added so future reviews can keep scope tight.
  • Update onboarding, mail-flow diagrams, or security runbooks if the issue exposed weak ownership or unclear routing between products.
  • Where possible, add validation, reporting, or alerting that would surface the same condition before users discover it first.