Mimecast with Exchange Server: 451 Open relay not allowed, connectors and rejection codes

With Mimecast in front of Exchange, inbound mail arrives from Mimecast's data centers and outbound mail leaves through Mimecast's smart hosts. When something breaks, Mimecast's SMTP reply usually names the problem, and most replies lead back to a handful of settings: authorized outbound addresses, SMTP authentication, TLS, recipient validation and anti-spoofing. In this post I'll configure both directions on Exchange Server SE and 2019 (2016 is identical), decode the Mimecast replies Exchange admins actually meet, and show how to prove each fix.

Symptoms#

• Outbound mail piles up in the smart host queue, and Get-Queue shows Mimecast's reply in LastError. Mimecast's error code article words it 451 An open relay is not allowed; admins also report the live reply as 451 Open relay not allowed followed by a link to Mimecast's documentation. Because it's a 4xx reply, Exchange keeps retrying until the message expires, after two days by default.
• After switching to SMTP authentication, sessions fail with 535 Incorrect authentication data or 550 Submitter failed to authenticate.
• Outbound mail is refused with 553 This route requires encryption (TLS) or 553 This route requires TLS version 1.2 or greater.
• External senders get 550 Invalid Recipient for addresses that exist, a scanner or SaaS app sending as your domain gets 550 Anti-Spoofing policy - Inbound not allowed, or a message bounces with 554 Mail loop detected.

Why it happens#

Mimecast only relays outbound mail it can tie to your account: the connection must come from an Authorized Outbound IP address or authenticate. Anything else looks like an attempt to use Mimecast as an open relay. Mimecast's error guide also notes that an IP address that keeps making invalid connections is put on a temporary block list, so a misconfigured server can delay mail for longer than the fix takes.

The other replies come from Mimecast policies. Authentication on port 587 must use an internal address with a Mimecast cloud password. Secure Receipt and Secure Delivery policies can require TLS and a minimum TLS version. Recipient validation (known recipients, LDAP or SMTP call forwarding) rejects addresses it can't match. Anti-spoofing policies reject inbound mail that claims to come from your own domain, and a message with 25 Received headers is rejected as a loop.

How to fix it#

1. Send outbound mail to your region's smart hosts#

Mimecast lists two outbound smart hosts per region, for example eu-smtp-outbound-1.mimecast.com and eu-smtp-outbound-2.mimecast.com for Europe (excluding Germany), or the us-smtp-outbound- pair for the United States. Put both on one connector so Exchange spreads the load and can fail over:

New-SendConnector -Name "Outbound via Mimecast" -Internet -AddressSpaces "*" -DNSRoutingEnabled $false `
    -SmartHosts "eu-smtp-outbound-1.mimecast.com","eu-smtp-outbound-2.mimecast.com" -SourceTransportServers EX01,EX02
Get-SendConnector | Format-Table Name, Enabled, AddressSpaces, SmartHosts -AutoSize
Set-SendConnector "Internet" -Enabled $false   # the connector you used before Mimecast

Disable the previous internet connector, but leave connectors that serve other purposes, such as archiving or journaling, alone.

2. Authorize the server by IP, or authenticate#

Find the public IP address each source server's SMTP traffic leaves from: your firewall's NAT rule, not the server's own address. It must be on your account's Authorized Outbound list, and Mimecast's guidance is to contact Mimecast Support to add it. Do this before a NAT change, a new data center or a new Exchange server goes live.

Without a static public IP, authenticate instead. Mimecast requires authentication on port 587, using an internal address that has a Mimecast cloud password:

Set-SendConnector "Outbound via Mimecast" -Port 587 -SmartHostAuthMechanism BasicAuthRequireTLS `
    -AuthenticationCredential (Get-Credential smtp-relay@contoso.com)

If you then see 535 or 550 Submitter failed to authenticate, the address or its cloud password doesn't match what Mimecast holds.

3. Let Mimecast in, and only Mimecast#

Take your region's IP ranges from Mimecast's Data Centers & URLs page. Inbound, Mimecast hands mail to the host set in your Delivery Routing policy, so point that at your Exchange servers or their load balancer. Allow SMTP between Exchange and those ranges (outbound on port 25, or 587 if you authenticate; inbound on 25 for delivery), and scope a receive connector to them:

New-ReceiveConnector -Name "Inbound from Mimecast" -Server EX01 -TransportRole FrontendTransport -Custom `
    -Bindings 0.0.0.0:25 -RemoteIPRanges 192.0.2.0/24,203.0.113.0/24 -PermissionGroups AnonymousUsers
Test-NetConnection eu-smtp-outbound-1.mimecast.com -Port 25

The ranges are placeholders. Keep the connector anonymous rather than externally secured, and make sure its certificate is valid in case your Mimecast setup requires TLS when delivering to you. Both 553 replies mean Mimecast didn't get the TLS session its policy requires: don't set IgnoreSTARTTLS on the send connector, and keep TLS 1.2 enabled on the server (see TLS hardening on Exchange Server).

4. Fix recipient validation, spoofing and loops#

• 550 Invalid Recipient for a real address: with LDAP validation, check that aliases, groups and contacts are included. With SMTP call forwarding, Exchange gives the answer, so confirm the address with Get-Recipient; and remember call forwarding only filters anything if Exchange rejects unknown recipients during the SMTP session. Mimecast's knowledge base covers enabling Exchange recipient filtering for this, but Microsoft says not to configure the Recipient Filter agent on Mailbox servers (see the FortiMail guide), so LDAP validation is the safer choice.
• 550 Anti-Spoofing policy - Inbound not allowed: something outside Exchange is sending as your domain straight to Mimecast's inbound servers. Route on-premises devices through an Exchange relay connector so they leave through the authorized path; for a cloud service, ask for an anti-spoofing policy exception scoped to its IP addresses.
• 554 Mail loop detected: check that every domain Mimecast delivers to Exchange is an accepted domain, and look for forwarding or mail contacts that point back to an address Mimecast delivers to Exchange; see finding and fixing Exchange mail loops.

One reply is normal: 452 Too many recipients means Mimecast takes 100 recipients per message transaction, and Exchange retries the rest. Mimecast advises disabling SMTP fix-up or ESMTP inspection on firewalls in the path (it names Cisco PIX and ASA), because those features don't respect such transient replies.

Verify the fix#

Get-Queue | Where-Object DeliveryType -eq SmartHostConnectorDelivery | Format-List Identity, Status, MessageCount, LastError
Retry-Queue -Filter "Status -eq 'Retry'" -Server EX01
Get-TransportService | Get-MessageTrackingLog -Start (Get-Date).AddMinutes(-30) -EventId SEND |
    Where-Object ConnectorId -like "*Mimecast*" | Format-Table Timestamp, Recipients, RecipientStatus -AutoSize

Good looks like this: the smart host queue drains with an empty LastError, and SEND events through "Outbound via Mimecast" show a 250 reply. In the Mimecast Administration Console the test appears under Message Center › Accepted Messages; refused and deferred connections are listed in the Message Center's rejected and deferred views instead. Inbound, a test from an external mailbox should produce a RECEIVE event through "Inbound from Mimecast".

Prevent it next time#

• Put the Authorized Outbound list under change control: a new public IP for mail must be authorized before traffic moves.
• Keep Exchange's accepted domains, Mimecast's internal domains and recipient validation in step.
• Alert on the smart host queue; a growing queue with a 451 LastError is your early warning.
• Look up other gateway replies in the gateway rejection codes quick reference. Journaling to the Mimecast archive is covered in journaling Exchange Server mail to a third-party archive.

References#

• Mimecast SMTP Error Codes (Mimecast Knowledge Base)
• Exchange SMTP Connector for Microsoft Exchange 2019 / 2016 (Mimecast Knowledge Base)
• Create a Send connector to route outbound mail through a smart host (Microsoft Learn)