02-23-2018 10:32 AM
02-23-2018 10:32 AM
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
02-26-2018 10:00 PM
02-27-2018 06:19 AM
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.
02-28-2018 04:54 AM
02-28-2018 07:27 AM
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.
02-28-2018 09:18 AM
02-28-2018 11:22 AM
Per Microsoft's article that I originally included, Option 2 will not work for sending emails to external users (live.com, gmail.com, etc.)
As far as what users will be logging into; Azure AD.
03-01-2018 03:29 PM
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.
03-02-2018 06:41 AM
08-14-2019 10:41 AM
@Jeff Harlow , did you solve the issue? I am facing exactly the same problem here - the send-mailmessage was working at smtp.outlook365.com 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.
08-14-2019 11:25 AM
@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!
08-14-2019 11:49 AM
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 ..
08-14-2019 12:32 PM
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?
08-14-2019 12:34 PM
@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.