DMARC, SPF, DKIM, and BIMI.
How the four email authentication standards relate to each other. What each one does, why all four are needed, and the order in which to implement them.
Email authentication is a stack, not a menu—each protocol builds on the last, creating a foundation strong enough to display your brand logo in the inbox.
The Foundation: SPF and DKIM
Before BIMI can display your logo, receiving mail servers need proof that your email is legitimate. That proof comes from two protocols working in tandem.
SPF (Sender Policy Framework) answers a simple question: is this mail server authorized to send email for your domain? You publish a DNS TXT record listing approved IP addresses and servers. When your email arrives, the receiving server checks whether it came from one of those approved sources.
DKIM (DomainKeys Identified Mail) takes a different approach. Rather than validating the source, it validates the content. Your mail server cryptographically signs each outgoing message using a private key. The receiving server uses your public key—also published as a DNS TXT record—to verify the signature. If the message was altered in transit, the signature breaks.
SPF says "this server is allowed to send for us." DKIM says "this message hasn't been tampered with." Both are necessary. Neither is sufficient alone.
The Policy Layer: DMARC
DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on SPF and DKIM to create an enforcement framework. It answers the critical question those protocols don't: what should happen when authentication fails?
A DMARC record is a DNS TXT entry that specifies your policy—p=none, p=quarantine, or p=reject. It also enables reporting, sending you aggregate and forensic data about who's sending email claiming to be from your domain.
DMARC requires at least one of SPF or DKIM to pass, with an additional alignment check: the domain in the From header must match the domain that passed authentication. This prevents a common spoofing technique where attackers pass SPF or DKIM for their own domain while forging your address in the visible From field.
The policy setting determines what happens to mail that fails:
p=none— Monitor only. Collect reports but don't enforce.p=quarantine— Send failed messages to spam.p=reject— Block failed messages entirely.
The Brand Layer: BIMI
BIMI (Brand Indicators for Message Identification) is the visible reward for implementing proper authentication. When your email passes DMARC, participating mailbox providers display your brand logo next to your message.
But BIMI has a strict prerequisite: DMARC must be set to enforcement. Specifically, p=quarantine or p=reject. A policy of p=none isn't enough.
This requirement isn't arbitrary. BIMI is a trust indicator. Displaying your logo tells recipients "this message is definitely from this brand." That guarantee only holds if you're actually blocking or filtering unauthenticated email. Without enforcement, attackers could pass authentication checks while spoofing your domain.
Implementation Order
The relationship between these protocols dictates a specific implementation sequence:
- Deploy SPF — Authorize your sending sources
- Deploy DKIM — Sign your outgoing mail
- Deploy DMARC at p=none — Start collecting data
- Monitor and remediate — Identify legitimate sources failing authentication
- Escalate to p=quarantine — Begin enforcement
- Escalate to p=reject — Full enforcement
- Implement BIMI — Display your logo
The most common mistake is rushing to BIMI before DMARC reaches enforcement. A logo without a reject or quarantine policy will simply not display. The second most common mistake is jumping to p=reject without monitoring—potentially blocking legitimate email from partners, vendors, or legacy systems you'd forgotten about.
Each protocol solves a specific problem. Together, they create a chain of custody from your mail server to your recipient's inbox, with your logo as the visible proof that chain is intact.