Secure Your Exchange Online Tenant with Important Settings
Security and Safety are more important today than ever before. Over the last few years, we have seen an increase in Zero-Day vulnerabilities or security flaws in software products. The world is spinning faster and faster, and we can expect the challenge of securing Exchange Online to continue.
A common aspect of many attacks is phishing, infiltration, and malware delivery to victims using email messages. We all need to understand that email protection is an important line of defense to protect our users, businesses, and companies. Email protection starts with some simple basics.
Basic Email Protection
Everything starts with Domain Name System (DNS), where information is published about email infrastructures, and the owners of SMTP domains want to handle malicious and suspicious emails sent “in our name.” A set of protocols and mechanisms are available to DNS:
- Sender Policy Framework (SPF as described in RFC 7208)
- DomainKeys Identified Mail (DKIM as described in RFC 6376)
- Domain-based Message Authentication, Reporting and Conformance (DMARC as described in RFC 7489)
- Authenticated Received Chain (ARC as described in RFC 8617)
- SMTP MTA Strict Transport Security (MTA-STS as described in RFC 8461)
- DNS-Based Authentication of Named Entities (DANE as described in RFC 7672)
Several Practical365.com articles cover these protocols and mechanisms, including:
- Getting Your DNS Ducks in a Row.
- The Most Important Steps an Administrator Can Take to Make Exchange Online Secure by Default.
- Microsoft Brings Improvements to DMARC.
- Exchange Online Enforces Sender DMARC Policy.
- Exchange Online Launches Support for MTA-STS.
SPF Records
The DNS record for SPF contains a mechanism describing how to get a match against the sending server (e.g.: “a” tries to match the IP address) and qualifiers, which instructs DNS what to do once a match is found. The RFC mentions the following mechanism:
| Mechanism | Description |
| include | The “include” mechanism triggers a recursive evaluation of check_host(). Supports multiple domains. |
| a | This mechanism matches if <ip> is one of the <target-name>’s IP addresses (“a” and “AAAA” records). |
| mx | This mechanism matches if <ip> is one of the MX hosts for a domain name. |
| Ip4 / Ip6 | These mechanisms test whether <ip> is contained within a given IP network. |
| exists | This mechanism is used to construct an arbitrary domain name that is used for a DNS A record query. It allows for complicated schemes involving arbitrary parts of the mail envelope to determine what is permitted (high complexity!). |
| ptr (do not use!) | This mechanism tests whether the DNS reverse-mapping for <ip> exists and correctly points to a domain name within a particular domain. This mechanism SHOULD NOT be published. See the note at the end of this section for more information. |
And qualifiers:
| Qualifier | Result code | Description |
| + | pass | A “pass” result explicitly states that the client is authorized to inject mail with the given identity. |
| – | fail | A “fail” result is an explicit statement that the client is not authorized to use the domain in the given identity. |
| ~ | softfail | A “softfail” result is a weak statement by the publishing ADMD that the host is probably not authorized. It has not published a stronger, more definitive policy that results in a “fail”. |
| ? | neutral | A “neutral” result means the ADMD has explicitly stated that it is not asserting whether the IP address is authorized. |
Note: Two additional result codes are possible.
| Result code | Description |
| Temperror | A “temperror” result means the SPF verifier encountered a transient (generally DNS) error while performing the check. A later retry may succeed without further DNS operator action. |
| Permerror | A “permerror” result means the domain’s published records could not be correctly interpreted. This signals an error condition that requires DNS operator intervention to be resolved. |
You should implement an SPF record for all your domains. With this record, you let the internet know what infrastructure is allowed to send emails on your behalf.
Note: Don’t forget to add -all! This ensures you override the default +all to force emails that don’t match your DNS records to fail.
Example SPF Records
Example #1:
v=spf1 include:spf.protection.outlook.com a:mytenant.com –all
Note: This allows Exchange Online and a server named “mytenant.com” to send email on behalf of our domain.
Example #2:
v=spf1 include:spf.protection.outlook.com Ip4:192.168.1.0/26 –all
Note: This allows Exchange Online and all servers matching the given subnet to send on behalf of our domain.
Example #3:
la.example.com. TXT “v=spf1 redirect=_spf.example.com”
ny.example.com. TXT “v=spf1 redirect=_spf.example.com”
sf.example.com. TXT “v=spf1 redirect=_spf.example.com”
_spf.example.com. TXT “v=spf1 mx:example.com -all”
Note: This example shows how to simplify multiple domain setups to a single DNS entry.
SPF Limitations
As you can see, SPF supports a wide variety of commands. Limitations also exist:
- Only a single DNS record per domain is allowed.
- DNS lookup limit of 10 (more than 10 causes “permerror”).
- Check is done only on the “Mail From” header (“From” header is not checked!).
- Insufficient security as spoofing is possible via the “From” header.
Understanding DKIM
To improve security and eliminate some of the limitations of SPF, DKIM helps by verifying that a message was not altered in transit by the following mechanism:
- The sending server uses a certificate with its public key published in DNS to sign a message and stores the signature in a message header
- The receiving server uses DNS to retrieve the published certificate and validate the signature in the message header
When all mailboxes are hosted in Exchange Online, you must add the following DNS records:
Hostname: selector1._domainkey
Points to address or value: selector1-<CustomDomain>._domainkey.<InitialDomain>
Hostname: selector2._domainkey
Points to address or value: selector2-<CustomDomain>._domainkey.<InitialDomain>
Example:
selector1._domainkey.example.com CNAME
selector1-example-com._domainkey.example.onmicrosoft.com
selector2._domainkey.example.com CNAME
selector2-example-com._domainkey.example.onmicrosoft.com
After adding the records, you should enable DKIM signing for custom domains used by the tenant in the Security Portal under Threat Policies in Email authentication settings (Figure 1):
Note: The interface does not support DKIM options. You must use the Set-DkimSigningConfig and Rotate-DkimSigningConfig cmdlets from the Exchange Online management PowerShell module to configure the KeySize (should be 2048!) and HeaderCanonicalization (Relaxed/Simple) options.
Understanding DMARC
The combination of SPF and DKIM gives a good start. However, we need to create a DMARC policy that describes what to do with emails depending on the outcome of the SPF or DKIM checks.
If a DMARC policy is not available for a domain, receiving systems have no information on how to handle email coming from the domain. This means that receiving organizations might treat emails differently, with some dropping email from the domain and others accepting the email. The DMARC policy helps to ensure consistent handling of the domain’s email around the internet.
When the email industry started to see the need to improve security, essential players like Yahoo and Google enforced sender guidelines requiring SPF, DKIM, and DMARC for senders with more than 5000 messages per day. If you don’t follow these guidelines, Google says:
“If you send more than 5,000 emails per day before February 1, 2024, follow the guidelines in this article as soon as possible. Meeting the sender’s requirements before the deadline may improve your email delivery. If you don’t meet the requirements described in this article, your email might not be delivered as expected, or might be marked as spam.”
You don’t want to be responsible for emails not being delivered, right?
DMARC uses the following syntax:
| Tag | Purpose | Sample |
| adkim (r=relaxed/s=strict) | Alignment mode for DKIM | adkim=r |
| aspf (r=relaxed/s=strict) | Alignment mode for SPF | aspf=r |
| fo (0/1/d/s) | Provides requested options for the generation of failure reports. | fo=0:1:s |
| p (none/quarantine/reject) | Policy for domain | p=reject |
| pct | Percentage of messages subjected to filtering | pct=30 |
| rf | Format to be used for message-specific failure reports | rf=afrf |
| ri | Interval requested between aggregate reports | ri=86400 |
| rua | Reporting URI of aggregate reports | rua=mailto:report@example.com |
| ruf | Reporting URI for forensic reports | ruf=mailto:forensic@example.com |
| sp (none/quarantine/reject) | Policy for subdomains | sp=reject |
| v | Version of DMARC | v=DMARC1 |
Implementing a DMARC policy is as crucial as having SPF and DKIM in place. Ensure you handle any subdomains in use with the tag “sp”. Be as explicit as you can!
An example of a DNS record for a DMARC policy looks like this:
v=DMARC1; p=quarantine; adkim=r; aspf=r; rua=mailto:mail-reports@example.com; ruf=mailto:mail-forensic@example.com; sp=reject
Understanding ARC
In some scenarios, messages fail a DMARC check and get junked, quarantined, or even rejected (depending on how the receiving infrastructure handles inbound email). One reason could be using mailing lists maintained by a listserv. In such cases, you could use ARC, and with that, you trust a previous receiving system’s authentication result on a domain level. You can check this by examining the header ARC-Authentication-Results.
This article explains more about how to configure trusted ARC sealers in Microsoft 365.
The Importance of MTA-STS and DANE
The MTA-STS and DANE protocols improve security for outbound email. These articles Exchange Online Launches Support for MTA-STS and Exchange Online Introduces DANE and DNSSEC for Outbound Email explain the basics.
Both protocols ensure that a receiving system checks the certificate provided by the sending MTA before receiving messages with SMTP.
Is That All?
This article only covers the basics you need to implement to protect Exchange Online.
The Microsoft Defender for Office 365 security suite is designed to protect Microsoft 365 tenants. Figure 2 shows the complete protection stack provided by Microsoft Defender for Office 365.
If you want to learn more about protecting Exchange Online and Microsoft Defender for Office 365, join me in Dallas on October 1-2, where I’ll speak about these topics and more at The Experts Conference (TEC)
Hello,
I’ve a question regarding the combination of DKIM and SPF for DMARC, when you want to allow some big email provider to send as your domain, as many companies do.
It’s a problematic that some people started talking about over the Internet recently, but I couldn’t seem to find any satisfying answer of someone really understanding deeply the mechanics of these protocols yet.
As it is stated is the RCF for DMARC, regardless of whether full or partial alignment of SPF and/or DKIM is required, only one of the two protocols needs to be verified for the email to be legitimized.
So let’s say you are allowing emailing provider company ABC to send emails as yourcompany.com. Therefore, you configure SPF and DKIM. If ABC has its email appliances hosted over Azure (or some other public cloud), sharing Azure’s IP addresses with other Azure customers, anybody else hosted in Azure could be allowed to send emails as yourcompany.com by this SPF record.
That’s also true for self-hosted emailing providers, we never truly know how they protect the use of other domains among their customers. Therefore, the DKIM key, usually linked only to one customer’s settings privately, seems to be more secure.
That’s why I know only configure SPF records for IP addresses I owe (among with DKIM), and in other cases I only configure DKIM records. Also, this has been advised to me by a company that was helping us troubleshoot our DMARC policy. I know both protocols should serve different purposes, but I have thought about this a lot, trust me, and it definitely seems more secure to me this way. Am I wrong here ?
“As it is stated IN the RCF for DMARC” *
“That’s why I NOW only” *
“(aLong with DKIM)” *
Sorry for the typos…
Hi Cyril,
You’re right. You should think about adding someone to your SPF record twice! However, there are scenarios where the sending infrastructure cannot sign messages, and DKIM is not an option. Then, you rely on SPF. I recommend using an in-house SMTP solution that supports SMTP Auth in such scenarios. With this, you can control what is sent and ensure it’s DKIM-signed.
Makes sense?
Ciao,
Ingo
@Ingo:
Did I get it right: You recommend a full blown SMTP solution like Postfix, hMailServer, Windows SMTP daemon etc – exposed to the Internet with official IP addresses – to send legitimate business email?
Limiting our thoughts to MS365 I think it is not possible that any tenant is able to send out emails with a domain that is registered in another tenant. If that’s true, the SPF record of your own domain can include the huge MS IP ranges (spf.protection.outlook.com) without anyone abusing your domain’s SPF record.
True or false?
Kind regards
Max
Hi Max,
No, this is not what I meant. Please don’t mix different scenarios.
If you want a company to send emails on your behalf and this company doesn’t support DKIM signing, you have multiple options:
1. add the company’s MTA to your SPF record
2. If SPF is not an option, you could provide a securely published SMTP service (yes, I highly prefer Postfix and have no issue publishing this service) with SMTP Auth.
This SMTP service would then be used INCOMING from this company. Once you receive these emails, you can route them OUTBOUND to external recipients in which way you want.
Ciao,
Ingo
Hi Max,
We had several vendors. All of them have flaws. I think it’s up to the vendors how they deal with your complaints and what the technical solution looks like.
Yes, we also have false positives or negatives. I can only emphasize doing as many admin submissions as possible to train your tenant-specific ML. If this still doesn’t help, open a case with MS.
Ciao,
Ingo
Hi Ingo,
thanks for your reply. I agree that every vendor has its advantages/disadvantages. Systems in front of EOP are limited to the mail routing chain, whereas EOP is better integrated.
On the other hand – due to million of M365 tenants sharing the same resources like IP addresses, AI intelligence – your freedom to configure your tenant’s settings according to your needs is limited e.g. being unable to really whitelist false-positive emails. Instead, submitting them is an unpredictable and tedious task.
Kind regards
Max.
Hi Max,
I agree flexibility is limited. Even sharing the same IP addresses, there is a way of identifying single tenants (I read this for outgoing direction). Adding a false-positive on the allow list is possible. You can do this in multiple ways, e.g., TABL or threat policies. You can do this on the sender’s mail or IP address. It’s always a question if you really want this.
But my point in this article is more about the “low hanging fruits” for an admin. The topics you mentioned are related to MDO.
Makes sense?
Ciao,
Ingo
Very useful tip regarding TABL and policies for whitelisting.
Dankeschön 😉
Hi Ingo,
“the best-run businesses run SAP” … and Microsoft 😉
How satisfied are you with the capabilities of Microsoft Defender for Office?
Do you have any problems with false positive emails or URLs that are deemed “malicous” or “high confidence phish” by MS?
Do you run a third party anti-spam/anti-phish/anti-virus tool in front of EOP?
Thanks and greetings from Germany.
Max.