SPF, DKIM, and DMARC: a safer rollout for Microsoft 365 email

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.

1. Confirm that each domain has one syntactically valid SPF policy and that all required senders are represented without creating an excessive lookup chain.
2. Enable DKIM signing for Microsoft 365 custom domains and obtain the vendor-specific setup for every third-party sender.
3. Publish a DMARC record with an aggregate reporting address and begin with an observation policy while reports are reviewed.
4. Correct legitimate alignment failures, isolate specialized senders on appropriate subdomains where useful, and retest forwarded and automated mail.
5. 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.