Forged sender addresses and domain-based spoofing attacks continue to be among the most effective attack vectors in email traffic. In the Microsoft 365 world, SPF, DKIM and DMARC are important and necessary building blocks for protecting sender domains, optimizing deliverability and making abuse transparent. However, consistent, technically sound implementation and ongoing operation are crucial. In this article, I will show you how to correctly implement DKIM and DMARC in Microsoft 365, what pitfalls there are and how to efficiently secure operations.
Definition of terms: SPF, DKIM, DMARC
- SPF (Sender Policy Framework) defines which IP addresses or hosts are allowed to send emails on behalf of your domain. SPF is easy to implement, but often breaks when forwarding.
- DKIM (DomainKeys Identified Mail) provides outgoing emails with a cryptographic signature that is generated by the sending MTA. The signature remains intact during forwarding as long as the content and header are not changed.
- DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy of the From: domain. It controls enforcement and reporting based on SPF and DKIM alignment. DMARC is considered passed if either SPF or DKIM is aligned PASS.
Alignment: Relaxed vs. Strict
DMARC distinguishes between relaxed (r) and strict (s) alignment. Relaxed allows subdomains (e.g. header.d=mail.graber.cloud, From=graber.cloud), strict requires exact alignment (header.d=graber.cloud, From=graber.cloud). For maximum security, strict is recommended as soon as all legitimate flows are cleanly aligned.
DKIM and DMARC go hand in hand. If you have multiple domains, each one must be activated separately and assigned its own CNAMEs. For subdomains with their own From: field, activate DKIM separately or use a specific DMARC sp policy for all subdomains. If a disclaimer or signature is added after signing, DKIM will break. Signing must always take place on the final outgoing hop. So check your mail flow topology carefully and only proceed if you are sure.
Requirements in Microsoft 365
But before you start, make sure of the following:
- The domain is verified in Microsoft 365.
- You have access to the public DNS of the domain.
- A correct SPF record is published (e.g. v=spf1 include:spf.protection.outlook.com -all).
- Necessary role (Global/Exchange Admin or Security Admin).
Implement DKIM in Exchange Online
The aim is for outgoing mails from your domain to be signed by Exchange Online. The process is divided into three core steps:
Create DKIM DNS records
Two CNAMEs must be created in the public DNS for each domain to be signed:
- selector1._domainkey. → CNAME to the host provided by Microsoft 365 for selector1.
- selector2._domainkey. → CNAME to the host provided by Microsoft 365 for selector2.
The exact target hosts are displayed in the Microsoft 365 Defender portal here. Important, only use these values - anything else will break your mail service.
Activate DKIM for the domain
DKIM can then be activated in the Microsoft Defender Portal as soon as the DNS entry has been created.
Alternatively, this can also be done via PowerShell:
Connect-ExchangeOnline
Get-DkimSigningConfig -Identity <domain>
Set-DkimSigningConfig -Identity <domain> -Enabled $trueImportant: The two CNAMEs must be visible in the DNS. If the portal reports "CnameMissing" (see PrintScreen above), check the DNS configuration and wait for the replication time, or check using CMD nslookup.
nslookup
set type=cname
selector1._domainkey.<domain>
selector2._domainkey.<domain>The status is then confirmed with "Valid" and the tobble is set to "Enabled".
Establish key rotation
Microsoft 365 uses two selectors (selector1/selector2) to enable zero-downtime rotation. Rotation is done via portal or PowerShell (Rotate-DkimSigningConfig -Identity ). Plan the rotation at least annually, preferably quarterly or semi-annually. It is best to test and automate this process.
Introducing DMARC - step by step and with reporting
The aim is to develop the policy from monitoring (p=none) to strict enforcement (p=reject) without excluding legitimate senders. This is how you proceed.
Prepare reporting addresses
Define the mail addresses for aggregate reports (rua), e.g. rua=mailto:dmarc-agg@domain.com. These mailboxes should be able to process reports automatically (e.g. a DMARC parser). Forensic/Failure Reports (ruf) is a detailed report on an individual email and is therefore optional and relevant to data protection.
Start with p=none (observe)
Publish a DNS TXT record _dmarc.:
v=DMARC1; p=none; rua=mailto:dmarc-agg@domain.com;The aim is to take an inventory of the station landscape and analyze the alignment. Check which SPF/DKIM aligned sources exist and where there is a need for action.
Clean up third-party/SaaS senders
Now identify all legitimate senders (Marketing, CRM, Ticketing, Scanner, ERP, CSPs). SPF and DKIM must be configured correctly for each sender. Best practice for external platforms with mail delivery is therefore to use a subdomain and manage SPF, DKIM and DMARC separately there. For example, news.domain.com
Increase policy level (quarantine)
Once the reports are stable, gradually increase the policy.
The tag “fo” is used to define the forensics. The value 1 defines that a report is generated as soon as the SPF or DKIM check fails. With "adkim=r” the DKIM alignment is set to ‘relaxed’ and thus also accepts subdomains such as sub..com. The same applies to the tag “aspf” which stands for SPF alignment.
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-agg@<domain>.com; fo=1; adkim=r; aspf=rKeep an eye on the report and gradually increase "pct" to 100 in steps of 25, i.e. 25, 50, 75 and 100.
Enforce policy (reject)
As soon as it is clear from the reports that everything is running correctly, set the policy to "reject" and the DKIM & DMARC alignment to "s" (strict).
v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc-agg@contoso.com; fo=1sp=reject protects subdomains if they do not have their own record. The adkim/aspf tags can be increased to strict if all legitimate mail flows are aligned 1:1.
Common errors and pitholes
- Incorrect record type: DKIM requires CNAMEs, not TXT for Microsoft 365.
- Incorrect entry: Target hosts of the CNAMEs vary - always use the values displayed in the portal.
- Too early enforcement: p=reject without cleanup blocks legitimate mails, especially from third-party providers.
- Only set to SPF: Forwarding breaks SPF. DKIM alignment is the more robust DMARC pillar.
- Subsequent content changes: Disclaimers/signatures that are inserted after the DKIM signature invalidate the signature. Signing at the last hop.
- Missing subdomain strategy: separate marketing/transaction mails cleanly (own subdomains, own DKIM/DMARC).
- No rotation: Rotate DKIM key regularly and automate rotation.
- No telemetry: rua/call is not configured or reports are not evaluated - so there is no security gain and monitoring.
Conclusion
With a clean initial implementation of DKIM and DMARC, a controlled, data-driven tightening up to p=reject and disciplined operation including rotation and monitoring, you can raise mail security in Microsoft 365 to a resilient level. If you integrate third-party senders at an early stage and segment subdomains cleanly, you will achieve high deliverability and minimize spoofing risks in the long term. DMARC and DKIM should always be used and should be standard.
Sources:
English 
German