SPF, DKIM, DMARC & BIMI: The Complete Email Authentication Guide

Why Authentication Is the #1 Pillar of Deliverability

Email authentication is the foundation on which every other deliverability factor is built. Without it, nothing else matters — not your content quality, not your engagement rates, not your sender reputation. If your domain cannot prove that an email genuinely came from you, mailbox providers have no reason to trust it.

This has always been true in principle. But since February 2024, it has been enforced in practice. Google and Yahoo jointly announced new sender requirements that made SPF, DKIM, and DMARC authentication mandatory for anyone sending more than 5,000 emails per day. Microsoft followed with equivalent requirements for Outlook.com and Hotmail in 2025. The era of optional authentication is over.

The numbers are stark. Internal data from Google Postmaster Tools shows that domains lacking proper authentication see inbox placement rates plummet by 30-50 percentage points compared to fully authenticated senders. For a business sending 500,000 emails per month, that can mean 150,000 to 250,000 messages that never reach a subscriber's inbox — even though those subscribers opted in.

Authentication serves three purposes. First, it prevents spoofing: bad actors cannot forge your domain to send phishing emails. Second, it builds reputation: mailbox providers associate positive engagement signals with your authenticated domain. Third, it unlocks advanced features: BIMI brand logos, one-click unsubscribe headers, and AMP for email all require full authentication as a prerequisite.

The four protocols — SPF, DKIM, DMARC, and BIMI — build on each other in sequence. Think of them as layers of proof: SPF confirms the sending server, DKIM confirms the message integrity, DMARC sets the enforcement policy, and BIMI rewards you with visual brand trust in the inbox.

SPF (Sender Policy Framework)

SPF is the first layer of email authentication. Published as a DNS TXT record on your domain, it declares exactly which mail servers are authorized to send email on your behalf. When a receiving server gets an email claiming to be from your domain, it checks your SPF record to verify that the sending IP is on the approved list.

How SPF Works

Think of SPF as a guest list for a private event. Your domain is the venue, and you publish a list of approved guests (IP addresses and services) at the door (DNS). When someone shows up claiming to be on your list, the bouncer (the receiving mail server) checks the guest list. If the sender's IP is on the list, they get in. If not, the email is treated as suspicious.

The technical flow works like this:

1. You send an email from your domain (e.g., [email protected]).
2. Your ESP sends it from one of its IP addresses (e.g., 198.51.100.22).
3. The receiving server extracts the domain from the envelope sender (the Return-Path header).
4. It performs a DNS lookup on that domain for a TXT record starting with v=spf1.
5. It checks whether the sending IP is included in the SPF record.
6. The result is pass, fail, softfail, neutral, or temperror/permerror.

SPF Record Syntax Explained

An SPF record is a single TXT record published at the root of your domain. Here is a realistic example for a company that sends through Google Workspace, Mailgun, and HubSpot:

v=spf1 include:_spf.google.com include:mailgun.org include:spf.protection.outlook.com include:servers.mcsv.net ip4:203.0.113.50 -all

Let's break down each component:

• v=spf1 — Required version tag. Must be the first element. There is only version 1.
• include:_spf.google.com — Authorizes all IPs that Google Workspace uses for sending.
• include:mailgun.org — Authorizes Mailgun's sending infrastructure.
• include:spf.protection.outlook.com — Authorizes Microsoft 365 sending servers.
• include:servers.mcsv.net — Authorizes Mailchimp's sending servers.
• ip4:203.0.113.50 — Authorizes a specific IPv4 address (e.g., your on-premise mail server).
• -all — The hard fail qualifier: any IP not listed should be rejected.

The qualifier before all is critical:

• -all (hard fail) — Reject unauthorized senders. Recommended for production domains.
• ~all (soft fail) — Flag but don't reject. Use during initial setup only.
• ?all (neutral) — No opinion. Provides essentially no protection.

The 10 DNS Lookup Limit

SPF has a hard limit of 10 DNS lookups per evaluation. Every include:, a:, mx:, and redirect= mechanism counts as one lookup. Nested includes also count — if include:_spf.google.com itself triggers 3 more lookups, those count toward your total of 10.

Exceeding this limit causes a permerror, and the entire SPF check fails. The receiving server treats it as if you have no SPF record at all.

To stay under the limit:

• Count your lookups using an SPF analyzer tool (Boxset's DNS Health Check does this automatically).
• Replace include: with ip4: or ip6: where possible to eliminate nested lookups.
• Use an SPF flattening service that resolves includes into IP addresses (but be aware that flattened records become stale when ESPs rotate IPs).
• Remove ESPs you no longer use. Stale includes are the most common cause of bloated SPF records.

Common SPF Mistakes

Publishing multiple SPF records. A domain must have exactly one SPF TXT record. If you have two, the result is a permerror and both are invalidated. This often happens when a new team member adds a second record instead of editing the existing one.

Using +all or ?all. Both effectively disable SPF protection. Always use -all for production domains.

Forgetting subdomains. SPF records are not inherited by subdomains. If you send from mail.yourdomain.com, it needs its own SPF record.

Including deprecated services. Every time you switch ESPs, remove the old include. Leftover includes waste your lookup budget and authorize servers you no longer control.

Deep dive into SPF record setup -->

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to every email you send. It allows the receiving server to verify that (1) the email genuinely originated from your domain and (2) the message body and headers were not tampered with in transit. If SPF is the guest list, DKIM is the wax seal on the envelope.

How DKIM Works

DKIM uses public-key cryptography, but the concept is straightforward:

1. You generate a key pair: a private key (kept secret on your sending server or ESP) and a public key (published in your DNS).
2. When an email is sent, your server uses the private key to create a digital signature of the email's headers and body.
3. The signature is added as a DKIM-Signature header in the email.
4. The receiving server extracts the signature, looks up your public key in DNS, and uses it to verify the signature.
5. If the signature matches, the email passes DKIM. If the content was altered — even by a single character — the signature breaks and DKIM fails.

The DNS record for a DKIM public key looks like this:

selector1._domainkey.yourdomain.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3QEKyU1fSma0axspqYK5iAj+54lsAg4qRRCnpKZyiGfjxIZtWfXPRCGIxkeawSHC5MiVOFJGlSe/vQuHwP9GkOFPRY8Lkp5k30gXkfhBMOGlOfCbSVMz0bZR8RnhXGb3BJWRG9fCnxJBAxQqOt1FHQjE8gLbzyUvHBiRfCDOqwIDAQAB"

• selector1 is the DKIM selector — a label that lets you have multiple DKIM keys simultaneously.
• _domainkey is the required namespace.
• v=DKIM1 declares the DKIM version.
• k=rsa specifies the key type (RSA is standard; Ed25519 is emerging).
• p=... is the Base64-encoded public key.

Setting Up DKIM

Most ESPs handle DKIM key generation for you. The setup process typically follows this pattern:

1. In your ESP's settings, navigate to domain authentication or DKIM setup.
2. The ESP provides you with a CNAME or TXT record to add to your DNS.
3. You add the record to your domain's DNS zone.
4. The ESP verifies the record is published and begins signing outgoing emails.

DKIM Key Rotation

DKIM keys should be rotated periodically — ideally every 6 to 12 months. Rotation reduces the risk that a compromised private key could be used to forge signatures.

The rotation process uses DKIM selectors:

1. Generate a new key pair with a new selector (e.g., selector2).
2. Publish the new public key in DNS under the new selector.
3. Configure your sending server to sign with the new private key using selector2.
4. Keep the old selector1 public key in DNS for 7-14 days (so emails in transit or cached can still be verified).
5. Remove the old selector after the grace period.

Most ESPs handle rotation automatically when you use CNAME delegation. If you manage your own mail servers, you should build key rotation into your operational calendar.

DKIM Alignment for DMARC

DKIM alignment means that the domain in the d= tag of the DKIM signature matches the domain in the From: header of the email. This alignment is critical because DMARC requires either SPF or DKIM to be both passing and aligned.

There are two alignment modes:

• Relaxed alignment (default): The organizational domains must match. mail.yourdomain.com in the DKIM d= tag aligns with yourdomain.com in the From header.
• Strict alignment: The exact domains must match. mail.yourdomain.com does not align with yourdomain.com.

Most organizations use relaxed alignment. Strict alignment is reserved for high-security environments.

Deep dive into DKIM -->

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC is the policy layer that ties SPF and DKIM together. It tells receiving servers what to do when an email fails authentication and gives you reporting visibility into who is sending email using your domain — both legitimate and fraudulent.

How DMARC Ties SPF and DKIM Together

DMARC requires that at least one of SPF or DKIM passes and is aligned with the From domain. Here is the decision logic:

1. The receiving server checks SPF: Did it pass? Does the envelope domain align with the From domain?
2. The receiving server checks DKIM: Did it pass? Does the d= domain align with the From domain?
3. If either SPF or DKIM passes and aligns, DMARC passes.
4. If neither passes and aligns, DMARC fails, and the receiving server applies your DMARC policy.

A DMARC record is published as a DNS TXT record at _dmarc.yourdomain.com:

_dmarc.yourdomain.com IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=r; aspf=r; pct=100; fo=1"

• v=DMARC1 — Version tag (required, must be first).
• p=reject — Policy: reject emails that fail DMARC.
• rua=mailto:... — Where to send aggregate reports (daily XML summaries).
• ruf=mailto:... — Where to send forensic reports (per-failure details; not supported by all providers).
• adkim=r — DKIM alignment mode: relaxed.
• aspf=r — SPF alignment mode: relaxed.
• pct=100 — Percentage of failing emails the policy applies to.
• fo=1 — Forensic reporting option: generate a report if any mechanism fails.

The 3 Policies: none, quarantine, reject

DMARC offers three escalating policies:

p=none (monitoring only) — No action is taken on failing emails. Emails are delivered normally regardless of authentication results. Aggregate reports are generated so you can see who is sending as your domain. This is the starting point.

p=quarantine — Failing emails are sent to the spam/junk folder. This is the enforcement threshold — it protects your recipients from spoofed emails while giving you a safety net in case legitimate senders are misconfigured.

p=reject — Failing emails are rejected outright at the SMTP level. They never reach the recipient. This is the gold standard for domain protection and a prerequisite for BIMI.

The 90-Day Path to Full Enforcement

The industry best practice is a 90-day phased rollout from monitoring to full enforcement. This gives you time to discover and fix all legitimate sending sources before you start rejecting mail.

Reading DMARC Reports

DMARC generates two types of reports:

Aggregate reports (rua) arrive as daily XML files from each mailbox provider that received email from your domain. They contain: the source IP, the volume of emails, the SPF result, the DKIM result, the DMARC result, and the policy applied. Raw XML is difficult to read — use a DMARC report analyzer (or Boxset's built-in report parser) to visualize this data.

Forensic reports (ruf) contain details of individual failures. They are useful for diagnosing why a specific message failed but are not universally supported — Gmail, for example, does not send forensic reports due to privacy concerns.

Key things to look for in aggregate reports:

• Unauthorized sources sending as your domain (potential spoofing or forgotten services).
• Legitimate services failing DKIM (indicates a configuration issue or key problem).
• SPF failures from known IPs (often means a new sending IP was added by your ESP but not included in SPF).
• Alignment failures (SPF or DKIM passes but the domain doesn't match the From header).

Deep dive into DMARC policy -->

BIMI (Brand Indicators for Message Identification)

BIMI is the newest email authentication standard, and it's the visible reward for getting your authentication right. It places your verified brand logo directly in the inbox next to your email, turning authentication from a behind-the-scenes technical requirement into a tangible brand asset.

What BIMI Does

When a recipient sees your email in their inbox, BIMI displays your official brand logo in the avatar/sender image slot. Instead of a generic initial or silhouette, your subscribers see your recognizable brand mark. Gmail, Apple Mail, Yahoo Mail, and Fastmail all support BIMI as of 2025.

The technical mechanism: a receiving server checks your BIMI record in DNS, retrieves your logo (in SVG Tiny PS format), verifies your VMC (Verified Mark Certificate), and displays the logo if all checks pass.

A BIMI DNS record looks like this:

default._bimi.yourdomain.com IN TXT "v=BIMI1; l=https://yourdomain.com/brand/logo.svg; a=https://yourdomain.com/brand/vmc.pem"

• v=BIMI1 — Version tag.
• l= — URL to your brand logo in SVG Tiny PS format.
• a= — URL to your Verified Mark Certificate (VMC).

Requirements

BIMI has strict prerequisites:

1. DMARC at p=quarantine or p=reject — This is non-negotiable. BIMI will not function without DMARC enforcement. Your DMARC policy must be at quarantine with pct=100 at minimum.
2. A trademarked logo — Your logo must be a registered trademark with an approved intellectual property office (USPTO, EUIPO, CIPO, etc.).
3. A Verified Mark Certificate (VMC) — Issued by a certificate authority (DigiCert or Entrust are the two current issuers). The VMC validates that you own the trademark and control the domain. VMCs currently cost approximately $1,200-$1,500/year.
4. SVG Tiny PS format — Your logo must be in the specific SVG Tiny Portable/Secure format. Standard SVGs won't work. Most designers need conversion tools to produce this format.
5. Proper DNS hosting — The logo and VMC must be hosted on HTTPS URLs accessible to mailbox providers.

Is BIMI Worth It?

The honest answer depends on your sending volume and brand recognition.

BIMI is worth it if:

• You send high-volume B2C email where brand recognition drives opens.
• You already have a registered trademark.
• Your DMARC is already at enforcement (p=quarantine or p=reject).
• You operate in industries vulnerable to phishing (finance, healthcare, e-commerce) and want visible brand trust signals.

BIMI may not be worth it yet if:

• Your sending volume is small (under 50,000/month).
• You don't have a registered trademark.
• You haven't yet reached DMARC enforcement — focus on that first.

Deep dive into BIMI setup -->

Authentication Troubleshooting: The 10 Most Common Errors

Authentication failures are rarely obvious. Emails don't bounce with a clear error message — they silently land in spam, or worse, are dropped entirely. Below are the ten most common authentication errors, their causes, and how to fix and prevent them.

How Boxset Monitors Authentication in Real-Time

Authentication isn't a set-it-and-forget-it task. DNS records change. ESPs rotate IPs. Certificates expire. Teams add new sending services without updating authentication. A record that was perfect six months ago can be broken today.

Why Authentication Is the Foundation of Email Warmup

There is a dangerous misconception in the cold email industry: that warmup tools will fix your deliverability regardless of your DNS configuration. This is false, and it costs senders thousands of dollars in wasted warmup spend every month.

How warmup actually works: Warmup tools send emails on your behalf through a peer network, generating opens, replies, and inbox moves that teach mailbox providers to trust your domain. But this trust mechanism depends entirely on providers being able to verify that those emails are legitimately from you. That verification happens through SPF, DKIM, and DMARC.

What happens when authentication fails during warmup:

1. Your warmup emails arrive at Gmail, Outlook, or Yahoo.
2. The receiving server checks SPF — it fails (your record is missing or broken).
3. The server checks DKIM — it fails (no valid signature found).
4. DMARC has no passing mechanism to evaluate — the email fails authentication entirely.
5. The email is either rejected or placed in spam.
6. The recipient in the warmup network opens it and moves it to inbox — but the provider has already recorded an authentication failure for your domain.
7. This repeats 20-40 times per day, per inbox, for 30 days.

The result: instead of building 600-1,200 positive reputation signals per inbox, you've accumulated 600-1,200 authentication failures. Your domain is now associated with unauthenticated sending patterns — the exact profile of a spammer.

Frequently Asked Questions