Email Deliverability 2026: Why One in Three Never Lands

Across the cold campaigns we have run for clients over the last two years, roughly one in three emails never reaches the inbox. Not bounced. Not rejected. Quietly filed into the spam folder by Gmail, Outlook, or the receiving server’s filter — invisible to the prospect, untracked by the sending tool, counted as “delivered” by every reporting dashboard you might open. That gap between delivered and seen is what email deliverability is actually about, and it is where most cold campaigns die without anyone noticing.

Most of what gets written on the topic in 2026 still misses the actual mechanics. This is the long version. By the end you will know how Gmail and Microsoft actually score your messages, which authentication and reputation moves matter (and which are theatre), and what the day-to-day operating rhythm of a deliverability-aware sender looks like. We pull from infrastructure we run ourselves at AFF Lab — domain warm-up at scale, Postfix and OpenDKIM in production, and the campaign data from real client outreach.

Email deliverability is the probability that a message you sent reaches the recipient’s inbox — not their spam folder, not their promotions tab, not silently dropped at the gateway. It is determined by three layers stacked on top of each other: authentication, reputation, and content + engagement signals. Each is necessary; none is sufficient on its own.

If you are setting up cold outreach for the first time, work through this from top to bottom. If something is already broken, jump to the diagnostic section at the end — it walks you through a five-minute triage.

”Delivered” is not what you think it is

The first confusion to clear out: the words delivered, inbox placement, and deliverability are routinely used to mean different things, and the gap between them is where most cold campaigns die.

When your outreach tool says a message was delivered, it usually means: the receiving SMTP server accepted the message at the gateway and returned a 250 OK. That is it. The server has agreed to take the message. What happens next — whether it ends up in the inbox, the spam folder, the promotions tab, or a quarantine the user never checks — is decided by the receiving system, not the sender.

The metric you actually care about is inbox placement rate: out of every 100 accepted messages, how many land in the primary inbox where a human will see them. Industry benchmarks for B2B cold email in 2026 sit in a fairly wide range:

What we see across our own sending infrastructure, by sender state:

Sender state	Typical inbox placement
Well-set-up domain, warmed 6+ weeks	75–90%
New domain, properly authenticated	50–70%
New domain, no warm-up	20–40%
Domain on a public blacklist	5–20%
Authentication failing (no SPF/DKIM)	10–30%

The invisible loss we mentioned at the top is the difference between a tool reporting 95% delivered and a real placement rate of 60%. Nothing in your outreach platform will tell you this. The only ways to actually know are seedbox testing (sending to a panel of test inboxes across providers) or third-party tools like GlockApps, MailGenius, or Mailtrap. Set this up before you send your first campaign. Otherwise you are flying blind.

The three layers of deliverability

Modern mail providers (Gmail, Microsoft, Yahoo, Apple) decide where to put your message based on three independent layers. We will go through each in turn, but understanding the structure first matters because most “deliverability hacks” you read about online are obsessed with one layer while completely ignoring another.

1. Authentication. Does the receiving server believe the sender is who they claim to be? SPF, DKIM, DMARC, and ARC handle this. A failure here is binary: most major providers now reject or quarantine unauthenticated bulk mail outright.
2. Reputation. Does the receiver trust this domain and IP based on past behavior? Spam complaint rate, bounce rate, engagement, blacklist status, and consistency of sending pattern all roll up into a reputation score the receiver computes privately. You cannot see your score directly; you can only infer it.
3. Content and engagement. Does the message itself look like spam, and do real users actually engage with it once delivered? Headers, body content, link patterns, image-to-text ratio, and recipient engagement (opens, replies, marks-as-spam) all feed into per-message classification.

Authentication is necessary but not enough. Reputation will sink you even with perfect authentication. Content can save or kill a delivery even with strong reputation. They are multiplicative — bad performance on any one layer drags everything else down.

Layer 1: authentication done right

This is the foundation. Every modern mail provider now requires SPF and DKIM at minimum, and DMARC is going from “recommended” to “expected” — since February 2024 Google has required bulk senders (above 5,000 messages/day to Gmail) to authenticate with SPF and DKIM and publish a DMARC record, which can be as light as p=none, with the From domain aligned to SPF or DKIM.^[1] Yahoo introduced the same authentication and DMARC (at least p=none) requirements, with no stated volume threshold.^[2]

Three records you must publish:

• SPF (Sender Policy Framework) — a DNS TXT record listing which servers are allowed to send mail for your domain. Receiving servers check the envelope sender against this list.
• DKIM (DomainKeys Identified Mail) — a cryptographic signature added to every outbound message. The receiver fetches your public key from DNS and verifies the signature.
• DMARC (Domain-based Message Authentication, Reporting & Conformance) — tells receivers what to do when SPF or DKIM fail, and where to send aggregate reports.

SPF and DKIM are not alternatives — you need both. SPF authenticates the sending IP (“is this server allowed to send for this domain?”); DKIM authenticates the message itself (“was this altered in transit?”). SPF breaks when mail is forwarded; DKIM’s signature survives it. DMARC wants at least one of them passing with alignment, and running both is the belt-and-suspenders that keeps you authenticated when one of them breaks. The three sections below are the exact setup for each record — SPF and DKIM first, then DMARC to tie them together.

Setting up SPF (step by step)

SPF (Sender Policy Framework) is one TXT record at the root of your sending domain that lists which servers may send mail as you. When a message arrives, the receiver looks up this record and checks the sending IP against it — a match passes, a miss reads as a spam signal. The record looks like this:

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

Step 1 — list every service that sends as your domain. Your mailbox provider (Google Workspace, Microsoft 365), your cold-email tool (Smartlead, Instantly, Lemlist, Apollo), and any transactional or CRM sender (SendGrid, Mailgun, HubSpot). Miss one and its mail SPF-fails.

Step 2 — collect each service’s include: value from its docs: Google Workspace include:_spf.google.com, Microsoft 365 include:spf.protection.outlook.com, SendGrid include:sendgrid.net. Combine them into a single string that opens with v=spf1 and ends with the fall-through.

Step 3 — publish one TXT record at the root (@) of the sending domain, value set to the string above, TTL default. One SPF record per domain, never two — multiple v=spf1 records invalidate each other.

Step 4 — verify after propagation (5–60 min) with dig +short TXT yourdomain.com, or MXToolbox’s SPF checker, which also validates syntax and the lookup count.

Two rules decide whether it actually works. Use ~all (soft-fail), not -all (hard-fail), until you have confirmed every legitimate service is listed — a premature -all rejects your own mail the moment you forget one; tighten to -all only after a month of clean sending. And stay under the 10-DNS-lookup limit: every include: counts, nested includes count too, and going over throws a permerror that most receivers read as an outright SPF failure.^[3] If deep include chains (Salesforce, HubSpot) push you over 10, flatten the includes to IPs or drop services you no longer use. Never use +all (authorizes anyone) or ?all (no opinion) — both defeat the record.

Setting up DKIM (step by step)

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outbound message. The sending service signs with a private key; the receiver fetches the matching public key from your DNS at <selector>._domainkey.yourdomain.com and verifies the signature — proof the message came from your domain and wasn’t altered in transit.^[4] The published record holds the public half only:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQK...

Step 1 — generate the key pair. Almost every service does this for you and hands you a public key to publish (Google Workspace: Admin Console → Apps → Gmail → Authenticate email → Generate new record). Self-hosted Postfix uses opendkim-genkey.

Step 2 — note the selector the service gives you (google, s1, smartlead, default). The DNS host is <selector>._domainkey — for example google._domainkey.

Step 3 — add the TXT record at that host with the public-key value. Use 2048-bit keys; they exceed the 255-character TXT-string limit and get split into multiple quoted strings — most DNS providers do this for you, but confirm the whole key landed with dig. Never put the private key in DNS.

Step 4 — verify the record resolves: dig +short TXT <selector>._domainkey.yourdomain.com.

Step 5 — verify signing actually happens. A published key does not mean mail is being signed. Send a test message and confirm a DKIM-Signature header on the way out and dkim=pass in the recipient’s Authentication-Results. This step catches the most common failure — a correct record sitting over a service that was never switched on to sign.

Give cold outreach its own selector, separate from transactional mail, so a reputation hit on one stream never touches the other; when you run several sending services, give each its own selector so their keys stay isolated. Most teams set DKIM up once per service and rotate keys once a year as security hygiene.

Setting up DMARC and choosing a policy

DMARC ties SPF and DKIM together and tells receivers what to do when they fail. One TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r

p= is the policy (below); rua= is where aggregate reports go — point it at a mailbox you actually check; adkim/aspf set alignment mode, and relaxed (r) is right for almost everyone. DMARC only passes when SPF or DKIM not merely passes but aligns with the From-domain: mail from outreach.example.com with a From header of [email protected] fails alignment even with a valid signature. And a record on example.com does not cover the subdomain mail.example.com — set sp= if your subdomains send.

The policy is a ladder, and the mistake that wrecks deliverability is jumping to the top of it.

• p=none (monitoring). Receivers change nothing but send you reports. Start here, always. Sit here 2–4 weeks, until the reports confirm 100% of your legitimate mail passes SPF or DKIM with alignment.
• p=quarantine. Failing mail goes to spam instead of the inbox — demoted, not lost. Roll it out gradually with the pct= knob: p=quarantine; pct=10 quarantines 10% of failing mail^[5]; raise to 25, 50, then 100 over 2–3 weeks while watching reports. This is where most B2B cold senders should stop.
• p=reject. Failing mail bounces outright — the strongest anti-spoofing signal and the least forgiving one: any authentication gap silently drops real mail. Reserve it for banks, government, and high-impersonation-risk brands with the operational rigor to back it.

Done properly, the full migration takes 6–12 weeks. Compressing it, or skipping p=none, is how teams end up bouncing their own mail for weeks before they work out why.

Two more failure modes survive even a correct set of records:

• Hosting your own SMTP without a PTR record. Reverse DNS still matters in 2026. Without a PTR record pointing back to the sending hostname, Gmail downgrades you regardless of how clean SPF, DKIM, and DMARC look.
• Skipping ARC. If your cold mail flows through a service that resigns or forwards (Google Groups, mailing lists, some agencies), ARC headers preserve the original authentication chain. Most cold senders don’t need it, but if you see DMARC failures on messages you trust, ARC is the likely cause.

Once authentication is solid, you have earned the right to send — but sending is only half the wiring.

MX records: what they are and how to set them up

Authentication is all about sending. But a cold campaign only works if replies come back — and that starts with MX.

An MX (Mail eXchange) record tells the internet where to deliver mail addressed to your domain. It is a hostname plus a priority value (lower = tried first); a receiving server looks up your MX records and delivers to the lowest-priority host that answers. No MX record, no replies — and you won’t notice, because the bounce goes to the prospect, not to you; they just seem to go quiet. Verification services also read MX to decide whether a domain can receive at all, so a domain sending at volume with no MX looks suspicious.

For Google Workspace in 2026 the setup is a single record:

Type: MX   Host: @   Value: smtp.google.com   Priority: 1

This replaced the old five-record aspmx.l.google.com set (priority 1 plus four alt fallbacks); the old format still works but new domains should use the single record.^[6] The steps:

Step 1 — open DNS for the domain at your provider (Cloudflare, Route53, GoDaddy, Namecheap).

Step 2 — remove any stale MX records left from a previous provider. Mixing old and new MX entries makes routing unpredictable.

Step 3 — add the MX record above: host @ for the root domain, value smtp.google.com, priority 1. Set the priority explicitly — some providers default it to 0 or 10, which won’t match.

Step 4 — verify after propagation with dig +short MX yourdomain.com (expect one record, smtp.google.com, priority 1), then confirm in Admin Console → Apps → Gmail → Verify your domain.

Two things to keep straight. Point MX at a hostname with a real A record, never a CNAME — some receivers reject a CNAME’d MX. And give every sending subdomain that should receive mail its own MX record. One common confusion: cold-email tools (Smartlead, Instantly, Apollo) are sending platforms — they don’t need MX records; your mailbox provider does.

Sending and reading mail: SMTP and IMAP

SMTP (ports 587 STARTTLS or 465 SSL) sends your outbound mail. IMAP (port 993) reads the inbox and sent folders. Cold-email platforms need both: SMTP to send, IMAP to detect replies, confirm sends, spot bounces and auto-replies, and drive the unified master inbox. Configure only SMTP and the platform sends but never sees the replies. Two practical notes for 2026: authenticate with an app password or OAuth, never your account password — Microsoft 365 has retired basic SMTP auth entirely, so OAuth is mandatory there — and at high volume prefer API sending (Gmail API, Microsoft Graph) over SMTP for higher rate limits and cleaner delivery feedback. Don’t use POP3: it pulls mail off the server and breaks the persistent state cold platforms rely on.

With the plumbing in place, reputation decides whether anyone actually reads what you send.

Layer 2: reputation, the invisible scoreboard

Here is the part that breaks new senders: even a perfectly authenticated message from a brand new domain will land in spam at Gmail. The reason is reputation.

Gmail and Microsoft each maintain a private reputation score for every sending domain and every sending IP. They never publish the score, never tell you what it is, never explain how it changed. They use it to decide, for each message, whether to inbox it, promotions-tab it, spam-folder it, or drop it on the floor.

A new domain has no reputation. To Gmail, “no reputation” is closer to “untrusted” than to “neutral.” So step one for any new cold sender is domain warm-up — a gradual ramp of sending volume and engagement to establish a track record.

The mechanics of a typical warm-up:

• Weeks 1–2: send 5–10 messages per day to inboxes you control or that participate in a warm-up pool. Open every message, reply to about a third, move any that landed in spam back to the inbox.
• Weeks 3–4: scale to 25–50 messages per day. Through the warm-up period, aim to keep replies to your warm-up correspondents at around 20–30% — this is a warm-up target on seeded mailboxes, not a benchmark for cold campaigns.
• Weeks 5–6: 100–200 per day, including a few real outreach messages mixed in.
• Week 7+: carefully ramp into real campaign volume, monitoring inbox placement weekly.

Skipping warm-up costs you the first month of campaigns — they go straight to spam. Several tools automate this (Mailwarm, Lemwarm, Warmup Inbox, Instantly’s built-in warm-up). They all do roughly the same thing: route messages between participating mailboxes and simulate engagement. They are not magic — what they do is buy you time to build a track record without burning real prospects.

Beyond warm-up, ongoing reputation depends on five inputs receivers watch:

Signal	What it measures	Healthy range (cold B2B)
Spam complaint rate	% of recipients clicking “Report spam”	< 0.1%
Bounce rate	% of messages rejected by the receiving server	< 2%
Reply rate	% of messages getting a human reply	> 3% (warm signal)
Engagement	Opens + clicks (less weighted in 2026)	varies
Sending consistency	Day-over-day volume volatility	low

Spam complaint rate is by far the biggest killer. Once you exceed 0.1% — that’s one complaint per thousand messages — Gmail throttles you fast and stays cautious for weeks.^[1] Bounce rate matters too; over 2% suggests poor list hygiene, which receivers interpret as a sign you’re sending to scraped or stale data.

Reply rate is the modern reputation booster. Cold senders who consistently provoke replies get a better reputation than legitimate transactional senders who don’t. Receivers know that a real human responded, which means the messages aren’t pure spam. This is one of the strongest arguments for personalization at scale — replies aren’t just nice to have; they directly improve your inbox placement on the next campaign.

The hardest part of reputation management: you can lose it in days and rebuild it over weeks. One bad batch (a stale list, a deliverability-tanking subject line, a sudden 5x volume spike) can knock your placement rate down by 20–30 percentage points overnight. Recovering requires going back to small volumes, high engagement, and patience. Plan for this. Senders who treat their domain reputation as a fragile asset — because it is — outlast the ones who don’t.

Layer 3: content and engagement signals

Content filters in 2026 are nothing like the keyword-blocker spam filters of 2010. Gmail and Microsoft both run learned models that combine hundreds of features — header structure, body language patterns, link domains, image-to-text ratios, sending patterns, recipient interaction history. You cannot game your way around them with tricks like writing “FR3E” instead of “FREE.”

What you can do is avoid the patterns that consistently correlate with spam in the training data.

Subject lines. Avoid all-caps, multiple exclamation marks, currency symbols followed by amounts, urgency markers (“ACT NOW”, “limited time”), and “Re:” or “Fwd:” prefixes on first contact (this last one used to work; it now actively flags). Subject lines that perform well in B2B cold mail tend to be short (3–7 words), specific, and reference something about the recipient or their company.

Body content. The single biggest red flag in 2026 is the template feel — a body that reads like 10,000 other identical messages. Filters detect this both through text similarity scoring and through the absence of personalization variables in the rendered HTML. A message that just substitutes [First Name] and nothing else looks templated; a message that references a specific recent event, role detail, or company fact looks bespoke. The filters can tell.

Links. One link per message is fine. Two is fine. Five or six trigger filters. Use a single direct link (your domain or a meeting tool), not URL shorteners (bit.ly, tinyurl), which are heavily downgraded. If you use a custom tracking domain — and you should — make sure it has its own SPF and DKIM, and that it’s not on any blacklists separate from your sending domain.

HTML versus plain text. Plain-text or lightly-styled HTML wins in B2B cold mail. Heavy HTML emails with embedded images, multiple fonts, and elaborate layouts look like marketing and get categorized as promotional. The styling penalty is real — we have seen the same message in two versions (plain text vs. styled HTML) place at 78% vs. 41% in the same domain pool.

Unsubscribe link. Required for compliance, but more importantly, having one lowers your spam complaint rate. A recipient who wants out will use the link instead of clicking “Report spam.” That difference is worth 5–10 points of inbox placement on its own. RFC 8058 one-click unsubscribe (List-Unsubscribe-Post: List-Unsubscribe=One-Click) is now expected by Gmail for bulk senders (above 5,000 messages/day)^[1] and by Yahoo.^[2]

Engagement is half the score. Receivers heavily weight what your actual recipients do with your messages. Opens (less than they used to, since Apple Mail Privacy Protection added a lot of noise), clicks, replies, deletions without reading, and marks-as-spam all feed back into per-recipient and per-domain reputation. The implication: targeting matters as much as content. A perfect message sent to the wrong list still gets ignored, and the receiving system learns that your domain sends to people who don’t engage.

Custom tracking domains

Every tracked link in your email — the ones that record opens and clicks — routes through a tracking domain before redirecting to the real destination. By default your platform uses a shared tracking domain, the same one used by every other sender on it, spammers included. When their tracking domain gets blocklisted, your tracked mail inherits the damage, because content filters judge the reputation of every link domain in the body.

A custom tracking domain fixes this: a CNAME record pointing a neutral subdomain (track., link., or r. — never offers. or promo.) at your platform’s tracking host, so links read as your domain and your tracking reputation is isolated from everyone else’s. Setup is 15–30 minutes per sending domain: add the CNAME, point the platform at it, and confirm the rendered links use HTTPS (an HTTP tracking link is itself a filter flag). The direct placement lift is modest — a few points — but the reputation isolation compounds as volume grows, which is why production teams at 500+ sends per day treat it as standard infrastructure, not an optional extra.

Operations: the day-to-day grind

Authentication and content are one-time setup. Reputation is built and lost continuously. The day-to-day operations of a deliverability-aware cold sender look more like running a small infrastructure than like marketing.

Volume management. Don’t ramp from 50 to 500 messages per day overnight. Increase volume by no more than 30% week over week, and back off immediately if placement rates drop. Send during business hours in the recipient’s timezone, not all in one burst at midnight.

List hygiene. Every list needs scrubbing before sending. Email verification tools (NeverBounce, ZeroBounce, Hunter Email Verifier, Bouncer) catch invalid addresses before they bounce — bounces directly damage reputation. Scrubbing typically removes 5–15% of any list; that’s normal. If verification flags more than 25%, your source is probably scraped or stale and the list should be discarded, not sent to.

Multiple sending domains. Senior cold operators run multiple sending domains in rotation. The pattern: own yourbrand.com as the main corporate domain (used for transactional and brand), then register variants like yourbrand-mail.com, getyourbrand.com, tryyourbrand.com for cold outreach. Each variant gets its own warm-up, its own reputation, and limits the blast radius if one gets burned. If you send more than 1,000 cold messages per week, this isn’t optional.

Blacklist monitoring. Public blacklists (Spamhaus, SORBS, Barracuda) flag domains and IPs they consider abusive. Being listed is mostly a symptom, not a cause — by the time you’re on Spamhaus, your placement has already collapsed. But scanning weekly catches problems you might otherwise miss. MXToolbox or Multi-RBL check let you scan in 30 seconds.

DMARC reports. Once DMARC is set to p=quarantine or p=reject, you receive aggregate XML reports daily. Most senders never read them. They are unpleasant raw — XML, technical, voluminous — but they’re the only place you see authentication failures from third parties, which catches misconfigurations and impersonation attempts. Postmark DMARC, dmarcian, or EasyDMARC turn the XML into a dashboard for $20–50 per month.

Seed testing. Run a seed test before any campaign over 1,000 messages. A seed list of 30–50 inboxes spread across Gmail, Outlook, Yahoo, and corporate domains, used as a control group. Send the campaign to the seed list first; if placement is under 60%, fix something before sending the rest.

A 30-day setup, day by day

For a brand new sending operation, the realistic timeline is one month from registration to confident campaign volume:

• Days 1–3. Register the sending domain, set up SPF, DKIM, DMARC at p=none. Set up mailbox infrastructure (Google Workspace, or self-hosted Postfix + Dovecot + OpenDKIM). Configure PTR records on your sending IP. Sign up for Postmaster Tools and a DMARC report dashboard.
• Days 4–7. Begin warm-up. Start at 5 messages per day, build to 25 by end of week one. Monitor placement on a small seed list daily.
• Days 8–14. Continue warm-up. Build to 75 messages per day. Move DMARC to p=quarantine once you’ve reviewed two weeks of clean reports.
• Days 15–21. Begin real outreach in low volumes (50 messages per day cold, plus continued warm-up). Run a seed test before the first real send.
• Days 22–30. Ramp to target sending volume. Run weekly seed tests, weekly blacklist scans, daily Postmaster checks. Adjust copy, targeting, and volume based on what the data shows.

One thing Google does not make obvious: Postmaster Tools shows nothing until your domain sends a meaningful daily volume to Gmail addresses, sustained over several days. Below that, every chart reads “No data to display” — which means a small or newly warmed sender cannot use it for diagnosis yet. Google does not publish the exact threshold. If you are seeing empty charts, the tool is not broken and neither is your domain; you simply are not sending enough to Gmail for the data to exist.

After 30 days you have a real domain with real reputation, deliverability around 75–85%, and a measurement loop. That is the baseline; from here, ongoing operations decide whether deliverability climbs to the 85–95% range over the next 90 days or slowly erodes.

Diagnosing deliverability problems: a five-minute triage

When campaigns suddenly stop performing, work through this checklist in order. Most problems resolve at one of the first three steps.

Step 1 — Authentication check (60 seconds). Use MXToolbox SuperTool or dig on your sending domain. Verify SPF resolves with no errors and stays under 10 DNS lookups. Verify DKIM selector resolves to a valid key. Verify DMARC record exists and uses a sensible policy. If any of these fail, fix authentication first — nothing else matters until they pass.

Step 2 — Blacklist scan (60 seconds). Run your sending domain and your sending IP through MXToolbox Multi-RBL. Hits on Spamhaus, SORBS, or Barracuda block 80%+ of inbox placement at major providers. Delisting takes 1–7 days and requires evidence that the problem is fixed.

Step 3 — Seed test (5 minutes to run, 30 minutes for results). Send the campaign — or just one of its messages — to a seed list. If placement is over 75%, deliverability is fine and the problem is elsewhere (targeting, copy, offer). If placement is under 50%, the problem is sender-side.

Step 4 — Recent volume and complaint check. Has volume jumped recently? Did a recent campaign get an unusual number of spam complaints? Gmail and Microsoft will throttle you for days after a single bad batch. Cut volume by 70% for a week, rebuild engagement, then ramp slowly.

Step 5 — Postmaster Tools. Sign up for Google Postmaster Tools for your sending domain. It’s the only public window into how Gmail sees your reputation.^[7] Domain reputation rated “Bad” or “Low” means stop sending until you fix things. “Medium” is salvageable. “High” is what you want.

For founders who send 20 emails per day, the setup above is overkill — Google Workspace plus reasonable copy is enough. For sales teams sending 200+ per day per rep across multiple campaigns, deliverability is a full-time job. Most teams underestimate this and lose three months of pipeline before realizing they have a deliverability problem rather than a copy problem. If you are seeing inbox placement under 60% on a domain that should be doing better, or if you are about to scale from 100 to 1,000 messages per day, the math usually favors handing the infrastructure work to someone whose entire job is keeping it running — which is what we do at AFF Lab’s email outreach service. The savings on one campaign that actually lands more than pay for it.