Sales, Marketing & Ad Tech
Email Deliverability Intelligence API
When a customer's email stops arriving, your support team gets the ticket. The cause is almost always in their domain configuration, and almost never visible to them.
- Email service providers
- Marketing automation platforms
- CRM and sales engagement vendors
- Agencies
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Any platform that sends email on a customer's behalf inherits a support burden it did not create. A customer sets up a sending domain, skips a DNS record, uses a shared subdomain for both transactional and marketing mail, buys a list, and then opens a ticket saying your product is broken. Diagnosing that takes an experienced engineer reading DNS records, bounce codes and authentication headers, and it takes them an hour.
The diagnostic signals are mostly available and mostly structured. SPF, DKIM and DMARC records can be validated directly. Alignment failures are deterministic once you read the headers. Blocklist presence is queryable. Bounce and complaint patterns are in your own logs, and they say a great deal about list quality that the customer will not volunteer. Sudden volume increases on a cold domain are visible before the blocks arrive.
What cannot be read directly is the receiving side's internal reputation. The large mailbox providers do not publish a score, and the feedback available — bounce codes, complaint feeds, postmaster tooling — is partial and lagging. A deliverability service that claims to know your inbox placement at a specific provider is extrapolating. One that reports the configuration faults and the behavioural patterns that cause problems is on solid ground.
Who buys this
Email service providers, Marketing automation platforms, CRM and sales engagement vendors, Agencies
What the API returns
What comes back
- SPF, DKIM and DMARC record validation with the specific fault, not a pass or fail flag
- Alignment checks across envelope, header and signing domains
- Blocklist presence across queryable public lists, with delisting routes where published
- DNS hygiene: reverse DNS, MX configuration, TLS availability, record syntax errors
- Bounce and complaint pattern analysis from your own sending logs
- Volume ramp assessment against the domain's sending history
- List quality indicators: hard bounce rate, role-address share, spam-trap pattern signals
- Prioritised remediation steps in language a marketing operations person can act on
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/domains/check | Full configuration and reputation check for a sending domain |
| GET | /v1/domains/{domain}/authentication | SPF, DKIM and DMARC detail with faults |
| GET | /v1/domains/{domain}/blocklists | Blocklist presence and delisting information |
| POST | /v1/sending/analyse | Bounce, complaint and ramp analysis from your logs |
| GET | /v1/domains/{domain}/remediation | Prioritised fixes with expected effect |
| POST | /v1/monitoring | Register domains for continuous monitoring and alerts |
Request and response
illustrativeRequest
{
"domain": "mail.example-industries.com",
"from_address": "news@mail.example-industries.com",
"include_sending_analysis": true,
"sending_window_days": 30
}Response
{
"domain": "mail.example-industries.com",
"checked_at": "2026-10-22T12:06:00Z",
"configuration": {
"spf": { "present": true, "valid": true, "lookups": 11,
"fault": "exceeds_10_dns_lookup_limit", "severity": "high" },
"dkim": { "present": true, "selectors_found": 1, "key_bits": 1024,
"fault": "key_length_below_2048", "severity": "medium" },
"dmarc": { "present": true, "policy": "none", "pct": 100,
"rua_configured": false,
"fault": "policy_none_and_no_aggregate_reporting", "severity": "medium" },
"alignment": { "spf_aligned": true, "dkim_aligned": false,
"detail": "Signing domain differs from header From domain" },
"dns": { "reverse_dns": "configured", "tls": "available", "mx": "valid" }
},
"blocklists": [
{ "list": "public_list_a", "listed": true, "since": "2026-10-19",
"delisting_url": "[published]" }
],
"sending": {
"volume_30d": 418000,
"ramp": { "increase_vs_prior_30d": 4.2, "assessment": "aggressive_for_domain_age" },
"hard_bounce_rate": 0.038,
"complaint_rate": 0.0012,
"role_address_share": 0.09,
"list_quality": "poor"
},
"remediation": [
{ "priority": 1, "action": "Flatten SPF includes to below 10 DNS lookups" },
{ "priority": 2, "action": "Re-sign with a 2048-bit DKIM key on the From domain" },
{ "priority": 3, "action": "Pause the volume ramp and re-verify the imported list" }
],
"note": "Inbox placement at individual mailbox providers is not measured and not inferred here."
}Where the data comes from
| Public DNS | SPF, DKIM, DMARC, MX and reverse DNS records, queryable directly and the source of most actionable faults |
| Public blocklists | Presence queries and published delisting procedures; coverage and usage differ per list and not all are widely consulted |
| Your own sending logs | Bounces, deferrals, complaints and volume by domain — the richest available source and one you already hold |
| Mailbox provider postmaster tooling | Where a provider offers it and your customer authorises access; partial, lagging, but genuinely informative |
| Complaint feedback loops | Where you are enrolled with a provider, complaint reports by campaign and domain |
| Deliberately excluded: seed list testing | Panel-based inbox placement testing is a different product with its own serious sampling limitations, and we would scope it separately rather than fold its estimates in here |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Deterministic validation first — record syntax, lookup counts, alignment and key length are specification questions with exact answers and no model belongs anywhere near them
- Fault-level reporting rather than a pass or fail, because 'SPF fails' sends a support engineer looking while 'exceeds 10 DNS lookups' is a fix
- Bounce code normalisation across providers, since the same condition is reported in many formats and the taxonomy is where the diagnostic value lives
- Ramp assessment against the domain's own history and age, not a fixed volume threshold
- List quality inference from hard bounce rate, role-address share and complaint patterns, with the signal basis stated
- Remediation ordered by expected effect, measured against which faults historically preceded delivery recovery in your own data
- Explicit refusal to output an inbox placement estimate, because the receiving side does not publish what would be needed to compute one honestly
- Continuous monitoring with change detection on records and blocklist status, since silent DNS edits by a customer's IT team are a common cause of sudden failures
What it changes for the business
Support tickets resolved faster
A fault-level diagnostic replaces the hour an engineer spends reading DNS records and headers.
Problems caught at onboarding
Configuration checks at domain setup prevent the class of ticket that arrives three weeks after a customer starts sending.
Platform reputation protected
Ramp and list-quality signals identify customers whose sending behaviour threatens shared sending infrastructure.
Self-service remediation
Prioritised fixes in plain language let a marketing operations user resolve most faults without your team.
How it fits into your product
How it embeds
- Synchronous check fast enough to run during domain setup in your onboarding flow
- Continuous monitoring with webhooks on record changes, blocklist events and pattern shifts
- Sending log ingestion from your existing event pipeline rather than a separate integration
- Customer-facing remediation components, written for a marketing user rather than a mail administrator
- Multi-tenant design for platforms running thousands of customer sending domains
- White-label delivery so diagnostics appear as part of your product
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 9 weeksDiscovery
Week 1
A short, focused scoping round: the inputs available, the output you need, expected volume and the latency budget.
Prototype on your data
Weeks 2–3
A callable endpoint running against a sample of your real records, so you can judge accuracy before committing to the full build.
Production build
Weeks 4–8
Hardening, documentation, authentication, monitoring and the throughput work needed to run this at your volume.
Integration and handover
Week 9
Integration support for your team, load testing and an agreed support arrangement.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Can you tell us whether email is landing in the inbox or the spam folder?
No. Mailbox providers do not publish inbox placement, and any service claiming to know it is either extrapolating from a seed panel or guessing. What we report is the configuration faults and behavioural patterns that cause placement problems, plus the real feedback that exists — bounce codes, complaints, blocklist status, postmaster data where authorised. That is actionable. A fabricated placement percentage is not, and we would rather omit it than ship a number your customers will quote back to you.
Will fixing everything you flag guarantee delivery?
No. Correct authentication and clean lists remove the causes you control, which is most of them. Receiving-side decisions also depend on recipient engagement, content, the reputation of shared infrastructure and provider policies that change without notice. The honest framing is that remediation removes known faults rather than guarantees an outcome.
How reliable are blocklists as a signal?
Mixed, and it depends entirely on which list. A few are widely consulted and a listing has real consequences; many are obscure and effectively ignored by major providers. We report presence per list with context on its practical significance rather than aggregating them into one alarming count, which is how deliverability tools generate panic over nothing.
Do you need access to our customers' DNS or mailboxes?
DNS records are public, so configuration checks need no access at all. Postmaster tooling requires your customer's authorisation, and we would only use it where they have granted it explicitly. We do not need mailbox access and would not ask for it.
What about seed list inbox testing?
That is a separate product with its own significant limitations — seed accounts do not behave like real recipients, so placement measured against them can diverge badly from reality. If you want it, we would build it as a clearly labelled separate signal rather than blending its estimates into these diagnostics and losing the distinction between measured and inferred.
Related blueprints
Brand Reputation Monitoring API
Mentions, sentiment, emerging complaint themes and topic trends across permitted public sources, aggregated rather than person-level.
Customer Segmentation API
Behavioural segments, propensity scores and audience classification computed from first-party customer data inside your own environment.
Company Enrichment API
Industry, size, locations, technology and firmographic attributes resolved from a domain or company name, with change detection.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.