About This Article
This article was created using an automated generation workflow powered by generative AI. It is organized by reviewing SPF (RFC 7208), DKIM (RFC 6376), DMARC (published in 2026 as RFC 9989), and the latest Microsoft 365 email authentication documentation.Verification Status: 📘 Current RFCs and Microsoft 365 official information verified · PowerShell DNS check sample implemented · Execution verification not yet performed
Where Do SPF, DKIM, and DMARC Apply? — Understanding All Three Through the Flow of a Single Email
SPF, DKIM, and DMARC do not perform the same authentication three times. SPF primarily links the sending IP and the MAIL FROM domain, DKIM links the signing domain and the message, and DMARC connects the user-visible From domain with the authentication results and alignment of SPF and DKIM.
When researching DMARC as of 2026, use RFC 9989 as the baseline rather than the older RFC 7489. RFC 9989 obsoletes both RFC 7489 and RFC 9091.
- Superimposing Them on a Single Email
- SPF Does Not Authenticate the “From Field Itself”
- DKIM Signs the Message
- DMARC Evaluates Alignment with the From Domain
- Try It Now: Inspecting Your Domain’s DNS
- Cautions When Reading Older Articles in 2026
- Do Not Treat the Three as Isolated in Microsoft 365
- GitHub Sample
- Official and Primary Sources
Superimposing Them on a Single Email
sequenceDiagram
participant S as Sending server
participant D as DNS
participant R as Receiving server
participant U as User
S->>R: SMTP message
R->>D: SPF: MAIL FROM側ドメインの許可情報を確認
D-->>R: SPF policy
R->>D: DKIM: d=署名ドメインの公開鍵を確認
D-->>R: DKIM public key
R->>R: SPF/DKIMの認証結果を評価
R->>D: DMARC policyを確認
D-->>R: DMARC policy
R->>R: Fromドメインとのalignmentを評価
R-->>U: 最終的な配送・処理
SPF Does Not Authenticate the “From Field Itself”
SPF checks whether the received SMTP connection source is authorized to send emails for the target domain, using an SPF record in DNS. In RFC 7208, identities checked include MAIL FROM and HELO.
What is important here is that this operates at a different layer than the From: header displayed in email clients. Official Microsoft 365 documentation also explains that SPF alone does not verify the alignment between the MAIL FROM domain and the From domain.
DKIM Signs the Message
With DKIM, the sender attaches a cryptographic signature to the message, and the receiver retrieves the public key via DNS to verify it. The signature indicates the signing domain via d=.
This allows verification of whether the headers and body included in the signature scope have been tampered with after signing. However, simply passing DKIM does not guarantee that the d= domain matches the user-visible From domain.
DMARC Evaluates Alignment with the From Domain
DMARC evaluates alignment centering on the RFC 5322 From: domain against domains authenticated via SPF or DKIM.
Roughly summarized, their relationship is as follows:
| Mechanism | Primary Focus | Relationship with DMARC |
|---|---|---|
| SPF | SMTP sender and SPF identity | Checks if the authenticated SPF domain aligns with the From domain |
| DKIM | Signature and d= domain | Checks if the authenticated DKIM signing domain aligns with the From domain |
| DMARC | From domain, SPF/DKIM results, and policy | Determines DMARC pass/fail including alignment |
DMARC additionally incorporates policies and reporting mechanisms published by the domain owner.
Try It Now: Inspecting Your Domain’s DNS
Beyond reading about how it works, you can check what is published in public DNS using PowerShell. The following is for reference only and does not change any DNS settings.
TXT directly under the domain serving as the SPF candidate:
Resolve-DnsName -Name example.com -Type TXT
DMARC:
Resolve-DnsName -Name _dmarc.example.com -Type TXT
DKIM requires a selector. For example, if you use an environment like selector1, you can first check the CNAME, considering cases where it is delegated via CNAME like in Microsoft 365.
Resolve-DnsName -Name selector1._domainkey.example.com -Type CNAME Resolve-DnsName -Name selector1._domainkey.example.com -Type TXT
Please replace example.com and selector1 with your own environment. Selector names vary depending on services and configurations.
What you are looking at here are public DNS records. You cannot determine that a single actual email has passed SPF/DKIM/DMARC based solely on these results. For real emails, you must verify the alignment across headers such as Authentication-Results, MAIL FROM, the DKIM d=, and the display From address.
A PowerShell version consolidating multiple queries is also available on GitHub.
Cautions When Reading Older Articles in 2026
DMARC explanatory articles have cited RFC 7489 for years. However, the current RFC Editor has published RFC 9989 as a Proposed Standard, obsoleting RFC 7489 and RFC 9091.
Therefore, you must check the current RFCs rather than treating older material as authoritative simply because “RFC 7489 says so.” This is an easily overlooked pitfall when rewriting legacy technical articles using AI.
Do Not Treat the Three as Isolated in Microsoft 365
Official Microsoft 365 documentation also explains SPF, DKIM, and DMARC as interconnected components. In real-world operations, your own senders, third-party sending via SaaS, forwarding, and subdomains are involved; hence, rather than simply copying sample DNS records, you should audit your email pathways first.
Focusing strictly on the structural positioning of these mechanisms, we do not uniformly recommend operational values such as specific instances of p=reject.
