Send Mail (SMTP) through Office 365 with MFA

Iron Contributor

We have a web server that needs to be able to send emails as users (FROM field); however, we have noticed that if the user account is protected with MFA, the message is rejected.  Has anyone been able to get this working? I found a work around by using an account that does not have MFA then adding that account as a delegate of the sending user, but that seems a bit extensive. 


In our scenario, web server sends a message showing it comes from a sales rep, that is populated dynamically on the web server. It uses CFMAIL (same rules as say PHPMailer) and uses the FROM field as the sales rep. That is handled off in this case to Office365 to send emails. 


Actual Error:  Diagnostic-Code: smtp;550 5.7.60 SMTP; Client does not have permissions to send as this sender



16 Replies
MFA has got nothing to do with this. Have you tried sending the email as anonymous (no login in the sending client) and configuring connectors in Exchange to support direct send to Exchange Online? This is covered in Option 2 or 3 under

When using Option 1, MFA has everything to do with it. Option 1 requires authentication to work and I have since been able to confirm from Microsoft that Option 1 will not work when MFA is enabled. 

Option 2 will not work in our environment, as the emails generated will often be sent externally. Option 2 (Direct Send) will only send to internal O365 recipients. 


Option 3 is still in question. We already have send connectors in-place due to our hybrid configuration. Still waiting on a response from Microsoft if we can modify these settings to all relay but without causing issues with our Hybrid.  We will eventually move away from this and our internal mail server which is why we are not deploying new services that point to our internal mail server. 


When I said that MFA has nothing to do with this, I mean this specific error. The error "Diagnostic-Code: smtp;550 5.7.60 SMTP; Client does not have permissions to send as this sender" means that the account you are logging in with does not have permission to send as the From address you are specifying.

Therefore for #1 you would need to login with the actual From address and not another account, but then MFA would impact you. This is why I did not suggest you try Option #1 and only either #2 or #3.

For either of these, it does not matter if the recipient is internal or external. This is regardless what it says in the support article under Direct Send about it being for internal mailboxes only (see the other scenarios text where it talks about using Direct Send for mailing lists - which are external by their nature).

As for #3, you realise when you say "We will eventually move away from this and our internal mail server which is why we are not deploying new services that point to our internal mail server. " that with hybrid you will never move away from this scenario. With hybrid you need to maintain an on-premises Exchange Server for cloud mailbox management as you are doing AD Sync. Given that you have an on-premises server, you would use that as your apps and devices SMTP relay device as well. Microsoft have said they are working on improving the management experience with hybrid at Ignite last year, but that does not cover the need for SMTP relay scenarios like you describe.

The reason I mention we are moving away from the Hybrid solution is that we are moving away from having everything on-premise and to AzureAD and Azure VMs. Our current setup does point to our on-premise Exchange server; however, we plan to phase that out as we consolidate solutions, move to Azure VM and migrate to Office 365 SharePoint.   The goal is to be moved off of our on-premise servers by end of the year, which is why I do not want to point any new projects to our On-premise Exchange server.  The do not plan on maintaining an on-premise AD, which is the only reason to keep running in a Hybrid scenario. 


The error message I originally included was when I was assigning the non-MFA account to our SMTP configuration and sending using an MFA account. Since Option 1 does not work with MFA accounts, that is where I am running into an issue. 

Yes, which is why I said options 2 or 3, and both will work for you even if your Exchange hybrid role server is in Azure.

By the way, if they don't plan on maintaining an on-premises AD, what are the users going to login to? Unless you are going cloud accounts completely and turning off AD, you still need local domain controllers to the users for efficient login.

Per Microsoft's article that I originally included, Option 2 will not work for sending emails to external users (,, etc.)  


As far as what users will be logging into; Azure AD. 


If you have an Azure AD app registration with permissions to send mail on behalf of a user, you can get an access token for that user and use it for such purposes.  The token is acquired during an interactive login, so MFA is supported, and then you can use that token to send email via the Office 365 REST API (and to a lesser extent, Microsoft Graph).  We have solutions that do this in exactly this scenario and work fine with MFA secured accounts.

Option 2 will work externally. You need to make sure your certificates for the connector contain your domain, or it will be treated as external email relaying. Option 3 is better. Option 2 is not there for allow mass marketing emails. But will work for a lower number of emails.

@Jeff Harlow , did you solve the issue? I am facing exactly the same problem here - the send-mailmessage was working at before enabling 2FA and after that I receive the same message you mentioned with no other changes. I also tried to use application specific password without success.  

We are using Option 3 now. Just configured the connector to allow the IPs for servers (in our case our external IP) to send mail and all works. No authentication required. @Kazu1301 

@Jeff Harlow thanks for your quick answer. I will consider the solution 3. The error message is very misleading. If the implementation of 2FA was not the only change made, I would misunderstand it and check other possibilities. Anyway, thanks a lot! 

@Jeff Harlow 



You can still use Option one .. all what you have to do is generate an app password to by pass MFA.


Follow the steps in the below article ..




Robin Nishad

Hi @Robin Nishad, it was the first thing I tried. In the same way I do with Outlook, I generated the app password and tried it with no success. I am creating a SecureString file (encrypted pwd file) and generating a PSCredential Object from it for authentication using Powershell, as follows (I hope the variables are self explanatory):  


$SecureStringPassword = Get-Content -Path $EncryptedPasswordFile | ConvertTo-SecureString

$EmailCredential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $SMTPUsername,$SecureStringPassword


Send-MailMessage -From $MailFrom -To $MailTo -Subject $MailSubject -Body $MailBody -Port $SMTPPort -Credential $EmailCredential -Attachments $Attachment


This approach works very well without 2FA, but not with app password. Do you see any mistake here or any changes that may work?





@Jeff Harlow someone answered below, not sure why that took so long. The easy answer is that you generate and then use an app password for that account, instead of the regular user password.  That in effect serves as the second authentication method for the dual authentication.   However...

We too use SMTP to send email from various robots, web sites, and marketing systems.  What I have done to reduce the complexity somewhere (perhaps?), is to adopt a third party mailing system with complete DKIM/DMARC/SPF records in place for this third party sender.  This really does eliminate so much of the hassle with using an Office 365 SMTP account to send email.  I really think that the app password is kind of hack, it's just another password that can be cracked!  We are using Mailjet. 

@Jeff Harlow 
Now in February 2020 they have published  this kind of documentation...  XOAUTH2 method?

@Jeff Harlow I was struggling with that too. Finally I found a solution which requires to change properties in Azure Active Directory (Properties > Manage Security Defaults). You have to turn off "Enable Security defaults" like at the linked screenshot from the documentation.


The starting point to find that solution was Microsoft 365 Admin Center > Settings > Org settings > Services > Modern authentication. The link to the above mentioned documentation is provided in description of Modern authentication.


Now I'm able to send emails by SMTP protocol with using an app password from MFA enabled account.