Microsoft 365: Setting Up SPF, DKIM, and DMARC Correctly in Exchange Online

Microsoft 365 takes a lot of email authentication work off your hands, but not all of it. For the initial domain ending in onmicrosoft.com, Microsoft sets up SPF and DKIM itself. For your own domain, the one your team actually sends from, you create the records in DNS yourself. If they are missing or do not match, your emails land in spam, get rejected, or fraudsters send emails in your name.

This article shows the setup for Exchange Online. The free guide Email security: SPF, DKIM, and DMARC in five steps covers the general basics with examples for other mail systems.

Why this topic should not wait

Large mailbox providers now explicitly require authentication. Since May 5, 2025, Microsoft has required domains that send more than 5,000 emails per day to Outlook.com, Hotmail, and Live addresses to pass SPF and DKIM and to have DMARC with at least p=none, aligned with SPF or DKIM. Non-compliant messages are rejected with the error 550 5.7.515. Since February 1, 2024, Google has imposed comparable requirements on senders with more than 5,000 messages per day to Gmail accounts.

Regardless of sending volume: only DMARC links the visible sender address to SPF and DKIM (RFC 9989). This is exactly the address fraudsters spoof in business email compromise and phishing.

Clarify the starting point: who sends with your domain?

Get an overview before making any change. The free Microsoft 365 domain check shows whether your domain belongs to a Microsoft tenant and what the status of SPF, DKIM, DMARC, and Autodiscover is. In addition, record every service that sends with your domain:

• Exchange Online itself and, if applicable, an on-premises Exchange server in a hybrid deployment
• Newsletter and marketing services, CRM, ticketing system, online shop, and accounting
• Multifunction devices, monitoring, and web forms that send via SMTP
• Domains that send no email at all

Microsoft recommends handling bulk and marketing email through a separate subdomain, such as marketing.ihredomain.at. Problems with this email then do not harm the reputation of your main domain, and each subdomain has its own budget of SPF lookups.

Step 1: SPF for Exchange Online

For a domain that sends only through Microsoft 365, the record according to Microsoft is v=spf1 include:spf.protection.outlook.com -all. If your own server also sends, its public address goes in front with ip4:. SPF cannot be configured in Microsoft 365: you create the TXT record with your DNS provider.

• Exactly one record per domain and subdomain. Two records with v=spf1 lead to a permanent error (RFC 7208).
• At most ten DNS lookups through include, a, mx, exists, and redirect, including nested records. Every additional service with its own include uses up part of this budget.
• -all instead of ~all. Microsoft recommends the hard fail, because DMARC decides what happens to messages that fail.
• No flattening of the Microsoft record. The sending addresses of Exchange Online change; include:spf.protection.outlook.com therefore stays an include.
• Parked domains without mail traffic get v=spf1 -all.

Step 2: Enable DKIM for your own domain

DKIM passes the DMARC check only if the signing domain matches the domain in the sender address. A signature from the onmicrosoft.com domain does not match ihredomain.at. Therefore, enable DKIM for every domain and subdomain of your own that you send with. The advantage over SPF: a DKIM signature usually survives forwarding, SPF does not.

1. In the Microsoft Defender portal, go to Email & collaboration, Policies & rules, Threat policies, Email authentication settings, open the DKIM tab, and select the domain.
2. Create the two CNAME records shown, selector1._domainkey and selector2._domainkey, with your DNS provider. Copy the targets exactly from the portal or from Get-DkimSigningConfig: for domains added since May 2025, Microsoft uses a new format ending in dkim.mail.microsoft; older domains point to their onmicrosoft.com domain.
3. Enable signing as soon as Microsoft detects the records. This takes a few minutes, sometimes longer.
4. Check the key length. If you create DKIM with New-DkimSigningConfig and do not specify a size, you get 1024 bits; RFC 8301 recommends 2048 bits. Rotate-DkimSigningConfig -Identity ihredomain.at -KeySize 2048 switches over. A rotation takes 96 hours, and the new length initially applies only to the next active selector.

Both CNAME records are mandatory: without selector2, the key cannot be rotated.

Step 3: DMARC in stages up to p=reject

Microsoft's goal for all of your own domains and subdomains is p=reject, introduced in stages so that no legitimate email is lost. The record is a TXT record at _dmarc.ihredomain.at.

1. Monitor: v=DMARC1; p=none; rua=mailto:dmarc@ihredomain.at. The aggregate reports show which servers send with your domain and whether they pass SPF and DKIM with alignment. Analyze them with a tool or service; the XML reports are not meant to be read by hand.
2. Quarantine: Once all legitimate senders pass, p=quarantine follows.
3. Reject: After a further monitoring phase, p=reject follows.

RFC 9989 recommends first publishing p=none for at least one month and p=quarantine for just as long, and comparing the results (Section 7.4). If you publish p=reject, you must not rely on SPF alone but must sign validly with DKIM. Do not rush the switch: as soon as your domain publishes p=quarantine or p=reject, Microsoft delivers outbound emails that fail DMARC at the recipient through a separate high-risk delivery pool.

Be careful with older guides: Microsoft's examples still contain the pct tag. The DMARC standard RFC 9989, published in May 2026, removed it; for test phases, t=y is available instead.

Two more records belong to this:

• The onmicrosoft.com domain. Microsoft sets up SPF and DKIM for it, but not DMARC. You create the record in the Microsoft 365 admin center under Settings, Domains; Microsoft suggests v=DMARC1; p=reject for this.
• Parked domains. v=DMARC1; p=reject together with v=spf1 -all, but without DKIM records: without a public key, no forged signature can pass.

Step 4: Evaluate inbound email correctly

DMARC works in both directions. For inbound messages, the anti-phishing policy in Microsoft Defender controls whether Exchange Online honors the sender's DMARC policy. The setting "Honor DMARC record policy when the message is detected as spoof" is enabled by default: messages from domains with p=quarantine then go to quarantine, and messages from domains with p=reject are rejected.

• Upstream filtering gateway: If your MX record does not point directly to Microsoft 365, enable enhanced filtering for connectors. Only then does Exchange Online recognize the actual sender, and only then is the sender's DMARC policy applied at all.
• Forwarding and distribution lists: If legitimate emails from a service fail DMARC because the service modifies or forwards them, Microsoft recommends adding it as a trusted ARC sealer instead of bypassing spam filtering.
• Reports: Microsoft 365 sends DMARC aggregate reports only if your MX record points directly to Microsoft 365. Microsoft 365 never sends failure reports (ruf).

Checklist for Exchange Online

• All senders and domains are recorded; marketing email runs through a subdomain.
• Exactly one SPF record per domain with include:spf.protection.outlook.com and -all, at most ten lookups.
• DKIM is enabled for every sending domain, both selectors are in DNS, and the keys have 2048 bits.
• DMARC with rua is published, and the reports are analyzed.
• The stages p=none, p=quarantine, and p=reject are planned and scheduled.
• The onmicrosoft.com domain and all parked domains have DMARC with p=reject.
• DMARC evaluation of inbound email is active; with an upstream gateway, enhanced filtering is set up.

Frequently asked questions

Is SPF enough if we only use Microsoft 365?

No. SPF checks only the technical sender in the email envelope and fails with forwarding. Microsoft itself states that SPF alone is not enough. Only DMARC connects the visible sender address with SPF and DKIM.

Do subdomains need their own records?

Every subdomain that sends email needs its own SPF record and its own DKIM configuration. The DMARC policy of the main domain also applies to all subdomains unless you specify otherwise.

How long does the path to p=reject take?

That depends on how many services send with your domain. RFC 9989 specifies at least one month per stage; according to the standard, it can also take many months until all senders are properly authenticated.

On request, the TOMORIS EXPERTS for Microsoft Security handle the setup in your tenant or review your existing configuration. The glossary explains terms such as Exchange Online and DNS.

Sources

• Microsoft Learn: Set up SPF to identify valid email sources
• Microsoft Learn: Set up DKIM to sign mail from your cloud domain
• Microsoft Learn: Set up DMARC to validate the From address domain
• Microsoft Learn: Recommended settings for EOP and Microsoft Defender for Office 365
• Microsoft Learn: Anti-phishing policies, spoof protection, and sender DMARC policies
• Microsoft Learn: Enhanced filtering for connectors in Exchange Online
• Microsoft Learn: Configure trusted ARC sealers
• Microsoft Tech Community: Outlook’s New Requirements for High-Volume Senders, April 2, 2025, updated April 30, 2025
• Google Workspace Admin Help: Email sender guidelines
• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures and RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 9989: DMARC, Section 7.4 and Appendix A.6, as well as RFC 9990: DMARC Aggregate Reporting