Domain Mail Check

Check mail delivery

delivery_check

Read-onlyIdempotent

Use this when the user asks whether mail from a domain will reach Gmail or Outlook, or why it is rejected or goes to spam, such as "will Gmail accept mail from example.com sent from 203.0.113.7?". Pass the domain, the sending IPv4 address if known, the return-path domain (mail_from) if known and, optionally, up to 5 DKIM selectors. Returns one verdict (likely_accepted, at_risk, likely_rejected or incomplete) with a verdict per provider, the top 3 causes each with one fix, the exact SPF and DMARC records to paste (records_to_paste) and the DKIM steps for the detected mail provider (fix_steps), every rule checked with its official source link (SPF for the IP, DKIM, DMARC, reverse DNS, blocklists), the 6 blocklists with their terms links, what was not checked, and the source and as_of date. Gmail and Outlook are always both reported, so there is no provider argument. It reads public DNS and free blocklists only: it sends no test message and cannot see sender reputation, so it does not promise inbox placement.

Input Schema

TableJSON Schema

Name	Required	Description
`domain`	Yes	The domain in the From address, such as "example.com". A web address or an email address is reduced to its domain.
`mail_from`	No	The return-path domain, which receivers test SPF on: the domain after @ in the Return-Path header of a sent message, or smtp.mailfrom in its Authentication-Results, such as "send.example.com". Optional: when omitted, SPF for sending_ip is tested on the From domain, then on the usual return-path names under it (send, bounce, bounces, mail, mg, pm-bounces). Mail providers such as Resend, Amazon SES and Postmark send with their own return-path domain.
`sending_ip`	No	The public IPv4 address your mail is sent from, such as 203.0.113.7. Optional: without it the IP checks (SPF for the address, reverse DNS, IP blocklists) are skipped. IPv6 is not supported.
`dkim_selectors`	No	DKIM selector names, the s= value in a DKIM-Signature header, such as ["google"]. Optional: when omitted, 10 usual selector names are tried. At most 5.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`dkim`	No
`as_of`	Yes
`rules`	Yes
`domain`	Yes
`notice`	No
`source`	Yes
`status`	Yes
`message`	No
`verdict`	Yes
`fix_steps`	No
`mail_from`	No
`blocklists`	Yes
`sending_ip`	No
`spf_for_ip`	No
`top_causes`	Yes
`by_provider`	No
`not_checked`	Yes
`reverse_dns`	No
`unavailable`	Yes
`rule_sources`	No
`verdict_basis`	No
`records_to_paste`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 14, 2026

addedInput schema / properties / mail_from

Added value: +{
+  "description": "The return-path domain, which receivers test SPF on: the domain after @ in the Return-Path header of a sent message, or smtp.mailfrom in its Authentication-Results, such as \"send.example.com\". Optional: when omitted, SPF for sending_ip is tested on the From domain, then on the usual return-path names under it (send, bounce, bounces, mail, mg, pm-bounces). Mail providers such as Resend, Amazon SES and Postmark send with their own return-path domain.",
+  "maxLength": 253,
+  "minLength": 3,
+  "type": "string"
+}

addedOutput schema / properties / mail_from

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / spf_for_ip / properties / basis

Added value: +{
+  "enum": [
+    "mail_from",
+    "from_domain",
+    "return_path_name"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / spf_for_ip / properties / domain
```
Added value: +{
+  "type": "string"
+}
```

Changed2 schema fields changedOct 14, 2026

addedOutput schema / properties / fix_steps

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / records_to_paste

Added value: +{
+  "items": {
+    "properties": {
+      "action": {
+        "enum": [
+          "add",
+          "replace"
+        ],
+        "type": "string"
+      },
+      "host": {
+        "type": "string"
+      },
+      "name": {
+        "type": "string"
+      },
+      "part": {
+        "enum": [
+          "SPF",
+          "DMARC"
+        ],
+        "type": "string"
+      },
+      "replaces": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "type": {
+        "enum": [
+          "TXT"
+        ],
+        "type": "string"
+      },
+      "value": {
+        "type": "string"
+      },
+      "when": {
+        "enum": [
+          "now",
+          "later"
+        ],
+        "type": "string"
+      },
+      "why": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "part",
+      "type",
+      "name",
+      "host",
+      "value",
+      "action",
+      "replaces",
+      "when",
+      "why"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

AddedOct 5, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/openWorld/idempotent/non-destructive, yet the description goes further: it reads public DNS and free blocklists only, sends no test message, cannot see sender reputation, and does not promise inbox placement. That is exactly the kind of expectation-setting the annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Trigger is front-loaded and the prose is dense and waste-free, but the long enumeration of return fields overlaps heavily with the existing output schema and makes the description bulkier than needed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a multi-input diagnostic tool with an output schema already present, the description still conveys scope of checks (SPF, DKIM, DMARC, rDNS, 6 blocklists), what is not checked, and freshness (as_of). Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics on top: when mail_from is omitted SPF falls back to the From domain and standard return-path names, DKIM selectors default to 10 usual names when omitted, and crucially why there is no provider argument. It only omits finer format details already carried by the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific diagnostic action over a specific resource: whether mail from a domain will reach Gmail/Outlook and why it is rejected or spammed. The verdict vocabulary and the explicit note that Gmail and Outlook are always both reported clearly separate it from sibling tools like check_dns_records and check_email_auth.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Opens with a concrete when-to-use trigger ('when the user asks whether mail from a domain will reach Gmail or Outlook, or why it is rejected or goes to spam') and includes a literal example query. It also states what the tool cannot do (no test message, no sender reputation), which bounds usage explicitly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Domain Mail Check tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.