DEV Community: live-direct-marketing

UI = MCP: How we got voice control of our B2B email platform for free via Model Context Protocol" published: false tags: mcp, architecture, voice, nestjs

live-direct-marketing — Fri, 22 May 2026 13:45:29 +0000

Context
Live Direct Marketing (LDM) is a multi-tenant B2B email platform: CRM (companies/contacts/leads), segments, creatives, mailings, dialogs (inbound/outbound), suppression/stop-lists, anti-spam marking, deliverability checks. Stack: NestJS + Prisma + PostgreSQL + BullMQ + Redis on the backend, React + Turborepo on the frontend. Tenant isolation via a separate database per user.
The product's main differentiator is per-message inbox verification — every outbound email is verified across 9 mailbox providers (Gmail, Outlook, Yandex, Mail.ru, iCloud, GMX, AOL, T-Online, Yahoo) via a network of seed mailboxes. Each outbound dialog row in the DB has a placement field: inbox | spam | unchecked. Billing is gated on confirmed inbox.
When MCP started becoming the de facto agent integration standard, we had a choice: build a separate agent API mirror on top of the existing web API, or unify them.
We picked unify.
Architecture: UI = MCP
All endpoints live under /api/. In front of them sits a HybridAuthGuard that resolves either a session cookie (web UI) or a Bearer key in the form ldm_pk_ (MCP / external agent / voice skill). Whichever auth succeeds, the request hits the same controller, the same scope check, the same business logic.
typescript@Injectable()
export class HybridAuthGuard implements CanActivate {
async canActivate(ctx: ExecutionContext): Promise {
const req = ctx.switchToHttp().getRequest();

// 1. Bearer (agent / MCP / voice skill)
const m = req.headers.authorization?.match(/^Bearer (ldm_pk_\w+)$/);
if (m) {
  const key = await this.apiKeys.verifyHash(m[1]);
  if (!key) throw new UnauthorizedException();
  req.user = key.user;
  req.scopes = key.scopes; // gated by what was granted
  return this.checkScopeFor(req);
}

// 2. Session cookie (web UI)
const session = await this.sessions.fromCookie(req);
if (!session) throw new UnauthorizedException();
req.user = session.user;
req.scopes = ['*']; // UI = full scope
return true;

}
}
Every capability is described in /.well-known/agent-card.json (A2A discovery standard) with its scope: email:send, crm:read, dialogs:write, mailing:write, etc. A Bearer key is issued with an explicit scope set — a voice skill can be given a limited key that reads dialogs and sends mailings from a specific account, with no access to exports, billing, or suppression management.
The MCP server
Published as the npm package ldm-crm-mcp. Under the hood it's a thin wrapper over /api/*: takes LDM_API_KEY from env, proxies MCP tool calls to HTTP. About 30 tools for the most common operations, ~120 endpoints total available via generic invocation.
Claude Desktop / Cursor config:
json{
"mcpServers": {
"ldm-crm": {
"command": "npx",
"args": ["-y", "ldm-crm-mcp"],
"env": { "LDM_API_KEY": "ldm_pk_..." }
}
}
}
Wiring a voice assistant on top
Voice integration pipeline:

Voice → STT → text
Text → skill backend → MCP tool selection + parameters
MCP tool call → /api/* → response
Response → reply phrasing → TTS

The "brain" inside the skill backend is Claude via API. It interprets free-form speech and picks the appropriate MCP tool from the server's tool list. No hand-written grammars per command.
Auth: OAuth account linking on the voice platform → user gets a Bearer key in their LDM account with a limited scope (dialogs:read, dialogs:write, mailing:write, contacts:read).
All destructive actions (start a mailing, send a single email, update a deal) require voice confirmation — the skill reads back a summary and waits for "yes". Reads and briefings — no confirmation.
Field case: a trade show floor
A real test on a real booth, May 22, 2026. One of our early users (commercial director at a composite-pool manufacturer) is working a booth at a water-infrastructure trade show in Moscow. A landscape designer walks up, asks for a catalog of pond/water-feature solutions, leaves a business card, moves on.
Normal flow: enter the contact into CRM, open laptop, pick segment "landscape designers — subscribed", attach current catalog version, check template, send. 10–15 minutes if you're at a computer.
He pulled out his phone instead:

Send the pond solutions catalog to all subscribed landscape designers.

Found 247 contacts in segment "landscape designers — subscribed".
Template: "Pond Solutions Catalog v3, May 2026".
Confirm send?

Yes.

Sending.
Under the hood, the agent in the skill backend ran:
bash# 1. Resolve segment
GET /api/contacts?tagId=landscape-designers&subscribed=1&pageSize=500
→ 247 contacts

2. Resolve creative

GET /api/creatives?search=pond+catalog&latest=1
→ creativeId

3. Create mailing task

POST /api/tasks
{
"methodId": 2,
"creativeId": "cmoue9...",
"contactListId": "",
"accountId": ""
}
→ taskId, status: DRAFT

4. Self-approve (scope: mailing:write)

POST /api/mailing/$TASK_ID/approve
{ "note": "Voice-approved at trade show booth" }

5. Start

POST /api/tasks/$TASK_ID/start
→ status: ACTIVE
20 seconds — sent to the full segment. Then the interesting part started.
Per-message inbox verification
The standard model in cold/B2B email platforms: warm-up + inbox rotation + a pre-flight inbox placement test (send 20 emails to seed mailboxes before launch, compute the % landing in inbox). That's a statistical estimate from a pre-send sample.
Our model: every actual outbound is verified post-send against a network of seed mailboxes. We run 10–30 seed mailboxes per provider (~100 each for Gmail and Outlook). Roughly: when sending SMTP → real recipient, we parallelize a test twin to a seed mailbox on the same provider, using the same headers, body, sending account. Via IMAP we then check INBOX vs SPAM/JUNK/Quarantine and write the result to the dialog's placement field.
It's not a perfect proxy — a seed mailbox isn't the actual recipient, and providers may filter individually based on per-recipient signals. But it's substantially better than a pre-flight test because:

The check runs on every real send, not a sample.
It captures the reputation state at the moment of sending, not a day before campaign launch.
A drop into spam for a specific provider gets caught in real time — and triggers an automatic pause if the spam rate within a window exceeds threshold.

The endpoint the voice skill polls after a mailing:
bashGET /api/dialogs/stats?taskId=$TASK_ID
{
"total": 247,
"placement": {
"inbox": 231,
"spam": 4,
"unchecked": 12
},
"byProvider": {
"gmail": { "inbox": 142, "spam": 1 },
"yandex": { "inbox": 47, "spam": 0 },
"outlook": { "inbox": 18, "spam": 3 }
}
}
Voice response: "247 sent. 231 in inbox, 4 in spam, 12 still verifying. Outlook dropped — 3 of 21 in spam."
Billing: 231 inbox-delivered. The 4 spam and 16 blocked are not billed.
Where voice control breaks
No marketing veneer. Voice covers maybe 20–30% of an operator's actual workflow. The other 70% really is more efficient via a screen.
Works well:

Morning briefings on incoming dialogs.
Triggering a pre-configured mailing to a known segment.
Replying to a specific incoming email (short).
Checking delivery status of a campaign or individual message.
Ad-hoc stat questions.

Doesn't work:

Complex multi-parameter filters. Dictating "companies in city X, 50–500 headcount, e-commerce, no activity in 30 days, tag Y" by voice is misery. This belongs in a UI.
HTML/creative editing.
Designing multi-step automation pipelines (best-time-sending, follow-up sequences, A/B branching).
Latin-alphabet brand / domain recognition. The STT layer systematically butchers "Apple" / "Acme" / domain names. Solvable with a phonetic-normalization layer on top of CRM data, but accuracy is ~70–85%, not 100%.

Fragile points:

OAuth refresh token handling. When users change passwords on the voice platform's OAuth provider, the linked Bearer key gets orphaned and the user has to re-link.
Voice confirmation in noisy environments. On a trade show floor or in a car with windows open, a confirmation "yes" gets misheard about 1 in 3 times.
Latency. The STT → Claude (intent + tool selection) → MCP → /api/* → response → phrasing → TTS chain runs 4–8 seconds on a typical command. Acceptable for email ops, noticeable for conversational UX.

Architectural tradeoffs
MCP is just transport. The value depends on what you expose through it. Many CRM platforms expose read-only MCP, or a limited subset of objects. Ours exposes the full UI surface including starting mailings and self-approval — useful for agents, but requires a sane scope model and confirmation handling on the client side.
"UI = MCP" has a cost. Any new endpoint becomes agent-callable by default. That requires discipline — you can't dump anything into /api/* that should be UI-only for UX or safety reasons. We solve this with scopes and additional middleware on specific handlers, but it adds design overhead.
Voice as a UI is niche. It's not a replacement for the dashboard. It's an extension for specific scenarios — mobility, hands-busy contexts, fast briefings. Maybe 10–15% of operations actually benefit, no more.
What's next

MCP server v2 with explicit JSON Schema per tool (currently many tools return loose JSON, agents have to parse manually).
Voice-friendly responses on /api/dialogs/stats — flat, terse, no nested objects, so TTS doesn't waste seconds reading structure.
ChatGPT MCP App directory submission.
Apple Intelligence MCP App Extensions support, once Apple opens that to third parties.

Docs are public: developers.live-direct-marketing.online. MCP package: ldm-crm-mcp on npm. Questions on architecture / implementation — happy to discuss in comments.

OpenClaw outbound agents need deliverability checks before sending

live-direct-marketing — Mon, 18 May 2026 17:05:09 +0000

Some agents can even schedule or send campaigns automatically.

But most outbound agents still do not know one important thing before sending:

Will the email land in Inbox, Spam, Promotions, or Junk?

For cold outreach, recruiting, investor updates, partnership outreach, and deal-flow automation, this becomes a real operational risk.

AI agents are getting very good at:

copy generation
personalization
sequencing
lead enrichment
autonomous workflows

But email deliverability is a different layer entirely.

An agent can generate a perfectly reasonable email that still lands directly in Spam.

That happens because deliverability depends on factors the model usually does not evaluate:

sender-domain reputation
SPF/DKIM/DMARC alignment
mailbox-provider filtering
HTML structure
tracking links
subject line patterns
sending infrastructure reputation

The result is a common failure mode:

The agent believes the campaign succeeded because emails were technically sent, while recipients never actually see them.

For autonomous outbound systems, this is a dangerous blind spot.

Before bulk outbound, run a deliverability preflight. If inbox placement is below 70%, pause and report fixes instead of sending.

That policy works surprisingly well as a safety rail for outbound agents.

Instead of optimizing only for “send success”, the agent also evaluates whether messages are likely to reach the inbox.

Two OpenClaw skills for deliverability preflight

I built two small OpenClaw skills around this workflow.

They are intentionally focused on outbound safety behavior rather than “email marketing”.

Skill 1 — LDM Deliverability Check

This is the lightweight policy layer.

Good fit for:

default outbound-agent behavior
pre-send checks
workflow rules
autonomous pause/report logic

The skill can:

evaluate outbound risk before send
stop risky campaigns
act as a safety layer in autonomous workflows
enforce deliverability policies

ClawHub:
https://clawhub.ai/live-direct-marketing/ldm-openclaw-skill

GitHub:
https://github.com/live-direct-marketing/ldm-openclaw-skill

Skill 2 — LDM Inbox Check MCP

The second skill is the heavier workflow using real inbox-placement testing.

It uses:

ldm-inbox-check-mcp
seed-mailbox testing
provider placement validation
authentication checks

The workflow creates real test sends and evaluates placement across providers including:

Gmail
Outlook
Yahoo
Mail.ru
Yandex

It also checks:

SPF
DKIM
DMARC

If placement is bad, the agent pauses the campaign instead of continuing the send.

ClawHub:
https://clawhub.ai/live-direct-marketing/ldm-openclaw-inbox-mcp-skill

GitHub:
https://github.com/live-direct-marketing/ldm-openclaw-inbox-mcp-skill

MCP package:
https://www.npmjs.com/package/ldm-inbox-check-mcp

MCP GitHub:
https://github.com/live-direct-marketing/ldm-inbox-check-mcp

Example workflow

A simple outbound-agent flow could look like this:

OpenClaw drafts 50 cold emails.
The agent runs an LDM preflight.
Gmail or Outlook placement lands in Spam/Junk.
The agent pauses instead of sending.
The agent reports fixes:
subject line
links
authentication
HTML structure
The user updates the campaign.
The agent reruns the check.
Only then does the agent send.

This turns deliverability into a first-class decision point instead of a postmortem problem.

OpenClaw install examples

Install the lightweight policy skill:

clawhub install ldm-openclaw-skill

Install the inbox-placement MCP skill:

clawhub install ldm-openclaw-inbox-mcp-skill

Example MCP configuration:

{
"mcpServers": {
"inbox-check": {
"command": "npx",
"args": ["-y", "ldm-inbox-check-mcp"],
"env": {
"INBOX_CHECK_API_KEY": "icp_live_xxxxxxxxxxxxxxxxxxxxxxxx"
}
}
}
}
Useful outbound-agent use cases

The workflow is useful anywhere autonomous systems send external email:

cold email campaigns
recruiting outreach
investor updates
deal-flow alerts
partnership outreach
transactional-mail audits
sender-domain warmup QA

The important part is not “sending more email”.

The important part is teaching outbound agents when not to send.

Closing note

If you are building outbound, recruiting, investor-update, or deal-flow agents with OpenClaw, I’d love feedback on the workflow.

Resources:

https://check.live-direct-marketing.online
https://developers.live-direct-marketing.online
https://clawhub.ai/live-direct-marketing/ldm-openclaw-skill
https://clawhub.ai/live-direct-marketing/ldm-openclaw-inbox-mcp-skill
https://github.com/live-direct-marketing/ldm-openclaw-skill
https://github.com/live-direct-marketing/ldm-openclaw-inbox-mcp-skill
https://github.com/VoltAgent/awesome-openclaw-skills/pull/465

I had 4 hours before an interview. My friend leaked the questions. I built the answer with Claude Code.

live-direct-marketing — Tue, 12 May 2026 17:47:32 +0000

My friend's interview ended at 9:03 AM. Mine started at 1:00 PM.

He texted me the second he walked out: "Bro. They grilled me on inbox placement. SPF, DKIM, DMARC was the warm-up. They wanted code."

I had 3 hours and 57 minutes.

The setup

The role was at a B2B outreach company. I'd applied a week earlier with a resume that said "email infrastructure" without committing to specifics. I figured I'd wing the technical part — I've shipped cold outreach systems for years, I know the theory cold.

My friend interviewed at 8 AM his time. I was scheduled for 1 PM mine. Same panel, same hiring manager, almost certainly the same playbook.

His debrief was three bullet points:

Explain how you'd detect whether an email landed in inbox, spam, or Gmail's Promotions tab — without access to the recipient's mailbox.
Walk through a system design for measuring deliverability across 10 mailbox providers in real time.
Bonus: show code. Any code. They'll respect a hack over a deck.

Theory I had. Code I didn't.

The 4-hour sprint

I opened Claude Code at 9:11 AM with a coffee and a deadline.

Plan:

Spin up a tiny seed-mailbox network — burner accounts at Gmail, Outlook, Yandex, Mail.ru, ProtonMail.
Build an IMAP fetcher that polls each seed and classifies where the inbound email landed (inbox / spam / category tab).
Wrap it in a CLI that takes a "from" address, sends a test message to every seed, and prints a placement report.

Claude Code wrote the scaffolding in about twenty minutes. NestJS + BullMQ for the queue, IMAP via imapflow, classification logic based on Gmail's X-Gm-Labels header and folder names for the other providers.

The real time went into edge cases:

Outlook's "Focused" vs "Other" inbox — neither is spam, but recruiters confuse them constantly.
Yandex returns folder names in Russian. Hardcoded fallbacks needed.
Some providers throttle IMAP polls aggressively. Had to add jittered retries.

By noon I had a working CLI. I sent a test from my personal Gmail to all five seeds, waited 90 seconds, and got back:
gmail.com → INBOX
outlook.com → JUNK
yandex.ru → INBOX
mail.ru → INBOX
proton.me → INBOX

Outlook eating a clean Gmail send was a useful surprise — exactly the kind of thing you'd want a tool to catch before sending 10,000 emails.

Screenshotted the output, pushed the repo to a private GitHub, ate lunch.

The interview

The first technical question was almost word-for-word what my friend warned about. I answered the theory part, then said: "I actually built a small reference implementation this morning. Want me to share my screen?"

The hiring manager paused for two seconds. "Please."

I ran a live test against their own marketing domain. Three providers came back clean, two came back spam. We spent the next twenty minutes debugging why — DMARC alignment was off on their no-reply subdomain.

I didn't pitch myself as the candidate who knew deliverability. I pitched myself as the candidate who could ship a deliverability tool between breakfast and lunch.

Offer arrived three days later. I declined for unrelated reasons, but that's a different post.

What Claude Code actually changed

The honest version: I could have written this prototype before Claude Code. It would have taken two days, not four hours, and I would have spent half of it on IMAP boilerplate I've written six times in my career.

What changed isn't capability. It's the size of the window where preparation is possible.

A four-hour gap used to be coffee and panic. Now it's a working prototype with edge cases handled. That's a different category of professional life.

I kept hacking on the CLI after the interview. It grew into a full inbox placement service — multi-tenant, hosted, with a free tier for one-off checks.

If you want to run the same test on your own sending domain, it lives here: https://check.live-direct-marketing.online. Paste a from-address, get an inbox-per-provider breakdown in about 60 seconds. No signup for single checks.

The four-hour version of this would have been embarrassing to ship publicly. The version after a few months of polish is what I would have wanted that morning.

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?