Email Security Overview
Email security is built on a foundation of DNS-based authentication protocols that work together to prevent spoofing, phishing, and other email-based attacks.
The Email Security Stack
Modern email security relies on several complementary protocols:
┌─────────────────────────────────────────┐
│ BIMI │ Brand visibility
├─────────────────────────────────────────┤
│ DMARC │ Policy & Reporting
├─────────────────────────────────────────┤
│ SPF │ DKIM │ Authentication
├─────────────────────────────────────────┤
│ MTA-STS │ TLS-RPT │ DANE │ Transport Security
├─────────────────────────────────────────┤
│ DNSSEC │ DNS Security
└─────────────────────────────────────────┘Authentication Protocols
SPF (Sender Policy Framework)
Purpose: Specifies which mail servers are authorized to send email for your domain.
How it works:
- You publish a list of authorized senders in DNS
- Receiving servers check if the sending server is on the list
- Unauthorized senders fail SPF verification
DKIM (DomainKeys Identified Mail)
Purpose: Adds a cryptographic signature to emails, proving they haven't been tampered with.
How it works:
- Your mail server signs outgoing emails with a private key
- You publish the public key in DNS
- Receiving servers verify the signature using your public key
DMARC (Domain-based Message Authentication)
Purpose: Ties SPF and DKIM together with policies and reporting.
How it works:
- You publish a policy in DNS (none, quarantine, or reject)
- Receiving servers check SPF and DKIM alignment
- Failed emails are handled according to your policy
- You receive reports about authentication results
Transport Security
MTA-STS (Mail Transfer Agent Strict Transport Security)
Purpose: Ensures email is transmitted over encrypted TLS connections.
How it works:
- You publish a policy requiring TLS
- Sending servers must use TLS to deliver email
- Prevents downgrade attacks and interception
TLS-RPT (TLS Reporting)
Purpose: Provides visibility into TLS connection failures.
How it works:
- You publish a reporting address in DNS
- Sending servers report TLS connection issues
- You receive reports to diagnose problems
DNS Security
DNSSEC (DNS Security Extensions)
Purpose: Ensures DNS responses are authentic and haven't been tampered with.
How it works:
- DNS responses are cryptographically signed
- Resolvers verify signatures before accepting responses
- Prevents DNS spoofing and cache poisoning
Brand Protection
BIMI (Brand Indicators for Message Identification)
Purpose: Displays your brand logo in email clients for authenticated messages.
How it works:
- You publish a logo URL in DNS
- Email clients display the logo for DMARC-authenticated emails
- Recipients can visually identify legitimate messages
How They Work Together
Authentication Flow
Sender Receiver
│ │
│ Send email │
│ ──────────────────────────────>│
│ │
│ Check SPF
│ (Is sender authorized?)
│ │
│ Check DKIM
│ (Is signature valid?)
│ │
│ Check DMARC
│ (Are SPF/DKIM aligned?)
│ │
│ Apply Policy
│ (none/quarantine/reject)
│ │
│ Deliver / Reject / Quarantine │
│ <──────────────────────────────│
│ │
│ Send DMARC Report │
│ <──────────────────────────────│Why All Three Matter
| Without | Risk |
|---|---|
| SPF | Anyone can send email claiming to be from your domain |
| DKIM | Emails can be modified in transit without detection |
| DMARC | No policy enforcement, no visibility into attacks |
Implementation Priority
If you're starting from scratch, implement in this order:
- SPF - Quick to set up, immediate protection
- DKIM - Requires mail server configuration
- DMARC - Start with
p=nonefor monitoring - TLS-RPT - Simple DNS record
- MTA-STS - More complex setup
- DNSSEC - Enable at registrar
- BIMI - After DMARC is at
p=quarantineor higher
Common Misconceptions
"SPF alone is enough"
SPF only checks the envelope sender, not the visible From header. Attackers can still spoof the From header while passing SPF.
"DKIM guarantees the sender"
DKIM only proves the email wasn't modified and came from a domain—not necessarily your domain. DMARC provides alignment.
"p=none means no protection"
DMARC p=none enables monitoring but doesn't enforce anything. It's a starting point, not the goal.
"Email security is too complex"
Each protocol serves a specific purpose. Implement them progressively, and tools like MailShield simplify monitoring.