---
name: mailcheck-jobs
description: "Step-by-step job recipes for the Domain Mail Check MCP server: Score a cold-email domain; Check mail delivery; Check DNS security faults. Use when the user asks things like \"Is acme-mail.com ready for cold email outreach?\" or \"Will Gmail and Outlook accept mail from example.com sent from 203.0.113.7?\""
license: MIT
---

# Domain Mail Check jobs

Each section below walks through one job with the tools of the `mailcheck` MCP server. The same recipes are MCP prompts (prompts/list) on `https://api.openkrill.app/gateway/mcp`.
Connect the server at `https://mailcheck.openkrill.app/mcp` in your MCP client settings (remote streamable HTTP, no key), then call its tools as normal tool calls. They are not command line programs: Bash, curl and scripts cannot reach them.

## Score a cold-email domain

Job: Score a cold-email domain, with the Domain Mail Check MCP server.

Use the `launch_score` tool for this job.

Work on the user's request. If there is none yet, ask what they need. A request this job handles: "Is acme-mail.com ready for cold email outreach?"

Steps:
1. Call `launch_score` as a normal MCP tool call, with the request's values in the fields of its inputSchema. It needs `domain`.
2. If a value the tool needs is missing and you cannot tell it from the request, ask the user one short question first.
3. This input is known to work; copy its format, not its values: `{"domain":"acme-mail.com"}`
4. For the request "Is acme-mail.com ready for cold email outreach?", a correct answer looks like this: status ok, a score from 0 to 100, a verdict, a fix_first list, rules each with a kind of standard or opinion and a source link, the registration date and age in days, a not_tested list, and source and as_of.
5. Follow the server's own rules:
   - Pass the domain and the sending IP when known, and mail_from when the user gives the Return-Path domain of a sent message.
   - Give the verdict, then the top causes with fixes, then the source links. likely_accepted means no published rule is broken, not that the inbox is certain.
   - Mention not_checked items only when they matter.
   - Call launch_score when the user asks whether a new or secondary domain is ready for cold email.
   - Give the score, the verdict and the fix_first list, and say whether each fix is standard or opinion.
   - Never present an opinion as a requirement, and say the score does not promise the inbox.
   - A domain under 14 days old fails an opinion rule: tell the user to wait and warm up, not that the domain is broken.
   - Give the faults with their fixes first.
   - A dangling CNAME is a risk to fix, not proof that someone took the subdomain over. could_not_connect or refused on a mail server means it was not read, never that STARTTLS is missing.
   - Pass dkim_selectors only when the user or their mail provider names them.
   - DKIM cannot be found without a selector, so unknown is not a failure.
   - Give the grade with its issues and fixes, and the source and as_of date.
   - These tools never return registrant or owner details: decline requests for an owner's name, email or phone and offer the registrar instead.
6. If the call fails or the answer looks wrong, tell the user, then report it with `submit_feedback` (kind bug, tool `launch_score`).

## Check mail delivery

Job: Check mail delivery, with the Domain Mail Check MCP server.

Use the `delivery_check` tool for this job.

Work on the user's request. If there is none yet, ask what they need. A request this job handles: "Will Gmail and Outlook accept mail from example.com sent from 203.0.113.7?"

Steps:
1. Call `delivery_check` as a normal MCP tool call, with the request's values in the fields of its inputSchema. It needs `domain`.
2. If a value the tool needs is missing and you cannot tell it from the request, ask the user one short question first.
3. This input is known to work; copy its format, not its values: `{"domain":"example.com","sending_ip":"203.0.113.7"}`
4. For the request "Will Gmail and Outlook accept mail from example.com sent from 203.0.113.7?", a correct answer looks like this: status ok, a verdict, a verdict per provider, up to 3 top_causes each with a fix, the rules with source links, the blocklists with terms links, a not_checked list, and source and as_of.
5. Follow the server's own rules:
   - Call delivery_check when the user asks whether mail will reach Gmail or Outlook, or why it is rejected or marked spam.
   - Pass the domain and the sending IP when known, and mail_from when the user gives the Return-Path domain of a sent message.
   - Give the verdict, then the top causes with fixes, then the source links. likely_accepted means no published rule is broken, not that the inbox is certain.
   - Mention not_checked items only when they matter.
   - Give the score, the verdict and the fix_first list, and say whether each fix is standard or opinion.
   - Never present an opinion as a requirement, and say the score does not promise the inbox.
   - A domain under 14 days old fails an opinion rule: tell the user to wait and warm up, not that the domain is broken.
   - Give the faults with their fixes first.
   - A dangling CNAME is a risk to fix, not proof that someone took the subdomain over. could_not_connect or refused on a mail server means it was not read, never that STARTTLS is missing.
   - Pass dkim_selectors only when the user or their mail provider names them.
   - DKIM cannot be found without a selector, so unknown is not a failure.
   - Give the grade with its issues and fixes, and the source and as_of date.
   - These tools never return registrant or owner details: decline requests for an owner's name, email or phone and offer the registrar instead.
   - They do not discover subdomains or send mail; delivery_check tests published rules and blocklists, not a real message.
6. If the call fails or the answer looks wrong, tell the user, then report it with `submit_feedback` (kind bug, tool `delivery_check`).

## Check DNS security faults

Job: Check DNS security faults, with the Domain Mail Check MCP server.

Use the `check_dns_hygiene` tool for this job.

Work on the user's request. If there is none yet, ask what they need. A request this job handles: "Does example.com have DNSSEC and a CAA record, and do its mail servers use STARTTLS?"

Steps:
1. Call `check_dns_hygiene` as a normal MCP tool call, with the request's values in the fields of its inputSchema. It needs `domain`.
2. If a value the tool needs is missing and you cannot tell it from the request, ask the user one short question first.
3. This input is known to work; copy its format, not its values: `{"domain":"cloudflare.com"}`
4. For the request "Does example.com have DNSSEC and a CAA record, and do its mail servers use STARTTLS?", a correct answer looks like this: status ok, caa, dnssec, starttls and dangling_cnames each with a status, a detail and a fix when failed, a faults list, and source and as_of.
5. Follow the server's own rules:
   - Pass the domain and the sending IP when known, and mail_from when the user gives the Return-Path domain of a sent message.
   - Give the verdict, then the top causes with fixes, then the source links. likely_accepted means no published rule is broken, not that the inbox is certain.
   - Mention not_checked items only when they matter.
   - Give the score, the verdict and the fix_first list, and say whether each fix is standard or opinion.
   - Never present an opinion as a requirement, and say the score does not promise the inbox.
   - A domain under 14 days old fails an opinion rule: tell the user to wait and warm up, not that the domain is broken.
   - Call check_dns_hygiene when the user asks about CAA, DNSSEC, STARTTLS or encrypted mail delivery, dangling CNAMEs or subdomain takeover, or for a wider DNS security check than SPF, DKIM and DMARC.
   - Give the faults with their fixes first.
   - A dangling CNAME is a risk to fix, not proof that someone took the subdomain over. could_not_connect or refused on a mail server means it was not read, never that STARTTLS is missing.
   - Pass dkim_selectors only when the user or their mail provider names them.
   - DKIM cannot be found without a selector, so unknown is not a failure.
   - Give the grade with its issues and fixes, and the source and as_of date.
   - These tools never return registrant or owner details: decline requests for an owner's name, email or phone and offer the registrar instead.
6. If the call fails or the answer looks wrong, tell the user, then report it with `submit_feedback` (kind bug, tool `check_dns_hygiene`).