We don’t like spam. And we need help fighting it, so this is what this post is about: Helping you help all of us that fight spam every day.
Let’s start with the concepts. I promise it’ll be quick:
| SPF | DKIM | DMARC |
|---|
| What does it stands for? | Sender Policy Framework | DomainKeys Identified Mail | Domain-based Message Authentication, Reporting and Conformance |
| What is it? | A system to declare and verify who can send e-mails from a given domain | An e-mail authentication system based on asymmetric cryptographic keys. | An e-mail authentication system that helps determining what to do when messages fail SPF or DKIM checks. |
| How does it work? | The receiving host checks if the sending host is allowed to send e-mails from the sender domain.
The information stating who can send e-mails is stored on a TXT record in the DNS zone.
| The sending host signs email body and/or headers with its private key. The receiving host verifies the signature, identifying if the fields are intact.
No digital certificate is required. Public key is published using DNS TXT records.
| The receiving hosts applies the DKIM and SPF checks. Then it validates the results against the published DMARC policy and decides what to do: Block, quarantine, deliver, report to sender.
The DMARC policy is published via DNS TXT record.
|
| Why is it important? | It helps preventing spoofing and can prevent damage to your brand. | Greatly reduces the chances that your messages are treated as spam by digital signature. | Helps receiving organization decide what to do with e-mails that fails checks and create a feedback loop to allow course correction. |
| Where can I learn more? | Sender Policy Framework | DomainKeys Identified Mail | Domain-based Message Authentication, Reporting & Conformance |
Enabling SPF, DKIM and DMARC on Exchange Online
The first thing we do is SPF, because it is simple and stops a lot of spam with little effort. Then we do DKIM and then DMARC, because this last one ties the others together.
Enabling SPF
It is important to understand where you are now so we don’t break anything. Take a look at the flowchart below:
Scenario 1 – Only Exchange Online can send e-mails from your domain
- Create a TXT record in your domain zone
TXT Name: @
Value: "v=spf1 include:spf.protection.outlook.com –all"
|
- Test your SPF record at Scott Kitterman's SPF record testing tools
Scenario 2 – Add Exchange Online Protection to your SPF record
- Get your SPF record
nslookup -querytype=txt contoso.com
Server: dns.external
Address: 192.168.1.1
Non-authoritative answer:
contoso.com text = "v=spf1 mx -all"
|
- Add Exchange Online Protection to your SPF record, just before the “all” verb.
TXT Name: @
Value: "v=spf1 mx include:spf.protection.outlook.com -all"
|
- Test your SPF record at Scott Kitterman's SPF record testing tools
Scenario 3 – Create a SPF record for your e-mail gateways and Exchange Online Protection
- Define which hosts will send e-mail and build the SPF string with the below table:
| Record start | v=spf1 |
| Exchange Online Protection | include:spf.protection.outlook.com |
| If your MX servers are also used for sending e-mail… | mx |
| If you use third party e-mail services… | include:<3rd party SPF record>
where <3rd party SPF record> will be provided by your service provider
|
| If you want to specify an IPv4 that will send e-mail… | ip4:<IP v4 Address>
where <IP v4 Address> will be replaced with the actual IPv4 address
|
| If you want to specify an IPv6 that will send e-mail… | Ip6:<IP v6 Address>
where <IP v6 Address> will be replaced with the actual IPv6 address
|
| Record end | <enforcement rule>
where <enforcement rule> can be:
-all – Anything not in the list will fail
~all – Anything not in the list will soft fail (avoid using this)
|
For example, if you want to allow Exchange Online and the IP address 40.124.14.27 to send e-mails from the domain contoso.com you can use the following SPF record at contoso.com DNS zone:
TXT Name: @
Value: "v=spf1 ip4:40.124.14.27 include:spf.protection.outlook.com –all"
|
- Test your SPF record at Scott Kitterman's SPF record testing tools
Enabling DKIM
Publish two CNAME records for your domain in DNS
You’ll have to know a couple of things from your e-mail services at Office 365: Your domain GUID and your initial domain. Don’t worry, we’ll guide you through it:
- Get your domain GUID
Your domain GUID is based on your domain name, replacing the dots with dashes. So let’s say your domain is contoso.com, then your domain GUID would be “contoso-com”
Take note of your domain GUID because you’ll need it latter.
- Get your initial domain
Initial domain is basically your tenant name in Office 365. You can get it from Admin Center – Domains. It is that domain ending with “.onmicrosoft.com”. For our Contoso company it could be “contoso.onmicrosoft.com”.
Take note of your initial domain too.
- Create two CNAME records in you external DNS zone
| Host name | selector1._domainkey.<domain>
where <domain> is your domain name
|
| Points to | selector1-<domainGUID>._domainkey.<initialDomain>
where <domainGUID> is your domain GUID and <initialDomain> is your initial domain.
|
| Host name | selector2._domainkey.<domain>
where <domain> is your domain name
|
| Points to | selector2-<domainGUID>._domainkey.<initialDomain>
where <domainGUID> is your domain GUID and <initialDomain> is your initial domain.
|
For Contoso.com, those would be the required records:
Host name: selector1._domainkey.contoso.com
Points to: selector1-contoso-com._domainkey.contoso.onmicrosoft.com
Host name: selector2._domainkey.contoso.com
Points to: selector2-contoso-com._domainkey.contoso.onmicrosoft.com
|
Enable DKIM signing for your domain in Office 365
- Sign-in at Exchange Admin Center with an administrative credential
- Go to Protection > dkim
- Select the domain for which you want to enable DKIM and then, for Sign messages for this domain with DKIM signatures, choose Enable.
Enabling DMARC
Covering the basics of DMARC
The most important things to consider when enabling DMARC are 1 – to make sure you got SPF + DKIM right and 2 – wisely define your policy. If you get any of those two wrong, there can be a lot of noise.
For the first part, we recommend you to test your SPF and DKIM implementation before moving forward with DMARC. We will help you with the second part.
The table below summarizes the options you have when configuring your DMARC policy:
| Tag | Purpose | Options |
|---|
| v | Version – Required | DMARC1 |
| p | Policy – Required | none: No specific action be taken regarding delivery of messages.
quarantine: E-mail that fails DMARC check should be considered suspicious.
reject: E-mail that fails DMARC check should be rejected.
|
| sp | Policy for all the subdomains – Optional, defaults to the parent domain policy if omitted. | none: No specific action be taken regarding delivery of messages – useful for monitoring.
quarantine: E-mail that fails DMARC check should be considered suspicious.
reject: E-mail that fails DMARC check should be rejected.
|
| adkim | Indicates whether strict or relaxed DKIM Identifier Alignment mode is required – Optional, defaults to r if omitted. | r: relaxed mode – Both the authenticated signing domain and the sender domain can be a subdomain of each other to be considered aligned.
s: strict mode – Only an exact match between both of the domains is considered to produce Identifier Alignment.
|
| aspf | Indicates whether strict or relaxed SPF Identifier Alignment mode is required – Optional, defaults to r if omitted. | r: relaxed mode – Both the authenticated signing domain and the sender domain can be a subdomain of each other to be considered aligned.
s: strict mode – Only an exact match between both of the domains is considered to produce Identifier Alignment.
|
| rua | Addresses to which aggregate feedback is to be sent – Optional | E-mail addresses in the format mailto:mbx@domain.com. Multiple addresses should be comma separated. |
| ruf | Addresses to which message-specific failure information is to be reported – Optional | E-mail addresses in the format mailto:mbx@domain.com. Multiple addresses should be comma separated. |
| rf | Format to be used for message-specific failure reports – Optional, defaults to afrf if omitted. | afrf: Authentication Failure Reporting Using the Abuse Reporting Format, as described in RFC 6591.
iodef: Incident Object Description Exchange Format, as described in RFC 5070
|
| ri | Interval requested (in seconds) between aggregate reports – Optional, defaults to 86400 if omitted. | 32-bit unsigned integer, from 0 to 4,294,967,295. |
| fo | Provides requested options for generation of failure reports – Optional, defaults to 0 if omitted. | 0: Generate a DMARC failure report if all underlying mechanisms fail.
1: Generate a DMARC failure report if any underlying mechanism produced something other than an aligned "pass" result.
d: Generate a DKIM failure report if the message had a signature that failed evaluation.
s: Generate an SPF failure report if the message failed SPF evaluation.
|
| pct | Percentage of messages to which the DMARC policy is to be applied. It allows to enact a slow rollout enforcement of the DMARC mechanism. – Optional, defaults to 100 if omitted. | Integer between 0 and 100, inclusive |
You can use one of the DMARC record assistant listed at
DMARC Deployment Tools. They can greatly reduce the chances of misspelling. However, you have to understand the options you have on the table above.
DMARC implementation best practices
We recommend you to follow the best practices below when implementing DMARC:
- Form the DMARC TXT record using one of the DMARC record assistant listed at DMARC Deployment Tools
- Start monitoring the impact of DMARC applying a monitoring-only policy (p=none). You can do this even before implementing SPF and DKIM, as it can give an insight of what is going to happen when you implement those mechanisms.
- Move to quarantine policy after the testing phase (p=quarantine).
- Only request that external mail systems not accept messages that fail DMARC (p=reject) if it makes sense for you and after extensive testing.
Form and deploy the DMARC TXT record
- Define the DMARC policy you want to apply.
- Use one of the record assistant listed at DMARC Deployment Tools to build the DMARC TXT record.
- Select the options according to the policy you defined.
- Publish the DMARC TXT record in your external DNS zone
For example, we can use the DMARC TXT record below for contoso.com:
TXT Name: _dmarc.contoso.com
Value: "v=DMARC1; p=none; rua=mailto:rua@contoso.com; ruf=mailto:ruf@contoso.com; fo=1"
|
