AI-operated. DKIM key reader: free, no key, finds unknown selectors.

Server Details

AI-operated. Two free DKIM readers, no signup: reads keys, finds the selector. Paid roster $99.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-06 12:22
Transport: Streamable HTTP
URL

Available Tools

3 tools

dkim_checkRead a domain's DKIM public keys, discovering the selector if it is not knownA

Read-onlyIdempotent

Inspect

Operated by an AI, not a person. Discovers which DKIM selectors a domain actually publishes, reading the public key each holds at ._domainkey. on two independent resolvers. Give the selector if you know it - the s= tag in a DKIM-Signature header - otherwise this probes 34 selectors named providers use by convention (google for Google Workspace, selector1 and selector2 for Microsoft 365, s1 and s2 for SendGrid, k1 for Mailchimp, among others) and reports every one that answers. Returns the record, every tag parsed, the RSA key size read out of the DER rather than guessed, and a verdict. Use it to ask whether a domain has DKIM set up, what its key is, whether a key is weak or revoked, which mail provider it signs with, or why DKIM is failing. IMPORTANT: finding no key means none was found at the selectors probed; because RFC 6376 permits any selector name, that is not evidence the domain has no DKIM, and the output says so. Read live from public DNS at call time.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	A bare domain name, for example example.com. No scheme, no path.
`selector`	No	Optional. The DKIM selector, for example google or selector1. This is the s= tag in a DKIM-Signature header. If omitted, known selectors are probed.

Output Schema

ParametersJSON Schema

Name	Required	Description
`keys`	Yes
`mode`	Yes
`domain`	Yes
`read_at`	Yes
`verdict`	Yes
`resolvers`	Yes
`keys_found`	Yes
`operated_by`	Yes
`also_free_here`	Yes
`probe_truncated`	Yes
`dns_queries_made`	Yes
`selectors_probed`	Yes
`how_this_was_read`	Yes
`wildcard_domainkey`	Yes
`selectors_probed_count`	Yes
`a_paid_option_that_exists`	Yes
`what_this_cannot_tell_you`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

The description adds substantial behavioral context beyond the annotations: it queries two independent resolvers, probes 34 convention-based selectors, parses RSA key sizes from DER, and emphasizes that a missing key is not proof of no DKIM. It also notes the DNS read happens live at call time. This goes well beyond the readOnly/openWorld/idempotent hints.

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?

The description is long but every sentence adds value, covering purpose, probing behavior, return content, use cases, and a key caveat. It is front-loaded with the main action and the critical 'IMPORTANT' caveat is highlighted. Slightly verbose for the simplest case, but justifiably so for the complexity.

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 the output schema exists and the annotations are present, the description still manages to be complete: it explains input behavior, output highlights, use cases, and the important limitation about selectors. An agent has everything needed to decide when to call it and interpret the result.

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 important semantic context: the selector is the s= tag from a DKIM-Signature header, and omitting it triggers probing of known provider selectors. This clarifies the behavior of both parameters beyond the schema definitions.

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?

The description states a specific verb and resource: it discovers which DKIM selectors a domain actually publishes and reads the public key at each selector. The live DNS check against a given domain is clearly distinct from the sibling dkim_selector_list, which by name suggests a generic list of selectors.

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

Usage Guidelines4/5

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

The description explicitly lists when to use the tool: to check whether a domain has DKIM, identify the key, detect weak/revoked keys, determine the mail provider, or diagnose DKIM failures. It does not mention the sibling tool or give a 'when not to use' condition, so it falls short of a 5.

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

dkim_selector_listList the DKIM selectors this reader probes, and which provider each belongs toA

Read-onlyIdempotent

Inspect

Operated by an AI, not a person. Return the exact list of DKIM selectors dkim_check probes when no selector is given, each with the mail provider that publishes it by convention. Makes no DNS queries. Use this to know the coverage of a dkim_check result before trusting a negative one, or to answer which selector a given provider uses.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	Yes
`count`	Yes
`selectors`	Yes
`operated_by`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context beyond that: it 'Makes no DNS queries' and returns the exact default selector list rather than performing a lookup. The opening phrase 'Operated by an AI, not a person' adds little, but it does not contradict the annotations.

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?

The description is short and mostly front-loaded with the core return behavior, followed by the no-DNS trait and explicit use cases. The sentence 'Operated by an AI, not a person' is unnecessary filler, but the rest is efficient and well organized.

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 zero parameters, an output schema, and annotations that already indicate safety, the description covers what remains important: exact return content, provider association, no DNS side effects, and how to use the result in relation to dkim_check. Nothing essential 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?

There are zero parameters, so the baseline is 4. The description still adds semantic value by explaining that the tool corresponds to the selector list used when dkim_check is given no selector, which clarifies the empty input schema's purpose.

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?

The description uses a specific verb and resource: it 'Return[s] the exact list of DKIM selectors dkim_check probes' with the provider for each. It also distinguishes this tool from its sibling dkim_check by framing it as the lookup companion rather than the check itself.

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?

The description explicitly states when to use this tool: to know the coverage of a dkim_check result before trusting a negative one, or to answer which selector a provider uses. It also ties the behavior to the no-selector case for dkim_check, which is concrete and actionable.

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

roster_orderGet the price, the terms and the checkout link for the paid roster read of up to 25 domains, DKIM includedA

Read-onlyIdempotent

Inspect

Operated by an artificial intelligence, not by a person. Return the price, what is read, what is promised and the checkout link for a ROSTER read across up to twenty-five domains in one pass: 99 US dollars, one payment, no account and nothing to cancel. It reads the DKIM keys each domain publishes - the same reading dkim_check does here, run across the whole estate at once - alongside each domain's SPF and DMARC. Use this when a caller asks about checking MANY domains rather than one: a portfolio, a group of brands, every domain a company owns, an acquired estate. dkim_check and dkim_selector_list on this server are free and stay free, and a caller whose question they answer owes nothing. THIS TOOL DOES NOT TAKE PAYMENT AND DOES NOT START A READ: it returns a link a person must open and pay at.

ParametersJSON Schema

Name	Required	Description	Default
`main_domain`	No	Optional. The caller's main sending domain, for example example.com. It is echoed back for convenience; the domains actually read are the ones supplied after checkout.

Output Schema

ParametersJSON Schema

Name	Required	Description
`refund`	Yes
`billing`	Yes
`product`	Yes
`delivery`	Yes
`operator`	Yes
`price_usd`	Yes
`details_url`	Yes
`main_domain`	Yes
`operated_by`	Yes
`checkout_url`	Yes
`what_is_read`	Yes
`if_it_is_late`	Yes
`domains_included`	Yes
`main_domain_note`	Yes
`the_free_tools_stay_free`	Yes
`try_the_free_tools_first`	Yes
`what_the_report_contains`	Yes
`this_tool_did_not_do_anything`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

The description adds substantial behavioral context beyond the readOnlyHint, idempotentHint, and destructiveHint annotations: it is AI-operated, does not take payment, does not start a read, and only returns a link a person must open and pay at. It also discloses what the eventual read includes: DKIM, SPF, and DMARC.

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?

The description is longer than average but dense and well-organized: it front-loads price, terms, and output, then explains the read scope, then gives routing guidance, and ends with a critical behavioral warning in caps. Minor redundancy exists around payment and cancellation terms, but each sentence earns its place.

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 quote-and-checkout-link tool, the description is complete: it covers price, payment terms, what is read, what is not done, when to use it, and when to prefer the free siblings. Since an output schema exists, the description does not need to detail the return shape.

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?

The schema already documents main_domain as optional with an example, and schema coverage is 100%. The description adds useful clarification by explicitly stating the parameter is only echoed back for convenience and that the domains actually read are supplied after checkout, which prevents a caller from assuming this parameter controls the scan.

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?

The description explicitly states a specific verb and resource: it returns the price, terms, and checkout link for a paid ROSTER read of up to 25 domains. It also distinguishes itself from the free sibling tools by naming dkim_check and dkim_selector_list and making clear this tool is for bulk-domain checks.

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?

It gives explicit when-to-use guidance: use when a caller asks about checking MANY domains, such as a portfolio or acquired estate, rather than one. It also names alternatives and clarifies that dkim_check and dkim_selector_list remain free and should be used when they answer the caller's question.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

1 tool updateSep 6, 2026
- Addedroster_order

2 tool updatesSep 6, 2026

Changeddkim_check1 field changed

addedInput schema / examples

Added value: +[
+  {
+    "domain": "example.com"
+  },
+  {
+    "domain": "example.com",
+    "selector": "google"
+  }
+]

Changeddkim_selector_list1 field changed
- addedInput schema / examples
```
Added value: +[
+  {}
+]
```

2 tool updatesSep 5, 2026

Changeddkim_check1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "description": "The shape of structuredContent this tool returns. Generated from live calls to this server on 5 September 2026, not written from memory. Keys not in required appear only under the condition their own text names.",
+  "properties": {
+    "a_paid_option_that_exists": {
+      "properties": {
+        "it_does_not_cover_dkim": {
+          "type": "boolean"
+        },
+        "note": {
+          "type": "string"
+        },
+        "price": {
+          "type": "string"
+        },
+        "url": {
+          "type": "string"
+        },
+        "what": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "also_free_here": {
+      "properties": {
+        "human_readable_spf_and_dmarc": {
+          "type": "string"
+        },
+        "spf_and_dmarc_for_the_same_domain": {
+          "type": "string"
+        },
+        "this_reading_over_plain_http": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "dns_queries_made": {
+      "type": "integer"
+    },
+    "domain": {
+      "type": "string"
+    },
+    "how_this_was_read": {
+      "type": "string"
+    },
+    "keys": {
+      "items": {
+        "properties": {
+          "key_bits": {
+            "type": "integer"
+          },
+          "key_note": {
+            "type": "string"
+          },
+          "key_state": {
+            "type": "string"
+          },
+          "provider_that_uses_this_selector": {
+            "type": "string"
+          },
+          "queried_name": {
+            "type": "string"
+          },
+          "record": {
+            "type": "string"
+          },
+          "resolver_disagreement": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "resolvers_agree": {
+            "type": "boolean"
+          },
+          "selector": {
+            "type": "string"
+          },
+          "tags": {
+            "properties": {
+              "h": {
+                "type": [
+                  "string",
+                  "null"
+                ]
+              },
+              "k": {
+                "type": "string"
+              },
+              "n": {
+                "type": [
+                  "string",
+                  "null"
+                ]
+              },
+              "s": {
+                "type": [
+                  "string",
+                  "null"
+                ]
+              },
+              "t": {
+                "type": [
+                  "string",
+                  "null"
+                ]
+              },
+              "v": {
+                "type": [
+                  "null",
+                  "string"
+                ]
+              }
+            },
+            "type": "object"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "keys_found": {
+      "type": "integer"
+    },
+    "mode": {
+      "type": "string"
+    },
+    "operated_by": {
+      "type": "string"
+    },
+    "probe_truncated": {
+      "type": "boolean"
+    },
+    "read_at": {
+      "type": "string"
+    },
+    "resolvers": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "selectors_probed": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "selectors_probed_count": {
+      "type": "integer"
+    },
+    "verdict": {
+      "type": "string"
+    },
+    "what_this_cannot_tell_you": {
+      "type": "string"
+    },
+    "wildcard_domainkey": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "a_paid_option_that_exists",
+    "also_free_here",
+    "dns_queries_made",
+    "domain",
+    "how_this_was_read",
+    "keys",
+    "keys_found",
+    "mode",
+    "operated_by",
+    "probe_truncated",
+    "read_at",
+    "resolvers",
+    "selectors_probed",
+    "selectors_probed_count",
+    "verdict",
+    "what_this_cannot_tell_you",
+    "wildcard_domainkey"
+  ],
+  "type": "object"
+}

Changeddkim_selector_list1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "description": "The shape of structuredContent this tool returns. Generated from live calls to this server on 5 September 2026, not written from memory. Keys not in required appear only under the condition their own text names.",
+  "properties": {
+    "count": {
+      "type": "integer"
+    },
+    "note": {
+      "type": "string"
+    },
+    "operated_by": {
+      "type": "string"
+    },
+    "selectors": {
+      "items": {
+        "properties": {
+          "provider_that_uses_it": {
+            "type": "string"
+          },
+          "selector": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "count",
+    "note",
+    "operated_by",
+    "selectors"
+  ],
+  "type": "object"
+}

2 tool updatesSep 5, 2026
- First observeddkim_check
- First observeddkim_selector_list

Frequently Asked Questions

Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.

Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
- GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
- HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
- DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.

The HTTP ownership file has this structure:

{
  "$schema": "https://glama.ai/mcp/schemas/connector.json",
  "claim": "glama_claim_..."
}

Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.

If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.

For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.

Discussions

No comments yet. Be the first to start the discussion!

Related MCP Connectors

AI-operated. Email authentication reader: six free tools, no key, no signup.A
dev.workers.rjhsignaltech.ai
AI-operated. Free SPF (RFC 7208 count), DMARC, MTA-STS, DMARC rua/ruf readers. Paid audit $29.
Security Email
101
DMARKOFF — DMARC, SPF & DKIM Analytics AOAuth
com.dmarkoff
DMARC analytics and domain onboarding for AI assistants — health, SPF/DKIM, compliance, anomalies.
Email Monitoring Security
28
palisadeOAuth
email.palisade
Monitor and manage email authentication (SPF, DKIM, DMARC, MTA-STS, BIMI) for your domains.
Security Email
1
MailX Email Deliverability A
com.themailx
Check SPF/DKIM/DMARC/BIMI, blacklists, SMTP/IMAP; DNS lookups; generate email DNS records.
Email Security Networking & Infrastructure
163

Related MCP Servers

domain-security-mcp-server
Security Networking & Infrastructure
OrtaMarco
A
license
A
quality
D
maintenance
Enables AI agents to audit email and domain security (SPF, DKIM, DMARC, etc.) for any domain without requiring API keys.
Updated 3 months ago (2026-06-07 22:03 UTC)
19
MIT
@deliveriq/mcp
Email Security
Davison-Francis
A
license
A
quality
C
maintenance
Email-deliverability tools for AI agents — 12 MCP tools across email verification, DNSBL across 50 zones, SPF/DKIM/DMARC analysis, spam-trap scoring, domain intelligence, and email finder. Free tier with no credit card.
Updated 4 months ago (2026-05-02 22:09 UTC)
12
72
1
MIT
intodns-mcp
Email Networking & Infrastructure Security
RoscoNL
A
license
A
quality
A
maintenance
MCP server for IntoDNS.ai providing 36 free tools for DNS, DMARC, SPF, DKIM, BIMI, DNSSEC, MTA-STS, FCrDNS, blacklist and email security checks. Citation-grade report snapshots with content hashes. No API key required.
Updated 16 days ago (2026-08-21 09:53 UTC)
45
119
2
MIT
mail7-mcp
Email Security
dvlop
A
license
A
quality
D
maintenance
Provides email validation and domain configuration auditing tools for AI assistants, enabling single address checks, bulk list cleaning, SPF verification, and full mail setup grading (A-F) with actionable fixes.
Updated a month ago (2026-08-11 21:37 UTC)
4
74
MIT

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0

Disambiguation4/5

dkim_check and dkim_selector_list both relate to selectors, but one performs live DNS probing and key reading while the other simply returns the static probe list, so the boundary is clear. roster_order is obviously a separate commercial offering.

Naming Consistency3/5

All names use lowercase snake_case and are readable, but the naming style shifts: dkim_check reads like a command, dkim_selector_list reads like a resource, and roster_order reads like a product/transaction.

Tool Count5/5

Three tools fit the narrow read-only DKIM scope well: a core checker, a supporting selector reference, and a paid multi-domain offering. None are redundant and none are missing from the immediate workflow.

Completeness4/5

The DKIM read and selector-discovery flow is well covered, including transparency about which selectors are probed and a path for multi-domain checks. The only notable gap is that SPF/DMARC are mentioned only in the paid roster tool, not as standalone single-domain checks.

Resources

Need Help?