Skip to content
SendPoint / Education
B2B security gateways

Mimecast greylisting and rejections

Read temporary deferrals and route persistent failures to the correct owner.

SendPoint referenceUpdated 2 min read

Recognize greylisting

Mimecast greylisting can temporarily defer a previously unseen combination of connecting IP, envelope sender and recipient. The sending MTA must retry through its normal queue. Mimecast’s policy documentation describes a retry window, but other controls and customer policies can still determine the final result.

Investigate a retry failure

  1. Preserve the full 451 response and the initial connection timestamp.
  2. Check the sending service’s queue logs for a real retry, rather than a fresh campaign submission.
  3. Compare the connecting IP and envelope identities across attempts. Ask the ESP whether retries preserve the relevant sending route.
  4. If the recipient administrator sees Sender Failed to Retry, compare that event with the sender’s retry logs before changing policy.

Separate other rejection causes

Response evidenceNext action
Temporary deferralReview scheduled retries and elapsed time.
Named DNSBL or IP reputation rejectionIdentify the named list and investigate the actual connecting IP.
Recipient or policy restrictionAsk the authorized recipient administrator to inspect the rejection log.
Message accepted then quarantinedUse the recipient-side message evidence and policy result.

Escalate with a complete timeline

SendPoint recommendation: submit the first attempt, subsequent attempts, response text and queue ID together. Explain whether the message expired, was accepted or remains queued. This prevents a greylisting observation from being mistaken for a permanent block.

Sources