Key Takeaways: DNS, Email, and Web Security

A one-page reference. Reread before an exam or before moving on. Dense by design.

Email authentication: SPF / DKIM / DMARC (memorize this table)

SPF DKIM DMARC
Full name Sender Policy Framework DomainKeys Identified Mail Domain-based Message Auth, Reporting & Conformance
Authenticates Which IPs may send (envelope sender / MAIL FROM) That the message is signed & unaltered Alignment of SPF/DKIM domain with visible From:
Where it lives DNS TXT at the domain DNS TXT at selector._domainkey.domain DNS TXT at _dmarc.domain
Survives forwarding? No (new sending IP) Yes (signature travels with message) Depends on SPF/DKIM
Key knob -all (hard fail) vs ~all (soft) vs ?all (none) selector (key rotation) p=none → quarantine → reject
Stops From: spoofing alone? No No Yes (via alignment)

DMARC passes iff SPF or DKIM passes AND that domain aligns with the visible From:. Deploy order: SPF + DKIM first → DMARC p=none (LISTEN, fix your own senders) → quarantine (pct ramp) → reject. p=none provides zero protection — it only reports. The control begins at quarantine/reject.

SPF:    v=spf1 ip4:203.0.113.10 include:_spf.cloud-mail.example -all
DKIM:   selector1._domainkey.<domain>  "v=DKIM1; k=rsa; p=<pubkey>"
DMARC:  _dmarc.<domain>  "v=DMARC1; p=reject; rua=mailto:dmarc@<domain>; pct=100; adkim=s; aspf=s"

A DMARC aggregate report is two tools: an intrusion feed (who is spoofing you) and a mail-hygiene audit (which of your own senders are broken). Act on both rows.

DNS threats and defenses

Threat What it is Log signature Defense
DNS poisoning Forged answer inserted into a resolver cache Answers disagree with authoritative DNSSEC (integrity)
Typosquatting Look-alike domain registered (merid1anbank) Cousin domain in From:/queries User awareness; look-alike detection
DNS tunneling Data smuggled in subdomain labels over port 53 Long, high-entropy labels; high volume to one domain Monitoring; egress control; DoH inspection
DNS exfiltration Tunneling used to steal data Same as tunneling, sustained Same
DGA Malware generates random C2 domains Burst of NXDOMAIN responses Sinkhole; DGA scoring; monitoring
  • DNSSEC = integrity + origin auth, NOT encryption. Chain of trust: root signs DS for .tld, .tld signs DS for the zone, zone signs records (DNSKEY/RRSIG). Fails closed (SERVFAIL).
  • DNS confidentiality (hide which sites you query) = DoH / DoT, a different technology.
  • DNS sinkhole = return a controlled answer for known-bad domains → preventive (blocks callback) and detective (only infected hosts query it). Sibling of firewall default-deny, one layer earlier.
  • Most common DNS vulnerability is missing visibility — collect resolver query logs.

Email threat spectrum

Phishing Spear-phishing BEC
Targeting Mass, generic Researched individual Specific finance/process
Payload Often a link/attachment Tailored lure Often none — pure social engineering
Defeats Filters catch much Higher click rate Antivirus, URL filters, even SPF/DKIM/DMARC (if mailbox is real)
Primary defense SEG + DMARC + awareness + targeted training Out-of-band verification (process) + awareness

Secure email gateway (SEG): filters spam/malware/URLs, sandboxes attachments, rewrites URLs for click-time checking, scores BEC language. Report-phish button → SOC is the highest-leverage, lowest-cost human control. A passing DMARC result means the domain is real — not that the request is legitimate.

Web security headers checklist

Header / flag Sets Defends against
Strict-Transport-Security (HSTS) max-age=63072000; includeSubDomains; preload Protocol downgrade / SSL stripping
Content-Security-Policy (CSP) default-src 'self'; object-src 'none'; frame-ancestors 'none' Cross-site scripting (XSS), injection
X-Content-Type-Options nosniff MIME-sniffing attacks
X-Frame-Options DENY Clickjacking
Referrer-Policy strict-origin-when-cross-origin URL/token leakage
Cookie Secure — Cookie theft over plain HTTP
Cookie HttpOnly — Cookie theft via XSS (JS can't read it)
Cookie SameSite=Strict — Cross-site request forgery (CSRF)
  • HSTS needs preload to protect the first visit (max-age only applies after the first HTTPS visit). Builds on TLS (Chapter 5). CSP is highest-value and easiest to ruin ('unsafe-inline' + wildcard = worthless). Verify headers externally — they must be on every response, including errors.

Certification crosswalk

Concept CompTIA Security+ (ISC)² CISSP domain
DNS attacks / DNSSEC / sinkhole 2.0 Threats & Mitigations; 4.0 Operations Communication & Network Security
SPF / DKIM / DMARC 4.0 Security Operations; 3.0 Architecture Communication & Network Security
Phishing / spear-phishing / BEC / social engineering 2.0 Threats, Vulnerabilities & Mitigations Security & Risk Mgmt; Security Operations
Secure email gateway 3.0 Security Architecture Communication & Network Security
HTTP security headers / HSTS / secure cookies 3.0 Architecture; 4.0 Operations Software Development Security; Network Security

Project additions this chapter

  • Meridian program: email & DNS controls — SPF(-all)/DKIM/DMARC→p=reject, DNSSEC + validation, threat-intel DNS sinkhole + query logging, HTTP security-header baseline on the banking portal, report-phish button to the SOC. Feeds Chapter 13 (web app) and Chapter 30 (awareness).
  • bluekit toolkit: dnsguard.py — check_spf(record), check_dmarc(record), dga_score(name).

Common pitfalls

  • Stopping at DMARC p=none and thinking the domain is protected (it is not — only reports).
  • Jumping to p=reject without the listening phase → bouncing your own legitimate mail.
  • Thinking DNSSEC encrypts DNS (it provides integrity only; DoH/DoT encrypts).
  • Treating "SPF/DKIM/DMARC passed" as "this email is safe" (BEC from a real mailbox passes all three).
  • Not logging DNS — blind to tunneling, DGAs, and C2 callbacks.
  • A CSP with 'unsafe-inline' and wildcard sources; cookies missing HttpOnly.
  • Exceeding SPF's 10-DNS-lookup limit (silent permerror breaks SPF for all mail).