Email security architecture is the layered set of controls that protects an organization's email systems from inbound threats (phishing, malware, business email compromise), outbound data loss (accidental or intentional disclosure of sensitive information), and domain abuse (spoofing, impersonation)
Continue your mission
# Email Security Architecture
Email security architecture is the layered set of controls that protects an organization's email systems from inbound threats (phishing, malware, business email compromise), outbound data loss (accidental or intentional disclosure of sensitive information), and domain abuse (spoofing, impersonation). Email remains the number one initial access vector for cyberattacks: Verizon's DBIR consistently reports that phishing and email-based social engineering are the most common methods attackers use to establish an initial foothold.
Email security is not a single product. It is an architecture: multiple controls operating at different layers to provide defense-in-depth. A secure email gateway filters inbound threats before they reach the mailbox. Email authentication protocols (SPF, DKIM, DMARC) prevent attackers from spoofing the organization's domain. Advanced threat protection sandboxes suspicious attachments. URL rewriting and time-of-click scanning protect against delayed phishing links. DLP policies prevent sensitive data from leaving the organization through email. User awareness training builds the human detection layer.
No single control is sufficient. A secure email gateway catches 95% to 99% of phishing emails. The 1% to 5% that get through reach users whose training determines whether the phishing succeeds. The architecture must assume that each layer will be bypassed occasionally and that the next layer provides the catch.
Three DNS-based protocols work together to prevent email spoofing and impersonation:
SPF (Sender Policy Framework). A DNS TXT record that specifies which mail servers are authorized to send email on behalf of the organization's domain. When a receiving mail server gets an email claiming to be from the organization's domain, it checks the SPF record to verify that the sending server's IP address is authorized. If the IP is not listed, the email fails SPF validation.
SPF prevents direct spoofing: an attacker cannot send email from an arbitrary server with a "from" address of the organization's domain if the receiving server enforces SPF. SPF does not prevent display name spoofing (using the organization's name with a different domain) or compromised account abuse (email sent from a legitimate, authorized server using stolen credentials).
DKIM (DomainKeys Identified Mail). A cryptographic authentication method where the sending mail server adds a digital signature to each outbound email. The signature is verified by the receiving server using a public key published in the sending domain's DNS. DKIM verifies that the email was sent by an authorized server and that the message content was not modified in transit.
DKIM provides integrity verification (the message was not altered) and origin authentication (the message came from a server that holds the domain's private key). DKIM does not, by itself, tell the receiving server what to do with messages that fail verification.
DMARC (Domain-based Message Authentication, Reporting, and Conformance). The policy layer that ties SPF and DKIM together. DMARC publishes a DNS record that specifies: how the receiving server should handle emails that fail SPF and DKIM alignment (none: report only; quarantine: deliver to spam; reject: block delivery), and where to send aggregate and forensic reports about email authentication results.
DMARC at enforcement (p=quarantine or p=reject) is the control that actually prevents spoofed email from reaching recipients. SPF and DKIM provide the authentication mechanisms. DMARC provides the policy that instructs receiving servers to act on authentication failures.
The deployment progression: start with DMARC p=none (monitoring mode) to collect data about who is sending email on behalf of the domain. Analyze the DMARC aggregate reports to identify all legitimate senders. Update SPF and DKIM to cover all legitimate senders. Move to p=quarantine (failed authentication goes to spam). Once confident that all legitimate senders are authenticated, move to p=reject (failed authentication is blocked).
As of 2024, Google and Yahoo require DMARC records for domains sending bulk email to their platforms. Microsoft requires SPF and DKIM for email delivery to Outlook/Hotmail. Email authentication is no longer optional for organizations that send email to major consumer platforms.
The secure email gateway is the primary inbound email filtering control. SEGs (Proofpoint, Mimecast, Microsoft Defender for Office 365, Google Workspace security, Barracuda) inspect every inbound email for threats before delivery to the user's mailbox:
Spam filtering. Filter bulk unsolicited email using reputation scoring, content analysis, and sender behavior patterns. Spam filtering is the coarsest filter: it removes the highest volume of unwanted email but is not designed to catch targeted phishing.
Malware scanning. Scan email attachments for known malware using signature-based detection and behavioral analysis. Modern SEGs submit suspicious attachments to cloud-based sandboxes that execute the attachment in an isolated environment, observe its behavior (does it attempt to download additional payloads? does it modify system files? does it communicate with external servers?), and make a deliver/block decision based on the observed behavior. Sandbox analysis catches malware that signature-based scanning misses, including zero-day exploits and polymorphic malware.
Phishing detection. Analyze email content, sender reputation, URL reputation, and contextual signals for phishing indicators. Brand impersonation detection identifies emails that mimic known brands (banks, cloud services, internal applications). Homoglyph detection identifies domains that use visually similar characters to impersonate legitimate domains (microsоft.com with a Cyrillic 'о' instead of a Latin 'o').
URL rewriting and time-of-click scanning. Replace URLs in delivered emails with rewritten URLs that route through the SEG's scanning service. When the user clicks the link, the SEG scans the destination in real time. This catches delayed phishing: an attacker sends an email with a clean URL, waits for the email to be delivered (passing initial scanning), then modifies the destination to a phishing page. Time-of-click scanning catches the malicious destination at click time rather than delivery time.
Business Email Compromise (BEC) detection. Analyze emails for BEC indicators: executive impersonation, urgent wire transfer requests, vendor invoice modifications, and authority-based social engineering. BEC does not use malware or malicious URLs (which traditional SEG controls are designed to catch). It uses social engineering through seemingly legitimate email content. BEC detection uses AI/ML models trained on the organization's normal communication patterns to identify anomalous requests.
Email security is not exclusively about inbound threats. Outbound email controls prevent data loss and protect the organization's domain reputation:
DLP integration. DLP policies applied to outbound email detect and prevent sensitive data from leaving the organization through email. An employee emailing a spreadsheet containing customer Social Security numbers triggers a DLP policy that blocks the email, strips the attachment, or encrypts it automatically (see Data Loss Prevention (DLP) for detailed coverage).
Email encryption. TLS encryption between mail servers (mandatory TLS, MTA-STS) protects email content in transit. S/MIME and PGP provide end-to-end encryption for sensitive communications (the content is encrypted from sender to recipient, readable only by the intended recipient). Message-level encryption services (Virtru, Zix, Microsoft Message Encryption) provide a user-friendly alternative to S/MIME/PGP that does not require the recipient to have a certificate or key.
Outbound spam and malware prevention. If an internal account is compromised (credential theft, malware), it may be used to send spam or phishing emails to external recipients. Outbound email monitoring detects anomalous sending patterns (sudden high volume, emails to many external recipients, content that matches known spam patterns) that indicate account compromise.
Phishing is the most common initial access vector in confirmed data breaches (Verizon DBIR, Mandiant M-Trends). Phishing effectiveness has increased with AI-generated content that eliminates the spelling and grammar errors that trained users relied on to identify phishing. Business email compromise losses exceeded $2.7 billion in 2023 (FBI IC3 report), making BEC the most financially damaging cyber threat category.
Email security architecture does not eliminate phishing. It reduces the volume that reaches users (SEG filtering), prevents domain impersonation (DMARC enforcement), catches delayed threats (time-of-click scanning), and detects BEC (AI-based behavioral analysis). The residual risk (the phishing emails that pass through all layers) is addressed by security awareness training (the human detection layer).
An organization's email domain is a trust asset. Customers, partners, and employees trust email that comes from the organization's domain. If an attacker spoofs the domain to send phishing or malware, the domain's reputation is damaged, and recipients may distrust legitimate email from the organization.
DMARC at enforcement prevents domain spoofing, protecting both the recipients (who receive fewer spoofed emails) and the organization (whose domain reputation is preserved). DMARC aggregate reports also provide visibility into unauthorized use of the domain: who is sending email that claims to be from the domain, and whether it passes authentication.
Email security controls satisfy compliance requirements across multiple frameworks. PCI DSS requires protection against malware delivered through email. HIPAA requires safeguards for PHI transmitted via email (encryption). NIST CSF 2.0 PR.PS includes email security as a platform security control. SOC 2 CC6 and CC7 include email access control and threat monitoring. DMARC enforcement is increasingly referenced as a baseline security expectation in vendor security assessments and insurance underwriting.
Email security sits at the intersection of SPH (Security Posture and Hygiene), TID (Threat Intelligence and Defense), and IAT (Identity Access and Trust) in the Planetary Defense Model. SPH owns the email infrastructure configuration: SEG deployment, DMARC/SPF/DKIM configuration, email platform hardening. TID owns the threat detection component: phishing detection, BEC detection, and email-based threat intelligence. IAT owns the authentication and access component: mailbox access controls, conditional access for email clients, and compromised account detection.
CDA's Autonomous Posture Command (APC) methodology monitors email security posture continuously. DMARC policy status, SPF record accuracy, DKIM key rotation, SEG filter effectiveness (catch rate), and phishing simulation results are all posture metrics tracked in the SPH domain score. A DMARC policy that drops from p=reject to p=none (due to a configuration change or new sending service that was not added to SPF) degrades the SPH score and triggers remediation.
Two TOP missions connect directly to email security:
CDA approaches email security with one emphasis: DMARC at enforcement (p=reject) is non-negotiable for any organization CDA assesses. Insurance underwriters check DMARC status. Customers check DMARC status. Attackers check DMARC status (to determine whether spoofing the domain will work). An organization without DMARC enforcement is broadcasting to attackers that domain spoofing will succeed. CDA's FRM (Foundational Recon Mission) checks DMARC status in every assessment, and a missing or unenforced DMARC policy is a finding in every FRM report.
Word count: 1,938
CDA Theater missions that address topics covered in this article.
Written by Evan Morgan
Found an issue? Help improve this article.