Email Security: How to Lock Down Your Most Attacked Surface

In 2024, the FBI's Internet Crime Complaint Center (IC3) recorded $2.9 billion in losses from Business Email Compromise (BEC) alone. Not all cybercrime — just one attack category that flows entirely through email. Adding ransomware (which most commonly arrives via phishing emails), credential theft, account takeover, and wire fraud, email is responsible for the majority of financial losses from cybercrime in the United States by a wide margin.

The underlying reason email is so exploitable is architectural: SMTP, the protocol that carries email, was designed in 1982 for a network of trusted academic and military nodes. It has no built-in sender authentication. Anyone with access to an SMTP server can send an email claiming to be from any address. For 42 years, this design decision has been papered over with increasingly complex authentication standards — none of which are universally deployed.

This guide covers those authentication standards in enough detail to implement them correctly, how to read email headers to detect spoofing, the specific attack patterns that cost organizations the most money, and the technical controls that actually stop them.

Why Email Authentication Matters: The SMTP Problem

Here's the root issue in concrete terms. Open a terminal, install a mail client like swaks, and run:

# Install swaks
apt-get install swaks
 
# Send a spoofed email (replace with test addresses)
swaks \
  --to target@example.com \
  --from ceo@yourcompany.com \
  --server mail.yourcompany.com \
  --header "Subject: Urgent Wire Transfer Request"

Without authentication controls, this works. The receiving server accepts the message and delivers it to the inbox with the "From: ceo@yourcompany.com" displayed to the user. The CEO never sent it. There was no security control preventing it.

SPF, DKIM, and DMARC are the three-layer authentication stack that closes this gap. Each layer addresses a different aspect of the problem. Implementing all three correctly is what moves you from "attackers can trivially spoof your domain" to "DMARC at p=reject means spoofed emails claiming your domain are discarded at the receiving server before they reach any inbox."

SPF: Authorizing Your Sending Infrastructure

Sender Policy Framework is a DNS TXT record that defines which IP addresses and mail servers are authorized to send email claiming to be from your domain. When a receiving mail server accepts a message claiming to be from yourcompany.com, it looks up the SPF record and checks whether the connecting server's IP is listed.

Reading and Writing SPF Records

An SPF record in DNS looks like this:

v=spf1 ip4:203.0.113.10 ip4:198.51.100.0/24 include:_spf.google.com include:sendgrid.net -all

Every component has a specific meaning:

• v=spf1 — SPF version identifier. Required. Must be first.
• ip4:203.0.113.10 — explicitly authorize a single IPv4 address (your on-premises mail server)
• ip4:198.51.100.0/24 — authorize an entire /24 subnet (all IPs in that range)
• ip6:2001:db8::/32 — authorize an IPv6 range (same format as ip4)
• include:_spf.google.com — include Google Workspace's authorized sending IPs (for orgs using Gmail for business email)
• include:sendgrid.net — include SendGrid's IPs for transactional email
• -all — hard fail: reject mail from any sender not covered above

The qualifier before all is the critical decision:

| Qualifier | Name | Effect on Non-Matching Senders | |-----------|------|-------------------------------| | +all | Pass | Allow everyone — do not use | | ?all | Neutral | No assertion — do not use | | ~all | Softfail | Mark suspicious but accept | | -all | Hard fail | Reject (or treat as reject) |

Use -all in production. The common mistake of using ~all (softfail) creates an SPF record that looks like it's doing something while providing minimal actual protection — most receiving servers treat softfail as a pass and deliver the message anyway. The only legitimate reason to use ~all is during initial deployment when you haven't yet inventoried all legitimate sending sources.

How to Inventory Your Sending Sources

Before deploying SPF with -all, you need to know every IP address and service that legitimately sends mail claiming your domain. Missing a legitimate sender causes mail delivery failures. Missing sources typically include:

• Your primary email provider (Google Workspace, Microsoft 365, on-premises Exchange)
• Transactional email services (SendGrid, Mailchimp, Mailgun, AWS SES, Postmark)
• Marketing automation platforms (HubSpot, Salesforce Marketing Cloud, Marketo)
• CRM systems that send emails (Salesforce, Dynamics)
• Alerting systems (PagerDuty, OpsGenie, monitoring tools)
• HR systems, accounting software, and business applications with email notification features
• Legacy systems and custom applications

Practical inventory method:

1. Set DMARC to p=none first and collect aggregate reports for 2-4 weeks (covered below)
2. The aggregate reports list every IP address that sends mail claiming your domain, with SPF and DKIM pass/fail rates
3. Use that data to build your complete SPF record

This is the correct order: DMARC reports first, then SPF enforcement.

The 10-Lookup Limit: A Common Breaking Point

RFC 7208 caps SPF processing at 10 DNS lookups. Each include:, a:, mx:, and ptr: mechanism in your record counts as one lookup, and included records can nest further lookups. An organization using Google Workspace, SendGrid, and three SaaS platforms can easily exceed 10 lookups.

When an SPF record exceeds 10 lookups, the record returns a permerror — which many receivers treat as a fail, causing legitimate mail to bounce.

Diagnosis:

# Check how many lookups your SPF record requires
dig TXT yourcompany.com | grep v=spf
 
# Use a dedicated SPF lookup counter tool
# Multiple online tools exist: mxtoolbox.com/spf.aspx, dmarcian.com/spf-survey/

Fix: "SPF flattening" — replacing include: directives with the underlying IP ranges:

# Find the actual IPs behind an include
dig TXT _spf.google.com
 
# Result shows nested includes — follow each recursively
dig TXT _netblocks.google.com
dig TXT _netblocks2.google.com
dig TXT _netblocks3.google.com

Replace the include: directives with the IP ranges directly. This eliminates lookup overhead. The downside: when the third-party service changes their IP ranges, your flattened record becomes outdated. Services like dmarcian's SPF Flattener and EasyDMARC's SPF Generator can automate this maintenance.

Null SPF for Non-Sending Domains

Every domain and subdomain you own that doesn't send email should have an explicit null SPF record:

v=spf1 -all

This tells receiving servers: "We explicitly send no email from this domain. Reject anything claiming to be from it." Without this, an attacker can spoof your parked domains and subdomains — which often have no SPF record at all, meaning receiving servers have no information to make a rejection decision.

Parked domains you own, legacy domains from past brand names, and unused subdomains should all have v=spf1 -all published.

DKIM: Cryptographic Signature Verification

SPF verifies which servers can send from your domain. It doesn't verify that a message wasn't modified in transit, and it breaks when mail is forwarded (because the forwarder's IP address isn't in the original domain's SPF record).

DomainKeys Identified Mail solves both problems. The sending server signs outgoing messages with a private key using public-key cryptography. The public key is published in DNS. Any receiving server can verify the signature regardless of how many hops the message made.

The DKIM Public Key Record

DKIM public keys live in DNS at a specific location: selector._domainkey.yourdomain.com

# Example DKIM DNS record
default._domainkey.yourcompany.com  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2D..."

Breaking down the record:

• default is the selector — an arbitrary string that identifies which key to use. You can have multiple selectors simultaneously, which enables key rotation.
• v=DKIM1 — version identifier
• k=rsa — key algorithm (RSA). Ed25519 (k=ed25519) is the modern alternative — smaller keys, faster verification, equivalent security to RSA-3072.
• p= — the base64-encoded public key material. The private key is held by your mail server.

Verifying your DKIM record is working:

# Query the DKIM record
dig TXT default._domainkey.yourcompany.com
 
# Send a test email and check the Authentication-Results header
# Look for: dkim=pass header.d=yourcompany.com
 
# Using swaks to test:
swaks --to test@example.com --from you@yourcompany.com --server smtp.yourcompany.com --auth LOGIN
 
# Check DKIM validation using an online tool or with Python:
python3 -c "
import dkim
with open('email.eml', 'rb') as f:
    d = dkim.DKIM(f.read())
    print('Valid:', d.verify())
"

What DKIM Signs and What It Doesn't

The DKIM signature covers:

• Specific email headers you configure (mandatory: From; recommended: Subject, Date, To, MIME-Version)
• Optionally the message body (using a hash of the body content)

The signature does NOT cover headers not listed in the h= field of the signature. This matters because attackers can add headers that DKIM doesn't cover — including a second From: header that email clients may display instead of the signed one (a technique called "header shadowing" or "multi-From" attacks).

Key Rotation

DKIM private keys should be rotated at minimum annually. The process:

1. Generate a new RSA-2048 or Ed25519 key pair
2. Add the new public key to DNS under a new selector name: 20260101._domainkey.yourcompany.com
3. Configure your mail server to sign new messages with the new key
4. Allow time for the new key to be cached (24-48 hours)
5. Verify new messages are signing with the new selector
6. Remove the old selector from DNS

# Generate RSA-2048 DKIM key pair
openssl genrsa -out dkim_private.pem 2048
openssl rsa -in dkim_private.pem -out dkim_public.pem -pubout
 
# Extract the public key in base64 for the DNS TXT record
openssl rsa -in dkim_private.pem -pubout -outform der 2>/dev/null | base64 | tr -d '\n'
 
# Generate Ed25519 key pair (smaller, faster, modern)
openssl genpkey -algorithm ed25519 -out ed25519_private.pem
openssl pkey -in ed25519_private.pem -pubout -outform der | base64 | tr -d '\n'

RSA-1024 DKIM keys are considered broken — don't use them. RSA-2048 is the minimum acceptable. Ed25519 is preferred for new deployments.

If a DKIM private key is ever compromised or suspected compromised, rotate immediately: generate new keys, update DNS, reconfigure the mail server, and remove the old selector record.

DMARC: Policy Enforcement and Reporting

SPF and DKIM each independently verify aspects of sender identity. But neither tells receiving servers what to do with messages that fail verification. DMARC adds two critical capabilities: a policy that tells receivers what to do when authentication fails, and an aggregate reporting mechanism that tells you what's happening to your mail in the wild.

The DMARC Record

_dmarc.yourcompany.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourcompany.com; ruf=mailto:dmarc-forensics@yourcompany.com; sp=reject; adkim=s; aspf=s; pct=100; fo=1"

Every field:

• v=DMARC1 — DMARC version identifier
• p=reject — Policy: what to do with mail that fails DMARC alignment. Options:
  • p=none — take no action, only report (monitoring mode)
  • p=quarantine — deliver to spam/junk folder
  • p=reject — reject the message before delivery (the strongest and correct enforcement)
• rua=mailto:dmarc-reports@yourcompany.com — aggregate report destination. You receive daily XML reports from participating receivers summarizing SPF/DKIM pass rates by sending source. If you don't want to parse XML yourself, use a DMARC reporting service (covered below) and point rua to their address.
• ruf=mailto:dmarc-forensics@yourcompany.com — forensic report destination. You receive redacted copies of specific failing messages. Not universally supported by receivers. Optional.
• sp=reject — policy for subdomains. If omitted, subdomains inherit the p= value. Explicitly set this to reject to prevent subdomain spoofing.
• adkim=s — DKIM alignment mode:
  • s (strict): the d= domain in the DKIM signature must exactly match the From: header domain
  • r (relaxed): organizational domain matching — mail.yourcompany.com matches yourcompany.com
• aspf=s — SPF alignment mode (same strict/relaxed distinction)
• pct=100 — percentage of failing mail to apply the policy to. Used for gradual rollout (start at pct=10, increase over time). pct=100 applies the policy to all failing mail.
• fo=1 — forensic report generation:
  • 0: generate report only if both SPF and DKIM fail (default)
  • 1: generate report if either SPF or DKIM fails
  • d: generate report if DKIM fails
  • s: generate report if SPF fails

The Alignment Concept: Why DMARC Closes the Gap

This is the most important concept in DMARC. Without alignment, an attacker can:

1. Send email from attacker.com (which passes SPF for attacker.com)
2. Set the visible From: header to ceo@yourcompany.com
3. The SPF check passes (for attacker.com), but the displayed sender is your domain

DMARC alignment requires that the domain passing SPF or DKIM matches the From: header domain. In the scenario above:

• The SPF check passes for attacker.com — but attacker.com doesn't match yourcompany.com in the From: header, so DMARC alignment fails
• No DKIM signature from yourcompany.com is present, so DKIM alignment also fails
• With p=reject, the receiving server rejects the message

This is why DMARC without alignment is incomplete, and why deploying SPF and DKIM without DMARC leaves you partially protected. The alignment check is what ties the authentication mechanisms to the visible sender.

Deploying DMARC Without Breaking Mail: The Safe Rollout Process

Rushing to p=reject without understanding your mail flows will cause legitimate mail to be silently rejected. The correct approach:

Phase 1 — Monitoring (2-4 weeks):

_dmarc.yourcompany.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com; pct=100"

Aggregate reports start arriving within 24 hours. Each report is an XML file listing:

• Sending IP addresses
• SPF pass/fail for each source
• DKIM pass/fail for each source
• Volume of mail from each source

Phase 2 — Analyze reports:

Parse DMARC aggregate reports using:

• parsedmarc (Python CLI, open source): pip install parsedmarc && parsedmarc report.xml
• DMARC reporting services (interpret reports in a dashboard without DIY parsing): Dmarcian ($20-$150/month), Postmark DMARC ($14/month), Valimail Monitor (free tier), EasyDMARC (free tier)

From the reports, identify:

• All legitimate sending sources (your mail servers, your SaaS platforms)
• Their SPF and DKIM pass rates
• Any unauthorized senders claiming your domain

Phase 3 — Remediate failures:

For each legitimate source with DKIM failures:

• Verify DKIM is correctly configured on that sending service
• Check that the From: domain in the sending service matches the domain in the DKIM signature

For each legitimate source with SPF failures:

• Add the service's IP ranges or include: to your SPF record

Phase 4 — Quarantine (1-2 weeks):

_dmarc.yourcompany.com  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com; pct=25"

Start at pct=25 — apply quarantine to 25% of failing messages, monitor for legitimate mail landing in spam. Increase to pct=100 over a week or two if no issues appear.

Phase 5 — Reject (ongoing):

_dmarc.yourcompany.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com; sp=reject; adkim=s; aspf=s; pct=100"

p=reject at pct=100 is the final target. At this point, spoofed emails claiming your domain are rejected at the receiving mail server before any user sees them.

This rollout typically takes 4-8 weeks for organizations with simple mail environments and 2-4 months for enterprises with complex multi-vendor mail stacks.

Reading Email Headers: The Forensic Layer

Every email contains headers that tell the full story of how it traveled from sender to recipient. These headers are hidden by default in every mail client but accessible on demand.

How to View Full Headers

Gmail: Open the email → three-dot menu → "Show original" Outlook: File → Properties → Internet headers (for specific message); or View → Options for older versions Apple Mail: View → Message → All Headers (or Command+Shift+H) Thunderbird: View → Headers → All

Header Analysis: A Real Example

Received: from compromised-server.evil.com (93.184.216.34)
  by mx.yourcompany.com with ESMTPS id abc123
  Mon, 03 Mar 2026 09:15:32 +0000

Received: from mail.yourcompany.com (198.51.100.10)
  by compromised-server.evil.com
  Mon, 03 Mar 2026 09:14:15 +0000

Authentication-Results: mx.yourcompany.com;
  dkim=fail (signature verification failed) header.d=yourcompany.com;
  spf=fail smtp.mailfrom=no-reply@yourcompany.com smtp.helo=evil.com;
  dmarc=fail (p=REJECT) header.from=yourcompany.com

From: "Finance Department" <no-reply@yourcompany.com>
Reply-To: payment@attacker-domain.com
Subject: Updated wire transfer instructions - URGENT
Date: Mon, 03 Mar 2026 09:14:00 +0000
Message-ID: <fake-id@evil.com>

Reading this from bottom to top (headers are added in reverse chronological order):

1. The Received: chain: Read these bottom to top. The first (bottom) Received header is where the message originated; the last (top) is your server accepting it. The originating server here is compromised-server.evil.com (93.184.216.34) — clearly not a legitimate yourcompany.com server.

2. Authentication-Results:: This is the critical field — your server's verdict.

   • dkim=fail — the DKIM signature was present but verification failed (the message was modified, or the signature was forged)
   • spf=fail — the sending IP isn't in yourcompany.com's SPF record
   • dmarc=fail (p=REJECT) — with your DMARC policy at reject, this message should have been rejected before delivery. If you're seeing it in your inbox, either your DMARC policy is p=none or p=quarantine, or your mail gateway isn't enforcing DMARC correctly.

3. Reply-To: diverges from From:: This is a classic Business Email Compromise setup. The displayed sender is no-reply@yourcompany.com (which DMARC should block when at reject). But even if DMARC isn't enforced, the Reply-To header sends responses to payment@attacker-domain.com. A user who replies or clicks "pay this invoice" is sending to the attacker.

4. Message-ID: domain mismatch: The Message-ID contains @evil.com while the From shows @yourcompany.com. Legitimate mail has Message-IDs matching the sending domain.

Identifying Legitimate vs. Spoofed Mail

A legitimate email from yourcompany.com looks like:

Authentication-Results: mx.recipient.com;
  dkim=pass header.d=yourcompany.com header.s=20240101 header.b=ABC123;
  spf=pass smtp.mailfrom=yourcompany.com smtp.helo=mail.yourcompany.com;
  dmarc=pass (p=reject) header.from=yourcompany.com

All three pass, and the dmarc=pass confirms alignment — the DKIM or SPF domain matches the From header domain.

Free tools for header analysis:

• MXToolbox Email Header Analyzer: mxtoolbox.com/EmailHeaders.aspx
• Google Admin Toolbox Messageheader: toolbox.googleapps.com/apps/messageheader/
• Mail Header Analyzer by Isaac Sukin: isaacsukin.com/news/email-header-analyzer

# Python for programmatic header analysis using the 'mail-parser' library
import mailparser
 
mail = mailparser.parse_from_file('suspicious_email.eml')
print("From:", mail.from_)
print("Reply-To:", mail.reply_to)
print("Authentication-Results:", mail.headers.get('Authentication-Results', 'Not present'))
print("Received chain:")
for received in mail.received:
    print(" -", received)

Business Email Compromise: The Highest-Dollar Attack

BEC is the attack category where email security failures translate most directly into dollar losses. The FBI IC3 reports $2.9 billion in 2024 losses in the United States alone — a figure that almost certainly understates actual losses due to underreporting.

BEC attacks differ from mass phishing in two ways: they're highly targeted (one attacker against one target organization) and they often involve no malware at all. The attacker's tool is a convincing email and knowledge of organizational context.

CEO Fraud / Executive Impersonation

An email appears to come from the CEO, CFO, or a board member. It instructs a finance team member to execute an urgent wire transfer — typically with a reason that sounds plausible (confidential M&A activity, regulatory settlement, emergency supplier payment) and explicit instructions to keep it confidential and process it outside normal channels.

The social engineering succeeds because:

• Authority: the email appears to come from someone with legitimate authority to authorize transfers
• Urgency: the "urgent" framing bypasses normal deliberation
• Secrecy: "keep this confidential" is designed to prevent the target from consulting colleagues who might raise doubts
• Context: sophisticated attackers research the organization beforehand — they know the CEO's name, the organization's financial software, the names of finance staff

Real case: In 2019, Toyota Boshoku Corporation lost approximately $37 million in a BEC attack where an attacker impersonating a business partner (using a compromised email account) convinced finance personnel to change bank account details for a legitimate payment. The money was transferred before the fraud was detected.

Real case: In 2016, Ucraniann hackers compromised a business email account and redirected $101 million in wire transfers from Bangladeshi central bank to accounts in the Philippines, Sri Lanka, and the United States. $81 million was successfully laundered. The attack exploited SWIFT banking network authentication alongside email social engineering.

Vendor Payment Fraud

The attacker monitors email conversations between a company and a vendor — either through a compromised email account or through social engineering that reveals payment patterns. At an opportune moment (just before a large payment is due), the attacker sends an email appearing to come from the vendor requesting that the payment be sent to a new bank account.

This attack is particularly insidious because:

• The email context is accurate (the attacker knows about the legitimate relationship and the pending payment)
• The request is not unusual (vendors sometimes legitimately change banking details)
• The attacker often registers a lookalike domain — vendor-corp.com vs. vendorcorp.com, vendor.corp.com vs. vendorcorp.com — making the email address look nearly identical

Real case: In 2021, the City of Tucson, Arizona, lost $1.2 million to a vendor impersonation BEC attack. The attacker sent a fake banking change notification for a legitimate contractor, intercepting a scheduled payment.

Payroll Diversion

The attacker identifies HR or payroll personnel through LinkedIn, then contacts them by email impersonating an employee. The request: change my direct deposit account before the next payroll run. The attacker provides a routing and account number they control.

This attack targets payroll systems during the narrow window before payroll processing. If successful, the employee doesn't discover the fraud until they don't receive their paycheck.

BEC Defense Architecture

The procedural defense is more important than the technical defense:

Out-of-band verification is non-negotiable: Any wire transfer request, banking change, or payment redirect that arrives via email must be verified through a phone call to a number from your verified internal directory or supplier list — never a number provided in the email. This single procedural control defeats almost all BEC attacks.

Dual authorization for financial transactions: No single person should be able to authorize a wire transfer above a threshold (commonly $5,000-$25,000 depending on organization size) without a second approval from a separate individual through a separate channel. This turns the attacker's single social engineering target into multiple simultaneous targets — exponentially harder.

Lookalike domain monitoring: Register common variations of your domain name yourself (youcompany.com, your-company.com, yourcompany.net). Monitor for newly registered lookalike domains using services like Brand Monitor, PhishLabs, or CSC's DomainSense — attackers register these domains days before the attack. A real-time alert when someone registers yourcornpany.com gives you time to prepare defenses.

DMARC at p=reject: Eliminates spoofed email claiming your exact domain. Note: this doesn't stop lookalike domain attacks — attacker-corp.com can have perfectly valid SPF, DKIM, and DMARC for its own domain. DMARC protects your domain from being spoofed; it doesn't protect against email from convincingly named lookalike domains.

Mail gateway impersonation detection: Enterprise mail gateways (Proofpoint, Mimecast, Microsoft Defender for Office 365) include features that detect display name spoofing (where the visible name is "CEO Name" but the actual email address is external), lookalike domain detection, and BEC pattern recognition. These are not foolproof but catch many automated BEC attempts.

Anti-Phishing Controls by Sophistication Level

Not all organizations have the same resources or threat exposure. Here's the control stack organized by tier.

Tier 1: Free Controls (Any Organization)

SPF + DKIM + DMARC at p=reject: Zero cost beyond implementation time. Prevents direct domain spoofing. Takes 4-8 weeks to implement correctly.

MFA on all email accounts: Google Workspace and Microsoft 365 both include MFA at no additional cost. Prevents account takeover even when credentials are phished. Enable it for every user.

Disable legacy authentication: IMAP, POP3, and Basic Auth bypass MFA entirely. If you're using Google Workspace or Microsoft 365, disable these protocols for all users unless there's a documented specific requirement.

# Google Workspace: Admin Console → Security → Access and data control → API Controls → Third-party app access
# Disable "Trust internal, domain-owned apps" and require OAuth only

# Microsoft 365: Via Conditional Access (E5 or Defender) or basic auth block policies (all tiers):
# Azure AD → Conditional Access → New policy → Grant (Block) for all legacy auth apps

BIMI (Brand Indicators for Message Identification): Once DMARC is at reject, BIMI allows your organization's logo to appear in supporting email clients (Gmail, Outlook 2025, iOS Mail) alongside authenticated emails from your domain. Requires a Verified Mark Certificate (VMC) from DigiCert or Entrust for full "blue checkmark" display. Basic BIMI without VMC is free and displays your logo in Gmail.

# BIMI DNS record:
default._bimi.yourcompany.com  TXT  "v=BIMI1; l=https://yourcompany.com/logo.svg; a=https://yourcompany.com/certificate.pem"

Tier 2: SMB-Grade Controls (~$500-$2,000/month)

Microsoft Defender for Office 365 Plan 1 ($2/user/month): Adds Safe Attachments (sandboxed detonation of email attachments), Safe Links (URL rewriting and click-time scanning), and anti-phishing policies with impersonation protection.

Proofpoint Essentials (~$7-$12/user/month): Comparable to Microsoft Defender but with stronger threat intelligence. Better for organizations not in the Microsoft ecosystem.

KnowBe4 (phishing simulation and training, ~$15-$30/user/year): Automated phishing simulations that send realistic test phishing emails to employees, track who clicks, and enroll clickers in targeted security awareness training. The simulation data tells you which employees need more training and which phishing templates are most effective against your organization.

Cloudflare Email Security (formerly Area 1, ~$5-$8/user/month): Pre-delivery scanning with advanced detection. Integrates with Google Workspace and Microsoft 365 as a preprocessing layer before mail reaches your inbox.

Tier 3: Enterprise Grade (~$2,000-$10,000+/month)

Proofpoint TAP (Targeted Attack Protection) enterprise tier: Advanced sandboxing, people-centric security analytics, CASB integration. Includes threat intelligence about which executives and roles are being targeted externally (gleaned from Proofpoint's network-wide threat data).

Microsoft Defender for Office 365 Plan 2 (included in M365 E5): Adds Threat Explorer for security team investigation, Attack Simulator for organization-wide campaigns, and extended detection and response (XDR) integration with Defender for Endpoint.

Mimecast Email Security enterprise: Established player with strong archive, continuity (email continues to flow if your mail server is down), and targeted threat protection features.

Valimail Enforce: DMARC deployment and enforcement automation specifically. Particularly strong for enterprises that want hands-off DMARC management after initial configuration.

Attachment and Link Security

Attachment Sandboxing: How It Works and Its Limits

Enterprise email security gateways handle incoming attachments by detonating them in an isolated virtual environment (sandbox) before delivery. The sandbox observes behavior:

• Registry writes (often indicative of malware establishing persistence)
• Network connections (malware phoning home to command-and-control)
• File system modifications (ransomware encrypting files)
• Process spawning (malicious macros launching PowerShell)

If the sandbox observes malicious behavior, the attachment is blocked. If behavior is clean after a configurable observation period, the attachment is delivered.

Sandbox evasion techniques used by sophisticated attackers:

• Time delays: Malware waits 30-60 minutes before executing, by which time the sandbox has completed its analysis window
• VM artifact detection: Malware checks for virtual machine indicators (specific registry keys, CPU features, screen resolutions common in VMs) and behaves cleanly if detected
• User interaction requirements: Malware requires mouse movement or specific user actions before executing — sandboxes that don't simulate user interaction don't trigger the payload
• Password-protected archives: ZIP files with passwords can't be opened by sandboxes that don't have the password (often provided in the email body)

Defense: Sandbox evasion raises the attacker's cost and sophistication requirements. Block entire file types that have no legitimate business use: .exe, .scr, .bat, .ps1 (PowerShell), .vbs (VBScript), .js when delivered by email. For file types that are used legitimately (PDFs, Office documents), aggressive sandboxing with extended dwell time and virtual machine diversity reduces evasion success rates.

Strip macros from Office documents by default. Microsoft disabled auto-execution of macros from internet-sourced documents in 2022, but many organizations still have this protection disabled for "compatibility." Enable it.

Safe Link Processing

URL rewriting rewrites hyperlinks in emails at delivery time. When the user clicks, the request goes to the email security gateway first, which:

1. Checks the URL against threat intelligence databases
2. Detonates the URL in a sandbox if it wasn't previously analyzed
3. Blocks if malicious; allows if clean

The benefit over scan-time checking: attackers increasingly use "time-of-click" delivery, where the URL is clean at delivery but switches to malicious content at click time. Click-time checking catches this.

Limitation: Users who notice rewritten URLs and bypass them (by manually copying the original URL) defeat this control. The link rewriting UI matters — excessive obfuscation of the destination URL trains users to ignore it.

End-to-End Email Encryption

Authentication (SPF/DKIM/DMARC) proves who sent the message. Encryption protects the message content from anyone who intercepts it in transit. These are separate concerns with separate solutions.

Encryption in Transit: TLS and MTA-STS

Most major email providers support STARTTLS — opportunistic TLS that encrypts the SMTP connection between servers. "Opportunistic" means it's used if both sides support it; it falls back to plaintext if not.

MTA-STS (Mail Transfer Agent Strict Transport Security) removes the "opportunistic" weakness. You publish a policy via HTTPS and DNS that requires supporting senders to use TLS with your server's certificates, rejecting any connection that can't meet these requirements.

# Check if a domain supports MTA-STS:
dig TXT _mta-sts.yourcompany.com
curl https://mta-sts.yourcompany.com/.well-known/mta-sts.txt
 
# The policy file at /.well-known/mta-sts.txt looks like:
version: STSv1
mode: enforce
mx: mail.yourcompany.com
max_age: 86400
 
# Pair with TLS-RPT to receive failure reports:
# _smtp._tls.yourcompany.com TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourcompany.com"

End-to-End Encryption: S/MIME vs. PGP

S/MIME uses certificates issued by trusted Certificate Authorities (CAs) — the same trust model as HTTPS. Your organization issues or purchases certificates for each user. The certificate is included in emails automatically, and supporting mail clients (Outlook, Apple Mail, iOS Mail, Android) handle encryption and decryption transparently.

# Check if an email was S/MIME signed (examine headers):
grep -i "content-type: application/pkcs7" email.eml
grep -i "smime" email.eml
 
# Obtain a free S/MIME certificate from Actalis:
# https://extrassl.actalis.it/portal/uapub/freessl (personal use, 1-year validity)
 
# Outlook: Configure S/MIME under File → Options → Trust Center → Trust Center Settings → Email Security
# Apple Mail: Automatically uses S/MIME if a valid certificate is in the Keychain

For enterprise deployment, integrate with your PKI (Public Key Infrastructure) to auto-issue S/MIME certificates for all employees. Microsoft Certificate Services, EJBCA, and commercial CA programs (DigiCert, Sectigo) all support this.

PGP (Pretty Good Privacy) uses a web-of-trust model rather than CA-issued certificates. Each user generates their own key pair and shares their public key directly. No CA hierarchy is required.

# Generate a PGP key pair
gpg --full-generate-key
# Choose RSA and RSA, 4096 bits, 2-year expiry
 
# Export your public key to share with others
gpg --armor --export your@email.com > public_key.asc
 
# Import someone else's public key
gpg --import their_public_key.asc
 
# Encrypt an email to someone
gpg --encrypt --armor --recipient their@email.com message.txt
 
# Decrypt a received encrypted message
gpg --decrypt message.asc
 
# Sign a message
gpg --sign --armor message.txt

The practical problem with PGP: Key discovery and verification are manual. There's no automatic mechanism to find someone's public key or verify it's the right one. The web-of-trust model requires deliberate social scaffolding. Most non-technical users don't use it. Most corporate mail clients (Outlook in particular) have poor native PGP support.

For most organizational email encryption needs, S/MIME is more practical. For individuals communicating with technically sophisticated contacts, PGP remains viable.

Provider-Specific Hardening

Google Workspace

DKIM and SPF via Admin Console:

Admin Console → Apps → Google Workspace → Gmail → Authenticate email

Enable DKIM signing and copy the generated DNS TXT record to your domain registrar.

Comprehensive security settings:

Admin Console → Apps → Google Workspace → Gmail → Safety

• Protect against domain spoofing: Enable
• Protect against spoofing of employee names: Enable
• Protect against inbound emails spoofing your domain: Enable
• Protect against any unauthenticated emails: Enable (with quarantine or warning label)

Disable POP and IMAP for high-risk roles:

Admin Console → Apps → Google Workspace → Gmail → End User Access
→ IMAP access: disabled for all or specific OUs
→ POP access: disabled

Enhanced sandbox for attachments:

Admin Console → Apps → Google Workspace → Gmail → Safety → Attachments
→ Enhanced pre-delivery message scanning: Enable

Microsoft 365 / Exchange Online

Anti-phishing policy configuration (via Defender portal):

security.microsoft.com → Email & collaboration → Policies & rules → Threat policies → Anti-phishing
→ Create/edit policy:
  - Impersonation: Add specific users (CEO, CFO, IT admin) and domains to protect
  - Mailbox intelligence: Enable (uses mail flow patterns to identify unusual senders)
  - First contact safety tips: Enable (warns when receiving email from a new sender)
  - Spoofing intelligence: Enable (identifies and applies policy to spoofed senders)

Safe Attachments policy:

security.microsoft.com → Email & collaboration → Policies & rules → Threat policies → Safe Attachments
→ Enable Safe Attachments for email messages
→ Action: Block — block current and future messages with detected malware
→ Enable redirect for blocked attachments (sends to a quarantine address for admin review)

Safe Links policy:

security.microsoft.com → Email & collaboration → Policies & rules → Threat policies → Safe Links
→ Enable URL checking in email messages
→ Apply real-time URL scanning for suspicious links
→ Apply Safe Links to email messages sent within the organization (catches internal phishing)
→ Do not allow users to click through to original URL

Block legacy authentication (via Conditional Access):

Azure Active Directory → Security → Conditional Access → New policy
→ Target: All users (with exceptions for service accounts as needed)
→ Conditions → Client apps → Select: "Exchange ActiveSync clients" and "Other clients"
→ Grant: Block access
→ Enable policy

Legacy authentication (basic auth over IMAP, POP3, SMTP AUTH) bypasses all Conditional Access policies including MFA. Blocking it is a high-priority hardening action.

The Complete Email Security Stack: Checklist

Domain authentication (protect your domain from spoofing):

• [ ] SPF record published with -all for every domain and subdomain you own
• [ ] Null SPF (v=spf1 -all) on parked domains and unused subdomains
• [ ] DKIM enabled with RSA-2048 or Ed25519 keys, selector rotation scheduled annually
• [ ] DMARC at p=reject with aggregate reports flowing to a monitored inbox or DMARC reporting service
• [ ] DMARC sp=reject to protect subdomains
• [ ] BIMI configured (bonus: logo display in supporting clients)

Inbound threat filtering:

• [ ] Attachment sandboxing enabled
• [ ] URL rewriting and click-time scanning enabled
• [ ] Anti-impersonation policies for executive names and domains
• [ ] Legacy authentication protocols (IMAP basic auth, POP3, SMTP AUTH) disabled for all users
• [ ] Inbound DMARC enforcement: reject mail that fails alignment for your own domains

Account security:

• [ ] MFA required for all mailbox access
• [ ] Hardware security key (FIDO2) for high-value accounts (executives, finance, IT admin)
• [ ] Suspicious sign-in alerts configured
• [ ] Alert on inbox rule creation (attackers create rules to forward mail or hide attack evidence)

Procedures (the human layer):

• [ ] Out-of-band verification required for all wire transfers and payment redirects
• [ ] Dual authorization required for financial transactions above threshold
• [ ] Clear, low-friction mechanism for reporting suspicious emails
• [ ] Quarterly phishing simulations with targeted follow-up training
• [ ] Lookalike domain monitoring for your primary domain

The technical controls at the domain authentication layer (SPF/DKIM/DMARC) are the foundation. They're free, they scale automatically, and at p=reject they eliminate an entire category of attack — direct domain spoofing — that would otherwise require sophisticated filtering to catch. Build that foundation first, then layer the gateway and procedure controls on top.

Email security is not a problem that gets solved. It's a problem that gets managed — the threat landscape continues to evolve, attack techniques continue to improve, and the defensive stack has to evolve with it. The goal is to systematically eliminate the cheap attacks (automated spoofing, credential stuffing, commodity phishing) through technical controls, leaving only the expensive attacks (targeted BEC requiring real research, sophisticated phishing requiring bespoke development) that reach humans — where training and procedure are the last line of defense.