domain-health-precheck

Files (9)

• .mcp.json
• LICENSE
• SKILL.md
• cases.json · evals/
• listing.json · listing/
• logo.png · listing/
• logo.svg · listing/
• check-output.py · scripts/
• output-contract.json · scripts/

SKILL.md (first lines)

# Domain Health Precheck

## What this does

Before a single email leaves a domain, four things decide whether it arrives: a valid SPF record, a published DKIM selector, a DMARC policy that is not left at none forever, and a clean listing across the major blocklists. This skill checks all four on one domain and returns a plain verdict with the exact DNS records to add for anything that fails.

## Requirements

Check these before you run the skill. Nothing outside this table is needed.

| Requirement | Needed | Used for | What it costs you |
| --- | --- | --- | --- |
| Apify account and API token (`APIFY_TOKEN`) | Required | Runs the live data actors | A free Apify account works. Each run bills your own Apify account at the actor's Store price: domain-deliverability-checker 0.005 USD per domain. |
| Node.js 18 or newer | Required | The MCP tool calls | Free. It starts the Mamba Labs MCP server with `npx`. |
| DNS access at your registrar, to apply the fixes | Optional | Applying the fixes | None. |

**Missing a required item?** Stop before the live steps and tell the user which item is
missing and what it is for. Do not run the step without it and do not present an empty
result as an answer. Keys are read from the environment at run time and are never
written into a file, a prompt or the output.

## When to use it

- check my domain
- am I going to land in spam
- is this domain blacklisted
- SPF DKIM DMARC setup
- domain health

## Inputs

- **domain**: the sending domain, not the website domain if they differ
- **provider**: which mail provider sends for it

## Shared context this skill reads

Before doing anything else, read whichever of these exist at the project root and
use them instead of asking the user to repeat themselves:

- `BRAND.md`

If none exist, do the work from what the user gives you, then offer to write the
missing file so the next skill in the pack starts warmer.

## Tool connection

The checks run live against DNS and public blocklists through the Mamba Labs deliverability actor, so the result is the current record rather than a cached report.

This skill calls live data through the Mamba Labs MCP server, which runs the
actors on Apify with your own Apify token (https://console.apify.com/account/integrations).

- Installed as a plugin: the server is already wired, and the plugin asks for the token once.
- Installed by hand: copy `.mcp.json` from this folder into your project root and set
  `APIFY_TOKEN` in your environment, or run:

```
claude mcp add mamba-deliverability -e APIFY_TOKEN=<your token> -- npx -y @mambalabsdev/mcp-domain-deliverability-checker@1.1.1
```

| Actor | MCP tool | Used for | Store page |
| --- | --- | --- | --- |
| Domain Deliverability Checker | `check_domain_deliverability` | SPF, DKIM, DMARC and blacklist status for a sending domain | https://apify.com/mambalabs/domain-deliverability-checker |

Runnable example input, matched to the live tool schema:

`check_domain_deliverability`:

```json
{
  "domains": [
    "example.com"
  ]
}
```

**Cost line.** Before any live call, state how many calls you plan and which actors
they bill. After the run, report the calls made, the calls that failed, and the Apify
usage where the tool reports it. Each actor bills the user's own Apify account at its
Store price.

**No token, no live data.** If no Apify token is available, say so and stop the live
steps. Never fill a live section from memory and present it as live.

## Method

1. Read the SPF record. Check that it exists, that there is exactly one, that it authorizes the actual sending provider, and that it stays under the ten lookup limit.
2. Read DKIM at the selector the provider uses. A domain with no published selector is unsigned regardless of what the provider dashboard says.
3. Read DMARC. Report the policy, and treat a policy of none that has been in place for months as a finding rather than a pass.
4. Check the blocklists and report which one, since the delisting process differs per list.
5. Check whether the sending domain is the primary brand domain. Sending cold outreach from the primary domain puts the whole company's mail at risk and is the single most consequential finding.
6. Return a verdict: safe to send, safe after the listed fixes, or do not send. Give the exact record content to add, not a description of it.
7. Check the output with `scripts/check-output.py` before you return it.

## Approval stop

This skill does not send email or write to a CRM. If the user asks it to, stop first:
show what would be sent or written and wait for an explicit yes.

## Output

A four row check table with the record found and the verdict, then the exact DNS records to add, then the one line overall verdict.

## Check the output before you return it

Save the output to a file and run `python3 scripts/check-output.py <file>`. The
contract it checks is `scripts/output-contract.json`.

- Exit 0, `COMPLETE`: return the output.
- Exit 2, `INCOMPLETE`: do not present the output as finished. Fill what you can, run
  the check again, and if parts stay missing, return the output under the heading
  `Incomplete` with every reason the check printed.

## Quality bar

- Every failed check comes with the literal record value to publish
- Multiple SPF records are reported as a failure, not merged
- A DMARC policy of none is reported with its age rather than passed silently
- Sending from the primary brand domain is called out explicitly

From mambalabsdev/mamba-labs-skills, MIT.

More from mambalabsdev/mamba-labs-skills