标签：#deliverability

By the team at MailTester Ninja — a real-time email verification API that stores nothing. Everyone says "IPv6 is here." For the web, mostly true. For email , it is a mirage. We resolved the MX records of 50,000 of the most-linked domains and checked whether any of their mail servers publish an AAAA record, meaning they can actually receive over IPv6. No sending, no personal data, just DNS. 55.2% of mail-enabled domains have at least one IPv6-capable MX. That sounds healthy. It is not, because two companies carry almost the whole number: Email provider IPv6 MX Other / self-hosted ██░░░░░░░░ 18.4% Google Workspace / Gmail ██████████ 100% Microsoft 365 / Outlook █████████░ 91.3% Proofpoint ░░░░░░░░░░ 0.6% Mimecast ░░░░░░░░░░ 0% Tencent QQ ░░░░░░░░░░ 4.2% Namecheap ░░░░░░░░░░ 0.2% Cisco IronPort ░░░░░░░░░░ 4.5% Zoho ░░░░░░░░░░ 0% Barracuda ░░░░░░░░░░ 0% Google ( 100% ) and Microsoft ( 91.3% ) run IPv6 on nearly every inbox. Remove those two, the providers that already anchor most of the world's mail, and IPv6 email adoption falls from 55.2% to 12.9% . The enterprise security gateways that gate corporate mail, such as Proofpoint, Mimecast and Barracuda, are effectively not on IPv6 at all. Why it matters for deliverability. IPv6-only sending is a dead end. It reaches Gmail and Outlook and little else. Dual-stack is not optional. IPv4 is still the backbone of email, and that is where blocklists, FCrDNS and IP reputation are mature. The takeaway: IPv6 email is not adopted. Google and Microsoft adopted it for you. Plan your sending for an IPv4 world with two big IPv6 exceptions. Check any domain yourself — our free deliverability analyzer shows a domain's MX / SPF / DMARC in one click (no signup, nothing stored). Need to confirm whether a specific mailbox actually exists and is deliverable? That is exactly what MailTester Ninja's email verifier does in real time — and we store no data. Source: MailTester Ninja's open Email Infrastructure Index — a live DNS scan of 50,000 of

By the team at MailTester Ninja — a real-time email verification API that stores nothing. We verify a lot of email for a living. So we pointed our infrastructure at a representative panel of 50,000 of the world's most-linked domains and measured how email is actually configured in 2026 — MX providers, SPF and DMARC. Pure DNS, aggregate only, no personal data . Here's what the internet's mail setup looks like right now. Email is still (almost) everywhere 79.9% of these domains are mail-enabled (they publish MX records). Email isn't going anywhere. Authentication: adopted, but not enforced 75.8% publish an SPF record 64% publish a DMARC record …but only 22.6% actually enforce it with p=reject That last number is the real story. Of the domains that bother to publish DMARC, only 35.2% are on p=reject — the rest sit on p=none (37.2%, monitoring only) or quarantine (27.6%). Most of the web announces a policy it doesn't enforce. That's a deliverability and spoofing gap hiding in plain sight. Who runs the world's inboxes? Other / self-hosted — 32.6% Google Workspace / Gmail — 28.2% Microsoft 365 / Outlook — 22.5% Proofpoint — 5.5% Mimecast — 3.1% Tencent QQ — 2% Namecheap — 1.3% Cisco IronPort — 0.9% Self-hosted and the two hyperscalers (Google Workspace and Microsoft 365) dominate, but the long tail of providers is very real — which is exactly why deliverability is hard: every provider blocks, greylists and reputation-scores differently. Why we publish this We built an open, daily-updated dataset and a live dashboard because deliverability decisions should be based on data, not folklore. It's CC BY 4.0 — use it, cite it, build on it. Want to check a specific domain? Our free analyzer shows any domain's MX / SPF / DMARC in one click — no signup, nothing stored. Methodology: Live DNS scan (MX/SPF/DMARC). Aggregate only — no email sent, no personal data. Sample updated Wed, 01 Jul 2026 12:31:00 GMT.

You give your AI agent a real mailbox, it sends its first batch of email, and half of it lands in spam. The agent did nothing wrong. The domain did — it's new, it has no sending history, and mailbox providers treat an unknown domain that suddenly sends volume the same way they treat a spammer. Deliverability is the work of proving the mail is really yours, sending at a pace providers trust, and watching the signals that say whether recipients want it. An Agent Account sends from a domain you own, so its inbox placement is yours to manage like any other mail from your company. This post is a practical playbook for getting and keeping an agent in the inbox, from two angles: the HTTP API for your backend, and the Nylas CLI for the terminal. I work on the CLI, so the terminal commands below are the ones I reach for when I'm wiring up monitoring. The deliverability checklist Five things decide whether an Agent Account reaches the inbox, and you can act on all of them before sending at volume. Work them in order — authentication first, because nothing else matters if recipient servers can't confirm the mail is yours, then pace and monitoring once mail is flowing. Authenticate the domain with DKIM and SPF as part of domain verification. Set up DMARC so providers know how to treat mail that fails authentication. Warm up a new domain before sending at volume, over roughly four weeks. Monitor bounces and complaints through the deliverability webhooks. Stay under the bounce and complaint thresholds that pause sending. The rest of this post covers each one with the commands and request bodies to wire it up. Authenticate with DKIM and SPF Authentication is the foundation, and for an Agent Account it rides on two records you already publish during domain setup. DKIM adds a cryptographic signature proving the message wasn't altered and really came from your domain; SPF authorizes the sending infrastructure to send on your behalf. Both are verified before a custom domain can host a

"Email verification" sounds like one thing, but it's really a stack of checks of increasing depth and cost. Knowing what each layer actually proves helps you pick the right level instead of overpaying for verification you don't need. Layer 1: syntax The cheapest check: does the string look like a valid email address? A pragmatic regex catches obvious garbage ( asdf , a@@b , trailing spaces). It's instant and free, but weak on its own: nobody@asdf.asdf passes syntax and can't receive a single message. Layer 2: domain and MX records Next, does the domain actually accept mail? Every domain that receives email publishes MX (mail exchanger) records in DNS pointing to its mail servers. A quick DNS lookup tells you whether any exist. No MX (and no fallback A record) means the domain can't receive mail, so the address is undeliverable no matter how it's spelled. This single step removes a large class of fakes and dead domains. Layer 3: SMTP mailbox check The deepest level connects to the domain's mail server and begins the motions of sending a message to ask whether that specific mailbox exists, without actually delivering anything. It's the only layer that can hint a particular inbox is real, but it comes with real caveats: It's slow (a live connection per address). Many servers are "accept-all" and say yes to everything, so the answer is often meaningless. Lots of providers block or throttle these probes, and outbound port 25 is blocked on most modern hosting, so it's frequently unavailable anyway. SMTP checks matter most for cleaning old, cold lists, and far less for stopping junk at signup. The heuristics layer Alongside those, useful verification adds signal that has nothing to do with deliverability per se: Disposable detection: is it a throwaway provider? Role detection: is it info@ or admin@ rather than a person? Typo suggestions: "did you mean gmail.com?" for gmial.com . A deliverability score: one 0–100 number that rolls it all up so you can just threshold on it.