553 you are trying to use me as a relay

[StevenAhmet]

Hi,

We have all inbound mail being routed through MessageLabs, then to our Office365 tenant.

All email is being delivered OK except for a specific circumstance.

Our domain is contoso.com.au.

If I create a DL, [e-mail] that has an external contact in it, [e-mail].

If I send an email to that DL from my internal contoso address, it gets delivred OK.

If I send an email from an external address, eg from [e-mail] to [e-mail];

• The email goes through MessageLabs
• Then goes to Office365. Office365 sees that it needs to go back out to deliver to that external address.
• Gets to MessageLabs, and MessageLabs returns "550 5.0.350 Remote server returned an error -> 553 you are trying to use me [server-17.tower-423.messagelab;s.com] as a relay, but I have not been configured to let you [104.47.116.56, mail-me1aus01lp2056.outbound.protection.outlook.com] do this. Please visit www.symanteccloud.com/troubleshooting for more details;about this error message and instructions to resolve;this issue. (#5.7.1)".

Within MessageLabs, we have configured the Office 365 hosted mail service in our outbound routes, so not sure what the problem is.

 

I've got cases open with both Microsoft and Symantec, but not getting very far.

Does anyone have any experience with this?

Thanks.

[StevenAhmet]

I've worked out this issue.

We recently changed our inbound routing to go from;

MessageLabs -> OnPrem Exchange 2010 -> back out to MessageLabs (if required)

to

MessageLabs -> Office365 -> back out to MessageLabs (if required)

 

Exchange 2010 was doing a rewrite of the message header, specifically the Return-Path, to be the email address of the distribution list. As this was an internal email address, MessageLabs would relay it succesfully.

Office 365 does not rewrite the message header, so the Return-Path is the external email sender. MessageLabs rejects the relay for that external domain from that email address (as you would expect).

 

The fix at the moment for us, is to do the following;

• Set a "Manager" for the Distribution Group to be an internal user.
• Run the following Exchange PowerShell command (we did ours on our onPrem Exchange server as we are in a Hybrid configuration)
  • Set-DistributionGroup "fstestdl" -ReportToManagerEnabled:$true -ReportToOriginatorEnabled:$false

Once that change was synced to Azure/EOL, any email to that DL had the Return-Path set to the manager's email address (which is internal) and MessageLabs now routes it correctly.

[Francis Hagyard]

Literally logged in just to say thank you for posting your solution to this! Had the exact same setup and issues as described in your original post, you've saved me many hours of painful troubleshooting so kudos to you! Well done on not being like 99% of people online, who usually say little more than 'nvm fixed' with no further information.