Email Domain Security
Rigorous, defensible email-spoofability verdict and SPF supply-chain risk analysis...
Install
npx skills add elementalsouls/Claude-OSINT --skill email-domain-security -g -a claude-code -y- Repository
- elementalsouls/Claude-OSINT2.9k
- Category
- Security
- Updated
- 15d ago
- License
- MIT
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
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
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 owndig) 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 TOliveness 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.
