# Email Domain Security

Rigorous, defensible email-spoofability verdict and SPF supply-chain risk analysis...

- Repository: https://github.com/elementalsouls/Claude-OSINT (2943 stars)
- Category: Security
- License: MIT
- Last updated: 2026-10-20
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add elementalsouls/Claude-OSINT --skill email-domain-security -g -a claude-code -y`
Codex: `npx skills add elementalsouls/Claude-OSINT --skill email-domain-security -g -a codex -y`
Cursor: `npx skills add elementalsouls/Claude-OSINT --skill email-domain-security -g -a cursor -y`
Gemini CLI: `npx skills add elementalsouls/Claude-OSINT --skill email-domain-security -g -a gemini-cli -y`

## Description

Rigorous, defensible email-spoofability verdict and SPF supply-chain risk analysis computed from published DNS alone. Deepens the record-level SPF/DMARC/DKIM/BIMI/MTA-STS/DNSSEC fetch recipes in the offensive-osint arsenal (§16.14) with the reasoning that section doesn't do: a priority-ordered composite verdict for whether an attacker can actually land header-From-spoofed mail in an inbox, and by which vector (exact-domain vs subdomain), grounded in the single most-misunderstood distinction in email security: the envelope MAIL FROM that SPF authenticates vs the visible header From: that only DMARC governs. Explains precisely why SPF -all/~all alone is NOT spoof-proof without DMARC enforcement, and why SPF +all bypasses DMARC even under p=reject pct=100. Covers RFC 7208 §4.6.4's 10-DNS-lookup / 2-void-lookup PermError fail-open condition with a runnable stdlib-only lookup-counter script, plus the SPF-include-takeover supply-chain vector (an attacker re-registering a dead include inherits SPF-pass authority over the victim domain) with strict transient-vs-NXDOMAIN discrimination discipline so a temporary SERVFAIL is never mistaken for a takeover lead. Fully passive: DNS TXT reads only, no mail sent, no RCPT TO probe, no API keys. Use when auditing a domain's real spoofing resistance (not just its published records), explaining to a client why 'we have SPF -all' does not mean they're covered, investigating an SPF PermError or an unusually long include chain, evaluating a dead S

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Email Domain Security, Spoofability Verdict & SPF Supply-Chain Analysis

> Companion skills: **`offensive-osint` §16.14** (raw record-fetch recipes, dig/PowerShell one-liners for SPF/DMARC/DKIM/BIMI/MTA-STS/TLS-RPT/DNSSEC/CAA, the MX→IdP inference table, the DMARC reporting-vendor table). **`osint-methodology`** (confidence levels, output format, severity rubric this skill inherits). Fetch the records with §16.14 first; bring the raw TXT text here for the verdict. This skill does not re-list what a record *is*, it reasons about what a domain's *combination* of records actually lets an attacker do.

## 0. When to Use / When NOT

**Use this skill when:**

- Asked to audit spoof feasibility, produce an email-spoofability verdict, or explain "is domain X spoofable."
- You already have raw SPF/DMARC TXT text (via `offensive-osint` §16.14 or your own `dig`) and need the *verdict*, not just the record dump.
- Investigating an SPF PermError, a long or unusual include chain, or a dead `include:` target.
- Writing a client-facing finding that has to survive the pushback "we have SPF `-all`, why is this flagged?"
- Reasoning about DMARC subdomain policy inheritance, `pct=` partial enforcement, or duplicate-record handling.

**Do NOT use this skill when:**

- You haven't fetched the raw records yet. Run `offensive-osint` §16.14's dig/PowerShell recipes first, then bring the text here.
- You want to actually *send* a spoofed test message or run an SMTP `RCPT TO` liveness check. That is active engagement work requiring explicit authorization and is out of scope for this passive-DNS skill, see §14.
- You're auditing TLS/cert posture rather than email auth, that's `offensive-osint` §16.15 / TLS deep audit territory.
- You need AXFR / zone-transfer analysis. `dns_deep`-class modules run that check alongside the email-auth sweep, but it's a distinct DNS finding (open zone transfer, unrelated to spoofability), see the note in §9.

---

## 1. Scope & Authorization Posture

The rest: https://github.com/elementalsouls/Claude-OSINT/blob/HEAD/skills/email-domain-security/SKILL.md