Microsoft 365: configure SPF, DKIM and DMARC for your domain

Securing email communication is paramount for any organization. Spoofed emails can lead to phishing attacks, malware distribution, and reputational…

Securing email communication is paramount for any organization. Spoofed emails can lead to phishing attacks, malware distribution, and reputational damage. Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) are three crucial DNS records that work together to authenticate sending domains and mitigate these threats. This article details the configuration of SPF, DKIM, and DMARC for domains managed within Microsoft 365 environments.

Understanding SPF, DKIM, and DMARC

Sender Policy Framework (SPF)

SPF is a DNS TXT record that specifies which mail servers are authorized to send email on behalf of a domain. When a recipient mail server receives an email, it checks the SPF record of the sending domain. If the email originates from an IP address not listed in the SPF record, it can be flagged as suspicious or rejected. For Microsoft 365, the primary SPF mechanism includes Microsoft's outbound mail servers.

DomainKeys Identified Mail (DKIM)

DKIM adds a digital signature to outgoing emails, allowing recipient servers to verify that the email was not altered in transit and genuinely originated from the claimed domain. This signature is generated using a private key on the sending server and validated using a public key published in the domain's DNS records (via CNAMEs pointing to Microsoft's keys). Microsoft 365 automatically handles the signing process once DKIM is enabled and configured.

Domain-based Message Authentication, Reporting, and Conformance (DMARC)

DMARC builds upon SPF and DKIM by providing a policy that tells recipient servers how to handle emails that fail SPF or DKIM checks, and it provides a reporting mechanism for domain owners to receive feedback on email authentication failures. DMARC policies range from 'none' (monitor only) to 'quarantine' (send to spam/junk) to 'reject' (block entirely).

Configuring SPF for Microsoft 365

The SPF record for a domain primarily sending email through Microsoft 365 should include the spf.protection.outlook.com mechanism. It's crucial to have only one SPF TXT record per domain. Multiple SPF records can lead to unpredictable validation results.

The basic SPF record for Microsoft 365 is:

"v=spf1 include:spf.protection.outlook.com -all"

v=spf1: Specifies the SPF version being used.
include:spf.protection.outlook.com: Authorizes Microsoft 365's outbound mail servers to send email on behalf of your domain.
-all: This is the "hard fail" mechanism. It instructs recipient servers to reject emails originating from servers not explicitly listed in the SPF record. While ~all (soft fail) is an option, -all is generally recommended once you are confident all legitimate sending sources are covered, as it offers stronger protection.

If you use other services to send email (e.g., Salesforce, Mailchimp, a third-party transactional email service), their SPF include: mechanisms or IP addresses must also be added to this single SPF record. For example:

"v=spf1 include:spf.protection.outlook.com include:sendgrid.net include:_spf.salesforce.com -all"

Always test your SPF record after making changes using an online SPF record checker to ensure correct syntax and avoid exceeding the 10 DNS lookup limit (which spf.protection.outlook.com already consumes one of).

Enabling and Configuring DKIM for Microsoft 365

DKIM configuration for Microsoft 365 involves enabling it within the Microsoft 365 Defender portal and then adding CNAME records to your domain's DNS. Microsoft automatically generates the public/private key pairs and handles the signing.

Steps for DKIM Configuration:

Navigate to the Microsoft 365 Defender portal: https://security.microsoft.com/
In the left navigation pane, go to Email & collaboration > Policies & rules > Threat policies.
Under the Policies section, click on DKIM.
You will see a list of your domains. Select the domain for which you want to enable DKIM.
On the right-hand flyout pane, you'll see a section for DKIM keys. There will be an option to "Create DKIM keys" or "Enable" if keys already exist. If it shows "No DKIM keys saved for this domain," click "Create DKIM keys."
Microsoft will present two CNAME records that need to be added to your domain's DNS. These typically follow the format:
- Host name: selector1._domainkey.yourdomain.com
- Points to address or value: selector1-yourdomain-com._domainkey.yourtenantname.onmicrosoft.com
- Host name: selector2._domainkey.yourdomain.com
- Points to address or value: selector2-yourdomain-com._domainkey.yourtenantname.onmicrosoft.com
(Replace yourdomain.com with your actual domain and yourtenantname with your Microsoft 365 tenant's initial domain name, e.g., contoso.onmicrosoft.com).
Add these two CNAME records to your domain's public DNS. DNS propagation can take some time (usually a few minutes to a few hours).
Once the CNAME records have propagated, return to the DKIM settings in the Defender portal for your domain. Click the "Enable" button. Microsoft will verify the DNS records. If successful, the status will change to "Enabled."

Note: Microsoft 365 uses 1024-bit DKIM keys by default. As of 2023, 2048-bit keys are also supported and can be enabled via PowerShell for enhanced security:

Connect-ExchangeOnline # Connect to Exchange Online PowerShell
Get-DkimSigningConfig -Identity yourdomain.com | Format-List Selector1CNAME, Selector2CNAME # Verify existing selectors
New-DkimSigningConfig -DomainName yourdomain.com -KeySize 2048
Set-DkimSigningConfig -Identity yourdomain.com -Enabled $true

This will generate new 2048-bit keys and new CNAME records. You will need to update your DNS records with the new CNAME values provided by the Get-DkimSigningConfig cmdlet after running the New-DkimSigningConfig command.

Implementing DMARC for Policy and Reporting

DMARC is implemented as a TXT record at the _dmarc.yourdomain.com subdomain. It specifies the policy for handling failed emails and where to send aggregate and forensic reports.

A DMARC record typically looks like this:

Host name: _dmarc
TXT value: "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; pct=100; adkim=s; aspf=s"

v=DMARC1: Specifies the DMARC version.
p=: The policy for domains failing DMARC. Options are none, quarantine, or reject.
- p=none: Monitor only. Emails failing DMARC will still be delivered, but reports will be sent to the RUA/RUF addresses. This is the recommended starting point.
- p=quarantine: Emails failing DMARC will be sent to the recipient's spam/junk folder.
- p=reject: Emails failing DMARC will be blocked entirely. This is the strongest policy.
rua=mailto:dmarc@example.com: Specifies the email address(es) to receive DMARC aggregate reports. These reports provide daily summaries of email authentication results. Use an address you actively monitor or a service that processes DMARC reports.
ruf=mailto:dmarc@example.com: (Optional but recommended) Specifies the email address(es) to receive DMARC forensic reports (failure reports). These are individual copies of messages that failed DMARC. These can be very verbose and contain sensitive information, so ensure the mailbox is secure. Many organizations omit ruf or send it to a dedicated analysis tool.
pct=100: Percentage of emails to apply the DMARC policy to. Starting with a lower percentage (e.g., pct=10) when moving from p=none to p=quarantine or p=reject can be a good intermediate step to minimize impact, but pct=100 is the ultimate goal.
adkim=s: Alignment mode for DKIM. s (strict) requires an exact match between the d= tag in the DKIM signature and the RFC5322.From domain. r (relaxed) allows subdomain matches. Strict is generally preferred.
aspf=s: Alignment mode for SPF. s (strict) requires an exact match between the RFC5322.From domain and the domain in the Return-Path (Mail From) header. r (relaxed) allows subdomain matches. Strict is generally preferred.

DMARC Rollout Strategy:

A phased approach is critical for DMARC to avoid inadvertently blocking legitimate email.

Start with p=none: Deploy your DMARC record with p=none and monitor the RUA reports for 2-4 weeks. Analyze these reports to identify all legitimate sending sources for your domain that might not yet be covered by SPF or DKIM. Adjust your SPF record and DKIM configurations as needed.
Move to p=quarantine: Once you are confident that all legitimate email sources are authenticating correctly, change your DMARC policy to p=quarantine. Continue monitoring reports closely. At this stage, some legitimate emails might still be sent to spam. Troubleshoot and refine your SPF/DKIM configurations. Consider using pct= to gradually increase the percentage of emails under quarantine if you have high volume.
Transition to p=reject: After a further 2-4 weeks of successful p=quarantine operation with no unexpected issues, you can transition to p=reject for maximum protection. This will block all unauthenticated emails from your domain. Continue monitoring reports for any unexpected legitimate mail rejections.

It's important to understand that DMARC reports can be extensive, especially for domains with high email volume. Consider using a third-party DMARC reporting service to parse and visualize these reports, as raw XML reports are difficult to interpret manually.

Common Pitfalls and Troubleshooting

Multiple SPF records: A domain should only have one SPF TXT record. If you have multiple, recipient servers will often ignore them or fail SPF checks. Consolidate all legitimate sending sources into a single record.
Exceeding SPF lookup limit: SPF records have a 10-lookup limit. Each include: mechanism counts as a lookup. If you exceed this, SPF will fail. Use an SPF flattening tool or carefully combine includes.
Incorrect CNAME records for DKIM: Typos in hostnames or values for DKIM CNAMEs are common. Double-check them against the Defender portal. DNS propagation time also needs to be considered. Use a tool like dig CNAME selector1._domainkey.yourdomain.com to verify propagation.
DMARC policy too aggressive too soon: Implementing p=reject without thorough monitoring can lead to legitimate emails being blocked, causing business disruption. Always start with p=none.
Missing DMARC reports: If you're not receiving RUA reports, ensure the email address specified in the rua= tag is correct and accessible, and check your spam folders.
Misconfigured external senders: If you use third-party services (e.g., marketing automation, CRM) to send emails on behalf of your domain, ensure they are properly configured to use SPF and DKIM for your domain. Their SPF mechanisms must be included in your primary SPF record, and you may need to configure DKIM within their platforms.