/email-domain-security

name: email-domain-security
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 SPF include as a takeover lead, or writing a defensible spoofability finding for a deliverable."
version: 1.0
sources: asm_reference_impl, rfc_7208, public_research
triggers:
  - email spoofability
  - email spoofing verdict
  - is this domain spoofable
  - spoof feasibility
  - header from spoofing
  - envelope from vs header from
  - BEC feasibility
  - business email compromise feasibility
  - SPF DMARC verdict
  - DMARC enforcement
  - DMARC alignment
  - SPF supply chain
  - SPF PermError
  - SPF lookup limit
  - 10 DNS lookup limit
  - SPF void lookup
  - SPF include takeover
  - dead SPF include
  - SPF +all
  - DMARC p=none
  - DMARC p=reject
  - DMARC subdomain policy
  - duplicate DMARC record
  - email domain security
  - email authentication audit
  - phishing feasibility domain
  - spoof proof domain

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

Same posture as the companion skills: assets you own or have written authorization to assess. Everything in this skill is **passive** — reading published, public DNS TXT records that any resolver on the internet can already see — so it carries essentially zero detectability risk on its own.

But the *verdict* this skill produces is the input to a decision someone downstream might act on (an authorized phishing-simulation send, a client remediation ticket, a bug bounty report). Flag the boundary explicitly: a passive verdict of "spoofable" is a strong, defensible claim about DNS-published policy — it is not itself proof that a spoofed message was delivered. See §14.

---

2. Confidence Levels

Inherits `osint-methodology` §2's three-tier scale, mapped onto email-auth assertions specifically:

| Level | Meaning here | |---|---| | **TENTATIVE** | A mechanism in the SPF chain could not be resolved (timeout / SERVFAIL / no nameservers) — the verdict for *that mechanism* is inconclusive. See §8's transient-vs-dead discipline; never silently upgrade this to FIRM. | | **FIRM** | Record(s) present, parsed under RFC 7208 (SPF) / RFC 7489 (DMARC) grammar, verdict computed purely from directly observed TXT text. This is the ceiling for everything this skill produces on its own. | | **CONFIRMED** | The verdict was cross-checked against actual mail-flow behavior (an authorized send-and-verify test). Outside this skill's passive scope — only ever assigned after an active test someone else ran. |

**Default posture:** everything this skill outputs is at most FIRM. Never claim CONFIRMED spoofability from DNS reading