Email Deliverability in 2026: SPF, DKIM, DMARC, BIMI, and Warming Up — A Practitioner's Guide

Email Deliverability in 2026: SPF, DKIM, DMARC, BIMI, and Warming Up — A Practitioner's Guide

Email deliverability used to be something you set up once and forgot. That hasn't been true since around 2022, and after Gmail and Yahoo's February 2024 sender requirements went into force — DMARC mandatory for bulk senders, one-click unsubscribe required, complaint rate caps with teeth — it stopped being optional for everyone else, too.

Most email deliverability problems follow the same pattern: a team launches a new product, ships their first marketing campaign through a fresh ESP account, and watches their open rates collapse. Or a long-running app suddenly starts sending password-reset emails to spam after a routine SPF change "to add SendGrid." Or a SaaS company brings a new domain online for transactional mail and discovers, three months in, that nothing they send to corporate Microsoft 365 inboxes ever arrives.

The fixes are almost always the same five things, in roughly the same order. This post walks through each one with working DNS examples, a realistic warm-up schedule for new senders, and a diagnostic checklist for when things go wrong.

The mental model: every modern receiver does the same four checks

When Gmail / Outlook / Yahoo / Apple Mail receives a message, they run it through (in this order):

1. SPF — was the sending IP authorized by the From-domain's DNS?
2. DKIM — does the message carry a valid cryptographic signature from the From-domain?
3. DMARC — do SPF and/or DKIM align with the From-domain, and what does the From-domain's policy say to do if not?
4. Reputation + content — sender's history, content patterns, complaint rate, list hygiene

The first three are technical. They're either set up correctly or they're not, and you can verify them in a few minutes. The fourth is reputation, which takes weeks to build and seconds to wreck. We'll cover both.

SPF — the foundation everyone gets wrong

SPF (Sender Policy Framework) is a TXT DNS record that lists which servers are allowed to send mail as your domain. It's the simplest of the three auth checks and the one with the most footguns.

A typical record looks like this:

example.com.    IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ip4:198.51.100.5 -all"

Reading right-to-left:

• -all — anyone not matched by an earlier mechanism FAILS
• ip4:198.51.100.5 — explicit IP allowed
• include:sendgrid.net — accept whatever SendGrid's SPF says
• include:_spf.google.com — accept whatever Google Workspace's SPF says
• v=spf1 — version

The three things that break SPF in production

1. The 10-DNS-lookup limit. SPF allows at most 10 DNS lookups while resolving the record. Each include:, a:, mx:, exists:, and ptr: mechanism counts. Big ESPs like Google Workspace consume 4 lookups by themselves. Add SendGrid (3), Mailgun (1), and a "small" include: for your CRM (3 more) and you're at 11. Permerror. All your authenticated mail starts looking unauthenticated.

This silent failure is the #1 SPF problem in production. You don't get an alert. You don't see it in your sending stats. Mail just starts going to spam, which you discover three weeks later from a customer.

Run SPF Checker on your domain monthly. The lookup counter is the metric that matters.

2. The +all qualifier. Means "allow ANY server to send mail as this domain." A wide-open spoofing invitation. Always end with -all (hard fail) or ~all (softfail). Never +all. Never ?all.

3. Multiple SPF records. RFC 7208 explicitly says a domain can have only ONE SPF record. After a migration, someone adds a new record instead of merging — receivers see two v=spf1 ... TXT records and return permerror. SPF Checker catches this.

What to actually publish

For a domain that sends mail through Google Workspace + one ESP + a few internal IPs:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:198.51.100.0/29 -all

For a domain that sends NO email (and you want to make sure no one can spoof it):

v=spf1 -all

For subdomains (which do NOT inherit parent SPF — common surprise), publish per-subdomain. Mail-only subdomains like mailer.example.com need their own SPF.

DKIM — the cryptographic signature

DKIM (DomainKeys Identified Mail) signs each outgoing message with a private key. The corresponding public key lives in DNS. Receivers verify the signature against the public key — if it matches, they know the message wasn't modified in transit and was authorized by whoever holds the private key.

Setup is per-ESP. Examples:

Google Workspace generates a 2048-bit key in the Admin Console (Apps → Google Workspace → Gmail → Authenticate email). Publish the resulting google._domainkey.example.com TXT record.

SendGrid / Mailgun / Postmark all give you 2-3 CNAMEs to add (e.g., s1._domainkey.example.com → s1.domainkey.u123456.wl.sendgrid.net). The CNAME approach lets the ESP rotate keys without you touching DNS.

Self-hosted (Postfix + OpenDKIM, etc.) generate the key with opendkim-genkey, install in your MTA, publish the selector._domainkey TXT record.

Two practical tips:

• Use 2048-bit keys, not 1024. Some receivers (Microsoft especially) downgrade trust on 1024-bit keys; the spec hasn't required it but the writing is on the wall.
• Rotate keys at least annually. Major ESPs do this for you with the CNAME approach. Self-hosted needs a calendar reminder.

Verifying DKIM is actually signing

Send a test email to a Gmail address you control. Open the message → ⋮ menu → Show original. Look for dkim=pass in the Authentication-Results: header. If you see dkim=none, signing isn't happening. If you see dkim=fail, the public key doesn't match the private key (mismatched selector, wrong DNS record).

The Email Header Analyzer parses these out automatically — paste the headers, see the verdict.

DMARC — the policy that ties it all together

DMARC (Domain-based Message Authentication, Reporting & Conformance) is a TXT record telling receivers what to do when SPF and DKIM disagree with the From-domain. It also enables aggregate reports — daily summaries of who's sending mail claiming to be you.

A starter DMARC record:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100;"

Breaking it down:

• p=none — monitor only, don't reject anything (the right starting policy)
• rua=mailto:dmarc-reports@example.com — receivers send aggregate reports here daily
• pct=100 — apply the policy to 100% of mail (lower this when ramping a stricter policy)

The three policies, explained honestly

The classic DMARC mistake: flipping straight to p=reject without monitoring first. Result: your own marketing emails get rejected because you forgot the marketing platform's SPF include. Then your support team's email gets rejected because they're sending through a separate ESP you didn't know about. Then your billing emails go through a fourth provider...

Always: p=none for 4-8 weeks → audit reports → add missing senders → p=quarantine; pct=10 → ramp to 100 → eventually p=reject. The whole process takes 2-3 months for a typical org.

DMARC alignment — the subtle thing

DMARC checks alignment between the SPF/DKIM domain and the From: header domain.

• Relaxed alignment (default): organizational domain match. mail.example.com aligns with example.com.
• Strict alignment: exact match required. mail.example.com does NOT align with example.com.

The classic alignment failure: you send via SendGrid, SPF passes for bounces.sendgrid.net (the SendGrid envelope sender), but the From: header is noreply@yourdomain.com. SPF passed but doesn't align. DKIM saves you — IF you set up DKIM with your own domain (not SendGrid's default s1._domainkey.u123.wl.sendgrid.net).

Lesson: when configuring an ESP, set up DKIM with YOUR domain, not the ESP's default. Most major ESPs offer this as "branded domain" or "custom domain" — use it.

Reading DMARC aggregate reports

Aggregate reports are XML files emailed daily to your rua= address. They're not human-readable raw — use a free service like dmarcian.com, postmarkapp.com/dmarc, or valimail.com to parse them into a dashboard. Look for:

• Unknown sources sending as you — could be legitimate (a marketing tool you forgot about) or actual spoofing.
• Specific senders failing alignment — usually a misconfigured SPF or DKIM on a known sender.
• Volume by IP — most of your mail should come from a small number of known sender IPs.

BIMI — brand logos in the inbox

BIMI (Brand Indicators for Message Identification) is the newest piece of the puzzle. It lets you display your company logo next to authenticated emails in supporting clients (Gmail, Yahoo, Apple Mail).

Requirements:

1. DMARC at p=quarantine or p=reject with pct=100. No exceptions. Reject-only setups get the logo; relaxed monitoring doesn't.
2. A BIMI logo in SVG Tiny PS format (a constrained SVG profile — no scripts, no animations, square aspect ratio).
3. A Verified Mark Certificate (VMC) for Gmail. Costs $1500-2500/year from DigiCert or Entrust. Yahoo accepts BIMI without VMC; Gmail mostly doesn't.
4. A BIMI DNS record pointing to the logo + VMC.

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

Honest take: BIMI is a "if you have it, it helps" rather than a "you need it." For B2B SaaS sending tens of thousands of mails monthly, the VMC cost is hard to justify against the trust signal. For consumer brands sending millions monthly with high open rates riding on visual trust, it pays back.

If you do BIMI:

• Use a logo that's recognizable at 96×96 pixels — the rendered size is small.
• Test in Gmail web AND mobile — render varies.
• Skip it entirely if your DMARC isn't at strict policy yet.

The MX side — verifying inbound is correct

SPF, DKIM, DMARC are about outbound authentication. MX records are about inbound delivery. They're independent, but a complete email setup needs both.

After any infrastructure change (provider migration, new subdomain, etc.), verify with MX Lookup:

• Are the right MX records present? Google Workspace publishes 5; Microsoft 365 publishes 1-2. If you're missing any, your migration is incomplete.
• Are the priorities correct? Lower number = preferred. Round-robin needs equal priorities.
• Are the servers actually reachable? MX Lookup probes TCP port 25. If reachability fails, mail destined for you may be deferred or refused.

Pair this with SMTP Test to verify your outbound relay is reachable, accepts AUTH, and successfully delivers a real message. Use it whenever provisioning a new ESP API key or after a credential rotation.

IP and domain reputation — the invisible layer

Even with SPF, DKIM, and DMARC perfectly configured, you can land in spam if your sending IP or domain has a bad reputation. Reputation is built (or wrecked) by:

• Bounce rate — hard bounces (5xx, "user does not exist") tank reputation fast. Soft bounces (4xx, temporary) are tolerated.
• Spam complaint rate — every "report spam" click hurts. Gmail's threshold for bulk senders is 0.3% (3 in 1000). Above that, your domain gets de-prioritized.
• Engagement — opens, clicks, replies help. Mail that nobody opens hurts.
• Content patterns — spam-trigger words, weird HTML, broken images. Less impactful than it used to be but still real.
• Blocklist status — if your sending IP gets listed on Spamhaus / Barracuda / SORBS, expect deliverability to crater.

Run your sending IPs through IP Blacklist Check monthly. A single major blocklist hit is recoverable; multiple hits or a Spamhaus listing is a big deal.

Warming up a new domain or IP — the warm-up plan

Here's the part most posts gloss over. If you start sending 100,000 emails a day from a brand-new sending domain (or a brand-new dedicated IP), receivers will treat you as suspicious — even if your SPF, DKIM, and DMARC are perfect. New senders have no reputation; mass volume from no reputation looks like a spam campaign.

The fix is warm-up: send slowly at first, ramp gradually over weeks, target your most engaged recipients first.

Why warm-up matters

Receivers learn about your sending behavior over time. When a Gmail server sees your IP for the first time, it has no historical data — so it leans on signals like SPF/DKIM/DMARC PLUS volume patterns. A brand-new IP suddenly sending 50,000 messages on day one looks identical to a freshly-rented spam botnet. A brand-new IP sending 200 messages on day one, growing 1.5×/day, looks like a normal business launching.

Warm-up applies most strongly to dedicated IPs (custom-allocated for your sending). Shared IPs at major ESPs (Mailgun, SendGrid shared pools) inherit the pool's reputation — usually fine for low-to-medium volume.

A realistic warm-up schedule

For a fresh dedicated IP or new sending domain, plan 4-8 weeks depending on your target volume. The schedule below is conservative; the rule is to ramp daily, not in weekly jumps, and only as fast as your engagement metrics justify.

Two important caveats about this table:

The numbers are starting guidance, not a contract. If your complaint rate climbs above 0.1% or your bounce rate above 2% in any given day, hold or reduce volume — don't keep ramping on schedule. Real warm-up is governed by engagement signal, not the calendar.

For target volumes above ~50K/day, plan 6-8 weeks minimum. Hitting 50K/day in 4 weeks works only if your existing list is genuinely engaged and you accept some risk of reputation damage. ESPs like Mailgun and SendGrid publish official warm-up schedules that span 4-8+ weeks for higher targets — follow theirs if you're on their dedicated IPs.

Two specific tactics:

Spread sends across hours, not minutes. Don't send 5,000 emails in 60 seconds. Spread them across the day in steady throughput. Receivers see "consistent low-volume sender" instead of "sudden burst."

Spread sends across providers, not all to Gmail at once. Each receiver (Gmail, Yahoo, Microsoft) maintains its own reputation for you independently. If your list is heavy on one provider, ramp slowly there and faster on the others.

Engagement-first list selection

The most important rule: only send to people who actually want your mail during warm-up. Specifically:

1. Day 1-7: users who opened or clicked something from you in the last 30 days.
2. Day 8-14: plus users who engaged in the last 90 days.
3. Day 15-21: plus users who engaged in the last 180 days.
4. Day 22+: plus everyone else.

Why? Because every "report spam" click during warm-up is catastrophic. Receivers heavily weight complaint rate during the reputation-building phase. One bad week of complaints during warm-up can set you back months.

Re-warming after a long pause

If you stop sending for 30+ days, your reputation degrades. Coming back from a multi-month silence requires a mini-warmup — start at maybe 10% of previous volume and ramp over 3-5 days.

Should you use a "warm-up service"?

Tools like Mailwarm, Warmy, Lemwarm pretend to engage with your emails to build engagement signal. Honest take: they help marginally for cold outreach, but Gmail and Microsoft have gotten much better at detecting the artificial engagement patterns. For transactional and opted-in marketing, organic engagement (sending to people who want your mail) beats any warm-up service. If your real engaged audience can't sustain warm-up, consider whether you should be sending at this volume at all.

When mail starts going to spam — the diagnostic checklist

When you (or a customer) reports "your emails are going to spam now," run through this in order:

1. Get the headers. Ask the affected recipient to forward you the email as attachment (so headers survive). Paste them into Email Header Analyzer and look at the Authentication-Results line.

2. Check what failed. SPF failure? DKIM failure? DMARC misalignment? Each points at a different fix.

3. Verify SPF for the From-domain. Run SPF Checker. Common findings: a recently-added include pushed you over 10 lookups, or someone added a second SPF record.

4. Verify the sending IP isn't blocklisted. Run IP Blacklist Check on your sending IP. Spamhaus PBL/SBL hits are the most damaging.

5. Check your sending volumes vs. complaint rates. If complaint rate is above 0.3% on Gmail, you have a content / list-hygiene problem, not an authentication problem. Where to look:

• Gmail Postmaster Tools (postmaster.google.com) — register your sending domain to see per-day complaint rate, spam rate, IP/domain reputation, and delivery errors directly from Google. This is the single most useful free tool for Gmail-bound mail.
• Microsoft SNDS (sendersupport.olc.protection.outlook.com/snds) — register the IPs that send into Microsoft 365 / Outlook to see filter results and complaint counts. Apply for the JMRP program at the same address to receive feedback loops on Outlook complaints.
• Your ESP dashboard — the typical paths: Mailgun → Sending > Domains > Logs/Stats; SendGrid → Stats > Recent Activity and Suppressions > Spam Reports; Postmark → Servers > Activity > Suppressions; Amazon SES → CloudWatch metrics + Reputation Dashboard; Mailchimp → Reports > Email per campaign.
• Feedback loops (FBL) — Yahoo, AOL, and several smaller receivers send "this user marked you as spam" reports to a registered abuse address. Sign up via each provider's FBL page; your ESP usually handles this automatically.

6. Check DMARC aggregate reports. Look for unauthorized senders, alignment failures, sudden volume changes from unexpected IPs. The reports themselves are XML files emailed to the address you put in rua=; raw XML is unreadable, so use one of these parsers:

• Postmark DMARC monitoring (dmarc.postmarkapp.com) — free, just point your rua= at the address they assign you. Weekly digest emails with a dashboard of who is sending using your domain.
• dmarcian (dmarcian.com) — commercial, more granular tooling and historical analysis; free tier for low-volume domains.
• URIports / dmarcanalyzer / Valimail — commercial alternatives with similar UI.
• Roll your own — drop the XML attachments into a parser like dmarc-cat (CLI) or the open-source dmarc-srg web UI hosted on your own infrastructure if you don't want to share aggregate reports with a third party.

What to scan for in any of these: senders you don't recognize, IPs outside your usual ranges, repeated alignment failures from a specific source, and sudden volume changes (especially spikes from a single unauthorised IP — strong indicator of a domain spoofing campaign).

7. Test the relay. Use SMTP Test to confirm your relay is healthy — TLS negotiating, AUTH succeeding, no 5xx errors at RCPT.

If everything passes the diagnostic checklist and mail is still going to spam, the issue is reputation/content. That's a slower fix — improve list hygiene, lower volume temporarily, increase engagement, wait for reputation to recover.

A practical setup checklist for a new domain

If you're standing up email for a new domain, here's the order:

1. Set up MX records — point at your inbound provider (Google Workspace, Microsoft 365, Mailgun receiving, etc.).
2. Publish SPF — start with just your inbound provider's include + ~all (softfail) to be safe.
3. Set up DKIM — generate keys at your sending provider, publish the public key.
4. Verify both with a test email — send to a Gmail you control, check Authentication-Results.
5. Publish DMARC p=none — with rua= pointing to a monitored mailbox.
6. Wait 4 weeks, read the aggregate reports. Identify all your sending sources.
7. Tighten SPF — add any missing legitimate senders, verify lookup count is under 10.
8. Move DMARC to p=quarantine with pct=10 — gradually ramp to 100.
9. Move DMARC to p=reject — once you're confident every sender is authenticated.
10. Optionally add BIMI — once DMARC is at strict policy and you have budget for VMC.

Total time: 8-12 weeks from "started" to "fully locked down." Faster only if you're willing to risk legitimate mail being rejected during the ramp.

If you only do one thing this week: run your primary sending domain through SPF Checker, MX Lookup, and IP Blacklist Check. Most teams discover at least one of: an SPF over the lookup limit, a stale MX record from an old provider, or a sending IP newly listed on a minor blocklist. Each one quietly hurts deliverability until found.