Manage spoofing protection
Spoofing is the term used for the creation of email messages with a forged sender address. Attackers use spoofing to convince the recipient that the email was sent by somebody else. The following technologies, all supported by Microsoft 365, ensure that your domain can't be spoofed by attackers:
- Sender Policy Framework (SPF)
- DomainKeys Identified Mail (DKIM), and
- Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- Mail Transfer Agent - Strict Transport Security (MTA-STS)
Configuring Sender Policy Framework (SPF)
Configuration for the SPF is identical for on-premises Exchange Server deployments, Exchange hybrid deployments, and Exchange Online only.
SPF is configured using a DNS TXT record for your public DNS domain. This design enables target mail servers to retrieve your SPF configuration information by doing just a normal public DNS lookup. Because SPF consists of simple TXT records in DNS, it's mandatory to use the following syntax on the TXT record:
v=spf1 <IP> <enforcement rule>
The following table identifies the different parts of an SPF record:
Part of SPF
Examples
Description
Declaration
v=spf1
This parameter defines the TXT record as an SPF TXT record.
Trusted hosts and networks
ip4:192.168.0.1/32 or
ipv6:ip6:1080::8:800:200C:417A/96
mx
a
Lists all trusted hosts, trusted network mail sources, and other DNS records with values that shall be trustworthy.
Include
include:spf.protection.outlook.com
Include SPF records from other domains.
Enforcement rule
-all
-all : Indicates hard fail. Recommended if you know all authorized IP addresses for a domain, or when using SPF only, without DMARC or DKIM.
~all : Indicates soft fail. Used when not all possible sending hosts are known. Also required if you're using DMARC with p=quarantine or p=reject.
?all : Indicates neutral. This option is used when testing SPF. It isn't recommended for live deployments.
For example, the default SPF TXT record for Exchange Online or Exchange Online Protection (EOP) is:
v=spf1 include:spf.protection.outlook.com -all
By configuring the SPF DNS records in your environment, you raise your domain reputation significantly. As such, the mail addresses of your domain are harder to spoof for malicious and phishing email senders.
Caution
You should be careful when configuring SPF records in your live environment if you have complex mail flow scenarios, many different sending hosts for application emails, automatic forwarding, and so on. For example, if a server in your environment is sending mail with sender addresses from your environment, and this server isn't included in your SPF record, mail from this host will be flagged as a phishing attack with a spoofed sender address.
Further reading. For more information, see How Microsoft 365 uses Sender Policy Framework (SPF) to prevent spoofing.
Configure DomainKeys Identified Mail (DKIM)
DKIM adds an encrypted entry to the message header called the DKIM-Signature entry. When you forward a message, portions of that message's envelope can be stripped away by the forwarding server. Since the digital signature stays with the email message because it's part of the email header, DKIM works even when a message has been forwarded as shown in the following example.
In this example, if you had only published an SPF TXT record for your domain, the recipient's mail server could have marked your email as spam and generated a false-positive result. The addition of DKIM in this scenario reduces false positive spam reporting.
Tip
Because DKIM relies on public-key cryptography to authenticate rather than just IP addresses, it's considered a much stronger form of authentication than SPF. As such, it's recommended that organizations use SPF, DKIM, and DMARC in their deployments.
Important
Organizations are currently unable to configure DKIM using the native tools in Exchange Server. You can only configure DKIM when using Exchange Online or a hybrid deployment.
DKIM is one of the trio of Authentication methods (SPF, DKIM, and DMARC) that help prevent attackers from sending messages that look like they come from your domain.
DKIM lets you add a digital signature to outbound email messages in the message header. When you configure DKIM, you authorize your domain to associate, or sign, its name to an email message using cryptographic authentication. Email systems that get email from your domain can use this digital signature to help verify whether incoming email is legitimate.
When using DKIM, a private key encrypts the header in a domain's outgoing email. The public key is published in the domain's DNS records, and receiving servers can use that key to decode the signature. DKIM verification helps the receiving servers confirm the mail is really coming from your domain and not someone spoofing your domain.
Tip
DKIM is enabled by default for Microsoft 365 domains that are named <tenant>.onmicrosoft.com. You only need to enable DKIM to any other domains that you've added to your Microsoft 365 tenant.
To enable signing DKIM for a domain in Microsoft 365, you must create two CNAME records.
Host name
Record type
Value
TTL
selector1._domainkey.<domain>
CNAME
selector1-<domainGUID>._domainkey.<initialDomain>
3600
selector2._domainkey.<domain>
CNAME
selector2-<domainGUID>._domainkey.<initialDomain>
3600
In this table, the <domainGUID> and <initialDomain> parameters are defined as follows:
- domainGUID. Can be taken from DNS MX record that points to Microsoft 365 (for example, contoso-com.mail.protection.outlook.com)
- initialDomain. Your default Microsoft 365 domain that's named <tenant>.onmicrosoft.com (for example, contoso.onmicrosoft.com)
For example, the following two DNS records are required to enable DKIM for the domain contoso.com:
First public DNS domain record:
- Host name: selector1._domainkey.contoso.com
- Record type: CNAME
- Value: selector1-contoso-com._domainkey.contoso.onmicrosoft.com.
- TTL: 3600
Second public DNS domain record:
- Host name: selector2._domainkey.contoso.com
- Record type: CNAME
- Value: selector2-contoso-com._domainkey.contoso.onmicrosoft.com.
- TTL: 3600
You would then complete the following steps to enable DKIM for the domain:
In the Microsoft 365 admin center, in the left-hand navigation pane, select Show all. Under the Admin centers group, select Security to open the Microsoft Defender XDR portal.
In the Microsoft Defender XDR portal, in the left-hand navigation pane, select Policies & rules.
On the Policies & rules page, select Threat policies.
On the Threat Policies page, under the Rules section, select DKIM.
On the DKIM page, select the domain you wish to configure.
On the detail pane that appears for the selected domain, select the Create DKIM keys button.
In the Publish CNAMEs pop-up window that appears, select the Copy button to copy the CNAMEs that are displayed in the window.
Leave the detail pane open for the selected domain. Publish the copied CNAME records to your DNS service provider. On your DNS provider's website, add CNAME records for DKIM that you want to enable. Ensure the fields are set to the following values for each:
Record Type: CNAME (Alias) Host: Paste the values you copy from DKIM page. Points to address: Copy the value from DKIM page. TTL: 3600 (or your provider default)Return to the detail pane in the Microsoft Defender XDR portal to enable DKIM. To do so, select the Sign messages for this domain with DKIM signatures toggle switch to change its status to Enabled. If you later wish to disable DKIM for the domain, navigate to this pane and select this toggle switch to change the DKIM status to Disabled.
Close the detail pane for the selected domain.
Further reading. For more information, see Use DKIM to validate outbound emails sent from your custom domain in Microsoft 365.
Configure Domain-based Message Authentication, Reporting, and Conformance (DMARC)
DMARC works like SPF with public DNS records. It's intended to give recommendations to the recipient about how to use SPF and DKIM for the recipient's domain. As such, it's available for all Exchange implementations. However, to use it, your MX record must point to Exchange Online because on-premises Exchange Servers are currently unable to use DMARC records.
Like the DNS records for SPF, the record for DMARC is a DNS text (TXT) record that helps prevent spoofing and phishing. DMARC TXT records validate the origin of email messages by verifying the IP address of an email's author against the supposed owner of the sending domain. The DMARC TXT record identifies authorized outbound email servers. Destination email systems can then verify whether messages they receive originate from authorized outbound email servers.
To configure DMARC for your SMTP mail domains, you must have a DNS TXT record configured by your Internet DNS provider for each domain. Each DNS TXT record should be configured per the following format:
\_dmarc.domain TTL IN TXT "v=DMARC1; pct=100; p=policy; ruf=failure\_report; rua=aggregate\_report; fo=failure\_option"
The following table describes the syntax used to format a DNS TXT record for DMARC.
Syntax
Example
Description
domain
Contoso.com
This parameter is the domain you want to protect. By default, the record protects mail from the domain and all subdomains. For example, if you specify _dmarc.contoso.com, then DMARC protects mail from the domain and all subdomains, such as marketing.contoso.com and itdepartment.contoso.com.
pct=100
pct=100
Indicates how many messages, as a percentage, that must be checked. A value of 100 means every email must be checked.
policy
p=none
Specifies what policy you want the receiving server to follow if DMARC fails. You can set the policy to one of the following values:
- None. Monitor only the impact of implementing DMARC.
- Quarantine. Request that external mail systems quarantine mail that fails DMARC.
- Reject. Request that external mail systems not accept messages that fail DMARC.
Important: You can't effectively quarantine or reject mail by using DMARC unless you also implement SPF and DKIM.
Failure report(optional)
ruf=mailto:fail@contoso.com
When specified, a message is sent every time an SPF, DKIM, or DMARC check fails.Caution: Only use this option when investigating issues.
Aggregate report(recommended)
rua=mailto:agg@contoso.com
When specified, a message including an overview report is sent once a day.
Failure Option(optional)
fo=0
Specifies which failure options will send a DMARC message:
- 0 - Generate report if all authentication mechanisms fail.
- 1 - Generate report if any authentication mechanism fails.
Caution: Only enable this option when investigating issues because it generates a large number of messages.
For example, the following DNS record configured DMARC for the domain contoso.com and all subdomains just to monitor the impact of DMARC by using a "none" policy, and to send an aggregate report to agg@contoso.com:
\_dmarc.contoso.com 3600 IN TXT "v=DMARC1; pct=100; p=none; rua=mailto:agg@contoso.com; fo=0"
Tip
As a best practice when implementing DMARC, you should start and configure your DMARC policy as None, measure the impact, and then consider moving to the more restrictive policies such as Quarantine or Reject.
Further reading. For more information, see Use DMARC to validate email in Microsoft 365.
Configure Mail Transfer Agent - Strict Transport Security (MTA-STS) in Exchange Online
By itself, TLS encryption is used to protect SMTP communications. However, it can't verify the identity of a destination server. Without vetting the identity of a destination server, SMTP connections could be exposed to DNS tampering. The SMTP connections allow attackers to route connections back to their own servers. MTA-STS safeguards you from these types of attacks by ensuring that Transport Layer Security (TLS) is always used. It also provides a way for sending servers to refuse message delivery should the server not support TLS and have a trusted certificate. Exchange Online has implemented MTA-STS and can be used to further secure your outgoing and incoming email. To take advantage of this functionality please see the following requirements:
Outbound protection. There's nothing you need to configure to take advantage of the MTA-STS security functionality on outgoing messages. The Exchange Online implementation respects the configuration of the recipient domain owners through their MTA-STS policy and will adhere to its conditions. This functionality is now supported for all outgoing messages and is always on by default.
Inbound protection. Exchange Online supports TLS 1.2 and offers the necessary TLS certificates required by MTA-STS. As such, there's no configuration needed in Exchange Online. Like DNS records for SPF and DMARC, MTA-STS is configured as a DNS TXT record on your domain. In addition to the DNS TXT record, a policy file is also published as an HTTPS web page hosted by the domains web infrastructure. This design introduces further security protection that attackers need to overcome. A domains MTA-STS TXT record declares MTA-STS support to a sender, after which the domains HTTPS-based MTA-STS policy is retrieved. To be fully protected by MTA-STS, a domain owner needs to create both the DNS TXT domain record and host the policy file at the required HTTPS URL with a valid certificate that contains their domain.
For example, the following DNS record declares MTS-STS support:
_mta-sts.contoso.com. 3600 IN TXT v=STSv1; id=20211201000000Z;
The HTTPS URL policy syntax should be:
https://mta-sts./.well-known/mta-sts.txt
The URL contents for the policy:
version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 604800
If your MX records point directly to Exchange Online, you can use the same values in the policy shown above. The required information in this policy is the MX record that points to Exchange Online (*.mail.protection.outlook.com), which is shared by all Exchange Online customers.
Note
The only scenario where message delivery will fail is when both sending and receiving sides have MTA-STS configured and MTA-STS validation fails. For example, If MTA-STS is configured on the sender's domain, but not on the recipient's domain, mail will still be delivered.