EMAIL GUARD

Check the mail before your agent acts on it.

Once an agent reads and sends email, the inbox becomes an attack surface. An incoming message can hijack the agent with instructions hidden in the body, spoof a sender it trusts, or bait it into a phishing link. On the way out, an agent can leak a secret or torch its own sending domain. Email Guard is the deterministic check for both directions: no LLM, so it can't be talked out of its verdict by the email it's scanning.

FreeDeterministic, no LLMSPF / DKIM / DMARC / RDAPHTTP + MCP

Try it

verdict appears here…

The endpoints

EndpointWhat it does
POST /api/scan-inboundThe guard. Before the agent acts on a message: prompt injection and hijack instructions (including zero-width, bidi, and hidden-HTML payloads), spoofed senders (SPF/DKIM/DMARC failures, reply-to mismatch, disposable or brand-new domains), risky links → verdict allow / review / block plus clean structured metadata
POST /api/scan-outboundBefore the agent sends: leaked secrets and PII (with a redacted copy), deliverability problems that burn the sender domain, dead recipients (disposable, or no MX = guaranteed bounce)
GET /api/check-domain-authSPF, DMARC, MX, domain age (RDAP), and disposable status for any domain or address → weak / enforced

Use it from an agent (MCP)

{ "mcpServers": { "email-guard": { "command": "npx", "args": ["-y", "email-guard-mcp"] } } }

Or call the HTTP endpoints directly — JSON in, JSON out, CORS open. OpenAPI spec.

Why structured metadata matters

The dangerous move is letting an agent reason over the raw body of a hostile email — that's exactly where the injection lives. scan-inbound returns the verdict and safe structured facts (sender, auth results, domain age, link analysis), so the agent can decide what to do without re-reading the attack. Data sources are all free and public: DNS, RDAP, disposable-domain lists, curated injection and secret rulesets.