# SPF, DKIM, and DMARC: a safer rollout for Microsoft 365 email > SPF, DKIM, and DMARC work together to authenticate sending infrastructure and align it with the address recipients see. A staged rollout helps protect a domain from spoofing without unexpectedly rejecting legitimate business mail. - Canonical URL: https://update.dsesecurity.com/updates/microsoft-365-spf-dkim-dmarc-safer-rollout/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T19:03:57+00:00 - Modified: 2026-07-19T19:03:57+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity - Reading time: 2 minutes ## What you need to know SPF, DKIM, and DMARC work together to authenticate sending infrastructure and align it with the address recipients see. A staged rollout helps protect a domain from spoofing without unexpectedly rejecting legitimate business mail. ## Potentially affected Organizations that send mail from Microsoft 365 or allow applications, websites, marketing platforms, ticketing systems, multifunction devices, or other services to use their domains. ## DSE recommendation Inventory every legitimate sender, configure SPF and DKIM for each sending path, monitor DMARC aggregate results, and move from observation to enforcement only after alignment failures are understood. ## Article ## Three controls, three different questions Email authentication is strongest when SPF, DKIM, and DMARC are treated as a coordinated system. SPF publishes which infrastructure may send for the envelope, or MAIL FROM, domain. DKIM adds a cryptographic signature so a receiving system can verify selected message elements and the signing domain. DMARC then checks whether an authenticated SPF or DKIM domain aligns with the domain in the visible From address and publishes a requested handling policy for failures. Passing SPF alone does not prove that the visible sender domain is authorized. Forwarding can also break SPF because the forwarding server becomes the apparent source. DKIM can survive forwarding when the signed content is unchanged, but a valid signature does not provide DMARC alignment unless its signing domain aligns with the visible From domain. DMARC supplies that missing alignment check. ## Build an authoritative sending inventory Before changing DNS, list every system that sends as each business domain. Include Exchange Online, line-of-business applications, customer communications platforms, scanners, website forms, monitoring tools, support systems, and vendors that send on the organization’s behalf. Document the visible From domain, envelope domain, DKIM signing domain, owner, and a test recipient for each path. Subdomains need deliberate treatment because an SPF record on a parent domain is not automatically inherited by a subdomain. - Confirm that each domain has one syntactically valid SPF policy and that all required senders are represented without creating an excessive lookup chain. - Enable DKIM signing for Microsoft 365 custom domains and obtain the vendor-specific setup for every third-party sender. - Publish a DMARC record with an aggregate reporting address and begin with an observation policy while reports are reviewed. - Correct legitimate alignment failures, isolate specialized senders on appropriate subdomains where useful, and retest forwarded and automated mail. - Advance deliberately toward quarantine or reject, watching aggregate reports and delivery telemetry after each change. ## Know what the records do not solve These records do not make every authenticated message trustworthy, stop display-name impersonation, or replace anti-phishing and user-awareness controls. A compromised legitimate account can still send authenticated mail. Mailing lists, forwarding services, and systems that modify message bodies can create legitimate failures; broad allowlisting can create a larger security problem than the original delivery issue. DNS hosting, third-party sender capabilities, and Microsoft 365 licensing and administration differ by tenant. Microsoft documents that its service does not send DMARC forensic reports; aggregate reporting and message trace should be planned accordingly. Preserve the previous DNS values, observe time-to-live behavior, and define a rollback point before enforcement. The goal is verified alignment for known senders and a controlled response to everything else, not an immediate switch to the strictest policy. ## Primary reference - Name: Microsoft Learn: Email authentication in Microsoft 365 - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-office-365/email-authentication-about - Source publication date: Not stated by the source ## Citation and use Preferred citation: “SPF, DKIM, and DMARC: a safer rollout for Microsoft 365 email,” DSE Security, https://update.dsesecurity.com/updates/microsoft-365-spf-dkim-dmarc-safer-rollout/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.