Domain Mail Check

Check email authentication

check_email_auth

Read-onlyIdempotent

Use this when the user asks whether a domain's email is set up correctly, such as "is DMARC set up for github.com?" or "check SPF and DKIM for example.com". Pass the domain and, if known, up to 5 DKIM selector names. Returns SPF (policy, DNS lookup count, issues), DMARC (policy, percentage, report address, issues), DKIM per selector, the MX hosts and mail provider, a grade from A to F, a list of fixes, the exact SPF and DMARC records to paste (records_to_paste) and the DKIM steps for the detected mail provider (fix_steps), the source and as_of date, and a page link that shows the same check on the web. It reads public DNS only: it does not send mail, test delivery or read mailboxes.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`domain`	Yes	The domain, such as "example.com". A web address or an email address is reduced to its domain.
`dkim_selectors`	No	DKIM selector names to look for, such as ["google"] or ["selector1", "selector2"]. Optional; DKIM cannot be found without one. At most 5.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`mx`	Yes
`spf`	No
`dkim`	Yes
`page`	No
`as_of`	Yes
`dmarc`	No
`fixes`	Yes
`grade`	Yes
`domain`	Yes
`notice`	No
`source`	Yes
`status`	Yes
`message`	No
`fix_steps`	No
`grade_basis`	No
`unavailable`	Yes
`mail_provider`	No
`records_to_paste`	No

Schema Changelog

Changes observed during successful MCP inspections.

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"
+}

Changed1 schema field changedOct 14, 2026
- addedOutput schema / properties / page
```
Added value: +{
+  "type": "string"
+}
```

Changed1 schema field changedOct 5, 2026

removedOutput schema / properties / note_from_openkrill

Removed value: -{
-  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
-  "type": "string"
-}

Changed1 schema field changedOct 4, 2026

addedOutput schema / properties / note_from_openkrill

Added value: +{
+  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
+  "type": "string"
+}

First observedOct 3, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already establish readOnly, idempotent, non-destructive, open-world behavior, so the bar is lower; the description nonetheless adds the meaningful constraint that it touches public DNS only and enumerates what it will not do. Much of the remaining behavioral text is return-value enumeration that the output schema already covers, so it does not reach the top of the range.

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

Conciseness3/5

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

Usage guidance is correctly front-loaded, but the description then spends most of its length enumerating return fields (SPF policy, lookup count, DMARC percentage, grade, fixes, records_to_paste, fix_steps, source, as_of, page link) that the output schema already defines. That enumeration bloats the text without adding selection value.

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?

Given an output schema exists, the description does not need to explain return values, yet it does anyway; what genuinely matters — when to use it, what it reads, what it never does, and the DKIM selector caveat — is all present. Nothing an agent needs to invoke this correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so both parameters are already fully documented in the schema, establishing the baseline of 3. The description restates 'pass the domain and, if known, up to 5 DKIM selector names' and notes DKIM cannot be found without a selector, but adds no syntax or format detail beyond 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 verb and resource (check a domain's email authentication) and immediately enumerates the concrete signals it evaluates: SPF, DMARC, DKIM, MX, and a letter grade. The closing line 'reads public DNS only: it does not send mail, test delivery or read mailboxes' cleanly separates it from siblings like check_dns_records and delivery_check.

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?

Gives explicit user-utterance triggers ('is DMARC set up for github.com?', 'check SPF and DKIM for example.com') so the agent can match intent directly. It also states a negative boundary — no mail sent, no delivery test, no mailbox reads — which implicitly routes delivery-testing requests to delivery_check.

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.