Cold email infrastructure starting at $1/mailbox. Volume discounts down to $0.55.Calculate your cost
ColdRelay
Back to Blog
Guide

SPF, DKIM, and DMARC for Cold Email: The Complete Setup Guide (2026)

The canonical SPF/DKIM/DMARC reference for cold email. Provider-by-provider setup walkthroughs (Google Workspace, Microsoft 365, ColdRelay, custom SMTP), DMARC report interpretation, alignment modes, common errors and fixes, and the path to BIMI in 2026.

•27 min read•Mo Tahboub
Cold EmailDeliverabilityEmail AuthenticationDNSSPFDKIMDMARC

SPF, DKIM, and DMARC for Cold Email: The Complete Setup Guide (2026)

Google, Microsoft, Yahoo, and every other major inbox provider evaluate sender reputation before deciding where to deliver your email. The first thing they check is not your content, your copy, or even your list hygiene — it is whether the email is cryptographically authenticated.

Three DNS records govern authentication: SPF, DKIM, and DMARC. Get them right and inbox providers treat you as a legitimate sender before they read the email. Get them wrong (or skip them) and you land in spam regardless of how good the campaign is.

TLDR — what each record does, in one sentence:

  • SPF authorizes a list of IP addresses to send email on behalf of your domain.
  • DKIM cryptographically signs each email so receivers can verify it has not been tampered with.
  • DMARC tells receivers what to do when SPF or DKIM fails (monitor, quarantine, or reject) and delivers reports about all mail claiming to be from your domain.

Cold email senders need all three at 100% pass rate. Anything less is invisible deliverability damage.

In February 2024, Google and Yahoo made these requirements explicit: any sender pushing more than 5,000 messages per day to Gmail or Yahoo inboxes must have all three configured correctly, or mail is rejected outright. Microsoft followed with tighter enforcement in 2025. For cold email senders running multiple mailboxes — typically thousands of total sends per day across the workspace — this is not optional. It is table stakes.

This guide is the canonical reference: what each record does, how to set them up provider-by-provider, how to read DMARC reports, the alignment modes nobody explains, the common errors that silently break authentication, and the path forward to BIMI in 2026.

Table of Contents

SPF — Sender Policy Framework

What It Does

SPF tells inbox providers which IP addresses are authorized to send email on behalf of your domain. When a message arrives claiming to be from sales@yourcompany.com, the receiving server looks up your domain's SPF record and checks whether the originating IP is in the allowed list.

If yes → email passes SPF. If no → email fails SPF, which is a significant negative signal in 2026.

The SPF Record Format

An SPF record is a TXT DNS record on your domain's root. It looks like this:

v=spf1 include:_spf.google.com include:spf.coldrelay.com ~all

Breaking it down:

  • v=spf1 — SPF version identifier (always this).
  • include:_spf.google.com — authorizes Google Workspace servers.
  • include:spf.coldrelay.com — authorizes ColdRelay's sending infrastructure.
  • ~all — "softfail" any IP not in the above list (treat as suspicious but do not reject).

Common SPF Scenarios

Using only Google Workspace:

v=spf1 include:_spf.google.com ~all

Using Google Workspace + a cold email platform:

v=spf1 include:_spf.google.com include:spf.coldrelay.com ~all

Using Microsoft 365 + a cold email platform:

v=spf1 include:spf.protection.outlook.com include:spf.coldrelay.com ~all

Using dedicated cold email infrastructure only:

v=spf1 include:spf.coldrelay.com ~all

Using custom SMTP / self-hosted (with explicit IPs):

v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 ip4:203.0.113.12 ~all

Use the free SPF generator tool to build your record from scratch and validate it stays under the lookup limit.

The 10-Lookup Limit

SPF has a hard technical limit: the record (after all include: lookups are recursively resolved) can perform at most 10 DNS lookups. Exceed this and receivers treat the SPF as invalid (returns PermError) — equivalent to having no SPF at all.

This is a common failure point when teams stack multiple email tools (CRM, marketing automation, transactional email, cold email sender, helpdesk) on one domain. Each tool wants its own include: and you quickly blow past 10 lookups.

How to check: use the SPF generator and analyzer, mxtoolbox.com/spf.aspx, or dmarcian.com/spf-survey/ to count lookups. If you are at 8 or 9, you are near the cliff.

How to fix three ways:

  1. Consolidate email providers — if you are sending from 4 tools, ask whether you can consolidate to 2.
  2. SPF flattening — replace include: references with the actual IP ranges they resolve to. Tools like dmarcian, ProDMARC, or EasyDMARC offer managed flattening services that keep the record updated as provider IPs change.
  3. Split senders across subdomains — put marketing tools on marketing.yourdomain.com with their own SPF record, cold email on outbound.yourdomain.com with its own SPF, etc. Subdomains have independent 10-lookup budgets.

The all Mechanism

The final part of an SPF record defines what happens to unauthorized senders:

  • -all — "hard fail" — reject unauthorized mail outright.
  • ~all — "soft fail" — flag but do not reject (recommended for cold email).
  • ?all — "neutral" — not recommended, effectively no enforcement.
  • +all — "pass all" — catastrophic, authorizes every server in the world (never use).

For cold email, use ~all. Hard fail (-all) can cause legitimate forwarded emails to bounce in edge cases (mailing lists, employee-to-employee forwards). Once you have DMARC at p=quarantine for 30+ days with clean reports, you can move to -all if you want the extra signal.

How SPF Works When Mail Is Forwarded

A common SPF surprise: when someone forwards your email, the forwarding server now sends it from its own IP — which is not in your SPF record. This causes SPF to fail at the final recipient.

This is one reason -all is risky in 2026: legitimate forwarding triggers it. The fix is to rely on DKIM for forwarded mail (DKIM signatures survive forwarding because they sign the message contents, not the transport). DMARC then evaluates "did SPF pass OR did DKIM pass?" — if either passes, DMARC passes. Hence the importance of running DKIM alongside SPF.

DKIM — DomainKeys Identified Mail

What It Does

DKIM adds a cryptographic signature to every outgoing email. The signature is generated using a private key stored on your sending server; the matching public key is published as a DNS record on your domain.

When an email arrives, the receiving server:

  1. Looks up the public key from your DNS at selector._domainkey.yourdomain.com.
  2. Verifies the signature against the message contents.
  3. Confirms the message has not been tampered with in transit.
  4. Confirms the sender controls the claimed domain.

If any of these fail → DKIM fails, a major negative signal.

The DKIM Record Format

DKIM records live at a subdomain like selector._domainkey.yourcompany.com where selector is a unique identifier your provider chooses (often google, k1, s1, cr1, or a custom name).

Example:

Host:  google._domainkey.yourcompany.com
Type:  TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...

The long string starting with p= is your public key. You do not generate this — your email provider (Google Workspace, Microsoft 365, ColdRelay, etc.) gives it to you. Use the DKIM generator tool when you need to generate keys for a self-hosted setup.

Key Length: 1024-bit vs 2048-bit

Older DKIM setups used 1,024-bit RSA keys. The 2026 standard is 2,048-bit. Why it matters:

  • Gmail downgrades 1,024-bit signatures with an Authentication-Results header note. Not an outright failure, but a measurable deliverability penalty.
  • Microsoft is moving the same direction in 2026 — expect parity with Gmail by mid-year.
  • 2,048-bit keys are too long for a single DNS TXT record in some legacy DNS systems (limit is 255 characters per string). Most providers split the key across multiple strings, which most modern DNS handles correctly. If your DNS provider is from before 2018, verify it splits correctly.

Multiple DKIM Selectors

You can (and should) have multiple DKIM records on the same domain if you send through multiple tools. Each tool uses its own selector. They coexist peacefully:

  • Google uses google._domainkey.yourdomain.com.
  • Microsoft uses selector1._domainkey.yourdomain.com and selector2._domainkey.yourdomain.com.
  • ColdRelay uses cr1._domainkey.yourdomain.com and cr2._domainkey.yourdomain.com.

When a message arrives, the receiving server checks the s= tag in the DKIM-Signature header to know which selector to look up. As long as the right selector matches the sending tool, all your tools coexist.

DKIM Key Rotation

Best practice: rotate DKIM keys every 6–12 months. Why:

  1. Security — older keys are more likely to have been compromised.
  2. Receiver expectations — Google and Microsoft both downgrade trust for very old keys.
  3. Forced cleanup — rotation catches stale selectors and abandoned tools that nobody remembers configuring years ago.

Rotation procedure (run two selectors during the transition):

  1. Generate new selector (e.g., cr2).
  2. Publish new public key at cr2._domainkey.yourdomain.com.
  3. Configure sending server to sign with cr2 going forward (old cr1 selector remains active for in-flight mail).
  4. Wait 7 days for in-flight retries to clear.
  5. Remove old cr1 DNS record. Old key is now retired.

ColdRelay handles DKIM key rotation automatically as part of the managed infrastructure — customers do not see this process.

DMARC — Domain-based Message Authentication

What It Does

DMARC is the policy layer on top of SPF and DKIM. It tells receiving servers:

  1. What to do with messages that fail SPF and/or DKIM (reject, quarantine, or monitor).
  2. Where to send reports about authentication results across all mail claiming to be from your domain.

Without DMARC, a failed SPF or DKIM is ambiguous — the receiver has to guess whether to deliver. With DMARC, you have told them exactly what to do.

The DMARC Record Format

DMARC records live at _dmarc.yourcompany.com:

Host:  _dmarc.yourcompany.com
Type:  TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com; pct=100; adkim=r; aspf=r; sp=none

Breaking it down:

  • v=DMARC1 — version identifier.
  • p=none — policy (none = monitor only, do not act on failures).
  • rua=mailto:dmarc@yourcompany.com — where to send aggregate reports.
  • pct=100 — apply policy to 100% of failing mail.
  • adkim=r — relaxed DKIM alignment (allows subdomain matching).
  • aspf=r — relaxed SPF alignment (allows subdomain matching).
  • sp=none — subdomain policy (applies to subdomains; can differ from p=).

Use the free DMARC generator tool to build your record correctly the first time.

The Three Policy Levels

p=none — Monitor

Log authentication failures and send reports, but do not change delivery. This is the starting policy. Run it for 2–4 weeks to confirm everything is authenticating correctly. Satisfies the Gmail/Yahoo 2024 requirement at minimum.

p=quarantine — Send to Spam

Failing messages are delivered to the spam folder at the receiver. Use this after you have verified (via aggregate reports) that all legitimate mail is passing. The recommended steady state for most cold email senders.

p=reject — Reject Outright

Failing messages are rejected at the SMTP layer, never delivered. Use only after you are 100% confident in your authentication setup. Reserve for senders with airtight authentication for 30+ days at p=quarantine and clean DMARC reports.

The Gmail/Yahoo Requirement (Feb 2024+)

For cold email senders targeting Gmail and Yahoo at scale, DMARC is required as of February 2024:

  • Must have a DMARC record at _dmarc.yourdomain.com.
  • Policy must be at least p=none (monitoring level).
  • SPF and DKIM must align with the From header (use relaxed alignment).
  • One-click unsubscribe (RFC 8058) required for bulk senders (>5,000/day to Gmail/Yahoo).
  • Spam complaint rate below 0.3% — enforcement threshold; above 0.1% triggers warnings.

Without DMARC, mail gets rejected with a permanent failure starting Feb 2024 for senders above the bulk threshold. Below the threshold, the same signals affect Domain Reputation in Google Postmaster Tools — just enforced less aggressively.

Most cold email senders run p=none for the first 30 days, then move to p=quarantine indefinitely. This satisfies the requirement without risking legitimate mail if authentication breaks.

Setup Walkthroughs by Provider

Setting up SPF/DKIM/DMARC on Google Workspace

SPF:

  1. In your DNS provider, create a TXT record at the root of your domain (@ or blank host).
  2. Value: v=spf1 include:_spf.google.com ~all (or include additional senders if you have them).
  3. Wait for DNS propagation (typically 15 minutes to 4 hours).
  4. Verify with MXToolbox SPF check.

DKIM:

  1. Open admin.google.com → Apps → Google Workspace → Gmail → Authenticate email.
  2. Select your domain. Click "Generate new record." Choose 2,048-bit key if available.
  3. Copy the selector (usually google) and the TXT value.
  4. In your DNS provider, add a TXT record:
    • Host: google._domainkey.yourdomain.com
    • Value: paste the full DKIM record
  5. Wait 48 hours for DNS to propagate.
  6. Return to Admin Console → Authenticate email → click "Start authentication". This is the step most setups miss — without clicking it, the DNS record is published but Google is not actually signing your outgoing mail.

DMARC:

  1. In your DNS provider, create a TXT record at _dmarc.yourdomain.com.
  2. Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100; adkim=r; aspf=r.
  3. Set up dmarc@yourdomain.com as a real inbox (or route to a DMARC parsing service).
  4. Wait 24–48 hours, then check the inbox for incoming aggregate reports.

Setting up SPF/DKIM/DMARC on Microsoft 365

SPF:

  1. In your DNS provider, create a TXT record at the root of your domain.
  2. Value: v=spf1 include:spf.protection.outlook.com ~all.
  3. Verify with MXToolbox.

DKIM:

  1. Open Microsoft 365 Defender → Email & collaboration → Policies → DKIM.
  2. Select your domain. Click "Enable."
  3. Microsoft provides two CNAME records (selector1 and selector2) to add to your DNS:
    • Host: selector1._domainkey.yourdomain.com → Value: selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com
    • Host: selector2._domainkey.yourdomain.com → Value: selector2-yourdomain-com._domainkey.yourdomain.onmicrosoft.com
  4. Add both CNAMEs to your DNS.
  5. Wait for propagation, then return to Defender → Enable.

DMARC:

  1. Same as Google: TXT record at _dmarc.yourdomain.com with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100; adkim=r; aspf=r.

Setting up SPF/DKIM/DMARC on ColdRelay

ColdRelay configures all three automatically when you add a domain. The flow:

  1. Add your domain in the ColdRelay dashboard.
  2. ColdRelay generates the exact DNS records needed (SPF, DKIM, DMARC, MX) and shows them to you.
  3. You add the records to your DNS provider (or use ColdRelay's nameserver delegation option for fully managed DNS).
  4. ColdRelay validates propagation, confirms DKIM signing is live, and confirms the first authenticated send.
  5. From then on, ColdRelay monitors pass rates continuously and alerts you if anything drifts.

The whole process takes 5–10 minutes per domain. See how ColdRelay auto-configures SPF/DKIM/DMARC for the deeper architecture.

Setting up SPF/DKIM/DMARC on Custom SMTP / Self-Hosted

If you are running your own MTA (Postfix, Haraka, or similar), you build all of this yourself:

SPF:

  1. Identify your sending IP addresses (static, in your hosting provider's allocations).
  2. Create TXT record: v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 ~all.

DKIM:

  1. Generate a 2,048-bit RSA key pair using opendkim-genkey or openssl.
  2. Install the private key on your MTA. Configure the MTA to sign with selector (e.g., s1).
  3. Publish public key at s1._domainkey.yourdomain.com as a TXT record.
  4. Test signing by sending mail to a Gmail address and checking "Show original."

DMARC:

  1. Same as managed providers: TXT record at _dmarc.yourdomain.com.
  2. Implement DMARC report parsing yourself, or route reports to a service like dmarcian or Postmark's free DMARC dashboard.

Custom SMTP requires significantly more ongoing maintenance — key rotation, IP warmup, blocklist monitoring, and bounce handling are all on you. The cost analysis in the infrastructure cost breakdown explains why dedicated cold-email providers win for 95% of use cases.

The Setup Sequence — Exact Order to Follow

Authenticate in this order. Skipping steps or doing them out of order is the cause of most authentication failures.

Step 1: SPF First

Add your SPF record before doing anything else. Without SPF, DKIM and DMARC mean less.

Verify: use mxtoolbox.com/spf.aspx or dmarcian.com/spf-survey/ to check the record resolves correctly and stays under 10 lookups.

Step 2: DKIM Second

Configure DKIM for each provider sending mail from your domain. Add multiple selectors as needed.

Verify: send a test email to a Gmail address, open in Gmail, click "Show original" — look for DKIM: 'PASS' in the Authentication-Results header. Use the email header analyzer to parse headers quickly.

Step 3: DMARC Third — Start with p=none

Only add DMARC after SPF and DKIM are both passing for 7+ days. Start with monitoring policy:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100; adkim=r; aspf=r

Verify: wait 2–3 days, check your DMARC reports inbox — you should start receiving aggregate reports (XML files) from major providers within 24–48 hours.

Step 4: Read Reports for 2–4 Weeks

Use a DMARC parser (dmarcian, Valimail, Postmark DMARC Digests) to convert the XML reports into readable summaries. Look for:

  • Legitimate mail that is failing — usually a misconfigured tool or a missing include:.
  • Unauthorized senders claiming to be you — spoofing attempts or rogue marketing tools.

Fix any legitimate-but-failing mail before raising the policy.

Step 5: Ramp DMARC Policy

After 2–4 weeks of p=none with clean reports:

  1. Move to p=quarantine; pct=25 (25% of failing mail goes to spam, 75% still passes).
  2. After 2 weeks clean: p=quarantine; pct=100.
  3. After 4 weeks clean at p=quarantine; pct=100: p=reject; pct=25.
  4. After another 2 weeks: p=reject; pct=100.

Never jump directly to p=reject. It is the fastest way to accidentally reject your own legitimate mail.

Interpreting DMARC Aggregate Reports

DMARC aggregate reports are XML files sent daily (sometimes more often) to the rua address in your DMARC record. They tell you exactly which IPs sent mail claiming to be from your domain and whether they passed authentication.

What a Raw Report Contains

For each reporting period (usually 24 hours):

  • Reporting organization (Google, Microsoft, Yahoo, etc.).
  • Your domain.
  • The DMARC policy in effect.
  • Per-source records, each containing:
    • Source IP.
    • Message count.
    • DMARC disposition (none, quarantine, reject).
    • SPF result (pass/fail) and the SPF domain.
    • DKIM result (pass/fail) and the DKIM domain.

What to Look For

1. Unauthorized senders claiming to be you:

If a source IP you do not recognize is sending mail with your domain, something is wrong. Two possibilities:

  • A legitimate tool you forgot about (old marketing platform, a CRM, a transactional service).
  • A spoofing attempt — someone trying to impersonate you.

Investigate every unknown source. If it is legitimate, add it to SPF. If it is unauthorized, raise your DMARC policy to quarantine or reject so receivers stop delivering its mail.

2. Legitimate sources that are failing:

If your own tools are sending mail that fails SPF or DKIM, something is misconfigured. Common causes:

  • A tool was added but its include: is not in SPF.
  • DKIM is enabled but the selector record is wrong.
  • The tool is signing with a domain different from your From domain (alignment failure).

Fix these before raising the DMARC policy.

3. Pass rates over time:

A healthy domain shows 98%+ DMARC pass rate. Anything below 95% has misconfiguration somewhere. The reports show you exactly which sources to investigate.

Tools to Read Reports

Reading raw XML is painful. Use a parser:

For ColdRelay customers, DMARC reports for your sending domains are surfaced in the dashboard alongside other deliverability signals.

Alignment Modes Explained (the Hidden DMARC Complication)

DMARC does not just check that SPF and DKIM pass — it checks that they align with the From header. Alignment is the most-skipped concept in DMARC setup, and the cause of about half of all "DMARC fails despite passing SPF and DKIM" complaints.

What Alignment Means

When DKIM signs a message, it includes the signing domain in the d= parameter (e.g., d=yourdomain.com). DMARC requires this d= value to align with the From header's domain (e.g., sales@yourdomain.com).

Similarly, SPF authenticates against the Return-Path domain (the MAIL FROM in SMTP). DMARC requires this to align with the From header domain.

If either authentication passes but is misaligned (different domain than the From header), DMARC fails — even though SPF or DKIM technically passed.

Strict vs. Relaxed Alignment

DMARC supports two alignment modes per protocol:

  • Strict (s) — the signing/authenticating domain must exactly equal the From domain. sales@yourdomain.com requires DKIM d=yourdomain.com (not d=mail.yourdomain.com).
  • Relaxed (r) — subdomains count. sales@yourdomain.com accepts DKIM d=mail.yourdomain.com because both are under yourdomain.com.

For cold email, always use relaxed alignment (adkim=r; aspf=r). Strict alignment breaks any sending tool that signs with its own subdomain via CNAME — which is most cold email infrastructure providers.

Example: When Alignment Fails

Scenario: you use ColdRelay, which signs with d=mail.coldrelay.com (their internal signing domain) by default. Your From header is sales@yourdomain.com. SPF passes (ColdRelay IPs are in your SPF). DKIM passes (signature verifies). But the DKIM signing domain (mail.coldrelay.com) does not align with your From domain (yourdomain.com).

DMARC fails. Mail goes to spam.

Fix: ColdRelay (and any other reputable cold-email infrastructure provider) supports CNAME-based DKIM where the signature is published under your domain (cr1._domainkey.yourdomain.com) and the d= tag references yourdomain.com. This way DKIM aligns naturally with your From domain.

Most modern cold email providers handle this automatically. If your provider does not, switch providers — alignment failures are a structural deliverability problem.

Common Misconfigurations That Break Everything

Misconfiguration 1: Multiple SPF Records

DNS allows multiple TXT records on the same host, but SPF spec says there can only be one SPF record per domain. Having two or more v=spf1 ... records at the root = all of them invalidate each other (PermError).

Fix: consolidate into one record with multiple include: statements.

Misconfiguration 2: DKIM Selector Mismatch

You have set up DKIM on Google Workspace, but mail is being signed with a selector that does not have a matching DNS record. Happens when you forget to click "Start Authentication" after adding the DNS record.

Fix: verify in your provider admin panel that DKIM signing is actually enabled, not just configured. Send a test, check headers.

Misconfiguration 3: DMARC Without Alignment Awareness

Mail is DKIM-signed by your sending tool (e.g., d=dkim.tool.com), but the From address says sales@yourcompany.com. Without proper alignment, DMARC sees the signing domain does not match and fails — even though DKIM itself passed.

Fix: ensure your sending tool uses CNAME-based DKIM that keeps signing aligned with your actual domain. Set DMARC alignment to adkim=r (relaxed).

Misconfiguration 4: Copying Records Wrong

The most common issue in practice. A single wrong character in a DKIM public key and verification fails for every email. A missing semicolon in SPF and the record does not parse. An accidentally-pasted leading space and DNS treats the record as a different one entirely.

Fix: copy records directly from provider admin panels (do not retype). Use a DNS checker (mxtoolbox, dmarcian) to validate after every change.

Misconfiguration 5: Subdomain Mail Without Subdomain Authentication

You send from sales@outbound.yourcompany.com but SPF, DKIM, and DMARC are only configured on yourcompany.com. Subdomains inherit some things but not all — misconfigured subdomain mail lands in spam.

Fix: authenticate each sending subdomain independently. SPF and DKIM are per-subdomain. DMARC at the root can cover subdomains via the sp= tag if you publish one (sp=quarantine applies the policy to subdomains too); otherwise add a DMARC record at the subdomain explicitly.

Misconfiguration 6: Using Spoofable Free Email Domains

Setting SPF/DKIM/DMARC on a domain you do not actually control (like trying to "authenticate" a @gmail.com sender). You cannot. These protocols only work for domains you own and control DNS for.

Fix: always send cold email from your own domain, never from a free email provider.

Misconfiguration 7: SPF Lookup Limit Exceeded

You added a 12th include: and now the entire SPF record fails with PermError. You did not get an obvious error — your mail just started going to spam more.

Fix: count your lookups with spf-record.com or dmarcian SPF survey. If over 10, flatten or split across subdomains.

Misconfiguration 8: Forgetting to Renew Domains

A domain expiry takes down all three records simultaneously. Mail starts failing dramatically and you spend hours debugging DNS before realizing the domain itself expired three days ago.

Fix: set auto-renewal on every sending domain. Set calendar reminders for any domain not on auto-renewal.

BIMI — the Follow-On After DMARC

BIMI (Brand Indicators for Message Identification) is the next layer after DMARC. It lets you display your company logo next to your name in the inbox at participating receivers — Gmail, Yahoo, Apple Mail, Fastmail.

Why BIMI Matters

BIMI is a brand-trust signal. A/B tests in 2024–2025 showed measurable open-rate lifts of 2–5% when BIMI was active (the effect is bigger in industries where brand recognition matters most: financial services, healthcare, retail).

For cold email, BIMI is less commonly used because most cold senders are smaller brands. But for established companies running outbound, it is worth the setup once authentication is solid.

BIMI Requirements (2026)

To publish a BIMI record, you must have:

  1. DMARC at p=quarantine or p=reject with high coverage (pct=100). p=none does not qualify.
  2. A square SVG logo (specific BIMI variant called SVG Tiny PS).
  3. A Verified Mark Certificate (VMC) — issued by Entrust or DigiCert, costs $1,000–1,500/year. Required for Gmail and Apple Mail (Yahoo accepts without).

How to Set Up BIMI

  1. Verify DMARC is at p=quarantine or p=reject for 30+ days.
  2. Convert your logo to SVG Tiny PS format (most major logos already exist in this format from prior BIMI deployments).
  3. Apply for a VMC certificate through Entrust or DigiCert. Process takes 2–4 weeks.
  4. Host the SVG and the VMC at publicly-accessible URLs.
  5. Add a BIMI DNS record: default._bimi.yourdomain.com → v=BIMI1; l=https://yourdomain.com/bimi.svg; a=https://yourdomain.com/bimi-vmc.pem.

Read the BIMI specification for current requirements (the standard is still evolving).

How to Verify Everything Is Working

Method 1: Send a Test, Read the Headers

Send an email from your cold email setup to a Gmail inbox you control. Open the message in Gmail, click the three-dot menu → "Show original". Look for:

SPF:      PASS with IP 203.0.113.10
DKIM:     'PASS' with domain yourcompany.com
DMARC:    'PASS' (policy of quarantine)

All three should say PASS. If any say FAIL or NEUTRAL, fix before proceeding. Use the email header analyzer to parse headers across providers in one place.

Method 2: Use an External Authentication Checker

Free tools that analyze your setup:

Method 3: Review DMARC Aggregate Reports

Once DMARC is set up, you will receive XML reports from Google, Microsoft, etc. showing which IPs sent mail claiming to be from your domain and whether they passed authentication. Read these to catch unauthorized senders or misconfigurations.

Method 4: Use ColdRelay's Built-in Monitoring

If you are on ColdRelay, the dashboard shows continuous SPF/DKIM/DMARC pass-rate monitoring per domain, surfaces DMARC report summaries, and alerts you if anything drifts below 99% pass rate.

When Something Goes Wrong (SMTP Bounces with Auth Failures)

If you start seeing bounces with messages like 550 5.7.26 This message does not have authentication information or 550 5.7.1 SPF check failed, you have an authentication problem. The SMTP error codes reference covers every auth-related code with diagnostic steps:

If you are seeing blocklist-related bounces, check the blocklist removal hub for delisting guides.

The Bottom Line

SPF, DKIM, and DMARC are the baseline of cold email deliverability. Not advanced optimizations — the starting point. You cannot skip this and expect inbox placement.

Setup takes 30–60 minutes if you do it carefully. It has a 24–48 hour DNS propagation window before everything activates. Then it keeps working indefinitely, protecting your sender reputation and ensuring your cold emails land in inboxes instead of spam folders.

The teams that treat authentication as "IT paperwork" and skip it are the same teams wondering why their open rates are 10% while the competition hits 50%. It is not the tools, the copy, or the lists — it is the DNS records nobody got around to setting up.

FAQ

Do I need SPF, DKIM, AND DMARC? Is one enough?

All three. SPF authorizes senders, DKIM signs messages, DMARC provides the policy layer tying them together. Gmail and Yahoo require all three at scale (>5,000/day). Skipping any one breaks deliverability significantly at any volume.

Will the wrong DMARC policy reject my legitimate emails?

Yes, if you jump to p=reject without verifying authentication first. The correct sequence is: set up SPF → set up DKIM → start DMARC at p=none → ramp to quarantine → then reject, over weeks, watching reports.

I use multiple email tools — do I need separate records for each?

SPF: one consolidated record listing all senders via include: statements. DKIM: separate selector record per tool. DMARC: one record per domain (all tools share it).

How long does DNS propagation take?

Most providers propagate within 1–4 hours. TTL settings on your DNS can extend this. Wait 48 hours before concluding a record "is not working" — often it is still propagating.

Can I use SPF/DKIM/DMARC on a shared domain?

Yes, but it is complicated. Hosted email domains (like @mycompany.shopify.com or @mycompany.freshdesk.com) may already have shared authentication configured. Ask your provider. For cold email, owned domains are always better.

What happens if my sending tool does not support DKIM?

Do not use that tool. In 2026, any legitimate email sending platform supports DKIM. Tools that do not are either scams or legacy systems that will fail in the current deliverability environment.

How do I read DMARC aggregate reports?

Do not read raw XML. Use a parser: dmarcian, Postmark DMARC Digests, Valimail, or EasyDMARC. For ColdRelay customers, summaries are in the dashboard.

What is BIMI and do I need it?

BIMI displays your logo in the inbox at supported receivers. Requires DMARC at p=quarantine or higher and a VMC certificate ($1,000–1,500/year). Optional for cold email; valuable once authentication is solid. See BIMI specification.

What is alignment in DMARC?

Alignment means the domain that signs (DKIM) or authenticates (SPF) matches the From header domain. DMARC checks alignment, not just pass/fail. Use relaxed alignment (adkim=r; aspf=r) for cold email — strict alignment breaks most third-party signing arrangements.

My SPF is failing with PermError — what do I do?

You exceeded the 10-lookup limit. Count your include: statements (each consumes one lookup; some resolve to additional lookups inside). Fix by consolidating providers, flattening the SPF record, or splitting senders across subdomains.

How do I generate DKIM keys for self-hosted SMTP?

Use opendkim-genkey -b 2048 -d yourdomain.com -s s1 or the DKIM generator tool. Install the private key on your MTA, publish the public key at s1._domainkey.yourdomain.com as a TXT record, and configure your MTA to sign with selector s1.

Should cold email use a separate domain from transactional email?

Yes, always. A cold email campaign that tanks domain reputation will drag your transactional mail (password resets, order confirmations) into spam at the same time. Use a subdomain like outbound.yourdomain.com or a dedicated cold-email domain for outreach.

ColdRelay handles SPF, DKIM, and DMARC automatically for every domain you add — guided setup with DNS records pre-generated, propagation validated, continuous pass-rate monitoring, and alerts if anything breaks. Authentication right on day one, without the DNS debugging.

Related reading:

Related reading

Keep going

Deliverability
How ColdRelay Auto-Configures SPF, DKIM, and DMARC for Cold Email
Every cold email infrastructure setup needs SPF, DKIM, and DMARC. ColdRelay writes them automatically the moment your first mailbox provisions. Here's exactly what we configure, why, and what to verify.
deliverability
Cold Email Deliverability: The Complete Guide (2026)
Everything you need to know about cold email deliverability in 2026 — authentication (SPF, DKIM, DMARC), reputation, warmup, content, inbox placement testing, blocklists, and the monitoring loop that keeps you in the primary inbox.
Cold Email
What to Send When Cold Email Prospects Don't Respond (2026)
Five field-tested follow-up angles for cold email prospects who go silent — bump, value-add, social proof, break-up, re-engagement. With reply-rate ranges per step, deliverability constraints, and the math on how many touches is too many.

Cold email infrastructure that delivers

ColdRelay handles domains, mailboxes, DNS, and dedicated IPs for you. Real-time monitoring and 95% inbox placement — starting at $50/month.

Start for $50/month →