For a Microsoft 365 custom email domain, configure SPF for the correct Microsoft cloud, publish both DKIM CNAMEs issued for your tenant, enable signing, and inspect an externally delivered message. Do not build DKIM targets from an old tutorial: Microsoft introduced a new target format for new custom domains in May 2025. Microsoft DKIM documentation.
This guide covers custom-domain outbound mail through Exchange Online, commonly searched for as Office 365 SPF or Office 365 DKIM setup. It distinguishes commercial Microsoft 365 from sovereign-cloud environments. It does not configure every Microsoft product, an independent bulk sender, or an on-premises Exchange server simply because the organization also has Microsoft 365.
Map employee mail and application mail separately
Before editing DNS, list each source using the domain: Outlook mailboxes, CRM tools, printers, website forms, billing services, on-premises servers, and gateways. Note the visible From address, envelope sender, outgoing transport, administrator, and recipient population. Include subsidiaries and sending subdomains rather than treating the tenant as one uniform mail stream.
Microsoft distinguishes authenticated client submission, connector-based SMTP relay, Direct Send, and High Volume Email. Direct Send and High Volume Email do not relay to the internet in Microsoft’s comparison. A successful internal device message therefore cannot establish external delivery or authentication for an application. Microsoft’s device and application sending comparison.
For an unfamiliar route, stop at identification before changing SPF. Ask the application owner for its configured destination and a recent message header. Do not enable legacy authentication, relax connector restrictions, or add broad IP ranges merely to make an authentication test pass. Those are separate security decisions.
Which SPF record does Microsoft 365 use?
If Microsoft 365 is the only sender for the domain, Microsoft documents these TXT policies by environment:
- Commercial Microsoft 365 and GCC:
v=spf1 include:spf.protection.outlook.com -all - GCC High and DoD:
v=spf1 include:spf.protection.office365.us -all - Microsoft 365 operated by 21Vianet:
v=spf1 include:spf.protection.partner.outlook.cn -all
Choose the policy for your actual tenant, not your company’s physical location. Publish at the relevant sending domain through its DNS host. Subdomains sending through Microsoft 365 need their own SPF configuration; the parent’s SPF policy does not automatically cover them. Microsoft’s cloud-specific SPF guidance.
For mixed-source domains, retain legitimate existing authorizations and merge necessary changes into one SPF policy. Do not append a second complete v=spf1 record. Save the before-and-after values and review obsolete services separately. SPF checks the SMTP envelope domain, so an unrelated provider’s bounce domain may be the domain evaluated even when the visible From address is yours.
SPF evaluation has a ten-term limit for DNS-querying mechanisms and modifiers, with nested processing counted. A second SPF policy at the same name produces a permanent error. -all produces fail for an unmatched source; it does not itself guarantee a particular receiver’s delivery decision. SPF specification, RFC 7208.
Before configuring DKIM, confirm the custom domain has been added and verified in the tenant, identify the authoritative DNS host, and use an administrator with appropriately delegated DKIM-management permissions. Check Microsoft’s current permission requirements rather than granting Global Administrator solely for this task. Microsoft DKIM prerequisites.
Get both DKIM CNAME targets from the tenant
In the appropriate Microsoft Defender portal, open Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM. Select the custom domain and obtain its required CNAME values. Publish both, then enable signing after detection. For a new configuration, the portal can initially show a missing-CNAME error while exposing the required values. Microsoft DKIM setup.
Use this worksheet without guessing the destinations:
selector1._domainkey: CNAME to the exact Selector1 target supplied for this domain.selector2._domainkey: CNAME to the exact Selector2 target supplied for this domain.- Zone: the intended custom domain or subdomain.
- Target source: tenant portal output or Exchange Online PowerShell.
The names above are relative owner names. Your DNS host may append the zone automatically. Inspect the resulting fully qualified name before saving, especially when configuring a subdomain. A CNAME destination is a hostname, not an HTTPS URL or a TXT public key.
New-format targets contain a Microsoft-assigned dynamic partition component. Existing configurations can use the older format. Do not convert a working record just to match a screenshot, and do not publish both old and new targets at one selector. The tenant output is authoritative for the required destination. Microsoft DKIM record formats.
Administrators already connected to Exchange Online PowerShell can inspect the configuration using this read-only example, replacing example.com:
Get-DkimSigningConfig -Identity example.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME
Save the output with the change request. If no configuration exists, follow Microsoft’s setup workflow rather than inventing targets or treating an empty result as success. Access to the command depends on the administrator’s permissions. Get-DkimSigningConfig reference.
Publish safely and inspect public answers
Export relevant DNS records first. Check whether either selector already exists, identify who owns it, and resolve conflicts before replacement. Do not delete another service’s record without understanding the effect. Keep ordinary domain-verification TXT records and inbound MX routing unchanged during this outbound-authentication task.
Publish both selectors as DNS-only CNAME aliases, not HTTP redirects or proxied website records. At each CNAME owner, do not add conflicting TXT, A, AAAA, MX or a second CNAME. Preserve any existing _domainkey delegation and resolve shared dependencies with the DNS administrator rather than deleting them.
The required end state is a literal CNAME answer for each tenant-issued selector, pointing to its exact Microsoft target. Where available, turn the relevant per-record Flatten control off and ensure applicable zone-wide settings do not suppress these aliases. Cloudflare documents that flatten-all cannot be overridden per record, that apex CNAMEs are flattened by default, and that same-zone targets are flattened regardless of the setting. These are conditional DNS-host behaviors, not universal field names. Coordinate a supported, dependency-safe configuration if global settings or mandatory apex/same-zone behavior prevent the required answer; do not blindly disable flattening for an entire shared zone or remove a delegation. Recheck both public selector answers afterward. Cloudflare CNAME-flattening controls.
After saving, run read-only public lookups or use an equivalent DNS inspection tool:
dig TXT example.com
dig CNAME selector1._domainkey.example.com
dig CNAME selector2._domainkey.example.com
Replace example.com with your domain. Compare both returned targets with tenant output character for character. Follow the CNAME chain to the public DKIM key when diagnosing lookup failure. A syntactically plausible record pointing somewhere else is not a successful configuration.
Keep three timestamps: when DNS changed, when the authoritative answer became correct, and when Microsoft’s status updated. This prevents repeated edits while cached answers are expiring. Missing CNAME publication or incomplete propagation can prevent the DKIM toggle from working. Microsoft authentication troubleshooting.
Prove the result with an external message
Send a fresh message from the configured custom-domain mailbox to an external account under your control. Do not use an internal-only message as the sole acceptance test. Preserve the raw received headers and identify which receiving system produced the authentication assessment. Establish which Authentication-Results fields were produced inside that receiving service’s known processing boundary and how it removes or treats externally supplied result fields. Use the receiver’s documented handling or ask its administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; ignore attacker-supplied or otherwise untrusted fields. Authentication-Results security requirements.
For each test, record the route, visible From domain, envelope domain, SPF result, DKIM d= domain and s= selector, DKIM result, and DMARC result. A DKIM key is looked up using the signature’s selector and signing domain. The presence of a signature is different from successful verification. DKIM specification, RFC 6376.
DMARC needs a passing SPF or DKIM identity aligned with the visible From domain. Strict alignment requires identical domains; relaxed alignment uses the same organizational domain. A passing result for a provider-owned identity alone does not prove alignment with your brand. Current DMARC specification, RFC 9989.
For this custom-domain DKIM setup, acceptance requires the intended Microsoft 365 signature to pass DKIM, its d= signing domain to align with the intended branded visible From under the effective policy, and the trusted receiver to report dmarc=pass. Match the observed selector to the tenant configuration. A rewritten provider From, an unrelated passing signature or DMARC passing through SPF alone does not prove the intended DKIM setup works. Assess SPF independently: investigate fail, softfail, neutral, none, temperror and permerror even when aligned DKIM supplies DMARC pass.
Repeat the test for applications and gateways. A CRM using an independent provider needs evidence from that provider’s real sending path. Likewise, a footer service can produce a different result from an untouched mailbox message. Keep passing and failing routes separate in the completion record.
Add DMARC without weakening an existing policy
Inspect TXT at _dmarc.YOUR-FROM-DOMAIN first, and check whether a parent policy applies when no exact-domain record exists. Preserve existing enforcement and report destinations. Do not add a monitoring override that silently weakens an inherited policy. Microsoft’s custom-domain DMARC policy is also published through DNS. Microsoft DMARC setup.
Publish one DMARC policy as a TXT record at _dmarc of the exact visible From domain. Use the DNS host’s relative-name or fully qualified-name convention, without duplicating the domain. If a record already exists, edit only the approved policy rather than adding a second.
Only for a domain with no established applicable policy, an approved initial monitoring template is v=DMARC1; p=none; rua=mailto:APPROVED-REPORT-ADDRESS. Replace the entire address with an authorized, functioning report destination before publication. This is a template, not a record to copy unchanged. Monitoring does not request quarantine or rejection. DMARC policy specification.
Choose report access and retention deliberately because aggregate reports describe sending activity. Compare the Organizational Domain of the report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, which is not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization; a destination within the same Organizational Domain as that policy domain is excepted. A different hostname alone does not make the destination external. Verify the required authorization with the report destination rather than assuming a mailbox address is sufficient. This protocol check is separate from the owner’s approval to share report data with that recipient. DMARC aggregate-report authorization, RFC 9990 section 4.
After publication, run dig TXT _dmarc.example.com, replacing the domain, and save the returned policy. Confirm a fresh external message’s DMARC result, then review reports across the sending inventory before changing enforcement.
Troubleshooting common failures
SPF returns permerror: check for duplicate policies and excess nested lookups. SPF returns temperror: investigate temporary DNS problems before rewriting a correct policy. SPF fails for one route: inspect its final sending IP and envelope domain. Microsoft troubleshooting.
DKIM is missing: confirm the message traversed the intended signing service and the correct custom domain is enabled. DKIM fails after a gateway: inspect whether signed headers or body content changed. DKIM’s DNS lookup fails: compare the selector and target chain with the signature and tenant configuration. Microsoft troubleshooting.
SPF and DKIM pass but DMARC fails: compare the authenticated domains with the visible From domain rather than adding more authorizations. Plan DMARC policy changes around known legitimate sources and reporting. Microsoft describes a staged deployment, beginning with visibility and correcting authentication before enforcement. Microsoft DMARC setup.
If employee mail uses Microsoft 365 while an application uses SES, configure that separate route with the Amazon SES authentication guide.