We will cover three ways you can continue sending emails while having Microsoft 365 secured. When the default security rules are on, sending via SMTP using your user account is disabled. SMTP does not support multifactor authentication or rotating tokens and is less secure than modern systems like OAuth.
| A word of warning: Some configurations we discuss here require editing DNS records. We will not dive into what these do, and your specific implementation might require a different configuration than what we are showing here. |
We will cover three common ways to send email:
FINDING THE BEST METHOD FOR YOU:
All of these require some configuration, so if you don’t already have any of these, you will need to be able to update your SPF DNS Record. Although SPF (Sender Policy Framework) is yet another acronym, it is a crucial component of reducing spam on the internet by ensuring that email comes from only verified servers. Email sending is becoming increasingly strict, with Google and Yahoo requiring DMARC (another acronym that helps verify email senders). That said, one can no longer just “send an email.” Instead, you must send it from a verified server, which means updating DNS records.
| A note on the “From” of an email message: it should match the domain you are sending from. Don’t ever try to send an email from a domain that is not the sending domain. For example, I should not try to send an email “from” esri.com when my domain is dymaptic.com. All that will do is make my domain look more like a spam domain, and likely, the email will never be delivered anyway! |
Method 1 – The Relay Server
This first method is both the easiest and the hardest of the three. If you work within a larger IT organization that has its own network (likely an on-premise one), you probably already have a relay server; you just need to ask IT for the information. A relay server is precisely what it sounds like - a trusted server on a trusted network that can “relay” the email you wish to send to the primary server to get your message out the door.
You probably don’t have a relay server if you are a small organization. Setting them up is not complicated, but you would have another server to maintain. Probably one of the other two options would make more sense for you.
Method 2 – The Third Party
This is the easiest option if you don’t have a relay server! This method involves paying a third-party email-sending service to send emails on your behalf. There are a couple that I have used and would recommend: SendGrid (Twillio), MailGun, and Brevo (Formerly SendInBlue). Any of these services will walk you through the configuration of sending email, but you will need access to your DNS entries to update your SPF and related signing records.
Once configured, you can generate a very long SMTP password (keep this password a secret, like an API Key) that you can enter into your ArcGIS Monitor email configuration, and you are up and running, easy as that! This type of service also behaves much like a relay server, so you can connect many things to send email this way: ArcGIS Monitor, ArcGIS Enterprise, and even your custom Python scripts!
If updating your DNS records is scary, I’m with you! It is terrifying knowing that a single character out of place could mean that we can’t send or receive emails for days! There are services that help automate this and make keeping up with email security configurations more straightforward, like EasyDMARC.
Method 3 – Microsoft 365 Direct Send
This one seems a bit crazy to me. When Kevin and I were testing all of these out, I didn’t believe it would work! Fortunately, Kevin is very persistent, and we got this going. If you want, you can read Microsoft’s documentation on this (see Option 2). It’s pretty dense and not very helpful, though.
This method works by pushing emails directly to your mail server, but you need to tell your mail server which server(s) is(are) allowed to do so. Let’s say you are configuring ArcGIS Monitor to send emails; that server will need a public IP address or a DNS entry that will resolve to one.
| Be careful here; you could use your public-facing IP address for your internal network, the one provided by your Internet Service Provider, but that would allow ANY AND ALL computers on your network to send mail this way. Be sure that is what you want and that you are not violating your IT security rules. I wouldn’t do it that way! |
Once you have that IP address, you’ll have to update your SPF DNS record. For our testing, that looks like this:
We’ve added the IP address of the server that we want to allow to send emails to our SPF record. You can see that we’ve left the other values in place.
Now, you’ll need your mail server, which is the server in your MX record. If you don’t know what’s in your MX DNS record, you can use a tool like MX Toolbox to get it for you.
With the MX server name and the SPF record updated, we can now configure ArcGIS Monitor or Enterprise (or any other software on that server that can send via SMTP) to send emails. The configuration will look like this:
You don’t need your password here - we have authorized this server to send mail by adding it to the SPF record! That’s one reason you should keep control over what software is on this server and who has access to it.
Once you click register, you can send a test email.
None of these methods are that complicated, but they all require some level of configuration you might not be used to. Please give us a holler if you have questions or want another pair of eyes.
This guide was put together by Christopher Moravec & Kevin Sadrak of dymaptic.