PostureCheck MCP
# PostureCheck MCP
Domain security checks for MCP-capable assistants — SPF, DKIM, DMARC, MTA-STS, TLS certificates and protocol support, and HTTP security headers.
An assistant can explain what DMARC is perfectly well. What it can't do is tell you whether *your* domain has it — that needs a live DNS lookup. This fills that gap.
```
> Is example.com protected against email spoofing?
[PASS] SPF: SPF record found
[FAIL] SPF policy: ~all (softfail — consider upgrading to -all)
[PASS] DKIM: DKIM found (selector: google), 2048-bit
[PASS] DMARC: DMARC record found
DMARC policy: p=none (monitoring only — provides no protection against spoofing)
```
## Install
No installation needed — it runs via `npx`.
### Claude Desktop
Add to `claude_desktop_config.json`:
```json
{
"mcpServers": {
"posturecheck": {
"command": "npx",
"args": ["-y", "posturecheck-mcp"]
}
}
}
```
On macOS that file lives at `~/Library/Application Support/Claude/claude_desktop_config.json`.
### Cursor, Cline, Windsurf and others
Same shape, in whichever config file that client uses:
```json
{
"mcpServers": {
"posturecheck": {
"command": "npx",
"args": ["-y", "posturecheck-mcp"]
}
}
}
```
Restart the client afterwards.
## Tools
### `scan_domain`
Full posture check in one call. Email authentication, TLS, and HTTP security headers, with an overall score.
Useful for: *"Is acme.com configured securely?"*, *"Can anyone spoof email from our domain?"*, *"Review the security of these five domains."*
### `check_tls`
TLS detail. Certificate validity, expiry, issuer, key strength, the full chain, and — importantly — **which protocol versions the server actually accepts**, tested with a separate handshake per version.
That last point matters. Most tools report the protocol that got negotiated, which is always the best one both sides support. Whether TLS 1.0 is *still enabled* is a different question, and it's the one a PCI DSS assessor asks.
Useful for: *"Which TLS versions does example.com accept?"*, *"When does this certificate expire?"*, *"Why does this site work in my browser but fail in curl?"*
### `analyse_spf`
Resolves the complete SPF include tree, counts DNS lookups against the RFC 7208 limit of 10, and names the services authorised to send mail.
SPF silently fails with a PermError above 10 lookups, and nested includes make the count hard to eyeball — a record with five includes can easily be at eleven.
Useful for: *"Why is our SPF failing?"*, *"How many DNS lookups is our SPF using?"*, *"Which services can send mail as our domain?"*
## What it checks
**Email** — SPF presence and policy, DNS lookup count, DKIM key detection and strength, DMARC policy and reporting address, MTA-STS.
**TLS** — certificate validity, expiry, issuer, key type and size, hostname coverage, full chain with missing-intermediate detection, protocol support for TLS 1.0 through 1.3, forward secrecy, CAA records.
**HTTP** — HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy.
## Notes
Checks read publicly published DNS records and make standard HTTPS connections — the same information any browser or mail server receives. Nothing is probed, exploited, or accessed beyond that. See the [scanning policy](https://posturecheck.io/scanning).
Results are not stored. There is no account and no API key.
Requests are rate limited. If you're scanning a large number of domains you'll be throttled; space them out.
Results reflect externally observable configuration only. A good score doesn't mean a domain is secure — it means the things visible from the public internet are configured sensibly.
## Configuration
| Variable | Default | Purpose |
|---|---|---|
| `POSTURECHECK_API` | `https://posturecheck.io` | Point at a different instance |
## Links
- [posturecheck.io](https://posturecheck.io) — web interface
- [Methodology](https://posturecheck.io/how-it-works) — what each check does and which standard it's based on
- [EU Domain Security Survey 2026](https://posturecheck.io/research) — 12,905 domains across 26 countries
## Licence
MIT
TDQS
Scored across 3 tools
The tools share a common domain, but scan_domain is clearly a broad assessment while check_tls and analyse_spf are deep dives. Overlap exists, but the descriptions effectively guide selection for specific use cases.
All tools use a consistent verb_noun pattern with snake_case (scan_domain, check_tls, analyse_spf). The verbs differ but the structure is uniform and predictable.
Three tools is lean but appropriate for the narrow scope of domain security posture. It avoids bloat, though a few more specialized tools (e.g., for DKIM/DMARC) could round out the set.
The broad scan_domain covers email and web security comprehensively, while check_tls and analyse_spf provide deep dives for two key areas. Missing are specialized deep dives for DKIM and DMARC, but those are still accessible through scan_domain, so it's a minor gap.