Email Security: SPF, DKIM, DMARC & DNS Security
BαΊ£o mαΊt Email & DNS
Email Authentication β SPF, DKIM, DMARC
Email was designed without authentication β any server can claim to send email from any domain. SPF, DKIM, and DMARC work together to close this gap. None of them alone is sufficient β all three are needed for complete email protection.
| Protocol | What It Does | DNS Record Type | Protects Against |
|---|---|---|---|
| SPF | Specifies which IP addresses are authorized to send email for your domain. Receiving server checks if the sending IP is in the SPF record. | TXT record on sender's domain | Email sent from unauthorized servers (server-level spoofing) |
| DKIM | Cryptographically signs email headers and body with the sender's private key. Receiving server verifies the signature using the public key in DNS. | TXT record (public key at selector._domainkey.domain) |
Email tampering in transit; confirms email was not modified after signing |
| DMARC | Policy that defines what to do when SPF and/or DKIM checks fail. Three policies: none (monitor), quarantine (spam folder), reject (drop). Also provides aggregate reporting. | TXT record at _dmarc.domain |
Domain spoofing β enforces SPF+DKIM and defines failure consequences |
How They Work Together
Without DMARC, SPF and DKIM results have no policy consequence β receiving servers may note the failure but still deliver the email. DMARC is what gives teeth to SPF and DKIM. The most protective setting is p=reject. Phase in from p=none (monitor) β p=quarantine β p=reject to avoid accidentally blocking legitimate email.
Other Email Security Technologies
End-to-end email encryption and digital signatures using X.509 certificates. Two separate operations:
- Encrypt: Use the RECIPIENT's PUBLIC key β only the recipient (with their private key) can decrypt
- Sign: Use the SENDER's PRIVATE key β recipient verifies with sender's public key to confirm authenticity
Alternative to S/MIME. Uses a "web of trust" model β no central CA. Users vouch for each other's public keys. Less common in enterprise (no central management), more common in open source and high-privacy communities. Same encryption/signing logic as S/MIME (public key to encrypt, private key to sign).
Sits in front of email infrastructure. Performs: spam filtering (content analysis), antivirus scanning (attachment inspection), DLP (data loss prevention β detects PII, credit card numbers in outbound email), and SPF/DKIM/DMARC validation for inbound email.
DNS Security β Attacks & Mitigations
DNS is a critical infrastructure service β poisoning it can redirect users to attacker-controlled servers without any visible indication to the user. DNS security has two separate concerns: integrity (DNSSEC) and privacy (DoH/DoT).
DNS Attacks
Inject false DNS records into a resolver's cache. Users querying that resolver receive the false IP and are redirected to an attacker's site β without knowing. DNSSEC mitigates this by signing DNS records.
Attacker modifies DNS records at the authoritative server level (e.g., by compromising registrar credentials). More severe than cache poisoning β affects all resolvers. Mitigated by registry lock, multi-factor auth on registrar accounts, and DNSSEC.
Attacker sends small DNS queries with a spoofed victim IP. DNS server sends large responses to the victim. Amplification factor up to 70x. Mitigated by BCP38 (anti-spoofing) and Response Rate Limiting (RRL) on DNS servers.
DNS Security Controls
| Control | What It Provides | Port | Does NOT Provide |
|---|---|---|---|
| DNSSEC | Cryptographic signatures on DNS records β verifies records have not been tampered with. Provides INTEGRITY. | UDP/TCP 53 (same as DNS) | Privacy β DNS queries are still visible to ISPs and network observers |
| DoH (DNS over HTTPS) | Encrypts DNS queries inside HTTPS traffic. Prevents ISP/network snooping on which domains you query. Provides PRIVACY. | TCP 443 (same as HTTPS) | Integrity β does not sign DNS record contents (DNSSEC does that) |
| DoT (DNS over TLS) | Encrypts DNS queries with TLS. Similar privacy protection to DoH but on a dedicated port. Easier to monitor/block at network level. | TCP 853 | Integrity β same limitation as DoH for record integrity |
DNSSEC = integrity (records cannot be forged/modified β cryptographic proof). DoH/DoT = privacy (queries cannot be observed in transit). They solve different problems. A complete DNS security strategy uses DNSSEC (at authoritative server) + DoH or DoT (at resolver client).
Key Terms
Sender Policy Framework β TXT record that lists authorized sending IPs for a domain. Prevents unauthorized server spoofing.
DomainKeys Identified Mail β cryptographic signature on email to verify it was sent and not modified. Uses public/private key pair.
Domain-based Message Authentication, Reporting & Conformance β policy for SPF/DKIM failures (none/quarantine/reject). Required to complete email protection.
End-to-end email encryption/signing using X.509 certificates. Encrypt with recipient's public key; sign with sender's private key.
Pretty Good Privacy β web of trust email encryption. No central CA. Same crypto principles as S/MIME.
Inject false DNS records into a resolver cache to redirect users to attacker-controlled sites.
DNS Security Extensions β cryptographic signatures on DNS records. Provides integrity (not privacy).
Encrypts DNS queries inside HTTPS on port 443. Provides privacy (not integrity). Harder for network admins to inspect/block.
Encrypts DNS queries with TLS on port 853. Provides privacy (not integrity). Easier to monitor at network level than DoH.
Inline email filtering: spam, AV scanning, DLP, SPF/DKIM/DMARC validation. Sits in front of mail server.
- DMARC builds on SPF + DKIM β all three are needed for complete email domain protection. DMARC alone does nothing without SPF and/or DKIM configured and passing.
- SPF = authorized sending IPs; DKIM = email signature (integrity); DMARC = policy enforcement (what happens when checks fail). Three separate but complementary mechanisms.
- DNSSEC = DNS record integrity (not privacy); DoH/DoT = DNS privacy (not integrity). These solve different problems. Don't confuse them on exam questions about "preventing DNS cache poisoning" (DNSSEC) vs "hiding DNS queries from ISP" (DoH/DoT).
- S/MIME: encrypt with recipient's PUBLIC key; sign with sender's PRIVATE key. This is a classic trick question. Encryption uses public key (anyone can encrypt to you, only you can decrypt). Signing uses private key (proves it came from you, anyone can verify).
- Without DMARC, SPF and DKIM failures have no policy consequence. A receiving server might note the failure in headers but still deliver the email. DMARC is what enforces rejection.
- SPF β Verify TXT record exists for company-x.com (and ts.finance, any subdomain used for email). Record must list all authorized mail servers: Google Workspace, Amazon SES (if used), any partner mail relay. Check with:
dig TXT company-x.com. Ensure SPF ends with-all(hard fail) not~all(soft fail). - DKIM β Verify signing on all outbound paths. Google Workspace DKIM signing must be enabled in Admin Console β Gmail β Authenticate Email. If Amazon SES is used for transactional email, verify DKIM is configured there too. DKIM must cover ALL outbound email paths, not just the primary mail server.
- DMARC β Phase in policy toward reject. Start with
p=none; rua=mailto:dmarc-reports@company-x.comto collect reports for 4 weeks. Review reports for legitimate email sources missing from SPF/DKIM. Then move top=quarantine, thenp=reject. - Customer-facing emails (loan approval, eSign, Partner C notifications): These must have DMARC=reject β phishing using company-x.com domain against loan customers is a critical fraud risk. High urgency.
- OTP delivery via SMS/Notification Vendor: SMS-based OTP bypasses email security entirely β no SPF/DKIM needed. But any fallback email OTP channel must go through secured mail paths with DMARC enforcement.
- DNS: Verify DNSSEC is enabled for all TS-owned domains. CloudFlare manages DNS for most TS domains β enable DNSSEC in CloudFlare dashboard (one click). This prevents DNS cache poisoning attacks against TS domains.
Practice Quiz β Email & DNS Security
Q1. DMARC policy is set to 'reject'. What happens to an email that fails both SPF and DKIM alignment?
Q2. DKIM signs an email. What does it sign, and what does it verify?
Q3. What does SPF specifically protect against (its primary threat model)?
Q4. DNSSEC vs DoH β which technology provides DNS record integrity vs DNS query privacy?
Q5. A user wants to send a confidential email to a colleague using S/MIME. Which key should they use to encrypt the message?