Email Deliverability for B2B Teams: A Practical Guide

When email performance drops, the instinct is to buy something — a warmup service, an inbox-placement monitor, a new sending platform. Almost always the cause is upstream of any tool: a missing DNS record, a list containing addresses nobody consented to, or a sending pattern structurally identical to a spammer's.

This guide is the diagnostic order: authentication, then list hygiene, then infrastructure and content. Tools come last, and for most teams never come at all. Mailbox providers do not sell trust — they publish requirements you can meet and weigh a reputation you earn by sending mail people want. Every deliverability product sits on top of that, measuring it, simulating it, or gaming it. Some is genuinely useful; DMARC reporting platforms solve a real problem, since raw aggregate reports are XML. But a warmup subscription bolted onto a domain with no DKIM record and a purchased list is money spent to make a broken thing fail more slowly. The highest-ROI fixes below cost nothing but DNS access and an afternoon.

Authentication: what SPF, DKIM and DMARC actually do

The three are described as one thing, but each answers a different question, and DMARC only works because the other two exist.

SPF (Sender Policy Framework) publishes a DNS TXT record listing which servers may send using your domain in the envelope sender — the MAIL FROM address, or return path. It says nothing about the From: address your recipient sees, and it breaks on forwarding, because the forwarding server isn't on your list. It also has a hard ceiling: RFC 7208 limits evaluation to ten DNS-querying mechanisms, after which the check returns permerror. Teams that chain an include: for every SaaS tool sending on their behalf blow past this without noticing.

DKIM (DomainKeys Identified Mail) signs the headers and body cryptographically, verifiable against a public key in DNS. It proves the message wasn't altered in transit and that the signer controls the signing domain. Unlike SPF it survives forwarding — but the signing domain needn't match the From: address, which is the gap DMARC closes.

DMARC requires alignment: the visible From: domain must match the SPF or DKIM signing domain. It then tells receiving servers what to do when alignment fails, and where to send reports. The policy values are what people get wrong:

• p=none — monitor only; failing mail is delivered normally and you get reports. A data-collection posture, not protection.
• p=quarantine — failing mail treated as suspicious, typically routed to spam.
• p=reject — failing mail refused outright.

Publishing p=none and stopping is the most common half-finished deliverability project in B2B: it satisfies the letter of the bulk-sender requirements while doing nothing to stop anyone spoofing your domain. Run p=none for a few weeks, read the aggregate reports, fix every legitimate service sending as you that isn't aligned, then move to quarantine and eventually reject. The sp= flag sets a separate subdomain policy. Note that pct=, long used to roll a policy out to a share of mail, was removed in the May 2026 DMARC revision (RFC 9989) and marked historic; a t= tag replaces part of its function. Guides still recommending pct= predate that change.

Authentication cheat-sheet

Record	What it proves	How to check it	Common failure
SPF (TXT, root domain)	The connecting server is authorised to use your domain in the envelope sender	dig TXT yourdomain.com — look for v=spf1	More than ten DNS lookups (permerror); two SPF records published, which invalidates both; using +all
DKIM (TXT, selector._domainkey)	The message was signed by a key holder and wasn't modified in transit	dig TXT selector._domainkey.yourdomain.com; check Authentication-Results on a received message	Never enabled in the ESP; key rotated at the provider but not in DNS; short keys
DMARC (TXT, _dmarc)	The visible From: domain aligns with an authenticated domain, and what to do if not	dig TXT _dmarc.yourdomain.com	Stuck at p=none forever; no rua= so nobody reads reports; published before SPF/DKIM are clean, then rolled back
Reverse DNS (PTR)	The sending IP resolves to a hostname that resolves forward to the same IP	dig -x <sending IP>	Missing on self-hosted or VPS sending
TLS	The connection was encrypted in transit	Message headers, or your ESP's delivery logs	Legacy on-prem relays negotiating plaintext

What Google and Yahoo actually require

In February 2024 Google and Yahoo introduced enforced sender requirements — the clearest published statement of the floor, and worth reading in the original.

Google's Email sender guidelines apply to mail sent to personal Gmail accounts. For all senders: SPF or DKIM, a TLS connection, valid forward and reverse DNS, messages formatted per RFC 5322, and no impersonation of Gmail in From: headers.

At roughly 5,000 or more messages a day to personal Gmail accounts the bar rises: SPF and DKIM, a DMARC record (Google explicitly states the enforcement policy "can be set to none"), alignment of the From: domain with the SPF or DKIM domain, and one-click unsubscribe for marketing and subscribed mail — the RFC 8058 headers (List-Unsubscribe plus List-Unsubscribe-Post: List-Unsubscribe=One-Click) and a visible unsubscribe link in the body.

Note the two complaint numbers, which get conflated constantly. Google's guidance is to "keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher." 0.10% is the operating target; 0.30% is the cliff.

Three details from Google's sender guidelines FAQ change how you plan. The 5,000 threshold counts across your primary domain, so subdomains aggregate. Bulk sender status has no expiry, so one large send commits you permanently. And enforcement stepped up from November 2025, with non-compliant traffic now facing "temporary and permanent rejections" rather than soft warnings; Google recommends fulfilling unsubscribe requests within 48 hours. Note also that Google states these requirements apply to personal Gmail accounts, not Workspace mailboxes — read that as a description of enforcement, not of filtering, since Workspace tenants filter on the same signals.

Yahoo's sender best practices run closely parallel: SPF or DKIM at minimum for everyone; both plus a valid DMARC policy of at least p=none that passes, for bulk senders; DKIM keys of at least 1024 bits; one-click unsubscribe with the RFC 8058 POST method highly recommended; spam rates below 0.3%; unsubscribes honoured within two days. Microsoft published its own requirements for high-volume senders to consumer Outlook mailboxes in 2025 — if a meaningful share of your list sits on outlook.com, hotmail.com or live.com, read Microsoft's announcement directly, since details and enforcement dates have moved.

The practical read: the technical requirements are a one-time afternoon of DNS work. The complaint rate is what you keep earning forever, and it is a list problem, not a tooling problem.

Domain strategy: never send cold outreach from your primary domain

This is the structural decision that is expensive to reverse. Cold outreach generates complaints at a rate opt-in mail does not, and if those complaints accrue to the domain that also sends your invoices and password resets, you have coupled your business communications to a prospecting campaign's performance.

So register a separate domain for cold outreach — close to your brand (getacme.com, acme-hq.com), authenticated exactly as thoroughly as the primary, pointed at the same website. Your main domain never sends cold mail; if the outreach domain burns, you replace it. This is why most tools in the cold email software category rotate sends across many mailboxes and domains. The corollary: your newsletter and your outreach are different risk classes and shouldn't share infrastructure either — the B2B email marketing platform comparison covers the opt-in side.

A new domain has no sending history, and sudden volume from an unknown domain is indistinguishable from a spam run. Warming means starting small and ramping over weeks while keeping engagement high. Two caveats: a domain also needs age, so buy it and let it sit; and automated warmup services — mailbox networks that send each other mail and mark it important — sell engagement no real person generated. That is a simulation of reputation, and providers have every incentive to detect artificial reciprocal traffic.

List hygiene is the deliverability lever and the cost lever

Complaint rate and bounce rate are the signals providers weigh most heavily, and both are downstream of who is on your list.

• Hard bounces (address doesn't exist) must be suppressed permanently. Any ESP does this; the failure mode is re-importing the same stale CSV and resurrecting them.
• Soft bounces get retried, but a repeatedly soft-bouncing address should be sunset after a few attempts.
• Spam complaints are the expensive one: Gmail's 0.10% target is one complaint per thousand delivered, and a single badly-targeted send can blow it.
• Unengaged contacts — no open, click or reply in six to twelve months — are the slow poison. They don't complain; they dilute your engagement signal and raise the odds some are now spam traps.

Sunsetting means removing them on a schedule: pick a window suited to your sales cycle, run a re-engagement sequence, then delete — not "pause" — everyone who doesn't respond. That feels wrong to anyone measured on list size for a decade. Do it anyway.

What makes it an easy internal sell is that most email platforms bill by contact count, so unengaged contacts are a line item. Cutting a third of a list that never engages improves your complaint and engagement rates and reduces your invoice, often enough to drop a pricing tier. It is the same logic as a sales tech stack audit that cuts SaaS spend applied to data instead of licences, and a strong card going into a renewal using the SaaS renewal negotiation playbook.

One sourcing point, without straying into legal advice: consent rules differ sharply by jurisdiction — CAN-SPAM in the US, GDPR in the EU and UK, PECR in the UK, separate regimes elsewhere — and differ again between B2B and B2C recipients. Broadly they cover lawful basis for contact, honest sender identification, a working unsubscribe, and a physical address. Get jurisdiction-specific advice from a qualified professional before building a programme on assumptions. From a deliverability standpoint, permission isn't a compliance chore; it's the input that produces the low complaint rate everything else depends on. A form-based lead capture flow recording where and when someone opted in beats any list you can buy.

Content and sending patterns that trigger filtering

Filters are not scanning for banned words. Modern filtering is reputation- and engagement-driven, so the content signals that matter are those correlated with unwanted mail:

• Links to a domain with no reputation, especially URL shorteners and tracking domains shared with thousands of senders. Use a custom tracking subdomain on a domain you own.
• Attachments in cold mail. Don't. Link instead.
• Image-heavy, text-light HTML in a message claiming to be one-to-one.
• Volume steps. Going from 200 sends a day to 5,000 overnight is a spam-run pattern regardless of content.
• Identical bodies at scale, which template-with-no-variables outbound produces.
• Unsubscribe friction. A login wall or multi-step preference centre converts people who would have unsubscribed into people who hit the spam button — the button you're measured on.

Replies are among the strongest positive engagement signals available, and also the actual goal of outbound. Optimising for a real conversation and optimising for deliverability point the same direction.

Diagnosing a deliverability problem, in order

Work down this list. Do not skip to the end because someone sent you a warmup vendor's deck.

1. Confirm authentication. dig your SPF, DKIM and DMARC records, then send to a seed address on Gmail and read the Authentication-Results header — it states spf=, dkim= and dmarc= results explicitly. Ten minutes, and it finds the cause more often than anything else here.
2. Read the DMARC aggregate reports. They list every source sending as your domain, including the tool someone connected without telling you.
3. Open Google Postmaster Tools. Free, and the only direct view of how Gmail rates you.
4. Segment the failure. All providers or one? Gmail-only is usually reputation or requirements on your side; a single corporate domain is usually their gateway, often solvable with a conversation.
5. Read the rejection codes. A 550 citing authentication is a different problem from a rate-limit 421.
6. Check blocklists for your sending domain and IP.
7. Ask what changed. New tool, list import, volume ramp, template change. Drops are almost always caused by an event, and someone knows what it was.
8. Only now consider a placement-testing tool, and only to measure the fix.

Shared vs dedicated IPs: when dedicated is a mistake

A dedicated IP means you control your own reputation, and that cuts both ways: it has none until you build one, needs continuous volume to hold it, and gives you nowhere to hide from your own mistakes. An IP sending in irregular bursts never establishes a stable signal. A shared pool at a reputable ESP is warm on day one and maintained by a vendor with a full-time deliverability team.

Dedicated makes sense at high and consistent volume, when isolating transactional from marketing streams, or when you're large enough that neighbours are a real risk. It's a mistake when volume is modest or spiky — which describes most B2B senders, whose sends cluster around campaigns. If a vendor pitches a dedicated IP as a deliverability fix, ask what your shared-pool reputation actually is. Usually nobody has looked.

What to actually do this quarter

Publish SPF, DKIM and DMARC and confirm alignment. Set a rua= address and read the reports. Move DMARC from none toward quarantine once they're clean. Turn on Google Postmaster Tools. Add RFC 8058 one-click unsubscribe and honour requests inside two days. Split cold outreach onto its own domain. Sunset unengaged contacts and take the ESP savings.

All of it is free apart from a domain registration. Do it before you buy anything, and most teams find there is nothing left to buy — which frees budget for something other than a DNS record you could have published yourself. If the broader tooling question is live, the budget CRM comparison is a better place to spend it.

Frequently Asked Questions

What are the Gmail and Yahoo bulk sender requirements?

For roughly 5,000 or more messages a day to personal Gmail accounts, Google requires SPF and DKIM, a DMARC record (which may be p=none), alignment between the visible From: domain and the SPF or DKIM domain, and one-click unsubscribe per RFC 8058. Google's guidance is to keep spam rates in Postmaster Tools below 0.10% and never reach 0.30%. Yahoo's requirements closely parallel these, adding a 1024-bit minimum DKIM key and honouring unsubscribes within two days.

Do I need DMARC if I already have SPF and DKIM?

Yes. SPF and DKIM each authenticate something that isn't the address your recipient sees, so without DMARC neither prevents someone spoofing your visible From: domain — DMARC is the alignment check that closes that gap. Separately, a DMARC record is an explicit requirement for bulk senders under both Google's and Yahoo's published guidelines.

Should DMARC be set to p=none, quarantine, or reject?

p=none is a starting posture, not a destination — it collects reports without protecting anything. Run it for a few weeks, use the reports to find every legitimate service sending as your domain that isn't aligned, fix those, then step to p=quarantine and eventually p=reject. Publishing p=none and never revisiting it satisfies a checkbox rather than solving a problem.

Do I need an email warmup service?

Usually not. Warming a new domain means ramping volume gradually into genuinely engaged recipients, which you can do without buying anything. Automated warmup networks generate reciprocal mail no real person wanted — a simulation of reputation rather than reputation — and providers have every incentive to detect that pattern.

Why did my email deliverability suddenly drop?

Drops are almost always caused by a specific event rather than gradual decay. Check in order: authentication and alignment via the Authentication-Results header on a test message, DMARC reports for unknown sending sources, Google Postmaster Tools for your spam rate, whether the failure is one mailbox provider or all of them, and the SMTP rejection codes in your ESP logs. Then ask what changed — a list import, a volume ramp, or a newly connected tool is usually it.