Correctly configure SPF, DKIM and DMARC for Microsoft 365 and verify with diagnostic tools

In this post we describe in practical terms how to correctly configure, validate and monitor SPF, DKIM and DMARC for Microsoft 365. The target audience is IT leadership, administrators and technical service providers who want to achieve secure mail flows without outages and with minimal false positives. This includes inventorying senders, DNS configuration, tests with local diagnostic tools, common error patterns, fallback strategies and operational monitoring cycles.

Kurzüberblick: Warum SPF, DKIM und DMARC zusammengehören

SPF (Sender Policy Framework) is a DNS TXT record that specifies which servers are authorized to send e-mail on behalf of your domain. DKIM (DomainKeys Identified Mail) appends a cryptographic signature to outgoing messages; the signature can be verified with a public key published in DNS. DMARC (Domain-based Message Authentication, Reporting & Conformance) is a policy layer that consolidates SPF and DKIM results, checks alignment and defines how receiving systems should handle unauthenticated messages as well as where reports (rua/ruf) should be sent.

Voraussetzungen und Inventarisierung

Before you make changes to DNS or Exchange Online, check:

• Which systems send e-mail for your domain? (Exchange Online, on-premises Exchange, multifunction devices, marketing platforms, CRM, third-party sending services)
• Who manages DNS? (internal DNS team, third party, CDN/DNS provider). DNS access is mandatory.
• Are subdomains involved? Some services send from sub.domain.tld and require their own records.
• Do you have access to the Microsoft 365 admin center and Exchange Online PowerShell?

A proper inventory reduces later outages: record each sending IP, each service and the responsible contact person in a table; also document whether a service signs messages (DKIM) or is only authorized via SPF.

SPF für Microsoft 365: Praktische Umsetzung

Standard recommendation for Microsoft 365 (Exchange Online): the domain must include Outlook/Exchange Online as an authorised sender. The typical minimum SPF is:

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

Explanation: include:spf.protection.outlook.com allows Microsoft’s outbound mail servers. The -all is a hard policy (Fail). During the testing phase ~all (SoftFail) is recommended so that legitimate, not-yet-registered services are not immediately rejected.

SPF mit Drittanbietern und das 10‑Lookup‑Limit

SPF has a technical limit: a maximum of 10 DNS lookups (include, a, mx, ptr, exists). If you have many third parties (e.g. marketing tools, sending services, authenticator e-mails), the lookups add up. Solutions:

• Consolidate services onto dedicated sending IPs or use dedicated subdomains for marketing to maintain separate SPF records.
• Use SPF‑flattening with caution: some providers replace includes with IP lists (this reduces lookups but can lead to larger TXT records).
• Check whether the third party provides dedicated IPs or a relay that you can include directly in SPF.

Beispiel: SPF mit mehreren Sendern

v=spf1 include:spf.protection.outlook.com include:spf.sendermarketing.example include:_spf.thirdparty.com ~all

Tip: Test changes first with ~all, monitor DMARC aggregate reports (rua) and switch to -all after a stable run. Tracking tools and logs help identify hidden senders.

DKIM in Microsoft 365: Concepts and setup

DKIM works with key pairs: a private key signs the outgoing message, a public key (as a DNS TXT under the selector name) enables signature verification. A selector is a prefix that allows different keys for rotation and subdomains (e.g. selector1._domainkey.example.com).

Microsoft 365: automatic or manual?

Microsoft 365 can manage DKIM for your custom domain. In the Microsoft 365 Defender / Security & Compliance portal two CNAME records are listed that you must create in DNS. These CNAMEs delegate the DKIM keys to Microsoft; Microsoft then signs the mails automatically. You find the target CNAME values in the Admin Center under „DKIM“ for the respective domain — copy the suggested values 1:1 into DNS.

Recommended procedure

1. Collect: Locate the required CNAME targets for your domain in the Admin Center.
2. DNS: Create the two CNAME records (for selector1 and selector2).
3. Enable: Turn on DKIM for the domain in the Defender/Microsoft 365 portal.
4. Test: Send test mails and check the headers for a valid DKIM signature.

If you prefer self-managed keys

Some organizations want to use their own private keys on their mail gateways. This is possible, but requires publishing the public key as a TXT under the selector and configuring the gateway signature correctly. Weigh the effort, key rotation and key management (e.g. KMS/HSM) and document the process rigorously.

DMARC policy: structure, reports and migration strategy

DMARC governs response and reporting. A typical DMARC record as TXT looks like:

v=DMARC1; p=quarantine; rua=mailto:dmarc-aggregate@yourdomain.example; ruf=mailto:dmarc-forensic@yourdomain.example; pct=100; adkim=r; aspf=r

Brief explanation: p is the policy (none/quarantine/reject). rua are aggregate reports (XML) sent regularly; ruf are forensic reports (sensitive and often privacy‑relevant). adkim and aspf control DKIM and SPF alignment: r = relaxed (partial matches allowed), s = strict (exact domain). You typically start with p=none to collect data, then p=quarantine and later p=reject.

Report extraction and analysis

Aggregate reports are XML files. For quick analyses on a Linux-/Bash host you can use xmlstarlet to extract IPs and volume. Example: extract all source IPs from a DMARC aggregate:

xmlstarlet sel -t -m '//record' -v 'row/source_ip' -n dmarc_report.xml | sort | uniq -c | sort -nr

This yields a list of source IPs with counts. For production environments a specialized DMARC analysis platform or a custom parser with storage in a SIEM/DB for trend analysis is recommended.

Diagnostic tools and testing sequence

Check using locally available tools and cloud services. Recommended test scenario:

1. DNS checks for SPF/DKIM/DMARC
2. Send test mails and analyze mail headers
3. Use Message Trace in Exchange Online
4. Analyze DMARC aggregate reports

DNS‑Checks (PowerShell / Bash)

Windows PowerShell with Resolve‑DnsName:

Resolve-DnsName -Name "example.com" -Type TXT
Resolve-DnsName -Name "selector1._domainkey.example.com" -Type TXT
Resolve-DnsName -Name "_dmarc.example.com" -Type TXT

Bash with dig:

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com

Header‑Analysis

Open a received test mail and look for Authentication-Results. Example:

Authentication-Results: mx.protection.outlook.com; spf=pass (sender IP is x.x.x.x) smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=pass (p=none) header.from=example.com

A practical approach: follow chronologically from bottom (Envelope‑From / smtp.mailfrom) to top (Header‑From) and check whether DKIM or SPF pass with alignment is present.

Message Trace in Exchange Online

Message Trace helps to check mail flows and authentication results. Example query (Exchange Online PowerShell):

Connect-ExchangeOnline -UserPrincipalName admin@yourtenant.onmicrosoft.com
Get-MessageTrace -StartDate 2026-07-01 -EndDate 2026-07-02 -SenderAddress sender@example.com | Select Received,SenderAddress,RecipientAddress,Subject,MessageTraceId

Message Trace provides delivery status and enables deeper analysis with Get-MessageTraceDetail. Use Trace combined with header analyses and DMARC reports.

SPF, DKIM and DMARC for Microsoft 365: operational knowledge and runbook

For ongoing operations it is important to automate checks, define responsibilities and have clear escalation paths. Below are practical additions you can adopt immediately into your runbook.

Automated DNS integrity check

A simple cron job can check for existence and basic integrity of the most important DNS records. Example: count the include: occurrences in SPF to monitor lookup risk:

#!/bin/bash
SPF=$(dig +short TXT example.com | tr -d '"')
echo "$SPF"
INCLUDES=$(echo "$SPF" | grep -o 'include:' | wc -l)
if [ "$INCLUDES" -gt 8 ]; then
  echo "Warnung: SPF includes = $INCLUDES" | mail -s "SPF Lookup Alert" ops-team@example.com
fi

This is a simple early warning; you should regularly check against the 10‑lookup limit in your monitoring.

Check DKIM status with PowerShell

Verify whether Microsoft 365 has enabled DKIM for your domain:

Connect-ExchangeOnline -UserPrincipalName admin@yourtenant.onmicrosoft.com
Get-DkimSigningConfig -Identity example.com | Format-List

This cmdlet shows whether DKIM is enabled and which selectors are used. Add this to your night-shift checks.

Rollback strategies and emergency measures

Any change to SPF/DKIM/DMARC requires a tested rollback plan. Good practice:

• Before changes: export current DNS records and store them versioned in your configuration repository.
• If a change causes a widespread delivery outage: set DMARC immediately to p=none, revert SPF to the previous version and disable newly activated DKIM selectors if possible.
• Communication: Inform affected departments (Marketing, Support) and arrange maintenance-window communication with an SLA for mail operations.

Operational Runbook: DMARC Escalation (Summary)

1. Check alert from the DMARC parser: volume, affected IPs, time window.
2. Check the Message Trace for the affected time periods and senders.
3. If legitimate senders are affected: immediately reset DMARC to p=none and temporarily adjust SPF/DKIM records.
4. After stabilization: gradually return to enforcement with monitoring.

Typical pitfalls and how to avoid them

• Incomplete inventory: missing sending systems lead to false positives. Keep the inventory list up to date.
• Underestimating DNS propagation: changes take time; plan maintenance windows.
• Neglecting key management: without rotation security risks increase. Define a rotation cycle (e.g., annually or semi-annually).
• Forensic reports (ruf) are data-protection sensitive: review retention and access control.

Compliance and data protection for DMARC reports

DMARC aggregate reports do not contain complete emails, but forensic reports can include sensitive information. Ensure the mailbox for rua/ruf is restricted, logged, and regularly cleaned. Document retention periods and who has access.

Conclusion

A secure mail operation with Microsoft 365 requires coordinated work on DNS, configuration in Microsoft 365, and monitoring. Start with a complete inventory, set SPF conservatively with ~all, delegate DKIM to Microsoft 365 via the CNAME values specified in the portal, and collect DMARC reports under p=none. Only when reports and the Message Trace show clean results should you increase enforcement gradually. Plan monitoring, key rotation, and clear rollback paths – this reduces outage risks and protects your domain from abuse.

Further links and internal references

Internal documents you should create as supplements: DNS change operations, runbook for mail outages, inventory list of all third parties, and a DMARC report dashboard. These artifacts enable rapid response and sustainable operations.

Operational architecture and integration notes

For stable operation, an architectural adjustment that separates sending flows logically is recommended: use dedicated subdomains (e.g. mails.example.com for transactions, news.example.com for marketing). This allows different DMARC enforcement levels, SPF sets, and DKIM selectors to be managed separately without risk to the primary domain.

Integration of external services and relay patterns

• If third parties do not provide a consistent DKIM signature, route their mail through a controlled relay (e.g., a company-owned SMTP gateway). There you can apply consistent signing and prevent header rewrites.
• APIs instead of SMTP: Many modern sending services offer HTTP APIs with integrated signing or authentication mechanisms. These reduce SPF lookup load and simplify IP management.

Operation, rotation and security

• Key rotation: plan DKIM rotation with at least two selectors (active/next). Test the switch in a staging subdomain before rotating in production.
• Key storage: use KMS/HSM for private DKIM keys, document access and recovery procedures.

Monitoring, Automation and Emergency Procedure

Integrate DMARC aggregate parsing into your SIEM or a small pipeline: automated tagging rules (e.g., new sending IP with high volume) generate alerts. Before major DNS changes, reduce TTLs, perform canary updates on a test subdomain and keep a versioned DNS backup ready. In an emergency: set DMARC immediately to p=none, roll SPF back to the previous TXT version and reactivate affected CNAME records. Document this procedure as a binding runbook step with contact details for the service owners and clear SLAs – this reduces time-to-recovery in critical incidents.

Email authentication and the SPF record are also important for this topic. This article places these aspects into context clearly and shows what matters in everyday operations.