The standard Microsoft 365 setup — one SPF include, two DKIM CNAMEs, a DMARC record — covers a tenant that only sends through Exchange Online. It stops covering you the moment a hybrid relay, a second verified domain or a third-party sender enters the picture. This guide covers those cases.
Hybrid: on-premises relay still sending
In a hybrid deployment, mail can leave through Exchange Online, through an on-premises server, or through both depending on the connector. Each path needs its own authorisation:
- SPF — add the on-premises public IPs with
ip4: mechanisms. If the range is large or changes, this is where the 10-lookup budget becomes a real design constraint.
- DKIM — Exchange Online signs at the point of egress. Mail relayed through on-premises infrastructure without passing through the service may leave unsigned.
- Headers — a relay can rewrite the envelope sender. Check a real message with the Header Analyzer rather than assuming the path.
Do not simply widen SPF until things pass. If a relay is rewriting the envelope domain to something you do not control, SPF cannot succeed no matter what you publish, and the fix belongs in the connector configuration.
DKIM key rotation without an outage
Microsoft 365 publishes two selectors so rotation can happen without a gap. The pattern is the same one used by virtually every DKIM implementation:
- Both selectors are published and resolvable. One signs, the other is idle or holds the previous key.
- To rotate, generate a new key on the idle selector and publish it. Wait for DNS propagation across the record's TTL.
- Switch signing to the new selector. Mail signed by the old selector still verifies because its public key remains published.
- After the maximum verification window has passed, retire the old key and reuse that selector for the next rotation.
Rotating immediately after a compromise is different: publish the new key, switch signing at once, and accept that in-flight mail signed with the old key may fail. Verify the new key with the DKIM Checker before and after the switch.
Subdomain governance with sp=
By default, a subdomain inherits the parent's p= policy. That is usually too blunt. If marketing.example.com is delegated to an ESP that is not fully authenticated, a single parent policy of reject will silently kill those campaigns.
Publish a separate DMARC record on the subdomain, or use sp= on the parent to set a different subdomain policy. Subdomains that send nothing at all should carry an explicit v=DMARC1; p=reject of their own — this is the cheapest defence against spoofing of a name you never use.
Multiple verified domains in one tenant
Each verified domain is authenticated independently. Enabling DKIM for one does not enable it for another, and a tenant can easily end up with three domains, two of which are signing and one of which is quietly failing. Audit per domain, not per tenant:
FAQ
Can I use -all with a hybrid relay?
Yes, provided every egress IP is authorised. The risk is not -all itself but an incomplete list — a relay added later without updating SPF will fail hard.
Does DKIM rotation require a DNS outage window?
No. Publishing the new key before switching signing is what makes rotation seamless. The outage pattern only appears when both steps happen at once.
Should every subdomain have its own DMARC record?
Every subdomain that sends should. Every subdomain that never sends should have a reject policy anyway, to prevent someone else using it.
