SPF, DKIM and DMARC Explained

SPF, DKIM and DMARC are related email-authentication mechanisms, but they answer different questions. SPF checks whether the sending infrastructure is authorized for an envelope domain. DKIM verifies a cryptographic signature attached to a message. DMARC evaluates whether one of those authenticated identities aligns with the domain visible to the recipient and publishes a requested handling policy.

The identities in an email message

Email has more than one “from” value. SMTP uses an envelope sender—often surfaced as Return-Path—for delivery errors. The message has a visible From: header that people usually see. DKIM adds a signing domain in its d= tag. Confusing these identities leads to the common but incorrect claim that an SPF pass authenticates whatever address appears in the visible From field.

SPF: authorizing sending infrastructure

A domain publishes one SPF policy as a TXT record beginning v=spf1. A receiving mail system compares the connecting IP with mechanisms in the policy for the relevant SMTP identity. Mechanisms can authorize address ranges, MX hosts, A records or other included policies. The final qualifier—commonly -all or ~all—describes how non-matches should be classified.

SPF has a DNS-lookup limit and evaluation rules that make simplistic string inspection unreliable. Multiple SPF records at the same owner are not additive and can cause a permanent error. Forwarding is also difficult: the forwarder’s address may not be authorized by the original envelope domain, even though the message is legitimate. Sender Rewriting Scheme is one way forwarders address that issue.

DKIM: signing selected message content

A sender computes a cryptographic signature over selected headers and a canonicalized message body, then adds a DKIM-Signature header. That header identifies a signing domain (d=) and selector (s=). The receiver looks up selector._domainkey.domain in DNS to obtain the public key and verify the signature.

The selector lets a domain operate several keys and rotate them. A generic domain lookup cannot discover every possible selector, so the Email DNS Checker queries DKIM only when you supply one. Finding a public key does not prove that a particular message was signed or passed verification; that requires the message headers and body.

DKIM can survive ordinary forwarding because it does not authorize the latest connecting IP. It can fail when mailing software modifies signed fields or the body beyond what canonicalization permits. A valid signature proves that the signed content was associated with control of the signing domain’s key—not that every assertion in the message is true.

DMARC: alignment, policy and reports

DMARC is published at _dmarc.example.com. It looks for an SPF or DKIM pass whose authenticated domain aligns with the organizational domain in the visible From header. SPF alignment compares the envelope domain; DKIM alignment compares the signing domain. Alignment can be relaxed, allowing an appropriate subdomain relationship, or strict, requiring an exact domain match.

Receivers retain local discretion, and the published policy is not a guarantee of identical handling everywhere. Other tags can specify subdomain policy, percentage rollout, alignment modes and report destinations. Aggregate reports help domain operators discover legitimate senders and abuse patterns; report addresses should be managed with privacy and data volume in mind.

How the three complement one another

SPF is tied to the current SMTP path and can be disrupted by forwarding. DKIM travels with the message and can survive forwarding, but it depends on signature-preserving handling and key management. DMARC connects at least one passing mechanism to the user-visible From domain. A common deployment signs outgoing mail with aligned DKIM, authorizes direct senders with SPF, and gradually moves DMARC from monitoring toward an enforcement policy after legitimate sources are understood.

Only one aligned mechanism must pass DMARC, not necessarily both. Nevertheless, maintaining both gives resilience: aligned DKIM may carry forwarded mail, while SPF can authenticate direct infrastructure when a signature is absent or modified.

Common conceptual mistakes

• An MX record identifies inbound mail routing; it does not authorize outbound senders.
• An SPF record does not list every domain allowed in the visible From header.
• A DKIM DNS key does not show whether a mailbox or message is legitimate.
• p=none is a real monitoring policy, not the same as no DMARC record.
• DMARC protects domain use in visible From; it does not encrypt messages.
• These records do not verify that a mailbox exists.

Authentication is not deliverability

A message can pass SPF, DKIM and DMARC and still be filtered because of content, reputation, recipient policy, complaint history or rate behavior. A legitimate message can also fail because a sender, forwarder or DNS configuration is wrong. Authentication gives receivers structured evidence; it is not a promise that mail reaches the inbox.

Use the DNS Lookup for raw TXT or MX inspection and the Email DNS Checker for a cautious grouped view. Neither tool sends mail, contacts an SMTP service or tests a mailbox.