Email Authentication Guide: SPF, DKIM, DMARC, and BIMI for Production Senders

Email authentication is the technical foundation that determines whether receiving mail servers trust the email you're sending. Without complete, correctly configured authentication, even the cleanest list, most compelling content, and best-managed IP reputation will generate deliverability problems — because ISP filtering systems treat unauthenticated mail as inherently suspicious.

This guide covers the complete email authentication stack: SPF, DKIM, DMARC, and BIMI, with specific configuration guidance, common failure modes, and operational practices for maintaining authentication in production.

The Authentication Stack: How Each Layer Protects You

Email authentication is not a single mechanism — it's a layered stack where each protocol addresses a different security and deliverability concern. Understanding what each layer does makes misconfiguration much easier to diagnose.

SPF: Authorizing Your Sending Sources

SPF (Sender Policy Framework) is a DNS TXT record at your domain that lists the IP addresses authorized to send email claiming to be from your domain. When a receiving server gets a connection from a sending IP, it checks whether that IP is listed in the SPF record for the envelope-from domain. If not, the check fails.

Writing a Correct SPF Record

A complete SPF record looks like: v=spf1 ip4:203.0.113.1 ip4:203.0.113.0/24 include:sendgrid.net include:_spf.google.com -all

Each mechanism means:

• v=spf1 — Required version declaration
• ip4:203.0.113.1 — Authorizes a single IPv4 address
• ip4:203.0.113.0/24 — Authorizes a CIDR range
• include:sendgrid.net — Includes all IPs from SendGrid's SPF record (one DNS lookup)
• -all — Hard fail: all other IPs should fail SPF

The 10 Lookup Limit Problem

RFC 7208 limits SPF evaluation to 10 DNS lookups. Each include:, a:, and mx: mechanism consumes one lookup. Nested includes (where an included domain also has includes) compound this. Exceeding 10 lookups generates a PermError, which most ISPs treat as SPF failure.

Solution: SPF flattening — replace include mechanisms with the actual IP addresses they resolve to. This trades regular maintenance (updating when third-party IPs change) for staying under the lookup limit. Tools like SPF Macros or automated SPF flattening services automate this maintenance.

DKIM: Cryptographic Message Signing

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every message. Your MTA signs messages with a private key; the corresponding public key is published in DNS. Receiving servers verify the signature against the public key, confirming: (1) the message was signed by someone controlling the private key, and (2) the message content hasn't been modified since signing.

DKIM Key Requirements in 2025

• Key size: 2048-bit minimum. 1024-bit keys are no longer accepted by Google as of 2024. Some providers still use 1024-bit — verify your key size with: dig TXT selector._domainkey.yourdomain.com and look for "k=rsa;p=[key]" — 1024-bit keys have ~172 character public keys; 2048-bit keys have ~344+ characters.
• Selector naming: Each key needs a unique selector (e.g., key2025). The selector appears in the DKIM signature header as s=key2025 and determines which DNS record to look up for verification.
• Key rotation: Rotate annually or after any suspected compromise. The rotation sequence: generate new keypair → publish new public key in DNS → wait 48 hours → update MTA to sign with new key → verify new key works → remove old DNS record after 7 days.

DKIM Signing Scope

The DKIM signature should cover critical headers: From, Subject, Date, Content-Type, and ideally To. The body hash covers the message body. A minimally signed message that only signs the body without key headers can be trivially manipulated by replacing headers while keeping the body intact. Configure your MTA to sign the full header set.

DMARC: Alignment and Policy Enforcement

DMARC (Domain-based Message Authentication, Reporting, and Conformance) answers the question SPF and DKIM alone can't: "Is the domain that signed/authorized this email the same domain the recipient sees in the From header?" This alignment check is what prevents "header spoofing" attacks where a spammer passes SPF authentication using a legitimately registered domain while showing your company name in the From header.

DMARC Alignment Modes

Relaxed alignment (default, adkim=r aspf=r): The authenticated domain must match the organizational domain (registered domain + TLD) of the From header. mail.yourcompany.com authenticating for yourcompany.com passes under relaxed alignment because both share the organizational domain.

Strict alignment (adkim=s aspf=s): The authenticated domain must exactly match the From header domain. mail.yourcompany.com authenticating for yourcompany.com fails strict alignment. Strict mode is appropriate for high-security environments where exact domain control is required.

DMARC Deployment Sequence

BIMI: Brand Logo in Gmail and Apple Mail

BIMI (Brand Indicators for Message Identification) is the newest member of the authentication stack, enabling your company logo to appear next to your email in Gmail and Apple Mail (iOS 16+, macOS Ventura+). BIMI doesn't affect delivery — it's a brand trust signal that increases recipient confidence and click rates.

BIMI requirements: (1) DMARC at minimum p=quarantine, (2) A BIMI record published at default._bimi.yourdomain.com, (3) A square SVG logo file accessible at a stable URL, (4) For Gmail — a Verified Mark Certificate (VMC) from an authorized Mark Verifier (Entrust or DigiCert). VMCs cost approximately €1,000–€1,500/year and require proof of trademark ownership.

Apple Mail's implementation is less strict — it displays BIMI logos without requiring a VMC. Gmail requires the VMC for brand indicators to appear.

Authentication Monitoring in Production

Authentication failures in production are insidious — they don't always produce obvious delivery failures. SPF softfails (~all) don't cause rejection at most ISPs; they produce worse reputation scores that accumulate into deliverability degradation over weeks. DKIM failures may result in DMARC failures only when SPF also fails on the same message. Proactive monitoring is the only way to catch these problems before they compound.

Minimum monitoring stack:

• DMARC aggregate reports processed weekly — review for new failing sending sources
• Weekly SPF validation check — confirm lookup count under 10, all IPs still authorized
• DKIM test message monthly — send through each configured signing domain and verify DKIM=pass in headers
• Authentication pass rate in Gmail Postmaster Tools — should be 100%; any drop below indicates a misconfigured sending source

Common Authentication Failures and Their Diagnosis

Authentication problems are rarely obvious — email continues to deliver (often), but quietly underperforms due to spam filtering. The failures worth understanding:

DMARC Alignment Failure (Most Common)

The message passes SPF and passes DKIM individually, but neither is aligned with the From header domain. DMARC evaluates alignment, not just authentication — the authenticated domain must match (or share an organizational domain with) the From address your recipient sees.

Symptom: DMARC=fail in message headers despite SPF=pass and DKIM=pass. Increased filtering at Gmail.

Cause: Your ESP or relay is using its own domain for SPF (their Return-Path) and DKIM signing (their d= domain), not your domain.

Fix: Configure custom domain DKIM at your ESP (most support this). Add your custom Return-Path subdomain to your SPF record for alignment.

SPF PermError from Too Many Lookups

SPF limits the number of DNS lookups a record can trigger to 10. Modern email setups with multiple ESPs, GSuite, marketing platforms, and CRM sending often exceed this limit silently — the result is SPF PermError, which is treated the same as SPF fail by DMARC.

Symptom: SPF=permerror in headers. DMARC fails despite SPF appearing to include the right sources.

Diagnosis: Run your domain through MXToolbox SPF checker — it counts your lookups. Any count above 10 is a PermError.

Fix: Reduce includes by combining them, removing unused ESPs, or using SPF flattening tools that expand nested includes into direct IP ranges.

DKIM Signing Not Propagating to All Sending Sources

DKIM is configured for your primary sending path, but a secondary source (a CRM, a support ticket system, a transactional platform) is sending from your domain without DKIM signing. These messages fail DKIM but continue to deliver — often to spam folders.

Symptom: DMARC aggregate reports show a percentage of your mail failing DKIM. The sending source in the reports is a platform you didn't configure.

Fix: Add DKIM signing at every identified sending source. DMARC aggregate reports (rua) are the diagnostic tool for finding unconfigured sources.

DKIM Signature Broken by Mail Processing

DKIM signatures cover specific headers and the body. Anything that modifies those headers or the body between sending and delivery breaks the signature. Common causes: email forwarding services that add footers, mailing list software that modifies Subject headers, security gateways that rewrite content.

Fix: ARC (Authenticated Received Chain) headers, which Gmail and Microsoft support, allow intermediate servers to record authentication status before modification. If your mail is forwarded extensively, implement ARC on your relay infrastructure.

Implementing DMARC: The Policy Progression

DMARC should be deployed in phases. Moving directly to p=reject without first understanding your sending sources causes legitimate email from misconfigured sources to be hard-rejected by receiving servers — an incident that can be difficult to reverse quickly.

The most important tool during phase 1 and 2 is the DMARC aggregate report parser. The raw XML reports are unreadable directly — use a DMARC reporting tool (dmarcian, PowerDMARC, Red Sift OnDMARC, or the free Google Postmaster Tools dashboard) to see human-readable summaries of which IPs are sending mail claiming your domain and whether they're authenticating correctly.

ARC: Authenticated Received Chain for Forwarding and Mailing Lists

Email forwarding is fundamentally incompatible with DMARC alignment. When a receiving server forwards a message, the outbound IP (the forwarder's IP) isn't in the original sender's SPF record, and DKIM signatures may be broken if the forwarder modifies the message. From the receiving server's perspective, a forwarded message looks like an authentication failure — and with DMARC p=reject, it gets rejected.

ARC (Authenticated Received Chain, RFC 8617) solves this by allowing intermediate servers to sign the authentication state they observed before forwarding. A Gmail server that receives a message from a properly authenticated sender can add an ARC seal documenting that it saw valid SPF and DKIM before forwarding. The ultimate receiving server evaluates the ARC chain rather than the broken original authentication.

Google, Microsoft, Yahoo, and Fastmail all support evaluating ARC seals. Organizations that see legitimate forwarded email getting rejected after moving to DMARC p=reject should investigate ARC implementation at their relay infrastructure.

Mailing lists (listservs, newsletters forwarded to subscribers) face a related problem: the mailing list server modifies the message (adding footers, rewriting subjects) which breaks DKIM, and sends from an IP not in the original sender's SPF. The practical solution for mailing list operators is to use the List-ID header (required by Google's 2024 bulk sender requirements) which tells ISPs to treat the message as mailing list traffic rather than direct domain spoofing.

Authentication Across Multiple Sending Sources

Most organizations send email from more than one source. A typical mid-size company might have: the primary email platform (Klaviyo, HubSpot, Mailchimp), a transactional email service (Postmark, SendGrid), a CRM system (Salesforce, HubSpot), a support ticketing system (Zendesk, Intercom), and potentially internal systems sending automated notifications. Every one of these must be properly authenticated with your domain's DKIM and SPF if they're sending with your From address.

The systematic approach:

1. Inventory all sending sources. The easiest way is to read your DMARC aggregate reports (rua). Every IP that sends mail claiming your domain shows up in these reports, whether it's authorized or not. Any source showing authentication failures is a source that needs attention.
2. Configure DKIM at each source. Most platforms support custom domain DKIM — this is usually a one-time DNS record addition (a TXT record at selector._domainkey.yourdomain.com). Check each platform's documentation for their specific process.
3. Update your SPF record. Each sending source needs an authorized IP range or include mechanism in your SPF record. Keep the lookup count below 10.
4. Verify alignment for each source. Send a test message from each platform and confirm DMARC=pass in the Authentication-Results header. The d= value in DKIM should match your From domain.

The audit process using DMARC reports takes 2–4 weeks to gather representative data, then 2–6 weeks to configure each discovered source. Organizations that skip this step frequently have one or two low-volume sending sources (often internal notification systems or a forgotten CRM integration) generating quiet authentication failures that appear in Postmaster Tools as unexplained compliance issues.

Authentication at Scale: Multi-Domain and Subdomain Strategy

Large organizations sending from multiple brands or distinct product lines face the challenge of managing authentication across many domains. The strategic approach:

Subdomains for stream isolation: Instead of sending all email from yourdomain.com, use subdomains — marketing.yourdomain.com for campaigns, transactional.yourdomain.com for receipts, notifications.yourdomain.com for automated alerts. Each subdomain gets its own DKIM key, builds its own reputation history, and can have its own DMARC policy. A problem in the marketing subdomain doesn't contaminate the reputation of the transactional subdomain.

Subdomain DMARC inheritance: DMARC policies are inherited by subdomains. If yourdomain.com has p=reject, that policy applies to all subdomains unless they publish their own DMARC record. This means you can protect your brand at the top-level domain while giving subdomains more permissive policies during warm-up phases.

BIMI domain requirements: BIMI (Brand Indicators for Message Identification) requires DMARC p=quarantine or p=reject at the organizational domain level. If you want your brand logo to appear in Gmail and Apple Mail, the authentication foundation must include DMARC enforcement. BIMI also requires a Verified Mark Certificate (VMC) for Gmail — an annual investment that validates trademark ownership of the logo being displayed.

Managing authentication across an ESP migration: When switching email platforms, authentication configuration doesn't transfer automatically. New DKIM keys must be generated and published, SPF records must be updated, and DMARC reports will show misaligned mail during the transition period. Plan for a parallel running window where both old and new infrastructure operate simultaneously, both properly authenticated, before fully cutting over.