Appearance
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; lists your authorized senders
- DKIM: requires mail server or provider configuration
- DMARC: start with
p=noneto get reports, then move to enforcement - TLS-RPT: a single DNS record
- MTA-STS: a DNS record plus a policy file
- DNSSEC: enable at your DNS provider and registrar
- BIMI: once DMARC is at
p=quarantineor higher
SPF and DKIM on their own don't stop spoofing of your From address. Protection starts when DMARC is at p=quarantine or p=reject.
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 was signed by some domain, not necessarily yours. DMARC checks that the signing domain matches your From domain.
"p=none protects my domain"
It doesn't. DMARC p=none only turns on reporting: receivers still deliver mail that fails. It's the right starting point, but spoofed mail is only stopped at p=quarantine or p=reject.
"Email security is too complex"
Each protocol serves a specific purpose. Implement them progressively, and tools like MailShield simplify monitoring.
Parked Domains
Not all domains receive email. For domains that don't accept incoming mail (brand protection, typosquatting prevention, website-only domains), you should configure them as parked domains to prevent abuse.