Answering the question “Why is email through Wordpress so complicated?”

Why aren’t website’s contact form messages showing up in my inbox? It’s a common problem. It’s a common question. Here’s an answer.
On a Reddit support forum for WordPress users, in a now-deleted post, someone said they were having trouble getting their contact forms and other email delivered when using 3rd-party email providers like Microsoft’s Office 365. They added that the “easy” answer, using an email plugin, is actually incredibly complicated. It’s a good question and common enough that I thought I should repost my answer here.
The problem isn’t with WordPress or even your hosting company. Other services (e.g. newsletter vendors, billing companies, cloud-based contact and project managers, etc.) that send email from your domain (e.g. info@mydomain.com) typically have the same problems.
And really? Really the problem is spammers and scammers that force mail providers to continuously tighten security screws to prevent random hackers from spoofing your email addresses.
From a customer’s perspective, MS365’s fanatical security is awesome. For site owners, web developers, and 3rd-party communications providers it’s a royal pain. But again, not WordPress’s fault.
Basically what’s going on is that your server sends email on your behalf, using some core PHP or server function to send email. The server dutifully sends a message to the client claiming to be from info@mydomain.com, right? But when the email provider’s server receives the email it goes “no, wait a minute, as far as I know I’m the only official server for all @mydomain.com email, so this has to be a forgery. So I’m rejecting it even before it goes into my user’s spam box.”
As email users that’s actually what we want to happen 99.9999% of the time, right? The alternative would be going back to the days when you’d get mail claiming to be from your aunt trying to sell you counterfeit watches.
The solution is to configure your DNS tables with records that will let Microsoft (or Gmail, SendMail, etc.) known that you’ve also authorized your web server to send mail on your behalf.
The main way you do that is by modifying the SPF record, but depending on how paranoid they’re feeling you may also have to have the correct DKIM, or DMARC records. You might even need to have text records with codes authenticating your account (e.g. ms=12345678)
If you’re using Microsoft Office 365 check with your account rep, or log into the 365 admin panel, then root around to find the correct records to use. (I think there may also be a way to specify your server and/or serve IP address for the SPF record.) If you use Gmail or another less-strict provider check with their support documentation.
And yes, the alternative as the original poster mentioned is to set up an SMPT plugin and then jump through all the (enormous!) hoops to create the right configurations, administrative permissions, and app passwords and keys Microsoft and Google require since they (unfortunately but correctly) won’t just let you add your username and password since the information have to be stored in more or less plain text somewhere on your website or web server.
One final possibility: a small handful of hosting companies disable all outbound email by default, in order to prevent poorly designed or poorly secured customer sites from sending spam. They do this to prevent their servers from winding up on email blacklists. You may want to contact their technical support to have that “option” turned off.