Office365 SMTP setup

  • 2 February 2016
  • 26 replies

Has anyone had success using Office 365 for SMTP with Looker?

I get this error when attempting to send a test email:

Failed to send mail: 504 5.7.4 Unrecognized authentication type

I’m selected the check box for SSL/TLS. I did note that the setting I’ve had to use with another tool is START TLS. I’m not clear on whether that variant should be handled by the SSL/TLS option.


Best answer by ryan.dunlavy 11 November 2020, 20:29

Hey all!


Starting in Looker 7.20 out later this month, Looker will support the PLAIN SMTP authentication protocol, which means that the recommended authentication config for Office365 will now work when setting up office365 as your custom SMTP server.


The caveats Ani mentioned above still apply for MFA and the Microsoft Security Defaults.

View original

26 replies

Did you ever get this answered and working? I’m looking to do the same thing.

Nope. I haven’t tried since, but the options don’t look like they’ve changed much. We’ve been using the default email settings, which are less of an issue now that we’ve had our IT team add the address (and potentially some IPs, I don’t remember) to our global whitelist in 365.

Userlevel 4

Hey @jyau and @srivera,

This is a known issue that our engineering team is working on. There are some workarounds you may be interested in; on this Microsoft article we have had success with options 2 and 3. For option 3, I recommend following these instructions (you’ll need to be an admin on your Office365 account):

  1. Once logged into Office 365, click the Admin app

  2. From the navbar on the left scroll down to ADMIN, then click Exchange.

  3. From the navbar on the left click Mail Flow

  4. Click the Connector tab (on the right)

  5. Click the plus button

  6. In the “From:” field select “Your organization’s email server”, in “To:” select “Office 365”. Click Next

  7. Enter a name and a description. These can be anything you like. Make sure “Turn it on” and “Retain internal Exchange email headers” are checked. Click Next.

  8. For “How should Office 365 identify email from your email server?” select the “By verifying that the IP address of the sending server matches one of these addresses that belong to your organization”.

  9. Click the plus button and enter the IP address or range that Looker will be sending email from. Click Next.

  10. Click Save.

For step 9, if you are hosted by Looker you can find the range of IP addresses that we use on this page.

Once you’ve gone through the instructions above to set things up in Office 365 the next step is to set up Looker’s SMTP page. You’ll want to use custom SMTP and the only thing to note is that you leave the username and password blank.

Userlevel 6


has this been resolved yet? Our security team are not keen for this work around.

Hey @IanT,

This is on our engineering team’s radar. If you’d like to provide further details of your use case or security team’s concerns feel free to visit with those details!

Userlevel 6

Hi, I know/understand very little about this however security told me this:

“whitelisting some outside servers we have no idea how well they are managed to peer into our email tenant is not a great security practice”.

We will probably end up using the default server settings until TLS is implemented.


Hey @IanT,

Thanks for providing those details! I’ve passed them along to the team.

Userlevel 6


Has there been any movement on this?


Any update on the internal discussion around improving this? Thanks.

Hi @balduncle,

The engineering team is still working on this. At the moment there isn’t a timeline for improvements but if you have any further context on your use case to provide please send that along to so we can add that to the discussion!

Userlevel 6

Just following this up, we will want to move to you guys hosting our instance but would really like our scheduled mails to come from ourselves so this (along with a handful of other considerations) is a blocker.

Userlevel 7

There hasn’t been any movement on this, but I’m looking for some more visibility. Your little looker-hosted carrot dangle might be enough to open some eyes 😄

Just checking in on the status of this internal discussion. Our security team will only allow username/password authentication for SMTP, so this is currently blocking any use of email within the application.

The main concern is that with a connector setup our O365 environment would be exposed to IP spoofing, potentially allowing an attacker to send what would appear to be authenticated email from our domain.

Userlevel 7

Thanks for checking in— This has historically not been prioritized very highly, but we have just recently rolled out some new internal prioritization guidelines. I’m taking this one back to the triage step and will report back with some honest info what our next steps will be on it.

Thanks for the transparency @izzy

To add more context, while this is a security issue at it’s core, there are downstream effects that are just as significant that have nothing to do with security, but more with the efficacy of the product for us as a business.

This is critical for us because it means we have to disable email until we can use username/password auth for SMTP, meaning that scheduled runs and delivery of Looks via email isn’t possible and users have to download data first in order to share it.

Both of those contribute to a poor UX, and I fear will make it more difficult for our business users to buy-in to and be excited about using Looker.

Not being able to use the scheduling and delivery via email capabilities just adds manual busy work that could otherwise be automated.

Userlevel 7

Thanks for the detailed context, Cole.

This is definitely not the experience we want to create for your team. Passing this onwards, as I mentioned, and I’ll be looping back here with what I find out.

Sure thing @izzy, and thanks for following up on this for us.

Userlevel 7

Checking back in: We haven’t yet fully scoped this out in terms of priority, but are going to explore it as maybe fitting into some general improvements to our email infrastructure that we’ll be doing soon. I’ll keep you posted, and you can also feel free to reach out to support to check back in anytime as well.

Thanks for checking back in @izzy. Please do keep us in the loop.

@IanT I don’t suppose your team has found or implemented another way to work around this for the time being?

Userlevel 6

no we just use default settings (lookers server) for our PBL instances but over the next 6 months we are looking at migrating from self hosted on our main instance…and this is going to be important to us to be resolved before then (along with some other blockers for us such as a few small on prem databases and github access!)

Userlevel 6

@izzy is there any news on this getting prioritized as we are looking at migrating to you hosting us and although its a bit silly it would annoy all of our users and look less professional for all our mails to be coming from someone else (looker mail server).

Hi everyone! I’m Ani, a Product Manager at Looker. 👋 Wanted to share a quick update - we’ve gotten a few requests around email and we’re taking a comprehensive look at this during our ongoing planning sessions. We don’t have a formal prioritization or timeline around this quite yet, but hoping to have an update soon. Thanks everyone for your patience and feedback here!

Userlevel 6

Hi @ani do you have an update around this? - we would really like to use our own smtp server in a secure way.



Userlevel 6

Any news?


Hi everyone, sorry for the delay on this. We’ve been troubleshooting more and now have a supportability checklist from Microsoft. A couple of things to verify that we found were blocking some customers:

  • Do you have an Office 365 subscription with Exchange Online? (Required)

  • Is your environment using Microsoft Security Defaults? (Not compatible)

  • Do you have multi-factor authentication (MFA) enabled? (Not compatible)

  • Is SMTP AUTH enabled for your Exchange Online organization, or the specific mailbox being used? More info here (Required)

In some cases, the main SMTP AUTH option is not possible due to other Microsoft settings, and they recommend using the direct send or SMTP relay workarounds. More information is outlined here.

This option is not compatible with Microsoft Security Defaults or multi-factor authentication (MFA). If your environment uses Microsoft Security Defaults or MFA, we recommend using Option 2 or 3 below. You must also verify that SMTP AUTH is enabled for the mailbox being used.