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.
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:
ip4: mechanisms. If the range is large or changes, this is where the 10-lookup budget becomes a real design constraint.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.
Microsoft 365 publishes two selectors so rotation can happen without a gap. The pattern is the same one used by virtually every DKIM implementation:
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.
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.
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:
-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.
No. Publishing the new key before switching signing is what makes rotation seamless. The outage pattern only appears when both steps happen at once.
Every subdomain that sends should. Every subdomain that never sends should have a reject policy anyway, to prevent someone else using it.