Microsoft 365 SPF, DKIM & DMARC Setup Guide

Overview

Microsoft 365 (formerly Office 365) is the second-most deployed business email platform. Its SPF record uses a single include:spf.protection.outlook.com directive, costing 1 DNS lookup. Like Google Workspace, it's efficient on its own but adds up quickly when combined with other email services. Organizations still on legacy Office 365 plans or those that refer to the service as O365 internally should note that the SPF include mechanism is identical across all Microsoft 365 plan tiers — the spf.protection.outlook.com record covers Exchange Online regardless of license level.

DKIM signing in Microsoft 365 uses two selectors — selector1 and selector2 — which allow Microsoft to rotate keys without downtime. DKIM must be enabled in the Microsoft Defender portal (formerly the Security & Compliance Center). Microsoft generates 2048-bit RSA keys by default. You'll need to publish two CNAME records that point to Microsoft's DKIM infrastructure.

DMARC alignment works straightforwardly with Exchange Online since messages are sent from the org domain. Organizations using shared tenancies or custom routing rules should test alignment in monitoring mode (p=none) before enforcing a stricter policy.

Additional Setup Notes

DKIM CNAME Record Format

Microsoft 365's DKIM setup uses CNAME records rather than TXT records. The CNAMEs follow the pattern selector1._domainkey.yourdomain.com pointing to selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com. This delegation approach lets Microsoft manage the actual DKIM keys while you control the DNS delegation.

The CNAME target includes your tenant name (the .onmicrosoft.com prefix assigned when you created your Microsoft 365 tenant). If you don't know your tenant name, find it in the Microsoft 365 admin center under Settings > Org Settings > Organization profile. Getting the tenant name wrong is one of the most common DKIM setup failures — the CNAME will resolve to nothing and DKIM verification will fail silently.

Enabling DKIM in the Defender Portal

DKIM activation has moved between Microsoft admin interfaces several times. As of the current portal layout, navigate to Microsoft Defender > Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM. Select your domain and click "Enable." If the CNAME records are not yet published, the portal will show an error — publish the records first, wait for DNS propagation, then enable.

For organizations managing multiple domains in a single Exchange Online tenant, each domain needs its own pair of CNAME records and must be enabled individually. DKIM does not propagate from one domain to another within the same tenant.

Hybrid Exchange Deployments

For organizations using both Microsoft 365 and on-premises Exchange servers in a hybrid deployment, you may need to include additional IP ranges in your SPF record. On-premises servers that route outbound mail directly to the internet (not through Exchange Online Protection) must have their public IPs listed in SPF. Use ip4: mechanisms for these — each IP adds zero DNS lookups to your budget.

If all outbound mail routes through Exchange Online Protection (the recommended hybrid configuration), the standard include:spf.protection.outlook.com covers both cloud and on-premises sending. This is the configuration Microsoft recommends, and it keeps your lookup count at 1 for the Microsoft side.

Migrating from Office 365 to Microsoft 365

Organizations that set up email authentication under the Office 365 branding do not need to change any DNS records. The SPF include (spf.protection.outlook.com) and the DKIM CNAME targets have remained stable through the rebrand. However, the admin portal URLs and navigation paths changed significantly — documentation referencing the "Office 365 Security & Compliance Center" now maps to the Microsoft Defender portal.

If your O365 tenant was created before Microsoft enabled DKIM by default for new tenants (a change rolled out gradually in 2023-2024), DKIM may still be disabled. Check the Defender portal to confirm. Tenants created before this change require manual DKIM enablement.

Troubleshooting

Error 5.7.23 — SPF Validation Failed

If you see 5.7.23 SPF validation errors, the most common cause is a missing or malformed SPF record. Microsoft 365's inbound mail flow strictly checks SPF and will reject messages that fail validation. Make sure your SPF record includes spf.protection.outlook.com and doesn't exceed the 10-lookup limit.

Other causes of 5.7.23:

1. Multiple SPF records — Your domain has more than one TXT record starting with v=spf1. SPF requires exactly one record per domain. Merge them into a single record.
2. Syntax errors — A missing space, a typo in include:, or ~all vs -all placement issues. Use an SPF checker to validate syntax.
3. Lookup limit exceeded — If your SPF record exceeds 10 DNS lookups, Microsoft's inbound evaluator returns PermError, which is treated as a fail. Managed SPF can flatten your record to stay within the limit.

Error 5.7.708 — IP Blocked by Exchange Online

The 5.7.708 error means Exchange Online received a message from an IP address that isn't authorized in the sender's SPF record. This commonly happens when:

• A third-party service sends on your behalf but isn't included in your SPF record.
• Your on-premises mail server's public IP changed (common with dynamic IP ranges from ISPs).
• You added a new email gateway or relay and forgot to update SPF.

Check the IP address in the bounce message and verify it's covered by your SPF record. If it should be there and isn't, add it with an ip4: mechanism or the appropriate include:.

DKIM Not Signing After Enablement

If you've enabled DKIM in the Defender portal but outgoing messages still lack a DKIM-Signature header, check the following:

1. CNAME propagation — Query both selector1._domainkey.yourdomain.com and selector2._domainkey.yourdomain.com to confirm they resolve correctly.
2. Tenant name mismatch — The CNAME target must exactly match your tenant's .onmicrosoft.com domain, with dots replaced by hyphens in the domain portion.
3. Connector overrides — Custom mail flow connectors in Exchange Online can sometimes bypass DKIM signing. Check your outbound connector configuration.
4. DNS proxy interference — If you use Cloudflare or a similar DNS proxy, ensure the CNAME records are set to DNS-only mode (not proxied).

Shared Tenancy and Multi-Org Alignment

Organizations in shared or partner-managed Microsoft 365 tenancies may encounter DMARC alignment issues if the tenant configuration routes mail through a shared infrastructure. In these setups, the Return-Path or DKIM signing domain may not match your From domain. Work with your Microsoft partner or reseller to ensure your domain's mail flow is isolated from other tenants in the shared environment.

For Enterprise organizations evaluating Exchange Online as part of a broader Microsoft 365 E3 or E5 license, DKIM and DMARC capabilities are included at no additional cost — they just need to be activated. There's no premium tier required for email authentication features.