Email Security Architecture: How the Full Stack Fits Together
Email security architecture is the complete layered system that protects your organization’s email, from the DNS records that authenticate sending domains through gateway filtering, encryption, and into the user inbox. It is not a single product. It is a sequence of interdependent controls, and a gap at any one layer creates a path that attackers will actively find and exploit.
Most IT managers know they have some email security in place. Very few can draw the full architecture or name exactly which layers are missing. This guide walks every layer in order, from DNS foundation to inbox delivery, so you can see precisely how the stack connects and where vulnerabilities most commonly hide.
What Is Email Security Architecture?
Email security architecture is the structured, layered design of all controls protecting an organization’s email system. It covers five distinct layers: DNS authentication records, security protocols, gateway filtering, encryption, and monitoring. Each layer depends on the one below it. A failure at the DNS layer undermines every control sitting above it.
The architecture must answer three questions for every message: did it come from who it claims (authentication), can it be read in transit (encryption), and does it carry something harmful (filtering)? Addressing all three, for both inbound and outbound email, is what a complete email security posture looks like in practice.
How Does an Email Travel From Sender to Recipient?
Understanding the email delivery path makes every security layer easier to place and easier to defend.
When a user sends a message, their mail server performs a DNS lookup to find the recipient’s MX record. The MX record identifies the correct destination server. The sending mail transfer agent (MTA) opens an SMTP connection to that server and negotiates a TLS handshake to encrypt the session. Once connected, it transmits the message. The receiving MTA checks the sender’s SPF, DKIM, and DMARC records before accepting delivery and routing the message to the inbox.
Each step in this email delivery pipeline is a potential attack point. DNS spoofing can redirect delivery to a rogue server. A downgraded TLS handshake exposes content in transit. Failed authentication checks let spoofed messages reach the inbox. Email security architecture exists to protect every one of these steps in sequence.
What Role Do DNS Records Play in Email Security?
DNS records form the authentication foundation of the entire email security architecture. Without correctly configured records at this layer, every authentication control above fails. The six DNS records every organization needs are listed below.
| Record | Purpose | Threat Addressed | Example |
| MX | Routes email to the correct mail server | Routing errors, misdirected delivery | MX 10 mail.domain.com |
| SPF | Lists IP addresses authorized to send email for a domain | Domain spoofing, unauthorized senders | v=spf1 include:_spf.google.com ~all |
| DKIM | Publishes public key for cryptographic signature verification | Message tampering, impersonation | v=DKIM1; k=rsa; p=[public key] |
| DMARC | Sets enforcement policy for SPF and DKIM failures | Spoofing, phishing, BEC | v=DMARC1; p=reject; rua=mailto:rua@domain.com |
| BIMI | Displays verified brand logo in supporting email clients | Brand impersonation, low inbox trust | v=BIMI1; l=https://domain.com/logo.svg |
| PTR | Reverse DNS confirming mail server identity | Spam reputation damage, deliverability failures | Resolves mail.domain.com |
BIMI is the most overlooked record in this set and the most business-visible output of a complete DNS authentication stack. It activates only when your DMARC policy reaches enforcement at p=quarantine or p=reject. Once live, your verified brand logo appears directly in the inbox in Gmail, Yahoo Mail, and Apple Mail. Most organizations spend months correctly configuring SPF, DKIM, and DMARC and never take the final step to BIMI, leaving the most recognizable inbox trust signal completely unused. For non-technical stakeholders and customers, a verified logo in the inbox is the clearest possible confirmation that your email authentication chain is complete and functioning.
PTR records are almost never mentioned in email security architecture guides, yet they carry real weight for deliverability. A PTR record maps your mail server IP address back to its hostname via reverse DNS lookup. Many receiving servers check PTR records during spam reputation scoring. A missing or mismatched PTR record is one of the most frequent causes of legitimate business email landing in spam, and it rarely appears on any setup checklist.
For the full setup walkthrough, see our article on SPF, DKIM and DMARC Explained.
What Are the Core Email Security Protocols?
Email security protocols define how messages are transmitted between servers and how connections are secured. The distinction that matters most but gets explained least in business-facing content is the difference between opportunistic TLS and enforced TLS.
| Protocol | What It Does | Layer | Status |
| SMTP | Transmits email between mail servers | Transport | Mandatory |
| STARTTLS | Opportunistic TLS upgrade for SMTP sessions | Transport encryption | Recommended baseline |
| MTA-STS | Enforces TLS, prevents plaintext downgrade | Enforced transport | Strongly recommended |
| DANE | Binds TLS certificates to domains via DNSSEC | Enforced transport | Advanced, optional |
| TLS 1.3 | Current encryption standard for email in transit | Encryption | Required for compliance |
| S/MIME | End-to-end encryption and digital signing of content | Message encryption | Required in regulated sectors |
| PGP | End-to-end public and private key encryption | Message encryption | Optional |
STARTTLS is what almost every mail server uses by default. It attempts to upgrade an SMTP connection to TLS when the receiving server supports it, but if an attacker intercepts the session and strips the TLS capability signal, the connection downgrades silently to plaintext. STARTTLS is opportunistic. It encrypts when it can and transmits in the clear when it cannot.
MTA-STS, defined in RFC 8461, prevents this. It publishes a policy telling sending servers that TLS is required for your domain and cannot be downgraded. If a valid TLS connection cannot be established, the message is not delivered rather than sent in plaintext. This closes the man-in-the-middle downgrade attack that STARTTLS leaves open by design.
DANE extends this protection further by using DNSSEC to cryptographically bind the specific TLS certificate a mail server should present during connection. An attacker cannot substitute a fraudulent certificate because the expected fingerprint is anchored in signed DNS records. DANE and MTA-STS address the same vulnerability from different directions and can be deployed together as complementary enforced TLS controls.
The practical implication: most businesses on Microsoft 365 or Google Workspace are running STARTTLS without a published MTA-STS policy. For standard high-volume traffic this carries low risk. For a targeted attacker positioned between specific mail servers, it is a real exploitable gap that a single published MTA-STS policy and DNS record closes entirely.
What Are Email Security Headers and What Do They Tell You?
Email security headers are metadata fields embedded in every message that record its complete delivery path and authentication results. Reading them tells you exactly how a message moved through the email delivery pipeline and whether it passed or failed each security check along the way.
The five headers every security practitioner needs to understand are the Received headers, which trace every mail server the message passed through with timestamps; the Authentication-Results header, which records SPF, DKIM, and DMARC pass or fail outcomes in a single readable field; the DKIM-Signature header, which carries the cryptographic signature block attached by the sending server; the X-Spam headers, which show the spam score and triggered filtering rules; and the ARC headers (Authenticated Received Chain).
ARC headers are the most important and least understood of the five. They exist to solve a specific, very common problem: DMARC failures on forwarded email. When a message is forwarded, the forwarding server changes the delivery path. The original SPF check fails because the message arrives from an IP address not listed in the authorized SPF record. If the forwarder modifies the message body at all, the DKIM signature breaks too. The result is a DMARC failure on a completely legitimate email.
ARC creates a verifiable chain of custody. Each intermediate server that handles the forwarded message stamps its own authentication results into ARC headers. The final receiving server checks this chain to confirm the original message passed authentication before forwarding, even if the current delivery no longer aligns with the original SPF or DKIM record. This is the mechanism that allows mailing lists, automated forwarding systems, and third-party sending platforms to coexist with an enforced DMARC policy without constantly breaking it.
Organizations that enforce DMARC at p=reject without understanding ARC will block legitimate email and spend considerable time troubleshooting what looks like a configuration error. Understanding ARC is the difference between a clean DMARC deployment and one that generates ongoing operational disruption.
How Does a Secure Email Gateway Fit Into the Architecture?
The secure email gateway (SEG) sits above the DNS and protocol layers and below the user inbox. It is the active threat interception point in the email security architecture, applying controls that DNS records and authentication protocols alone cannot provide.
Inbound messages arrive at the gateway after DNS authentication runs at the server level. The gateway applies anti-spam filtering, anti-phishing detection, and malware scanning before any message reaches a user. Outbound messages pass through in the opposite direction, where the gateway enforces email DLP policies, inspects content for sensitive data, and confirms DKIM signing is applied.
For a full breakdown of gateway architecture including API-based deployment models for Microsoft 365 and Google Workspace, see our guide on What Is a Secure Email Gateway (SEG).
What Is the Difference Between Inbound and Outbound Email Security?
Inbound email security filters messages arriving at your organization. The threat is external: attackers delivering malware, phishing links, and spoofed messages to your users. Controls include anti-spam, anti-phishing, malware scanning, and authentication verification at the gateway layer.
Outbound email security monitors messages leaving your organization. The threat is internal and accidental: sensitive data leaving through email, your domain being used to relay phishing to others, and outgoing messages sent without DKIM signing. Email DLP, DKIM enforcement, and outbound gateway controls operate on this traffic.
Most security incidents exploit gaps in inbound controls. Most compliance violations and domain reputation damage stem from gaps in outbound controls. An architecture that only addresses one direction is incomplete regardless of how strong each individual layer is.
How Do SPF, DKIM and DMARC Work Together in the Architecture?
SPF, DKIM, and DMARC form a three-part authentication chain. They cannot replace each other, and each one closes a gap the others leave open.
SPF, defined in RFC 7208, checks whether the sending IP address is authorized to send email for the domain. It verifies the message route, not the content itself.
DKIM, defined in RFC 6376, attaches a cryptographic signature to every outgoing message. The receiving server verifies this signature against a public key in DNS, confirming the message was not altered in transit.
DMARC, defined in RFC 7489, requires at least one of SPF or DKIM to pass and demands the result aligns with the domain in the visible From address. When neither passes alignment, the DMARC policy determines the outcome: deliver, quarantine, or reject. NIST SP 800-177 and UK NCSC Email Security guidance both identify full DMARC enforcement as a baseline email security requirement. Cyber Security Solutions Ltd recommends reaching p=reject only after all legitimate sending sources are mapped, aligned, and tested to prevent blocking valid email during rollout.
To understand how this authentication chain fits the wider architecture, see The Complete Guide to Email Security.
What Does a Complete Email Security Stack Look Like in 2026?
A complete email security stack in 2026 consists of five operational layers. Most organizations have elements of the first two. Very few run all five as a connected, monitored architecture.
The DNS layer covers SPF, DKIM, DMARC at enforcement, BIMI, MX, and PTR records, all actively reviewed through DMARC aggregate reporting.
The gateway layer handles inbound anti-spam, anti-phishing, and malware scanning alongside outbound email DLP and DKIM signing enforcement.
The protocol layer includes MTA-STS to enforce TLS for your domain and TLS 1.3 as the minimum encryption standard on your mail server, closing the STARTTLS downgrade exposure.
The encryption layer applies TLS 1.3 in transit for all email and S/MIME or PGP for messages containing sensitive, regulated, or legally privileged content.
The monitoring layer is what almost every competitor guide omits. Email logs, SIEM integration, DMARC aggregate report analysis, and real-time alerting on authentication failures are what tell you whether the first four layers are actually working. Without monitoring, you cannot detect an attacker probing your SMTP relay. You cannot see a spike in DMARC failures that signals an active spoofing campaign targeting your domain. A real-world example: a business that deploys DMARC at p=reject with no reporting pipeline will not know when a third-party marketing platform, approved years earlier, begins sending from an IP address no longer in their SPF record until deliverability drops or a spoofing incident surfaces. SIEM-connected email log monitoring catches that scenario in real time. The monitoring layer turns your email security architecture from a static configuration into an active, continuously verified detection capability.
For the component-level view of each layer, visit Types of Email Security: A Complete Breakdown.
Conclusion
Email security architecture works only when all five layers are in place and actively monitored. DNS authentication without gateway filtering leaves malware unblocked. Gateway filtering without MTA-STS leaves your transport layer vulnerable to downgrade. Monitoring without the underlying controls has nothing to measure. Getting the full stack right is the only way to close the gaps attackers probe for first. To have your current architecture reviewed against this complete framework, visit cybersecuritysolutionsltd.com for a free email security assessment.
FAQs
What is the difference between email security protocols and email security headers?
Email security protocols (SMTP, STARTTLS, MTA-STS, TLS 1.3) define how messages are transmitted and encrypted between servers. Email security headers are metadata fields inside each message, recording the actual delivery path and authentication results. Protocols set the rules of transmission. Headers document exactly what happened during delivery for every individual message sent.
Is STARTTLS the same as full TLS encryption for email?
No. STARTTLS is opportunistic and can be downgraded to plaintext if an attacker strips the TLS capability signal during an SMTP session. MTA-STS and DANE enforce TLS and prevent any downgrade from occurring. Most organizations run STARTTLS without MTA-STS and incorrectly assume their email transit is fully encrypted at all times.
What DNS records are required for email security?
The essential email security DNS records are MX for routing, SPF for authorized sending IPs, DKIM for the cryptographic signing key, and DMARC for enforcement policy. PTR records support server reputation and deliverability. BIMI activates inbox logo display once DMARC enforcement is in place. All six together form a complete DNS authentication foundation.
Why does DMARC fail when email is forwarded?
Forwarding changes the delivery path, causing the message to arrive from an IP not listed in the original SPF record. If the forwarder modifies the message body, the DKIM signature breaks too. ARC (Authenticated Received Chain) headers solve this by preserving the original authentication results through each forwarding hop, letting the final receiving server verify legitimacy.
What is BIMI and what do you need before you can enable it?
BIMI displays your verified brand logo in supporting email clients including Gmail and Apple Mail. You need a fully enforced DMARC policy at p=quarantine or p=reject, a correctly formatted SVG logo file, and in most implementations a Verified Mark Certificate (VMC). BIMI is the most visible outcome of completing your DNS authentication stack correctly.
How do I know if my email security architecture has gaps?
Review your DMARC aggregate reports to identify every IP sending on your domain’s behalf. Check whether MTA-STS is published for your domain. Inspect email headers for ARC entries and Authentication-Results data. Verify your outbound gateway applies DLP and DKIM signing. Confirm email logs are feeding into your SIEM and authentication failures are triggering real-time alerts.
