What "AI" means in deliverability tools, and what to verify

The machine learning that matters most in email is on the receiving side, and you do not control it. Gmail, Microsoft and Yahoo run learned classifiers over reputation, authentication, content and per-recipient engagement, and they do not publish the features or the weights. Sender-side "AI" is a much smaller category: scheduling, anomaly detection, text generation, and classification of your own results. Knowing which is which makes vendor comparison tractable.

What is genuinely learned on the sending side

• Adaptive send scheduling. Deciding how many messages a mailbox sends per hour, spread across a window, adjusting when a provider starts deferring. This is real, measurable and useful, and it is mostly control theory rather than anything exotic.
• Anomaly detection on your own metrics. Flagging that a mailbox's bounce pattern changed before the weekly rate moves. Useful because humans do not read logs daily.
• Classification of bounce and rejection text. Mapping thousands of different SMTP strings to a small set of causes — rate limit, policy block, bad recipient, authentication failure. Unglamorous and the highest-value automation in the category, because the right response to a 451 and a 550 are opposite.
• Content generation. Drafting copy. Nothing to do with deliverability; a different product in the same bundle.

What cannot be true

Be sceptical of these specific claims, whatever the label on them:

• "AI guarantees inbox placement." Placement is decided by the receiver, per recipient, partly on that recipient's own behaviour. No sender-side system can guarantee it.
• "AI predicts your spam score before you send." A local content score has no access to your reputation, your recipient's history, or the receiver's model. It can catch an obvious mistake; it cannot predict the outcome.
• "AI engagement that trains the filter." If the opens and replies are simulated rather than produced by real mailboxes exchanging real messages, the signal is thin and the approach ages badly as providers get better at spotting it. Ask what the network actually is.
• "AI monitors your domain reputation score at Gmail." Google retired the domain reputation chart in Postmaster Tools. Anything presenting a Gmail domain reputation grade today is inferring it, and should say so.
• "AI-powered blocklist removal." Delisting is a form submission and a waiting period, sometimes manual review by the list operator. There is no model in that loop.

Questions that get a straight answer

Ask these in a demo and listen for specifics:

1. What data does the model take as input, and is it my data or a global pool?
2. What decision does it actually change — volume, timing, routing, or just a displayed score?
3. When it is wrong, what do I see, and can I override it?
4. For warm-up: are the recipients real mailboxes with real inboxes, and how are they recruited? Can I see which providers are represented?
5. How is placement measured — seed inboxes read over IMAP or an API, or inferred from opens? Inferred placement from open tracking is not placement, especially with Apple Mail Privacy Protection inflating opens.
6. Does the tool report per provider, or one aggregate score? Aggregates hide the Microsoft-only failure that is usually the real problem.

How to evaluate it with your own data

You do not need to take anyone's word for this. Run a controlled comparison:

• Pick two matched sets of mailboxes on the same domain and provider mix.
• Keep the message, the list source and the volume identical. Change only the tool.
• Measure for at least three weeks: per-provider placement from seed tests, bounce and deferral mix from the SMTP strings, Gmail spam rate from Postmaster Tools, and reply rate as the business outcome.
• Treat small differences as noise. Seed sets are tens of mailboxes, so a few percentage points of placement difference means nothing.

Hold one thing constant that most trials do not: the recipient list. A tool evaluated against a fresh list and a competitor evaluated against a tired one will always win.

What not to do

• Do not buy a model to fix a list problem. No scheduling policy survives a 5% bounce rate; Amazon SES will review the account regardless.
• Do not let automated volume ramping run unsupervised on a new domain. Check what it is doing in week one.
• Do not swap tools mid-incident. You lose attribution for the recovery.
• Do not pay for a "reputation score" you cannot trace to a source. If the vendor cannot say which of Postmaster Tools, SNDS, your ESP's events, a seed test or a blocklist lookup it came from, it is an opinion.

MailPilot's position here is deliberately plain. It warms mailboxes over OAuth (Gmail, Outlook) or SMTP and IMAP (SendGrid, Amazon SES, Mailgun, Postmark, custom SMTP) using real mailboxes exchanging real messages, measures inbox placement per provider through a seed-inbox network read over IMAP, checks SPF, DKIM and DMARC, and tracks per-mailbox reputation daily. Every number it shows traces back to one of those measurements.