MultiMail checks MX records, SPF/DMARC configuration, and cross-tenant bounce history on every send — automatically, at scale, with no extra API calls from your agent.
High-volume outbound agents accumulate deliverability debt fast. A single campaign to a stale list can push your domain's bounce rate past 2% — the threshold where Gmail and Outlook start bulk-filtering your legitimate mail. Most email APIs let agents send to anything and handle the fallout after the fact. By then, your sender reputation is already damaged, and recovery takes weeks of suppressed volume and careful warm-up.
MultiMail runs domain intelligence checks before every outbound send. When your agent calls send_email, the platform extracts the recipient domain, queries live MX records, validates SPF and DMARC configuration, and cross-references a deliverability map built from send outcomes across all tenants. Domains classified as high-risk are blocked before the message ever leaves the platform. Your agent gets a structured result explaining the block — not a bounce notification hours later.
On every send_email call, MultiMail parses the To address and extracts the recipient domain. This happens inside the platform — your agent does not need to pre-process addresses or call a separate verification endpoint.
The platform queries authoritative DNS for the recipient domain's MX records. Domains with no MX records, misconfigured records, or records pointing to known spam traps are flagged immediately. Results are cached per domain with a short TTL to avoid redundant lookups on bulk sends.
MultiMail checks whether the recipient domain publishes SPF and DMARC policies. Domains without DMARC are statistically more likely to have abandoned or poorly-managed inboxes. This signal contributes to the domain's risk score alongside MX data.
Every hard bounce recorded across all MultiMail tenants contributes to a shared deliverability map. When your agent targets a domain that has produced hard bounces for other tenants, that history is factored into the risk classification — without exposing which tenants sent to that domain.
Domains are classified as green (proceed), yellow (proceed with warning logged), or red (blocked). Your agent receives the classification and reason in the send_email response. Red domains are blocked before transmission; no message is queued, no webhook fires for delivery.
from multimail import MultiMailClient
client = MultiMailClient(api_key="$MULTIMAIL_API_KEY")
result = client.send_email(
from_address="[email protected]",
to="[email protected]",
subject="Following up on your inquiry",
body="Hi — wanted to follow up on the estimate we sent last week."
)
"cm"># Verification runs automatically — check the result
if result.status == "blocked":
print(f"Blocked: {result.verification.reason}")
"cm"># e.g. "No MX records found" or "Platform bounce rate: 23%"
elif result.verification.risk == "yellow":
print(f"Sent with warning: {result.verification.note}")
else:
print(f"Delivered: {result.message_id}")Every send_email call runs domain intelligence checks. The response includes a verification object describing the outcome.
from multimail import MultiMailClient
client = MultiMailClient(api_key="$MULTIMAIL_API_KEY")
recipients = [
"[email protected]",
"[email protected]",
"[email protected]",
]
delivered, blocked = [], []
for recipient in recipients:
result = client.send_email(
from_address="[email protected]",
to=recipient,
subject="Q2 product update",
body="Here is what shipped this quarter..."
)
if result.status == "blocked":
blocked.append({
"address": recipient,
"reason": result.verification.reason,
"risk_score": result.verification.risk_score
})
else:
delivered.append(recipient)
print(f"Delivered: {len(delivered)}, Blocked: {len(blocked)}")
for b in blocked:
print(f" {b[&"cm">#039;address']}: {b['reason']} (score={b['risk_score']})")When sending to a list, iterate results to separate delivered, warned, and blocked addresses for downstream handling.
curl -X POST https://api.multimail.dev/send_email \
-H "Authorization: Bearer $MULTIMAIL_API_KEY" \
-H "Content-Type: application/json" \
-d &"cm">#039;{
"from": "[email protected]",
"to": "[email protected]",
"subject": "Verification result: acmeplumbing.com",
"body": "Domain: acmeplumbing.com | MX: Google Workspace | SPF: configured | Status: Green"
}&"cm">#039;
"cm"># Response when domain passes verification:
"cm"># {
"cm"># "message_id": "msg_01HZ...",
"cm"># "status": "queued",
"cm"># "verification": {
"cm"># "domain": "acmeplumbing.com",
"cm"># "risk": "green",
"cm"># "mx_found": true,
"cm"># "spf_configured": true,
"cm"># "dmarc_configured": true,
"cm"># "platform_bounce_rate": 0.004
"cm"># }
"cm"># }
"cm"># Response when domain is blocked:
"cm"># {
"cm"># "status": "blocked",
"cm"># "verification": {
"cm"># "domain": "oldstartup.io",
"cm"># "risk": "red",
"cm"># "mx_found": false,
"cm"># "reason": "No MX records found"
"cm"># }
"cm"># }Call the send_email endpoint directly. The verification block is always present in the response body.
# In a Claude Desktop or Cursor session with MultiMail MCP configured:
# Tool: send_email
# Arguments:
# from: [email protected]
# to: [email protected]
# subject: Following up on your inquiry
# body: Hi — wanted to check in on the proposal we sent.
# MCP tool response:
# {
# "message_id": "msg_01HZ...",
# "status": "queued",
# "verification": {
# "domain": "acmeplumbing.com",
# "risk": "green",
# "mx_found": true,
# "spf_configured": true,
# "platform_bounce_rate": 0.004
# }
# }
# If blocked, the agent can relay the reason to the user:
# "I couldn't send to [email protected] — that domain has no
# MX records, which means no mail server is configured to receive
# email there. You may want to find an updated contact address."When using MultiMail via MCP, the send_email tool returns the same verification block. Agents can inspect it and explain the outcome to users.
Hard bounces are permanent reputation events. Gmail and Outlook track bounce rates per sending domain and apply bulk filtering once rates exceed 2%. Blocking bad addresses before transmission prevents bounce events from accumulating, keeping your domain in good standing.
Verification is built into the send path — not a separate pre-flight endpoint your agent must remember to call. Every send_email call runs checks automatically. Agents that forget to verify don't cause incidents; they just get a blocked status back.
Every bounce recorded across all MultiMail tenants contributes to the shared deliverability map. A domain that produced hard bounces for a marketing team last week is already flagged when your SaaS onboarding agent encounters it today. The platform gets smarter as more agents use it.
When a send is blocked, the response includes the specific reason: missing MX records, no DMARC policy, or high platform-wide bounce rate. Agents can surface this reason to users, log it for human review, or route the contact to a manual verification queue.
MX lookups are cached per domain with short TTLs inside the platform. Sending 10,000 emails to 500 companies does not trigger 10,000 DNS queries. The caching layer handles bulk campaigns without degrading lookup quality or hitting resolver limits.
Email infrastructure built for AI agents. Verifiable identity, graduated oversight, and a 50-tool MCP server. Formally verified in Lean 4.