Email Domain Health Checker

Domain health

by realjaymes · MIT license · ★ 65 on GitHub

When the user wants to check email deliverability posture, domain authentication, or sending reputation for a domain. Use when the user mentions "domain health," "inbox health," "deliverability," "SPF," "DKIM," "DMARC," "email…

---
name: domain-health
description: When the user wants to check email deliverability posture, domain authentication, or sending reputation for a domain. Use when the user mentions "domain health," "inbox health," "deliverability," "SPF," "DKIM," "DMARC," "email authentication," "are my emails landing in spam," "can I send from this domain," "is my domain spoofable," "warm up a domain," "check this sending domain," "DMARC rollout," "p=quarantine," "p=reject," "blacklisted," or "email going to spam." Also use before starting cold outbound from any domain, and to score prospect domains for deliverability gaps worth opening a cold email with. For writing the outbound emails themselves, see cold-email. For building the prospect list, see clay-gtm-outbound.
metadata:
  version: 1.0.0
---

# Domain Health

Email authentication and deliverability posture for any domain, using only `dig` and the standard library. No API key, no paid tool, no per-check cost.

The same DNS primitives serve two opposite jobs, which is why they live in one skill:

**Defensive.** Audit a domain you own before you send from it, and before you tighten a DMARC policy. Getting this wrong silently sends your own invoices and password resets to spam.

**Offensive.** Score a prospect's domain to find a real, specific gap worth opening a cold email with.

## When to run it

Overview

Email authentication and deliverability posture for any domain, using only dig and the standard library. No API key, no paid tool, no per-check cost.

Manual install (npx, ZIP)

Claude Codenpx skills add realjaymes/marketingagentskills --skill domain-health -g -a claude-code

Claude Code (degit)npx degit realjaymes/marketingagentskills/skills/domain-health#main ~/.claude/skills/domain-health

Claude.ai / desktopZip the folder and upload it under Settings → Capabilities → Skills.

Codex, Cursor, other agentsPoint them at SKILL.md. The other files are plain text.

Connects with Agent Alley MCP · agentalley.io/mcp

Files included

SKILL.md5.8 KB

Read SKILL.md here

realjaymes/main1 file shown

SKILL.md5.8 KB

Browse every file on GitHub↗

SKILL.md

Show the full text89 lines

domain-health/SKILL.md89 lines · 5.8 KB

PreviewCode

Outline

RawView on GitHub

Domain Health

Email authentication and deliverability posture for any domain, using only dig and the standard library. No API key, no paid tool, no per-check cost.

The same DNS primitives serve two opposite jobs, which is why they live in one skill:

Defensive. Audit a domain you own before you send from it, and before you tighten a DMARC policy. Getting this wrong silently sends your own invoices and password resets to spam.

Offensive. Score a prospect's domain to find a real, specific gap worth opening a cold email with.

When to run it

Before starting outbound from any domain. Before changing a DMARC policy. When email is landing in spam and nobody knows why. When enriching a prospect list with a technical hook. After adding any new sending tool, because that is when sender inventory drifts.

Modes

Audit (default) runs against domains you own.

python3 scripts/domain_health.py --domain example.com
python3 scripts/domain_health.py --domain example.com --json
python3 scripts/domain_health.py domains.txt

Prospect produces a CSV for list enrichment, with a gap column that is true when the domain's DMARC is missing or monitoring-only.

python3 scripts/domain_health.py --mode prospect domains.txt > signals.csv

Blacklist is opt-in via --blacklist. See the warning below before using it.

Mailbox verification is separate, in scripts/verify_email.py. It does MX plus an SMTP probe for a single address. Most networks block outbound port 25, in which case it returns unknown rather than guessing.

What it checks

MX, establishing who receives mail for the domain.

SPF, including whether more than one record exists (which is a PermError and means SPF fails entirely), the qualifier the record ends in, and the count of DNS-lookup-triggering mechanisms against the limit of ten. Exceeding ten is a common and invisible failure.

DKIM, by sweeping a maintained list of per-provider selectors in scripts/selectors.json.

DMARC, covering policy, the separate subdomain policy, percentage, reporting addresses, and whether those reports go somewhere a human will actually read.

Sender inventory, which is the check that matters most and the reason this skill exists. It reads apex verification tokens and sending-subdomain CNAMEs to infer which providers are attached to the domain, then cross-checks each against SPF. This catches a provider verified two years ago, still able to send, never added to SPF, and invisible until the day the policy tightens.

Maturity signals, meaning MTA-STS, TLS-RPT and BIMI.

Honesty constraints

These are load-bearing. Do not relax them, and do not let output phrasing drift past them.

DKIM absence is never claimed. Selectors are arbitrary strings and some providers use per-account random ones that cannot be guessed. A sweep that finds nothing means "no key on the selectors tried."

Verification tokens prove a relationship, not sending. A token proves the domain was verified with a provider at some point. Treat every inferred sender as a lead to confirm, never a fact. The tool separates mail-relevant signals from non-mail ones (site verification, custom web domains) precisely so the gap list stays worth reading.

A prospect's primary domain is a proxy. Teams running cold outbound properly send from a separate domain to protect the primary. Never state a finding about a prospect's primary domain as a confirmed claim about their outbound.

Blacklist results describe the provider. For any domain on hosted email, the MX addresses belong to the provider, so a listing reflects their shared infrastructure, not this domain's reputation. This is why the check is gated behind a flag and labelled in the output. Do not report it as the domain's own reputation.

The DMARC rollout

Never raise a DMARC policy without first completing a sender inventory and reading real aggregate reports. The staged sequence, including how to make reports readable and what to fix before each step, is in references/dmarc-rollout.md.

The short version: make reports readable, wait and read them, fix every legitimate sender that is failing, then tighten policy one step at a time. The cost of waiting a month is zero. The cost of guessing wrong is business mail silently going to spam.

Remediation

Per-provider fixes for each failure mode, covering the records to add and where to find them in each provider's dashboard, are in references/remediation.md.

Turning gaps into outbound

How to convert a prospect's missing or monitoring-only DMARC into a specific, non-generic cold email opener, and the framing rules that keep it honest, are in references/prospect-scoring.md.

Scoring

The audit returns a 0 to 100 readiness score weighted toward what actually blocks a rollout. Treat it as a triage signal for comparing domains, not a precise measurement. The numbered findings beneath it are the real output.

cold-email for writing the outbound itself. clay-gtm-outbound for building and enriching the prospect list. seo-audit for the equivalent audit on the web side.

1	---
2	name: domain-health
3	description: When the user wants to check email deliverability posture, domain authentication, or sending reputation for a domain. Use when the user mentions "domain health," "inbox health," "deliverability," "SPF," "DKIM," "DMARC," "email authentication," "are my emails landing in spam," "can I send from this domain," "is my domain spoofable," "warm up a domain," "check this sending domain," "DMARC rollout," "p=quarantine," "p=reject," "blacklisted," or "email going to spam." Also use before starting cold outbound from any domain, and to score prospect domains for deliverability gaps worth opening a cold email with. For writing the outbound emails themselves, see cold-email. For building the prospect list, see clay-gtm-outbound.
4	metadata:
5	version: 1.0.0
6	---
7
8	# Domain Health
9
10	Email authentication and deliverability posture for any domain, using only `dig` and the standard library. No API key, no paid tool, no per-check cost.
11
12	The same DNS primitives serve two opposite jobs, which is why they live in one skill:
13
14	Defensive. Audit a domain you own before you send from it, and before you tighten a DMARC policy. Getting this wrong silently sends your own invoices and password resets to spam.
15
16	Offensive. Score a prospect's domain to find a real, specific gap worth opening a cold email with.
17
18	## When to run it
19
20	Before starting outbound from any domain. Before changing a DMARC policy. When email is landing in spam and nobody knows why. When enriching a prospect list with a technical hook. After adding any new sending tool, because that is when sender inventory drifts.
21
22	## Modes
23
24	Audit (default) runs against domains you own.
25
26	```bash
27	python3 scripts/domain_health.py --domain example.com
28	python3 scripts/domain_health.py --domain example.com --json
29	python3 scripts/domain_health.py domains.txt
30	```
31
32	Prospect produces a CSV for list enrichment, with a `gap` column that is true when the domain's DMARC is missing or monitoring-only.
33
34	```bash
35	python3 scripts/domain_health.py --mode prospect domains.txt > signals.csv
36	```
37
38	Blacklist is opt-in via `--blacklist`. See the warning below before using it.
39
40	Mailbox verification is separate, in `scripts/verify_email.py`. It does MX plus an SMTP probe for a single address. Most networks block outbound port 25, in which case it returns `unknown` rather than guessing.
41
42	## What it checks
43
44	MX, establishing who receives mail for the domain.
45
46	SPF, including whether more than one record exists (which is a PermError and means SPF fails entirely), the qualifier the record ends in, and the count of DNS-lookup-triggering mechanisms against the limit of ten. Exceeding ten is a common and invisible failure.
47
48	DKIM, by sweeping a maintained list of per-provider selectors in `scripts/selectors.json`.
49
50	DMARC, covering policy, the separate subdomain policy, percentage, reporting addresses, and whether those reports go somewhere a human will actually read.
51
52	Sender inventory, which is the check that matters most and the reason this skill exists. It reads apex verification tokens and sending-subdomain CNAMEs to infer which providers are attached to the domain, then cross-checks each against SPF. This catches a provider verified two years ago, still able to send, never added to SPF, and invisible until the day the policy tightens.
53
54	Maturity signals, meaning MTA-STS, TLS-RPT and BIMI.
55
56	## Honesty constraints
57
58	These are load-bearing. Do not relax them, and do not let output phrasing drift past them.
59
60	DKIM absence is never claimed. Selectors are arbitrary strings and some providers use per-account random ones that cannot be guessed. A sweep that finds nothing means "no key on the selectors tried."
61
62	Verification tokens prove a relationship, not sending. A token proves the domain was verified with a provider at some point. Treat every inferred sender as a lead to confirm, never a fact. The tool separates mail-relevant signals from non-mail ones (site verification, custom web domains) precisely so the gap list stays worth reading.
63
64	A prospect's primary domain is a proxy. Teams running cold outbound properly send from a separate domain to protect the primary. Never state a finding about a prospect's primary domain as a confirmed claim about their outbound.
65
66	Blacklist results describe the provider. For any domain on hosted email, the MX addresses belong to the provider, so a listing reflects their shared infrastructure, not this domain's reputation. This is why the check is gated behind a flag and labelled in the output. Do not report it as the domain's own reputation.
67
68	## The DMARC rollout
69
70	Never raise a DMARC policy without first completing a sender inventory and reading real aggregate reports. The staged sequence, including how to make reports readable and what to fix before each step, is in `references/dmarc-rollout.md`.
71
72	The short version: make reports readable, wait and read them, fix every legitimate sender that is failing, then tighten policy one step at a time. The cost of waiting a month is zero. The cost of guessing wrong is business mail silently going to spam.
73
74	## Remediation
75
76	Per-provider fixes for each failure mode, covering the records to add and where to find them in each provider's dashboard, are in `references/remediation.md`.
77
78	## Turning gaps into outbound
79
80	How to convert a prospect's missing or monitoring-only DMARC into a specific, non-generic cold email opener, and the framing rules that keep it honest, are in `references/prospect-scoring.md`.
81
82	## Scoring
83
84	The audit returns a 0 to 100 readiness score weighted toward what actually blocks a rollout. Treat it as a triage signal for comparing domains, not a precise measurement. The numbered findings beneath it are the real output.
85
86	## Related skills
87
88	`cold-email` for writing the outbound itself. `clay-gtm-outbound` for building and enriching the prospect list. `seo-audit` for the equivalent audit on the web side.
89