Freigeben über

Mail relay, gateways SMTP and Exchange Online

  • Artikel

Almost every customer at FastTrack Center ask what to do with applications that send e-mail after moving to Exchange Online. Most of the apps use e-mail for internal and/or external notification mail. So... what to do with them?

 

My four rules for mail relay

Please take into consideration I am not talking about massive systems that rely on e-mail for customer notification, such as Amazon does. That's a whole other story, ok? I am solely discussing the way internal applications use SMTP gateways to get the job done.

We want to ensure all our users can communicate with their peers, customers, suppliers, friends, family... To do that, we must make sure the antispam receiving our users' e-mails treat them with the same carefulness we do.

 

1 - Use a dedicated SMTP gateway for mail relay

The thing is that most of the antispam around use a least effort principle. In a way that they do not waste time with spammers. So, they try to block the maximum of the spammers right at the door, refusing their connection. We keep tabs on how much messages an SMTP gateway sends, if they are on known spammers lists... In short, we consider the sender (the machine, not the person) reputation when evaluating if that is a spam.

What happens if out of a sudden a rather idle SMTP gateway decides to send a thousand e-mails? It should lift some eyebrows, because that is not its regular behavior. And that counts against its reputation, imposing a penalty for every e-mail coming out of that gateway. Including the e-mails from your dearest users.

If you want to keep things separate and reduce the risk for your users' e-mails, keep a dedicated SMTP gateway for your applications. That way we will not mix things up when receiving your e-mails, increasing the chance your users' emails arrive correctly to their recipients.

In addition to all the reasons before, I believe it would easier for you to configure your apps and troubleshoot mail flow issues if you have an SMTP gateway in place. Having a single place to check for logs and queues can be handy. And eventual futures changes can be easier as well. Imagine not having to configure apps every time you make a change in your infrastructure.

 

2 - Dedicate an SMTP domain for your applications

The same way we evaluate the gateway reputation, we do consider the reputation of the sender domain.

Have you ever signed up for one of our mailing lists? Such as TechNet, MSDN... the sender address is something@email.microsoft.com. I never asked why, but there must be a reason for those smart guys not to use a sender address @microsoft.com.

You can choose to use a completely different domain or a subdomain for your applications. It does not matter for the issue in focus here: Go for the solution that makes more sense for your business.

 

3 - Use a valid sender address

Imagine you get a message from an invalid address. Should you trust that source? Now imagine that invalid address is an SMTP address one of my apps is using. It goes like this:

  • MyApp send an e-mail from the address invalid@contoso.com
  • The antispam receiving that e-mail gets wary and decides to check
  • The antispam pretends it will send an e-mail to invalid@contoso.com
  • The antispam gets a response stating that invalid@contoso.com does not exist
  • The antispam drops the e-mail from MyApp and put a black mark on my domain and SMTP gateway tabs

I can't blame the antispam for its actions. I would have done the same if some bogus, untrusted, sender tried to fill my inbox.

 

4 - Get your SPF right

That's an easy one and it is documented here. You should be crystal clear about who can and who cannot send messages in your company name.

The best thing you can do is to state who can send messages with your company domain as sender and hard-fail anyone that is not explicitly on the list. Just don’t do that without testing first.

Since we are talking about preventing people from impersonating your company, you might want to consider DKIM and DMARC as well.

 

How does that apply to Exchange Online?

First, Exchange Online is a service you procure for your users. Not your apps. It can be used for mail relay, but that is not the intention.

There are several limitations imposed for mail relay in Exchange Online as documented here. The documented limitations themselves might be enough for any company to consider not using Exchange Online as a SMTP gateway. Additionally, Exchange Online Protection will protect it users. It can take measures to prevent mass mailing and suspicious e-mail from compromising the service availability.

 

Dedicated SMTP gateway

Your dedicated SMTP gateway should be able to send e-mails to Exchange Online. No complex configuration is required: You can simply white list its public IP address in Exchange Online.

 

Dedicated SMTP domain

You verify additional domains to Office 365 and use them for your applications. It can be as inexpensive as adding a subdomain and configuring your applications.

 

Valid sender address

You can create dedicated mailboxes in Exchange Online to handle the messages they receive. You can also decide to discard the messages and notify the senders (or silently delete them). Depending you your objectives, you can leverage shared mailboxes for that purpose.

 

SPF record

You can use an SPF record allowing only the SMTP gateway to send messages from your dedicated domain. That would exclude Exchange Online from the list as well, since you probably don't expect sending mail from application through Exchange Online.

 

If your scenario is different from what I have here or if you want to say hello, please leave me a comment. I would be glad learn your thoughts!