Skip to main content
IT KORR
IT KORRKeeping Organizations Reliable & Resilient
Knowledge Center

Email Authentication Architecture: How SPF, DKIM, and DMARC Work Together

Why SPF and DKIM alone do not protect a domain, what "alignment" actually means, and the decision flow a receiving mail server follows.

4 min read

Most explanations of email authentication describe SPF, DKIM, and DMARC as three separate things to configure. That's true but incomplete — the part that actually determines whether spoofed email gets blocked is how the three work together, specifically a concept called alignment that a surprising number of otherwise-correct configurations get wrong.

The three standards, briefly

SPF (Sender Policy Framework) is a DNS TXT record listing which mail servers are authorized to send email claiming to be from your domain. A receiving server checks the IP address the message actually came from against this list.

DKIM (DomainKeys Identified Mail) is a cryptographic signature added to outgoing messages, verified against a public key published in your DNS. It proves the message content wasn't altered in transit and that it was genuinely signed by a system holding the corresponding private key.

DMARC (Domain-based Message Authentication, Reporting & Conformance) is a policy record that tells receiving servers what to do when SPF and/or DKIM fail — and, critically, defines the alignment requirement that connects the other two standards to the domain a human actually sees in their inbox.

The part everyone gets wrong: authenticated is not the same as aligned

SPF and DKIM each authenticate a domain — but not necessarily the domain in the message's visible "From" header.

SPF authenticates the Return-Path domain (also called the envelope sender or MAIL FROM domain) — a technical field most email clients never display.

DKIM authenticates the d= domain in the DKIM signature — which the signer chooses, and which also isn't necessarily the visible From domain.

DMARC's job is to check whether either of those authenticated domains aligns with the domain in the visible From header the recipient actually sees. A message can pass SPF, pass DKIM, and still fail DMARC if neither authenticated domain matches (or is a subdomain of) the visible From domain.

Sender

Message sent from your domain

SPF Check

Is the sending IP authorized?

DKIM Check

Is the signature valid?

DMARC Alignment

Does SPF or DKIM align with the From domain?

Receiving System

Applies your DMARC policy: none, quarantine, or reject

Authenticated ≠ AlignedSPF/DKIM can both pass and DMARC can still fail if neither aligns with the visible From domain.
SPF and DKIM are checked independently. DMARC then evaluates whether either one aligns with the visible From address — alignment, not just a pass/fail on SPF or DKIM alone, is what actually determines the outcome.

This is precisely the gap DMARC exists to close: without it, an attacker can send a message with a fraudulent visible "From: [email protected]" while technically passing SPF/DKIM using a different, attacker-controlled domain for the parts a recipient never sees. DMARC forces the alignment check that makes that spoofing technique fail.

Two alignment modes

DMARC supports strict and relaxed alignment (configured independently for SPF and DKIM via the aspf and adkim tags):

  • Relaxed (the default) allows the authenticated domain to be an exact match or a parent/subdomain relationship with the visible From domain (e.g., mail.yourcompany.com aligns with yourcompany.com).
  • Strict requires an exact match.

Relaxed alignment is appropriate for most organizations, particularly those using subdomains for different sending purposes (marketing platforms, transactional email services) under one parent domain. Strict alignment is a meaningful additional control for organizations with a specific reason to require it, but it will break legitimate mail from subdomain-based senders that aren't configured to match exactly.

Why all three standards matter together

A domain with only SPF configured is not protected from DKIM-based spoofing techniques (and vice versa), and neither SPF nor DKIM alone enforces anything — they only produce a pass/fail signal. Without DMARC, a receiving server has no domain-provided instruction on what to do with a failing message, and defaults to whatever heuristic that particular mail provider uses, which varies and which you don't control.

This is why an assessment finding "SPF configured, no DMARC" is a materially different (and more urgent) risk than it might first appear: the authentication signal exists, but nothing is acting on it, and the domain still has no enforced protection against visible-From spoofing.

Practical next steps

Run IT KORR's SPF/DKIM/DMARC Checker to see your domain's current configuration across all three standards, including live DMARC alignment status. For deeper SPF-specific configuration issues (the DNS lookup limit, include chains), see SPF Configuration and Troubleshooting. For DKIM selector and key issues, see DKIM Configuration and Troubleshooting. For policy enforcement strategy, see DMARC Policy and Reporting.

If your organization sends through Microsoft 365, IT KORR's Microsoft 365 Management service can coordinate email authentication configuration alongside broader tenant governance.

Operational Support

Need help implementing these findings?

IT KORR can coordinate DNS configuration, email authentication setup, and Microsoft 365 governance alignment. We work with your current providers — no migration required.

No commitment required — we respond within one business day.

Build: 7b54ed9 | Built: Jul 21, 2026 9:32 PM EDT