# How do I set up SPF and DKIM for Microsoft 365? > Configure SPF and DKIM for a Microsoft 365 custom domain, enable signing in Defender, and validate alignment with DNS, headers, and DMARC reports. To set up SPF and DKIM for a Microsoft 365 custom cloud domain, publish one SPF TXT policy that authorizes Microsoft 365 and every other legitimate sender. Then open the DKIM page in Microsoft Defender, copy both tenant-specific CNAME records, publish them in DNS, and enable signing after they resolve. Finish by sending a new message to an external mailbox and checking its authentication results. ## Quick takeaways - A domain must have one SPF policy, not one record per sending service. - Microsoft 365 commercial cloud mail normally uses `include:spf.protection.outlook.com`, but sovereign clouds and complex mail flows need the instructions for their environment. - Custom-domain DKIM requires two tenant-specific CNAME records. - Copy DKIM targets from your tenant because examples and another tenant's values will not work. - A green portal status does not replace an external delivered-message check or DMARC reports. ## What should I check before configuring Microsoft 365? Confirm that the custom domain is added and accepted in Microsoft 365, that you can edit its authoritative DNS zone, and that you have permission to manage email authentication in Microsoft Defender. Inventory every service that sends with the domain in the visible From address. This includes Microsoft 365, marketing platforms, ticketing systems, scanners, and on-premises relays. Microsoft's [current SPF guidance](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) says a domain must have one SPF TXT record and that the policy should remain below the protocol's ten-DNS-lookup limit. Do not publish a second SPF policy for Microsoft 365. Merge authorized sources into the existing policy and remove a source only after confirming it no longer sends. This guide covers a custom domain sending through the commercial Microsoft 365 cloud. Government, China-operated, hybrid, and on-premises environments can use different routes or values. Follow the official instructions for the tenant and actual mail path. > Copy both DKIM CNAME targets from the Microsoft Defender portal or Exchange Online PowerShell for the domain you are configuring. Tenant names, partition identifiers, and target formats can vary. Never paste values from a tutorial or another tenant into production DNS. ## Which setup method should I use? Use the Microsoft Defender portal for an interactive setup and clear status display. The documented path is `Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM`. Select the custom domain to view its signing state and the two CNAME records it expects. Use Exchange Online PowerShell when you need repeatable administration across several domains or the portal does not expose the values clearly. The DNS targets still come from the tenant. PowerShell does not make example targets safe to reuse. ## How do I set up SPF and DKIM for Microsoft 365? ### 1. Confirm the custom domain and sending inventory Verify that users send from the custom domain and list every authorized outbound service. Decide whether Microsoft 365 sends directly, receives mail from an on-premises system, or relays through another gateway. This determines what the SPF policy must authorize and which message path you need to test. ### 2. Publish one SPF policy At the root of the custom domain, create or update a single TXT record beginning with `v=spf1`. For a straightforward commercial Microsoft 365 cloud setup, authorize Microsoft with `include:spf.protection.outlook.com`, preserve other legitimate senders, and end with the failure behavior chosen for the domain. Do not flatten Microsoft's include into copied IP addresses. Microsoft can change the addresses behind the include. Check the result with Palisade's [SPF checker](/tools/spf), including the number of DNS-based lookups. ### 3. Open the Microsoft Defender DKIM page In Microsoft Defender, go to `Email & collaboration > Policies & rules > Threat policies > Email authentication settings`, then choose the `DKIM` tab. Select the custom domain. Microsoft's [current DKIM guide](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure) documents this path and the domain status flow. ### 4. Copy both tenant-specific CNAME records If the domain does not have keys, create them in the portal when prompted. Copy both CNAME owner and target pairs shown for the domain. The owner labels normally begin with `selector1._domainkey` and `selector2._domainkey`, but the targets are tenant-specific. Microsoft changed the target format used for newly provisioned custom domains in 2025. That is another reason to use the values displayed by the current tenant instead of reconstructing a target from an older example. ### 5. Publish both CNAME records and wait for resolution Create both CNAME records in the authoritative DNS zone. Some DNS providers append the root domain automatically, so enter the relative owner when the interface expects it. Resolve each complete owner publicly and compare the returned target character for character with Microsoft Defender. Use Palisade's [DKIM checker](/tools/dkim) for each selector. Do not enable signing after only one selector resolves. Microsoft uses two selectors so it can rotate keys without interrupting authentication. ### 6. Enable DKIM signing and send an external test Return to the domain flyout and enable `Sign messages for this domain with DKIM signatures`. If Microsoft still reports a missing CNAME, recheck both public records and wait for DNS caches before changing correct values. After the domain reports a valid signing state, send a new message through the production route to a mailbox outside the Microsoft 365 tenant. Inspect the receiver-added headers rather than relying on a message delivered internally. The free [email deliverability test](/tools/email-deliverability-test) provides an external address for exactly this: send to it and it parses the receiver-added headers for you, reporting the DKIM result, the signing domain and selector, and whether the signature aligned with your From domain. ## How does this setup affect DMARC? DMARC evaluates whether an authenticated SPF or DKIM identifier aligns with the visible From domain. Under the [current DMARC standard](https://www.rfc-editor.org/info/rfc9989), either aligned path can produce a pass. Microsoft 365 DKIM signing gives custom-domain mail a stable aligned path when the signature uses that domain. SPF can also align, but forwarding often breaks SPF and complex relays can change the MAIL FROM identity. Configure and validate DKIM even when SPF already passes. Microsoft's [DMARC deployment guidance](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure) recommends identifying legitimate senders before moving a policy toward enforcement. Use Palisade's [DMARC checker](/tools/dmarc) to inspect the published policy. Keep one record at `_dmarc`, preserve reporting addresses during planned changes, and use aggregate evidence before increasing enforcement. ## How do I validate the setup? ### Check public DNS Resolve the root SPF TXT record and both DKIM selector CNAMEs from outside the DNS provider. Confirm there is one SPF policy, the Microsoft include is correct for the environment, the lookup count is safe, and both selectors point to the exact values supplied by the tenant. ### Check the Microsoft 365 status Open the custom domain on the Defender DKIM tab. The domain should show a valid state and signing should be enabled. Statuses such as `NoDKIMKeys` or `CnameMissing` identify a tenant or DNS prerequisite, but they do not prove the behavior of a later message. ### Inspect a delivered message Send a new message to an external mailbox and inspect the receiver-added `Authentication-Results` field. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601) defines this field and its trust boundary. Confirm `dkim=pass`, record the DKIM `d=` domain, and compare it with the visible From domain. Also record the SPF, MAIL FROM, and DMARC results. Test each materially different path, including direct cloud mailbox mail, applications, relays, and hybrid transport. One successful Outlook message does not validate every service using the domain. ### Review DMARC reports Review aggregate reports after normal traffic appears. Confirm Microsoft 365 source volume, the observed DKIM domain, SPF identity, alignment, and disposition. Separate Microsoft traffic from third-party senders so a correct tenant configuration does not hide another platform's failures. ## Troubleshooting ### The domain has more than one SPF record Merge the authorized mechanisms into one policy at the root domain. Do not delete a record until you identify the service that uses it. Multiple SPF policies can produce a permanent error instead of authorizing both services. ### SPF exceeds the DNS lookup limit Inventory includes, redirects, MX mechanisms, and other lookup-producing terms. Remove retired senders and redesign the policy with the service owners. Do not flatten Microsoft's include into static addresses because those addresses can change. ### Microsoft Defender shows CnameMissing Resolve both selector owners publicly and compare their targets with the current tenant values. Check for a repeated domain suffix, a typo, a proxy feature, or a CNAME created in the wrong DNS zone. Wait for caches before repeatedly replacing correct records. ### Only selector1 resolves Publish selector2 as well. Both CNAMEs are required for Microsoft-managed key rotation. Recheck that the second owner was not copied over the first and that no conflicting record exists at the same name. ### DKIM passes but DMARC fails Compare the DKIM `d=` value and visible From domain. The message may use the tenant's default domain, a different custom domain, or another route. Fix the sending identity or authentication scope rather than weakening the DMARC policy. ## Check the Microsoft 365 domain beyond the portal Run Palisade's [Microsoft compliance checker](/tools/microsoft-compliance-checker) after the Defender status is valid. It evaluates public authentication requirements, but it cannot see private tenant settings, prove that every Microsoft or third-party route used the intended identity, or guarantee future delivery. Microsoft 365 is often only one sender in a domain's mail ecosystem. Palisade's DMARC Agent turns aggregate-report data into a prioritized list of sender, SPF, DKIM, and DMARC issues. It detects when authentication and alignment conditions indicate that a domain is ready for the next policy stage, then proposes the move for your team to review and apply. This human-in-the-loop workflow helps you progress toward `p=reject` while keeping policy changes under your control. Stronger authentication helps protect your domains and supports better email deliverability. Palisade does not administer Microsoft 365, change DNS autonomously, control recipient decisions, guarantee inbox placement, or apply a DMARC policy change without human approval. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=vendor_setup&utm_content=dkim-for-office-365) ## Frequently asked questions ### Does Microsoft 365 sign the onmicrosoft.com domain automatically? Yes. Microsoft configures DKIM for the initial `onmicrosoft.com` domain, but that does not replace custom-domain signing. Configure DKIM for the domain readers see in the From address. ### Do I need both DKIM selectors? Yes. Publish both tenant-specific CNAME records. Microsoft alternates selectors during key rotation, so a setup with only one selector is incomplete even if a single test happens to pass. ### Should I create a second SPF record for Microsoft 365? No. A domain should have one SPF policy. Add the correct Microsoft 365 authorization to the existing policy and retain every other legitimate sender that still uses the domain. ### Can I copy Microsoft 365 DKIM targets from another guide? No. The targets contain tenant-specific values and their format has changed over time. Copy both records from Microsoft Defender or Exchange Online PowerShell for the exact custom domain. ### Does this procedure cover hybrid mail flow? Only partly. The DNS and Defender steps still matter, but hybrid transport can change the outbound route and authentication identity. Inventory the actual path and test external delivery through every materially different route. ### Will valid Microsoft 365 SPF and DKIM guarantee inbox placement? No. Authentication supports identity and DMARC alignment, but receivers also consider reputation, content, complaints, traffic patterns, and other signals. Treat it as necessary technical groundwork, not a delivery guarantee.