Forum Discussion
Jeff Harlow
Feb 23, 2018Iron Contributor
Send Mail (SMTP) through Office 365 with MFA
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
- Szymon_B_InfoSenseCopper Contributor
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.
- eino_makitaloCopper Contributor
Jeff Harlow
Now in February 2020 they have published this kind of documentation... XOAUTH2 method? - Jim HillBrass Contributor
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.
- Rnishat0786Iron Contributor
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 ..
Thanks
Robin Nishad
- Kazu1301Copper Contributor
Hi Rnishat0786, 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?
Regards
Kazu
- Steve PeschkaCopper Contributor
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.
- 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 https://support.office.com/en-gb/article/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-office-365-69f58e99-c550-4274-ad18-c805d654b4c4
- Jeff HarlowIron Contributor
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.