npx skills add ...
npx skills add yaklang/hack-skills --skill email-header-injection
Email header injection and spoofing playbook. Use when testing contact forms, email APIs, password reset flows, or any feature that constructs SMTP messages with user-controlled fields. Covers CRLF injection in headers, SPF/DKIM/DMARC bypass, and phishing amplification.
npx skills add yaklang/hack-skills --skill email-header-injection
AI LOAD INSTRUCTION: Expert email header injection and authentication bypass. Covers SMTP CRLF injection, SPF/DKIM/DMARC circumvention, display name spoofing, and mail client rendering abuse. Base models miss the nuance between header injection (technical) and email auth bypass (protocol-level) — this skill covers both attack surfaces.
SMTP headers are separated by CRLF (\r\n). If user input is placed into email headers without sanitization, injecting %0d%0a (or \r\n) adds arbitrary headers.
| Encoding | Payload |
|---|---|
| URL-encoded | %0d%0a |
| Double URL-encoded | %250d%250a |
| Unicode | \u000d\u000a |
| Raw CRLF | \r\n (in raw request) |
| LF only | %0a (some SMTP servers accept LF without CR) |
| Null byte + CRLF | %00%0d%0a |
A blank line (\r\n\r\n) separates headers from body in SMTP:
SPF validates the MAIL FROM envelope sender IP against DNS TXT records.
| Technique | How |
|---|---|
| Subdomain delegation | Target has include:_spf.google.com; attacker uses Google Workspace to send as anything@mail.target.com |
| Include chain abuse | v=spf1 include:third-party.com — if third-party allows broad sending |
| DNS lookup limit (10) | SPF allows max 10 DNS lookups; chains exceeding this → permerror → some receivers accept |
+all misconfiguration | v=spf1 +all allows any IP (rare but exists) |
?all or ~all | Softfail/neutral → most receivers still deliver to inbox |
| No SPF record | Domain without SPF → anyone can send as that domain |
DKIM signs specific headers with a domain key. Bypass vectors:
| Technique | How |
|---|---|
d= vs From: mismatch | DKIM signs with d=subdomain.target.com but From: ceo@target.com — valid DKIM, spoofed From |
l= tag abuse | l= limits body length signed; attacker appends content after signed portion |
| Replay attack | Capture valid DKIM-signed email, resend with modified unsigned headers |
Missing h=from | If from header not in signed headers list (h=), From can be modified |
| Key rotation window | During DKIM key rotation, old selector may still validate |
DMARC requires SPF or DKIM to align with the From: header domain.
| Technique | How |
|---|---|
Relaxed alignment (aspf=r) | SPF passes for sub.target.com, DMARC accepts for target.com |
| Organizational domain | mail.target.com aligns with target.com in relaxed mode |
| No DMARC record | Domain without DMARC → no policy enforcement |
p=none | DMARC exists but policy is none → no enforcement, just reporting |
Subdomain policy (sp=none) | Main domain p=reject but sp=none → subdomains spoofable |
Even with perfect SPF/DKIM/DMARC, display name is not authenticated:
Most email clients show only the display name in the inbox view. Mobile clients are especially vulnerable.