Understanding mail relay options with Office 365

One of the most commonly misunderstood aspects of an Office 365 rollout is what to do with scanners and other applications that need to relay mail. Microsoft publishes documentation on this but in my experience many who are unfamiliar with SMTP flow quickly get in over their heads.

I generally recommend relaying via the MX record for all applications unless your source can't support it. This has several advantages:

• it can be configured to support both internal and external recipients
• it doesn't require a mailbox license
• it has the least requirements for authentication

Note that you always have to send as an accepted domain in Exchange to make this work.

I've seen an uptick in support requests with a new SMTP error code in Office 365:

451 4.4.62 Mail sent to the wrong Office 365 region. ATTR35.

It seems that Microsoft (somewhat quitely) began enforcing MX record external relay authentication. If you're relaying directly to your record as @domain.com to an EXTERNAL recipient, say @domain2.com, then you must create a connector to let Office 365 know this is an authenticated source. You don't have to have a certificate or user for this method, only a specific IP address.

I've also seen customers do a DNS lookup for their MX record until they get an IP address, and then use that IP address for legacy equipment that doesn't support a hostname (i.e. AS/400). Do not do this. Microsoft rotates IPs and it's never a sure bet that an IP in use at any given moment will always work. If you need to relay to an IP address, you should create an internal relay that DOES support a DNS-based hostname - Exchange Hybrid, IIS, or Postfix, for example - and relay to that.

Source:
https://support.microsoft.com/en-us/help/4057301/attr35-response-code-when-mail-is-sent-to-eop-exo