Modern Authentication to Transport Security

Sending an email securely requires more moving parts than most people expect. You don’t notice when it works, but you really notice when it doesn’t!

Email is still one of the most critical and most abused communication channels in modern IT environments. While most organizations rely on email every day, not enough people understand how emails and the security surrounding them actually work under the hood.

This comprehensive guide breaks down the core building blocks of modern email security, from sender authentication and domain alignment to DNS integrity and transport-layer protection. We’ll explore technologies like SPF, DKIM, DMARC, ARC, DNSSEC, DANE, and MTA-STS—what they do, why they exist, and how they fit together to form a layered defense against spoofing, tampering, and interception.

The Parts of Modern Email Security

Modern email security isn’t a single feature or toggle; it’s a collection of independent standards, each designed to solve a very specific problem. On their own, each control offers limited protection, but when combined, they form a chain of trust that governs who is allowed to send email, whether a message has been altered, and how it’s protected while in transit.

These mechanisms operate at different layers of the email pipeline. Some validate identity, some enforce alignment, others ensure that the information on which email security depends hasn’t been tampered with, and others protect the message as it moves between mail servers.

The core building blocks are:

• SPF (Sender Policy Framework)
• DKIM (DomainKeys Identified Mail)
• DMARC (Domain-based Message Authentication, Reporting and Conformance)
• ARC (Authenticated Received Chain)
• DNSSEC (Domain Name System Security Extensions)
• DANE (DNS-Based Authentication of Named Entities)
• MTA-STS (Mail Transfer Agent Strict Transport Security)

The complexity and the security primarily come from how they interact, overlap, and compensate for each other’s limitations. Let’s break down what each of these technologies actually does, why it exists, and where it fits into the overall email security model.

Sender Policy Framework (SPF)

SPF is an email authentication method that attempts to answer a single question: Does the sending IP have permission to send email for this domain?

When a receiving mail server gets a message, it looks up the SPF TXT DNS record for the domain and confirms whether the sending mail server is authorized for that domain.

Example SPF Record

yourdomain.com TXT “v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all”

SPF records are evaluated from left to right, with different mechanisms that authorize servers. Only one SPF record is allowed per domain and subdomain.

SPF Mechanisms

Mechanism	Description
ip4: / ip6:	Specifies authorized IP ranges for sender servers
a	Utilizes the IPs of the domain’s A or AAAA records to authorize senders
mx	Authorizes the IPs of the domain’s MX servers
include	Pull in another domain’s SPF policy (used for Exchange Online)
all	Catch-all telling receiving servers what to do with mails from unauthorized servers (must be placed last)

Important note: Forwarding an email breaks SPF on its own, which is where other mechanisms like ARC become important.

DomainKeys Identified Mail (DKIM)

DKIM is an email authentication method that attempts to answer two questions: Was this message signed by a domain that controls the signing key? Has the message been modified since it was signed?

DKIM works by adding a cryptographic signature to each outgoing message using a private key held by the sending system. When a receiving mail server gets a message, it retrieves the DKIM public key from DNS and validates the signature. If validation succeeds, DKIM passes.

The public key is published as a TXT record under a selector, for example:

selector1._domainkey.yourdomain.com TXT “v=DKIM1; k=rsa; p=MIIBIjANBgkq…”

The selector allows multiple keys to coexist, enabling key rotation without disrupting mail. Within Exchange Online, there are two DKIM keys for this purpose.

Critical limitation: DKIM alone does not prevent domain spoofing without DMARC alignment.

Domain-based Message Authentication, Reporting and Conformance (DMARC)

DMARC builds on SPF and DKIM and attempts to answer the question: Does this email authenticate using SPF and/or DKIM in a way that aligns with the domain?

Once a receiving mail server has evaluated SPF and DKIM, it compares the authenticated domains with the domain found in the From: header. If SPF and/or DKIM don’t pass and don’t align with the From domain, the message fails DMARC.

DMARC specifically protects the domain found in the From: header—the domain visible to end users. This is crucial for preventing display-name spoofing and other social engineering attacks.

Alignment Types

Relaxed alignment (default):

Subdomains are allowed. Example: mail.yourdomain.com aligns with yourdomain.com

Strict alignment:

Exact domain match required. Example: mail.yourdomain.com does NOT align with yourdomain.com

Domain Sources

SPF: Envelope-From domain (SMTP level sender domain)

DKIM: Signing domain

Emails will pass DMARC if either SPF or DKIM passes and aligns with the From domain. DMARC is published as a TXT DNS record:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r

DMARC Policy Options

Policy	Description
p=none	Monitoring only, no enforcement
p=quarantine	Failing messages should be treated as suspicious and quarantined
p=reject	Failing messages should be rejected directly

Best practice: Always start with p=none and gradually move to p=reject after analyzing the data and ensuring legitimate emails will pass once enforced.

Additional DMARC Mechanisms

pct= – Percentage-based rollout of the DMARC policy (e.g., pct=50 means 50% of emails follow the policy)

sp= – Specifies a different DMARC policy for subdomains

rua= – Email address for aggregate reports (typically sent daily, containing authentication attributes)

ruf= – Near real-time forensic reports (used for troubleshooting misconfigurations and investigating attacks, but not widely used due to privacy concerns)

Authenticated Received Chain (ARC)

ARC is designed to preserve authentication results when email passes through intermediaries that legitimately modify messages, such as mailing lists, mail relays, secure gateways, or forwarding services.

ARC exists to help legitimate intermediaries maintain SPF/DKIM on an email, ensuring alignment with DMARC and allowing it to meet requirements even after forwarding.

Each ARC-enabled intermediary adds a set of headers:

• ARC-Authentication-Results (AAR): Records the SPF, DKIM, and DMARC results observed by that intermediary
• ARC-Message-Signature (AMS): DKIM-like signature of the message at that hop
• ARC-Seal (AS): Cryptographically seals the ARC set and links it into a chain using an instance number (i=1, i=2, etc.)

Important: ARC does not override DMARC on its own, and trust is based on the reputation of the sealing forwarder.

Domain Name System Security Extensions (DNSSEC)

DNSSEC is an extension to DNS that protects DNS data by adding cryptographic signatures, allowing resolvers to verify authenticity and integrity. This protects against DNS spoofing, which can completely bypass SPF, DKIM, and DMARC protections.

DNSSEC attempts to answer the question: Is this DNS response authentic and unmodified?

With email heavily relying on DNS MX records for mail routing, SPF, DKIM, and DMARC all using DNS records for policy configuration, and DANE requiring DNSSEC, it’s essential to use DNSSEC if your DNS registrar supports it.

DNSSEC provides protection against:

• DNS cache poisoning
• Redirections due to fake MX records
• Replacement of DKIM keys
• Alteration or replacement of SPF and DMARC policies

How DNSSEC Works

DNSSEC works by having each DNS zone signed with a private key. The signature is stored in a Resource Record Signature (RRSIG) record, and a public key is stored in a DNSKEY record. This DNSKEY is, in turn, stored in a Delegation Signer (DS) record in the parent DNS zone.

All of these records, RRSIG, DNSKEY, and DS, are cryptographically verified by a DNSSEC-capable resolver. DNSSEC is usually handled at the DNS registrar, with the resolver being part of the registrar’s infrastructure.

Key point: DNSSEC does not directly protect email, but it protects the DNS records that are required for email protection—and it’s a direct requirement for DANE.

DNS-Based Authentication of Named Entities (DANE)

DANE builds on DNSSEC by binding cryptographic information to domain names via TLSA records. DANE allows a domain to say: This is the exact TLS certificate or key you must see when connecting to my service.

This statement is published in DNS, and DNSSEC cryptographic protection ensures its trustworthiness and security. While DANE can be used for multiple services, in email, it’s used to secure SMTP over TLS.

By default, email is protected by opportunistic TLS encryption is used only if both servers support it and no errors occur. It’s attempted, not enforced. This leads to many emails being transported as cleartext, prone to downgrade and man-in-the-middle attacks, or spoofing.

DANE changes opportunistic TLS to mandatory TLS.

How DANE Works for SMTP

When using DANE with DNSSEC for inbound emails, the receiving domain publishes TLSA records in the DNS zone, specifying which certificate or public key to use and how it should be validated.

When a remote mail server sends an email to your DANE-configured domain:

• The sender server looks up the receiving domain’s MX records
• The sender server connects to the receiving domain’s MX over SMTP
• The sender server sees STARTTLS
• The sender server looks up a TLSA record
• The sender server validates DNSSEC
• The sender server validates your TLS certificate against TLSA

If any of these steps fails, the email is not delivered. If all passes, the email is delivered.

Example TLSA Record

_25._tcp.mx.yourdomain.com. IN TLSA (  3 1 1  9a4c8e6d3b1c4e7f9c8d1f4a6b3e2d9f8c7b6a5e4d3c2b1a0f9e8d7c6b )

Note: Inbound SMTP DANE with DNSSEC for Exchange Online has been in General Availability since 2024.

Mail Transfer Agent Strict Transport Security (MTA-STS)

MTA-STS is an email security standard that protects SMTP-transported data by requiring TLS, verified over HTTPS, ensuring all emails are protected and blocking bad actors.

MTA-STS upgrades SMTP’s opportunistic TLS to require it and ensures no cleartext data is sent. It’s very similar to DANE, though less secure as it relies on DNS and public Certificate Authorities (CAs). It does not require DNSSEC and should be utilized primarily where DNSSEC is not viable.

MTA-STS is fundamentally a policy discovery and enforcement system with two main parts:

• Policy advertisement (via DNS)
• Policy retrieval (via HTTPS)

Step 1: DNS TXT Record

The DNS TXT record for policy advertisement is published on the receiving domain, signaling that an MTA-STS policy exists. The ‘id’ value is a simple version identifier used for caching.

_mta-sts.yourdomain.com TXT “v=STSv1; id=20240501”

This TXT record does not contain the actual policy—it’s simply a signal and versioning mechanism.

Step 2: HTTPS Policy Fetch

The sending mail server fetches the MTA-STS policy file, which is available over HTTPS at:

https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

The policy file consists of CRLF-separated key/value pairs supporting these four fields:

• version: Only supports STSv1 currently
• mode: enforce, testing, or none
• max_age: Maximum lifetime of the policy (typically weeks or more)
• mx: Allowed MX hosts for the policy domain

Example Policy

version: STSv1 mode: enforce mx: *.mail.yourdomain.com mx: mail.yourdomain.com mx: backupmx.example.com max_age: 86400

The policy file is always fetched over HTTPS and signed by public CAs, providing a second layer of trust compared to simple DNS.

Step 3: Caching and Enforcement

The sending email server caches the fetched policy for up to the max_age specified. Any future sending attempts will use the cached policy to enforce:

• TLS must be negotiated (STARTTLS)
• A valid certificate must be presented
• The MX hostname must match the mx: patterns from the policy

If any of these checks fail for a policy with mode: enforce, delivery will fail.

These steps help protect against multiple attacks:

• STARTTLS downgrade attacks (fallback to no TLS)
• Passive eavesdropping
• Invalid certificates (from misconfiguration or attack)
• Accidental cleartext delivery

Note: MTA-STS can be seen as a ‘lightweight’ DANE solution implemented due to the slow rollout of DNSSEC. Both SMTP DANE and MTA-STS can be used for the same domain simultaneously. MTA-STS will always adhere to DANE and won’t interfere with DANE protection. MTA-STS for Exchange Online has been in general availability since 2022.

Microsoft Exchange Online Security – How It All Fits Together

Each of the mentioned technologies provides security and protects a different layer of the email pipeline. None of these technologies can stand alone. We must protect our email services with a layered approach that leverages all available components.

Sender Identity and Policy

• SPF: Who is allowed to send
• DKIM: Whether the message was modified
• DMARC: Whether authentication aligns with the From domain and what to do if it doesn’t
• ARC: Preserves authentication across trusted intermediaries

DNS Integrity

• DNSSEC: Ensures DNS responses are authentic and unmodified

Transport Security

• DANE: Enforces TLS using DNSSEC as the trust anchor (Recommended)
• MTA-STS: Enforces TLS using HTTPS and public CAs

Each layer builds on the others, providing additional protections and guarantees.

Conclusion: Understanding the Modern Building Blocks

Modern email security is not a single control or configuration setting, but a layered stack of complementary protections that each solve a specific part of the problem. While this guide has focused primarily on Exchange Online, every mechanism covered here is based on open standards and applies equally to any other email platform or environment.

At a high level, the responsibilities break down like this:

• SPF, DKIM, DMARC, and ARC protect sender identity, message integrity, and domain alignment
• DNSSEC protects the DNS data that these mechanisms depend on
• DANE and MTA-STS protect the SMTP transport by enforcing encrypted delivery

When combined, these technologies significantly reduce the risks associated with email, including:

• Domain spoofing
• Message tampering
• Transport-level interception
• Downgrade and man-in-the-middle attacks

Individually, each mechanism is useful. Together, they form a modern and resilient email security posture.

The most important takeaway: No single control is sufficient on its own. Email security works because these standards reinforce each other, address edge cases, and create multiple points of validation and enforcement throughout the entire mail flow.

Whether you manage Microsoft Exchange Online or another mail platform, these mechanisms are foundational and universal. Understanding them is key to building a resilient and trustworthy email posture.

Next Steps

If you want to go deeper into modern email security, transport hardening, and real-world Exchange Online configurations, consider exploring hands-on implementation of inbound SMTP DANE with DNSSEC within Microsoft Exchange Online. This will take your environment from opportunistic to mandatory TLS for email delivery.