DEV Community: live-direct-marketing

Building an Agent-Native Cold Outreach Platform: MCP, A2A, and Pay-Per-Inbox Billing

live-direct-marketing — Fri, 08 May 2026 16:30:49 +0000

LDM launches on Product Hunt this weekend. Sharing what's under the hood for builders.

The two technical bets

Most cold email tools (Instantly, Smartlead, Lemlist, Apollo) are built UI-first. Sales teams click through onboarding, build sequences in dashboards, monitor in dashboards. The API is an afterthought. Agent integration is a webhook at best.

LDM is built API-first, then UI. This let me make two unusual technical bets.

1. Native MCP server, not a plugin

ldm-crm-mcp ships as an npm package. Drop it into Claude Desktop's claude_desktop_config.json and the agent gets typed access to:
contacts.create(data)
contacts.search(query)
pipelines.list()
pipelines.move_card(card_id, stage_id)
campaigns.create(spec)
campaigns.send(id)
dialogs.list(filter)
dialogs.reply(dialog_id, message)
billing.summary(period)

The agent doesn't scrape a UI or call REST manually. It calls tools with typed args, gets typed results. Errors come back as proper tool-call failures, not HTTP status codes the agent has to interpret.

This sounds basic but no other cold outreach platform ships an MCP server today. Smartlead, Lemlist, Instantly — all UI-first, API as afterthought, no MCP.

2. A2A agent card at /.well-known

curl https://live-direct-marketing.online/.well-known/agent-card.json

Returns the A2A protocol manifest — what LDM can do, how to authenticate, what tasks it accepts. Other agents can discover and delegate to LDM without any human pre-configuration.

Why this matters: as agentic systems compose, agents need to discover services they don't know about. A2A is Google's proposed protocol for that. We shipped it as a default, not an add-on.

The pay-per-inbox methodology

The other unusual bet — billing.

Every other cold email tool charges per send. SMTP returns 250 OK, vendor charges, recipient gets it in spam folder. Up to 40% of B2B cold outreach goes to spam (Validity / GlockApps benchmarks). Customers pay for the invisible half.

LDM bills only on verified inbox delivery. Methodology:
For each outbound message M sent at time T from sender S to provider P:

Run concurrent seed test: send equivalent message to our seed mailbox
at provider P from sender S within ±5min window of T
Classify seed result: Inbox, Promotions, Spam, Not-received
Bill on M only if seed verdict ∈ {Inbox, Promotions}
If seed verdict = Spam: don't bill, log as cohort_negative
Maintain rolling cohort accuracy per (provider, sender) pair, exposed in API

Critical honesty: this is probabilistic, not per-message guarantee. We can't see inside the recipient's mailbox. What we can do is bet our revenue that the seed cohort matches the real recipient pool within ±X% — and publish backtest data to prove it.

This is why we don't promise "100% inbox guarantee". Anyone who promises that without controlling the recipient mailbox is lying. We promise: "if our seed cohort says spam, you don't pay."

Edge cases we don't pretend to solve

Corporate Exchange / M365 tenants with custom rules. Our seed cohort can't replicate a recipient's corporate spam policy. We mark these recipients with cohort_confidence: low in the API response. We're explicit about it.

Apple Mail Privacy Protection prefetches images. Open-pixel data is unreliable. Opens are a UX signal in dashboard, never a billing trigger.

Engagement-based gaming. We don't bill on engagement (opens, clicks, replies), so there's nothing to game. Billing is on cohort delivery — which depends on sender domain reputation, which can't be gamed.

The architecture

For builders curious about the stack:

Backend: NestJS + TypeScript + Prisma with multi-tenant DB-per-tenant pattern on PostgreSQL
Workers: BullMQ + Redis for queue management, separate worker pools for send / seed-test / cohort-classification / billing
Monorepo: Turborepo with api, web, mcp-server, agent-card, shared core package
Hosting: EU (Netherlands), GDPR-aligned
MCP transport: stdio (for Claude Desktop / Cursor) and HTTP-SSE (for remote agents)
AI: hybrid OpenAI + Anthropic for content generation, classification, ICP discovery

Try it

Sandbox key in one curl, no signup form:

curl -X POST https://developers.live-direct-marketing.online/v1/signup \
  -H "Content-Type: application/json" \
  -d '{"email": "you@example.com"}'

Then drop into Claude Desktop config:

{
  "mcpServers": {
    "ldm": {
      "command": "npx",
      "args": ["-y", "ldm-crm-mcp"],
      "env": { "LDM_API_KEY": "ldm_pk_..." }
    }
  }
}

Restart Claude. Ask: "show me my LDM pipelines". The agent calls the tool, you see real (empty) data.

What I want feedback on

MCP tool surface: what's missing? What's awkward to call?
Billing methodology: where does the cohort approach break down beyond corporate Exchange?
A2A agent card schema: is the manifest complete enough for cross-agent delegation?

Comments here, on Product Hunt, or DM on X.

Product Hunt launch: https://www.producthunt.com/products/live-direct-marketing?utm_source=devto&utm_medium=article

Docs: https://developers.live-direct-marketing.online

MCP server: npm package ldm-crm-mcp
Перед публикацией — три вещи проверь

ldm-crm-mcp реально опубликован на npm? В памяти у меня ldm-inbox-check-mcp (из awesome-mcp-servers). Если crm-версии нет — либо публикуй пакет до dev.to-публикации, либо поменяй в статье на реальное название
Tool surface в первой code-секции (contacts.create, pipelines.list и т.д.) — это то что реально экспортирует твой MCP сервер? Если нет — поправь под актуальные exports. dev.to-аудитория проверит и спалит несовпадение
/.well-known/agent-card.json — он реально отдаётся? Если нет — либо подними, либо убери эту секцию из статьи

Если хоть один пункт нет — лучше отложи статью на день после PH, доделаешь и опубликуешь когда всё работает. На dev.to легче перенести дату, чем чинить репутацию после "это не работает" коммента.You said: давай в формате md без таблицдавай в формате md без таблиц12:29 PMClaude responded: curl https://live-direct-marketing.markdown---
title: "Building an Agent-Native Cold Outreach Platform: MCP, A2A, and Pay-Per-Inbox Billing"
published: true
description: How we built the first cold email platform with native MCP server and A2A agent card, plus the methodology behind pay-per-inbox billing.
tags: mcp, ai, agents, saas
canonical_url: https://live-direct-marketing.online

cover_image:

LDM launches on Product Hunt this weekend. Sharing what's under the hood for builders.

The two technical bets

Most cold email tools — Instantly, Smartlead, Lemlist, Apollo — are built UI-first. Sales teams click through onboarding, build sequences in dashboards, monitor in dashboards. The API is an afterthought. Agent integration is a webhook at best.

LDM is built API-first, then UI. This let me make two unusual technical bets.

1. Native MCP server, not a plugin

ldm-crm-mcp ships as an npm package. Drop it into Claude Desktop's claude_desktop_config.json and the agent gets typed access to operations like creating contacts, listing pipelines, moving cards between stages, building campaigns, sending them, reading dialogs, replying in threads, and pulling billing summaries.

This sounds basic but no other cold outreach platform ships an MCP server today. Smartlead, Lemlist, Instantly — all UI-first, API as afterthought, no MCP.

2. A2A agent card at /.well-known

curl https://live-direct-marketing.online/.well-known/agent-card.json

Returns the A2A protocol manifest — what LDM can do, how to authenticate, what tasks it accepts. Other agents can discover and delegate to LDM without any human pre-configuration.

Why this matters: as agentic systems compose, agents need to discover services they don't know about. A2A is Google's proposed protocol for that. We shipped it as a default, not an add-on.

The pay-per-inbox methodology

The other unusual bet — billing.

Every other cold email tool charges per send. SMTP returns 250 OK, vendor charges, recipient gets it in spam folder. Up to 40% of B2B cold outreach goes to spam — that's the Validity and GlockApps benchmark range. Customers pay for the invisible half.

LDM bills only on verified inbox delivery. The methodology in plain English:

For each outbound message at time T from sender S to provider P, we run a concurrent seed test — send an equivalent message to our seed mailbox at provider P from sender S within a five-minute window of T. The seed result gets classified as Inbox, Promotions, Spam, or Not-received. We bill on the first two outcomes only. If the seed verdict is Spam, we don't charge and we log it as cohort_negative. We maintain rolling cohort accuracy per provider-sender pair and expose it in the API.

Critical honesty: this is probabilistic, not a per-message guarantee. We can't see inside the recipient's mailbox. What we can do is bet our revenue that the seed cohort matches the real recipient pool within a known error margin — and publish backtest data to prove it.

This is why we don't promise "100% inbox guarantee". Anyone who promises that without controlling the recipient mailbox is lying. We promise: if our seed cohort says spam, you don't pay.

Edge cases we don't pretend to solve

Corporate Exchange and M365 tenants with custom rules. Our seed cohort can't replicate a recipient's corporate spam policy. We mark these recipients with cohort_confidence: low in the API response. We're explicit about it instead of pretending it works.

Apple Mail Privacy Protection prefetches images. Open-pixel data is unreliable. Opens are a UX signal in the dashboard, never a billing trigger.

Engagement-based gaming. We don't bill on engagement — opens, clicks, replies — so there's nothing to game. Billing is on cohort delivery, which depends on sender domain reputation, which can't be gamed.

The architecture

For builders curious about the stack: NestJS with TypeScript and Prisma on the backend, multi-tenant DB-per-tenant pattern on PostgreSQL, BullMQ on Redis for queue management with separate worker pools for send / seed-test / cohort-classification / billing. Monorepo on Turborepo with separate packages for api, web, mcp-server, agent-card, and shared core. EU-hosted in the Netherlands, GDPR-aligned. MCP transport over stdio for Claude Desktop and Cursor, plus HTTP-SSE for remote agents. AI is hybrid OpenAI plus Anthropic for content generation, classification, and ICP discovery.

Try it

Sandbox key in one curl, no signup form:

curl -X POST https://developers.live-direct-marketing.online/v1/signup \
  -H "Content-Type: application/json" \
  -d '{"email": "you@example.com"}'

Then drop into Claude Desktop config:

{
  "mcpServers": {
    "ldm": {
      "command": "npx",
      "args": ["-y", "ldm-crm-mcp"],
      "env": { "LDM_API_KEY": "ldm_pk_..." }
    }
  }
}

Restart Claude. Ask "show me my LDM pipelines". The agent calls the tool, you see real (empty) data.

What I want feedback on

The MCP tool surface — what's missing, what's awkward to call. The billing methodology — where the cohort approach breaks down beyond corporate Exchange. The A2A agent card schema — whether the manifest is complete enough for cross-agent delegation.

Comments here, on Product Hunt, or DM on X.

Product Hunt launch: https://www.producthunt.com/products/live-direct-marketing?utm_source=devto&utm_medium=article

Docs: https://developers.live-direct-marketing.online

MCP server: npm package ldm-crm-mcp

The state of email infrastructure: what 660K DNS records reveal in 2026

live-direct-marketing — Tue, 28 Apr 2026 12:26:32 +0000

The conventional wisdom is that Google Workspace and Microsoft 365 dominate business email. I pulled the DNS records of every domain in Tranco top-1M to check.

Their combined share: 37.94%.

The other ~62% — half a million domains — live somewhere else: hosted at registrars, in regional providers, on cPanel installs at small hosters, or on actual self-managed mail servers. The "duopoly" framing is a thing people say, not a thing the data shows.

This post is about what you actually find when you build a daily DNS snapshot of email infrastructure for the entire public web, what it can and can't tell you, and what's surprisingly broken about it.

TL;DR. Daily snapshot of OpenINTEL's Tranco-1M scan, 2026-01-01. 660,114 domains publish MX, 616,352 publish SPF, 431,133 publish DMARC. Receiving-side share: Google 21.7%, Microsoft 16.3%, Yandex 1.9%, Mimecast 1.5%, Zoho 1.0% — and 25.9% "Unknown" plus another 24% on generic shared-hosting MX patterns. Sending-side: Amazon SES (5.86%) edged past SendGrid (4.66%) by domain count. 20.3% of all DMARC records are p=none with no reporting endpoint — formal compliance, zero protection. Methodology is open and reproducible. Caveats below.

Why measure email infrastructure from DNS

Email is the oldest still-relevant protocol on the public internet, the primary B2B channel, and one of the main attack vectors for phishing. And yet there's no good open dataset of how the ecosystem actually looks: who hosts what, who sends what, and how authentication is configured.

What exists today:

Valimail's Email Fraud Landscape — annual since 2017, DMARC-only, focused on industry cohorts (Fortune 500, US Gov, healthcare). Closed dataset, behind a lead form.
Academic OpenINTEL papers — solid methodology, but each is a one-shot snapshot for a specific publication, not maintained.
BuiltWith / Datanyze — commercial technographics, not reproducible, not for research.

The gap: an open daily snapshot, across all four layers (MX, SPF, DMARC, SaaS senders), at top-1M scale, with transparent methodology. That's what this is.

The data

Source

Base dataset is the daily forward-DNS snapshot from OpenINTEL (University of Twente / SURFnet / SIDN Labs), running since 2015. OpenINTEL queries the entire Tranco top-1M every day for MX, TXT, NS, A, AAAA, SOA, CAA, DNSSEC records and publishes Apache Parquet. Methodology paper: van Rijswijk-Deij et al., IEEE JSAC 2016.

Domain list is Tranco — the research-grade replacement for the deprecated Alexa list, hardened against manipulation (Le Pochat et al., NDSS 2019).

For 2026-01-01: 660,114 domains have valid MX, 616,352 publish SPF (v=spf1), 431,133 publish DMARC (v=DMARC1).

Classification

For each domain we look at four things:

# 1. Mailbox provider — primary MX target (lowest preference)
# matched against ~80 regex rules in mx_providers.py
RULES = [
    (r"\.mail\.protection\.outlook\.com$", "Microsoft 365"),
    (r"aspmx\.l\.google\.com$|aspmx.*\.googlemail\.com$", "Google Workspace"),
    (r"mx\d?\.yandex\.net$", "Yandex 360"),
    (r"\.mimecast\.com$", "Mimecast"),
    # ... specific rules first, generic fallbacks last:
    (r"^mail\.", "Generic / unmatched (mail.*)"),
    (r"^mx\d*\.", "Generic / unmatched (mx*.*)"),
]

# 2. ESPs — every include: in the SPF record, matched against esps.py
# (Amazon SES, SendGrid, Mailgun, Mailchimp, Brevo, etc.)

# 3. SaaS senders — same mechanism, separate dictionary saas_senders.py
# (Shopify, Atlassian, Pardot, KnowBe4, Trustpilot, etc.)

# 4. DMARC — _dmarc.<domain> TXT, parsed for p=, sp=, pct=, rua=
# Domain is "enforced" if p ∈ {quarantine, reject} AND pct=100
# (or pct absent — RFC 7489 §6.6.4 default is 100)

If no rule matches, the domain goes to "Unknown / Other" — never dropped — and its MX target is logged for the next dictionary iteration. Domains are never excluded. Total by category = total domains, always.

Receiving side: who hosts inbound mail

#	Mailbox provider	Domains	Share
1	Unknown / Other	171,044	25.91%
2	Google Workspace	143,171	21.69%
3	Microsoft 365	107,277	16.25%
4	Generic / unmatched (mail.*)	91,739	13.90%
5	Generic / unmatched (mx.)	59,783	9.06%
6	Yandex 360	12,587	1.91%
7	Mimecast	9,850	1.49%
8	Generic / unmatched (smtp.*)	7,649	1.16%
9	Zoho Mail	6,800	1.03%
10	Amazon WorkMail	4,707	0.71%

Two observations that contradict typical industry talking points:

1. The Google/Microsoft duopoly isn't dominant. Combined: 37.94%. The long tail of registrar email, regional hosters, small SaaS, and self-hosted setups is half the market (25.91% Unknown + 24.12% generic = 50.03%).

2. "Generic" doesn't mean self-hosted. A hostname like mail.example.com is the default for cPanel/DirectAdmin shared hosting (Hostinger, GoDaddy, OVH, hundreds of regional providers). The unmatched MX targets confirm registrars dominate the long tail:

#	MX target	Domains
1	route1.mx.cloudflare.net	7,728
2	route2.mx.cloudflare.net	7,727
3	route3.mx.cloudflare.net	7,726
4	eforward5.registrar-servers.com	6,930
5	mx1.hostinger.com	5,110
6	smtp.secureserver.net (GoDaddy)	5,078
7	mx3-hosting.jellyfish.systems	2,212
8	mx1.privateemail.com (Namecheap)	1,658

Cloudflare Email Routing alone shows up on ~23,000 domains across its three MX targets. It's a free email-forwarding service with no real inbox, but as primary MX it's massive — and worth its own writeup.

Yandex 360 at 1.91% looks weirdly low. It is — Tranco is biased toward US/EU and global SaaS. Russian domains with low international traffic are underrepresented. Any conclusion about the Russian email market from this dataset will be wrong; you'd need a separate .ru ccTLD slice.

Sending side: ESPs

Share of the 616,352 SPF-publishing domains. Sums to >100% — most domains authorize multiple ESPs (e.g., Mailchimp for newsletters + SendGrid for transactional):

#	ESP	Domains	Share
1	Amazon SES	36,148	5.86%
2	SendGrid (Twilio)	28,695	4.66%
3	Mailgun	25,066	4.07%
4	Zendesk	24,053	3.90%
5	Mailchimp	23,606	3.83%
6	Mandrill	22,008	3.57%
7	Salesforce	15,426	2.50%
8	Mailjet (Sinch)	12,720	2.06%
9	Brevo (ex-Sendinblue)	6,892	1.12%
10	Elastic Email	4,399	0.71%

Important caveats:

Domain count ≠ email volume. Amazon SES leads by domains because it's the cheapest IaaS-tier sender — small projects pile onto it. Big mailing lists actually run on specialized platforms with worse domain counts.
Mandrill is part of Mailchimp. Combined Intuit MailChimp share is 7.40%, formally first. But many Mandrill SPF includes are leftover from migrations — actual usage is lower.
All numbers are a lower bound. SPF flattening — replacing include: chains with raw IP networks to fit the 10-lookup limit (RFC 7208 §4.6.4) — hides the original ESP. Sample checks suggest 5–15% of larger corporate domains are flattened. If they all unflattened tomorrow, the top ESPs would gain a few percentage points.

The third layer: SaaS senders

Business apps that send mail on behalf of their customers:

#	SaaS app	Domains	Share
1	Shopify	5,446	0.88%
2	Pardot (Salesforce)	5,191	0.84%
3	KnowBe4	3,309	0.54%
4	Trustpilot	1,966	0.32%
5	Atlassian (Jira/Confluence)	1,864	0.30%
6	Firebase (Google)	1,614	0.26%
7	Lark / Feishu	1,181	0.19%
8	BigCommerce	1,157	0.19%
9	NetSuite (Oracle)	1,139	0.18%
10	Qualtrics	1,104	0.18%

Two interesting datapoints here:

KnowBe4 at #3 (3,309 domains). KnowBe4 is security-awareness training — they send simulated phishing emails to your employees from your own domain (so the simulation is realistic). To do that, customers add KnowBe4 to their SPF. So 3,309 ≈ active KnowBe4 customer count in Tranco-1M, modulo SPF flattening. That's a public proxy metric for the security-awareness market — usually impossible to estimate without vendor reports.

Lark / Feishu at #7 (1,181 domains). ByteDance's Slack competitor showing measurable Western expansion. Useful trendline candidate.

DMARC: the compliance theater

431,133 domains publish DMARC = 69.95% of SPF-publishing domains. Looks great. The devil's in pct=.

Here are the 11 most common verbatim DMARC records:

#	DMARC record	Domains
1	`v=DMARC1; p=none;`	50,658
2	`v=DMARC1; p=none`	32,837
3	`v=DMARC1; p=none; rua=mailto:rua@dmarc.brevo.com`	7,172
4	`v=DMARC1; p=quarantine;`	4,365
5	`v=DMARC1;p=none;`	3,974
6	`v=DMARC1; p=quarantine`	3,636
7	`v=DMARC1; p=reject; fo=1; rua=...@emaildefense.proofpoint.com; ruf=...`	3,333
8	`v=DMARC1; p=reject;`	3,319
9	`v=DMARC1; p=quarantine; adkim=s; aspf=s`	2,978
10	`v=DMARC1; p=reject`	2,753
11	`v=DMARC1; p=none; sp=none; rua=mailto:dmarc@mailinblue.com!10m; ...`	2,353

Add up #1, #2, #5 — all p=none with no rua= — and you get 87,469 domains, 20.3% of all DMARC records. This is what I call DMARC compliance theater: the domain "has DMARC" formally, but there's no monitoring, no enforcement, no reporting endpoint. Usually this is auto-generated by a registrar setup wizard to satisfy the Google/Yahoo bulk sender requirements from Feb 2024.

There's also a fun side effect of how vendors deploy DMARC at scale — their reporting endpoints are visible in DNS as fingerprints:

Brevo — rua=mailto:rua@dmarc.brevo.com on 7,172 domains. Brevo auto-generates this template for customers.
Proofpoint Email Defense — 3,333 enterprise customers route aggregate reports through emaildefense.proofpoint.com.
Valimail — dmarc_agg@vali.email on ~3,700 domains. Note: Valimail publicly claims 65,000 customers — most of them are SMBs not in Tranco top-1M.

Practical implication for your own domain: counting DMARC adoption by record presence is the wrong metric. The right metric is enforcement rate — domains with p ∈ {quarantine, reject} AND pct=100. By that measure, the picture is much smaller, and the trend (+1.86% over the last 90 days) is slow.

What this measures, and what it doesn't

To be honest about it:

DNS configuration ≠ email volume. All numbers are domain counts. We see declarations, not actual traffic.
Tranco bias toward US/EU. RU/CN/JP/KR conclusions from this dataset will be wrong; you need ccTLD-specific slices.
SPF flattening undercounts ESPs. Notable for large corporate domains (5–15%).
CNAME chains on MX aren't unrolled. A domain with MX mail.example.com → CNAME → example-com.mail.protection.outlook.com lands in "Unknown" instead of Microsoft 365. This will be fixed in the next iteration.
DKIM isn't measured at all. Reading a DKIM key requires knowing the selector (selector1._domainkey.example.com), which is arbitrary. OpenINTEL doesn't query it. There's no way to get DKIM coverage at this scale without active probing.
Vanity-MX setups for security vendors (Mimecast/Proofpoint customers using their own brand on the MX) are undetectable from DNS alone.
Snapshots only. Trends come from snapshot diffs. ESP/MX changes between snapshots are invisible.

What you can do with this

If you run a domain:

Audit your DMARC record. If it's v=DMARC1; p=none; with no rua=, you're in the compliance theater bucket. Set rua=mailto:dmarc@yourdomain.com, let it run for 2–4 weeks, then move to p=quarantine; pct=10 and ramp up. Tools: Postmark's DMARC Digests, dmarcian, EasyDMARC.
Check if your SPF is flattened. If your record has 30 IP networks instead of include: directives, you're losing visibility for analytics and overloading every receiving resolver. Modern platforms can auto-flatten safely. Manual flattening is technical debt.
Unroll CNAMEs on your MX. Doesn't affect deliverability, but improves discoverability in security audits and industry analytics.

If you build email tooling:

The combined Generic + Unknown ~50% is your TAM if you're building any kind of "mailbox-as-a-service" product targeting non-Google/non-Microsoft.
The KnowBe4 / Pardot / Atlassian patterns are reusable: any SaaS that sends from customer domains leaves a fingerprint in SPF. You can build adoption metrics for any vendor with a known SPF include.

If you do research:

The dataset is open and reproducible. Classifier dictionaries are public. OpenINTEL has reasonable data agreements for academic use. Pull requests for missed providers/ESPs are welcome — they'll be in the next daily run.

What's next

In rough priority order:

CNAME unrolling for MX targets — should move some "Unknown" mass into Microsoft 365 / Google Workspace and tighten the duopoly estimate.
BIMI keys (default._bimi.<domain>) — the brand-indicator follow-up to DMARC. Requires p=quarantine|reject with pct=100 plus a VMC certificate; should be a small but interesting cohort.
MTA-STS / DANE / TLS-RPT — the next layer of email security beyond authentication. OpenINTEL queries these; metrics not yet computed.
Per-ccTLD slices — fix the Tranco bias for regional analyses (.ru, .cn, .de, .jp).
Cross-tabs: domains with p=reject per ESP, DMARC adoption among Cloudflare Email Routing users, etc. — 2D slices unlock more interesting stories than 1D rankings.
Historical reconstruction back to 2017 — OpenINTEL has the archive; building it into a time series.

Reproducibility & contributions

Each daily report ships with:

The OpenINTEL snapshot date.
SHA256 hashes of mx_providers.py, esps.py, saas_senders.py.
The top-100 unmatched MX targets and SPF includes — published explicitly so anyone can suggest dictionary additions.

Raw OpenINTEL Parquet is deleted after analysis (per their data agreement); only aggregates persist.

Three classifications I already know need fixing for the next iteration:

eforward*.registrar-servers.com  → Namecheap email forwarding (currently generic)
route*.mx.cloudflare.net         → Cloudflare Email Routing (currently unknown)
mailstore1.secureserver.net      → GoDaddy (currently unknown)

Daily snapshots: https://check.live-direct-marketing.online/email-stats/

If you spot a misclassification or a missing ESP/provider, drop it in the comments or open an issue — it'll show up in tomorrow's run.

What I'd love to know in comments: are you tracking your DMARC enforcement rate? What does it look like for your stack? And if you've seen flattening hide an ESP in your own SPF, how did you debug it?

References

OpenINTEL — https://openintel.nl/
Tranco list — https://tranco-list.eu/
van Rijswijk-Deij et al., "A High-Performance, Scalable Infrastructure for Large-Scale Active DNS Measurements", IEEE JSAC 2016
Le Pochat et al., "Tranco: A Research-Oriented Top Sites Ranking Hardened Against Manipulation", NDSS 2019
RFC 7489 — DMARC
RFC 7208 — SPF
Google/Yahoo bulk sender requirements (Feb 2024)

Top 5 Free Email Deliverability Tools You Should Be Using in 2026

live-direct-marketing — Sun, 19 Apr 2026 22:26:19 +0000

Top 5 Free Email Deliverability Tools You Should Be Using in 2026

If you send cold emails, newsletters, or transactional mail — you've probably wondered: "Is my email actually reaching the inbox?"

ESPs confirm SMTP delivery (status 250), but that only means the server accepted the message. Your email could still be sitting in Spam, Promotions, or never displayed at all. Open rate tracking is unreliable thanks to Apple Mail Privacy Protection and Outlook image blocking.

The only way to know for sure is to test placement directly.

After 5+ years in B2B cold outreach, I've tested dozens of tools. Here are the 5 best free options in 2026 — what each does well, where it falls short, and when to use which.

1. Inbox Placement Test (by LDM)

What it does: Gives you 5-7 seed addresses across Gmail, Outlook, Yahoo, Mail.ru, and Yandex. You send your test email, and see live where it lands — Inbox, Spam, or Promotions. Results stream via SSE in under 2 minutes.

Free tier: Unlimited tests. No signup, no credit card.

Best for: Quick pre-campaign checks. Covers both Western and CIS providers — the only tool on this list that tests Mail.ru and Yandex.

Also includes: Full SPF, DKIM, and DMARC authentication check with actionable recommendations. REST API available for automated testing at scale.

Try it: check.live-direct-marketing.online

2. Mail-Tester

What it does: You send an email to a unique address, and it returns a score from 1 to 10 based on spam likelihood. Checks SPF, DKIM, DMARC, blacklists, and content.

Free tier: 3 tests per day.

Best for: Quick spam score checks and content analysis. Great UI, very beginner-friendly.

Limitation: Tests against a single mailbox — doesn't show per-provider placement (Gmail vs Outlook vs Yahoo). Score is helpful but doesn't tell you the actual folder.

Website: mail-tester.com

3. MXToolbox

What it does: Swiss army knife for email infrastructure. Checks DNS records, blacklists, SMTP diagnostics, SPF/DKIM/DMARC validation, and mail flow.

Free tier: Most diagnostic tools are free. Some advanced monitoring requires a paid plan.

Best for: Diagnosing infrastructure problems — DNS misconfigurations, blacklist issues, MX record errors. More of a diagnostic tool than a placement tester.

Limitation: Doesn't test actual inbox placement. Tells you if your setup is correct, but not where your email lands.

Website: mxtoolbox.com

4. GlockApps

What it does: Full inbox placement testing across major providers with detailed reports. Shows placement per provider, spam filters triggered, authentication results.

Free tier: 2 free tests (lifetime, not per day). Paid plans start at $59/month.

Best for: Teams and agencies that need ongoing monitoring and detailed analytics. The most comprehensive paid tool in this category.

Limitation: Free tier is extremely limited. Essentially a trial, not a free tool.

Website: glockapps.com

5. Postmark DMARC Tool

What it does: Free DMARC monitoring. Parses DMARC aggregate reports and sends you weekly digests so you can see who's sending email from your domain and whether authentication passes.

Free tier: Completely free DMARC monitoring for any domain.

Best for: Long-term DMARC monitoring — catches unauthorized senders and authentication failures over time. Complements placement testing tools.

Limitation: DMARC-only. Doesn't test inbox placement or spam scoring.

Website: dmarc.postmarkapp.com

When to Use What

Scenario	Tool
Pre-campaign placement check	Inbox Placement Test
Quick spam score	Mail-Tester
DNS/infrastructure diagnostics	MXToolbox
Ongoing monitoring (paid)	GlockApps
DMARC monitoring	Postmark
CIS market (Mail.ru, Yandex)	Inbox Placement Test

My Workflow

Before every campaign, I run this sequence:

MXToolbox — verify DNS, SPF, DKIM, DMARC records are correct
Inbox Placement Test — send a test email, check actual folder placement across providers
Mail-Tester — get a spam score and content analysis
Fix issues — usually SPF/DKIM misconfiguration or content triggers
Re-test — confirm fixes worked before sending to the real list

This takes about 10 minutes and has saved me from countless campaigns landing in Spam.

Conclusion

Most deliverability problems are authentication issues, not content issues. Fix SPF, DKIM, and DMARC first — then worry about subject lines and copy.

All five tools above are free (or have meaningful free tiers) and cover different angles. Use them together for the most complete picture.

What tools are you using for deliverability? Drop a comment — always looking for new ones to test.

How I Built a Free Inbox Placement Test with Node.js and SSE

live-direct-marketing — Fri, 17 Apr 2026 22:30:48 +0000

The Problem

I've been doing B2B cold outreach for 5+ years. The #1 blind spot? ESPs confirm SMTP delivery — status 250, "message accepted." But they never tell you which folder your email actually landed in.

Your campaign could have a 0% open rate not because of bad copy, but because every email is sitting in Spam. And you'd never know.

The Solution

I built a free tool that answers one question: did my email hit Inbox, Spam, or Promotions?

Try it here: https://check.live-direct-marketing.online/

How It Works

You enter your email address
You get 5-7 seed addresses across Gmail, Outlook, Yahoo, Mail.ru, and Yandex
You send your test email from your real mailing system
Results stream in live — placement per provider + full authentication report

Tech Stack

Backend: Node.js
Live updates: Server-Sent Events (SSE) — lightweight, no WebSocket overhead
Folder detection: IMAP connection to seed mailboxes, parsing folder placement
Authentication parsing: SPF, DKIM, DMARC results extracted from email headers
Frontend: Vanilla JS, no framework — keeps it fast

Why SSE over WebSocket?

For this use case SSE is a better fit. The data flows one direction: server → client. No need for bidirectional communication. SSE auto-reconnects, works through proxies, and is dead simple to implement:

const evtSource = new EventSource('/api/test/stream?id=' + testId);
evtSource.onmessage = (e) => {
  const result = JSON.parse(e.data);
  updateUI(result);
};

IMAP Folder Detection

The core logic connects to each seed mailbox via IMAP, searches for the test email by Message-ID, and checks which folder it landed in:

INBOX → your email is fine
[Gmail]/Spam, Junk, etc. → problem with reputation or authentication
[Gmail]/Promotions → not critical, but reduces visibility

Authentication Breakdown

Every incoming email has authentication headers. The tool parses them and gives you a clear SPF/DKIM/DMARC status — pass, fail, or missing. This is usually the first thing to fix if you're landing in Spam.

What I Learned

Mail.ru and Yandex matter if you target CIS markets. Most tools ignore them.
SPF/DKIM/DMARC issues are the #1 reason emails land in Spam — not content, not subject lines.
Live results (SSE) make a huge UX difference vs "check back in 5 minutes."

Try It

Free, no signup, no credit card: https://check.live-direct-marketing.online/

Feedback welcome — what providers or features should I add next?