Email Authentication: SPF, DKIM, DMARC, ARC, BIMI

Email authentication is not one thing. It is a small stack of independent standards that each answer a narrow, different question, and they are routinely conflated. People say “we set up SPF so we’re authenticated,” or treat DMARC as a spam filter. Neither is right. This page is the map: what each layer actually checks, what a passing result proves, and - just as important - what it does not.

The 60-second version

Layer	RFC	What it checks	What a pass proves	What it does NOT prove
SPF	7208	the sending IP against the envelope MAIL FROM (and optionally HELO) domain	the IP was authorized to use that domain in the envelope	anything about the visible From:, the content, or whether the mail is wanted
DKIM	6376	a cryptographic signature tied to the d= domain	the d= domain took responsibility and the signed parts were not modified in transit	that d= is the author’s domain, or that the message is wanted
DMARC	9989 (+9990/9991)	the visible From: domain, via aligned SPF or DKIM	the From: domain was used with authorization	inbox placement, content safety, or reputation
Alignment	9989	the relationship between an authenticated identifier and the From: domain	(it is the rule that ties SPF/DKIM to DMARC, not a separate check)	-
ARC	8617	the chain of intermediaries that relayed a message	what authentication looked like before an intermediary changed the message	the trustworthiness of any handler; ARC is advisory
BIMI	bimigroup.org	nothing about the message itself	(it relies entirely on DMARC)	authentication; it is a logo display layer, not a security control

The one sentence to remember: SPF and DKIM are the two ways to authenticate; DMARC is the policy that says which authenticated identity has to match the From: you can see.

What each layer actually proves

SPF answers: “was this IP allowed to use this envelope domain?”

SPF lets a domain owner publish, in DNS, the list of hosts authorized to send mail using their domain in the MAIL FROM or HELO identity. A verifier checks the connecting SMTP client’s IP against that list (RFC 7208 §1, §2.2).

What it does not touch: the From: header the recipient sees. SPF validates the envelope sender, which is invisible in most mail clients and is frequently a different domain than the visible From:. That gap is exactly why SPF alone never stopped From:-header spoofing, and why DMARC had to exist.

DKIM answers: “did the d= domain sign this, and is the signed part intact?”

DKIM attaches a cryptographic signature so that a domain can “claim some responsibility for a message by associating the domain with the message” (RFC 6376 §1). A valid signature proves two things and only two things: the message was signed by something holding the private key for the d= domain’s published public key, and the signed parts have not been modified since signing (RFC 6376 §1.5).

RFC 6376 §1.5 is explicit that a DKIM signature “asserts nothing else.” It does not prove d= is the author’s domain, and a signature failure does not force rejection (RFC 6376 §1).

DMARC answers: “does an authenticated identity match the From: the human sees?”

DMARC is the layer that connects the other two to the visible From:. A message passes DMARC when SPF or DKIM passes and that passing identifier is aligned with the From: domain (RFC 9989 §4.1, §4.4). Either one is enough; you never need both.

Critically, RFC 9989 §4.1 states a DMARC pass “indicates only that the use of the Author Domain has been validated” and carries no “value assertion about that message.” DMARC proves authorized domain use. It is not a content scanner, a reputation system, or an inbox-placement guarantee. The full breakdown of the 2026 DMARC standard lives on the DMARC in 2026 page.

Alignment is the glue (and the usual point of failure)

SPF and DKIM each authenticate some domain. Alignment is the rule that says that domain has to relate to the From: domain for DMARC to pass.

• Relaxed alignment (the default): the authenticated identifier shares the same Organizational Domain as From:. foo.example.com and news.example.com are relaxed-aligned because both reduce to example.com (RFC 9989 §3.2.10.1, §4.4).
• Strict alignment: the authenticated identifier domain is identical to the From: domain (RFC 9989 §3.2.10.2).

This is where well-meaning setups fail silently. An ESP can produce a perfectly valid SPF pass on its bounce domain and a valid DKIM signature on its domain, yet DMARC still fails because neither authenticated domain aligns with your visible From:. Authentication passing is not the same as DMARC passing.

One more alignment fact people get wrong: for DMARC, SPF is evaluated only against the MAIL FROM identity, not HELO (RFC 9989 §3.2.4, §4.4.2). And DMARC can pass on DKIM alone even when SPF fails, as long as an aligned signature validates.

ARC: the rescue for forwarded and list mail

SPF and DKIM both break in predictable ways when a message passes through an intermediary. SPF breaks because the forwarder sends from a different IP that is not in your SPF record; DKIM breaks when a mailing list rewrites the subject or appends a footer, changing the signed content (RFC 8617 §1, §2).

ARC (Authenticated Received Chain) addresses this by recording an authenticated “chain of custody”: each participating handler records what authentication looked like when the message arrived, so a downstream receiver can see the original result even after the message was modified (RFC 8617 §1, §2).

Two honest caveats, both normative:

• ARC is advisory, not a pass. A receiver may use a valid ARC chain to override a DMARC failure, but it is not obligated to (RFC 8617 §7). ARC “is not a trust framework” - a malicious actor can seal spam (RFC 8617 §9.3).
• It is not widely deployed. As of RFC 9989’s publication in 2026, methods like ARC “have not become widely used” (RFC 9989 §7.4).

Details on the three header fields and chain validation are on the ARC page.

BIMI: the visible payoff, sitting on top of everything

BIMI (Brand Indicators for Message Identification) is the only layer here a recipient can see directly: a brand logo in the inbox. It authenticates nothing itself. It “leverages an organization’s DMARC deployment” and a logo only displays if the message passes DMARC at enforcement (BIMI Group, implementation guide).

So BIMI is the top of the stack, not a substitute for any of it. No DMARC, no logo. The BIMI page covers the SVG Tiny PS requirement, mark certificates, and the provider-support reality.

How they fit together (the flow)

                      ┌─────────────┐        ┌─────────────┐
   sending IP ──────► │     SPF     │        │    DKIM     │ ◄── signature
   (MAIL FROM)        │  (RFC 7208) │        │ (RFC 6376)  │     over content
                      └──────┬──────┘        └──────┬──────┘
                             │                      │
                       authenticated          authenticated
                       MAIL FROM domain        d= domain
                             │                      │
                             └───────┬──────────────┘
                                     ▼
                        ┌──────────────────────────┐
                        │   ALIGNMENT with From:    │   ◄── DMARC asks:
                        │       (RFC 9989)          │       does either aligned?
                        └─────────────┬─────────────┘
                                      ▼
                            DMARC pass / fail
                                      │
                  (enforced DMARC)    ▼
                        ┌──────────────────────────┐
                        │      BIMI logo shown      │
                        └──────────────────────────┘

   ARC (RFC 8617) runs alongside: it carries the pre-forwarding
   authentication result so a receiver can recover a broken SPF/DKIM.

What did NOT change / common confusion

• “We have SPF, so we’re authenticated.” SPF authenticates the envelope, not the visible From:. Without aligned SPF or DKIM, DMARC still fails.
• “DMARC needs both SPF and DKIM to pass.” No. DMARC passes on either one, as long as it is aligned (RFC 9989 §4.4).
• “A DMARC pass means the mail is safe / will inbox.” No. It proves authorized domain use and nothing about content, reputation, or placement (RFC 9989 §4.1).
• “DKIM proves who wrote the message.” No. It proves the d= domain took responsibility and the signed bytes are intact - not authorship (RFC 6376 §1.5).
• “BIMI is a security feature.” BIMI displays a logo; it authenticates nothing and does nothing without enforced DMARC.

What Egressif does

We treat these as one system, not a checklist. On the domains we operate, SPF and DKIM are both published and both aligned to your From:, so DMARC has two independent ways to pass and a single broken source does not silently drop your mail. We watch the alignment results in DMARC aggregate reports, because the failure mode that hurts is not “no authentication” - it is authentication that passes for the wrong domain. Where forwarding and lists are in play, we design around the fact that SPF and DKIM break there by default, rather than pretending they do not.