top of page
Search

Modern Email Security Explained: From Sender Authentication to Transport Security

  • Writer: Sebastian F. Markdanner
    Sebastian F. Markdanner
  • 15 hours ago
  • 12 min read

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

Email security graphic with a shield and envelope icon. Text reads "Modern Email Security Explained: From Sender Authentication to Transport Security."

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 knows how emails, and the security surrounding it, actually works under the hood.


This post 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 walk through what technologies like SPF, DKIM, DMARC, ARC, DNSSEC, DANE, and MTA-STS do, why they exist, and how they fit together to form a layered defense against spoofing, tampering, and interception.


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.


Let's dive in!


Table of Contents


The Parts of Modern Email Security

Let’s start at the beginning: what are the actual moving parts involved in securing email?


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, from sender authentication and policy enforcement to DNS integrity and transport-level encryption. Some validate identity, some enforce alignment, others ensure that the information email security depends on hasn’t been tampered with, and others again protect the message as it moves between mail servers.


Together, these are the core building blocks of modern email security:


  • SPF

  • DKIM

  • DMARC

  • ARC

  • DNSSEC

  • DANE

  • MTA-STS


The complexity, and the security, primarily comes from how they interact, overlap, and compensate for each other’s limitations.


So with that in mind, 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, which in very simple terms attempts to answer a single question:


Does the sending IP have permission to send email for this domain?


Once a receiving mail server gets a message, it looks up the SPF txt dns record for the domain, and from that confirms whether the sending mail server is authorized for the domain.


Example:

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 all the different mechanisms within the policy, one SPF record is allowed for each domain and subdomains.


An SPF record have these different mechanisms (authorization policies) which can be used to allow servers:


  • 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. This is used for Exchange Online

  • exists

    • Advanced conditional checks, which is rare. Does an A query on the domain, if it resolves it's a match regardless of the IP resolved.

  • all

    • Works as a catch all, telling receiving servers what to do with mails coming from sender servers not matching the rest of the SPF record. Must be placed last.

  • PRT

    • Reverse DNS lookup using PRT queries on the hostname, afterwards it's validated by having at least one A record match the sender client IP. This shouldn't, and mostly aren't, used anymore


Note that forwarding an email breaks SPF on its own.



DomainKeys Identified Mail (DKIM)

DKIM is an email authentication method that attempts to answer the following 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. This signature is generated using a private key held by the sending system.

Once 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 of the key pair is published in a DNS record on the DNS registrar, allowing receiving mail servers to verify the signature is intact, and therefore that the email contents haven't been tampered with.


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 exist simultaneously, which enables key rotation without mail disruption.

Within Exchange Online, we've got two DKIM keys.


Note that 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 doesn't pass and doesn't align with the From domain, the message fails DMARC.


So, DMARC specifically protects the domain found in the From: header, which is the domain visible to end users.


DMARC works by, once a receiving server processes SPF and DKIM, checking:


  • Whether SPF and/or DKIM passed

  • Whether the authenticated domain aligns with the From domain


If alignment fails, DMARC applies the policy defined by the domain owner.

The alignment comes in two flavors:


  • 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


As SPF and DKIM can use different sources, the From domain is checked a bit differently for each, these are the domains that are used.

  • SPF

    • Envelope-From domain (SMTP level sender domain)

  • DKIM

    • Signing domain


You'll see that emails will pass on DMARC if either SPF or DKIM passes and are aligned with the From domain.


DMARC is published as a TXT DNS record at the DNS registrar, for example:

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

Policy options

There are a few different policy options for DMARC. I always suggest going from none, and gradually moving to reject after analyzing the data and ensuring any legitimate emails will be able to pass once enforced.


These are the 3 options:


  • p=none

    • Monitoring only, no enforcement

  • p=quarantine

    • Failing messages should be treated as suspicious, and be quarantined in the receivers end.

  • p=reject

    • Failing messages should be rejected directly in the receivers end.


On top of the policy options, we also have different mechanisms that we can use for collecting of data, extending the policies or make staged rollouts:


  • pct= 

    • Can be used to make percentage based rollout of the DMARC policy. fx pct=50 means that 50% of the emails will follow the DMARC policy. Using this with p=reject will tell receivers to reject 50% of failed emails.

  • sp= 

    • Specifies a DMARC policy for the specific subdomain. Subdomains are protected by the parent policy as long as it includes a p= tag. This means you'll only use the sp= if you want to have a different policy for a subdomain.

  • rua= 

    • This tag specifies which email aggregate reports should be delivered to. These xml reports are typically sent once a day, with no sensitive data, no PII or any further email data. It's merely providing authentication atrributes, which can be used to find, fix and monitor DMARC fails.

  • ruf= 

    • Near real-time forensic reports, which aren't cleaned of PII, meaning it can include sensitive data, and is used mostly used for troubleshooting mistconfigured email setups as well as identify, investigate and analyse malicious, unauthorized or targeted attacks via emails. This isn't very broadly used due to privacy concerns.


There exists multiple different DMARC reporting providers, such as ValiMail and Dmarcian, which provides processing, guidance and overall handling of aggregate reports (RUA) and forensics reports (RUF) - do note that RUF isn't always supported.


Reporting on DMARC is essential in ensuring illegitimate emails aren't reaching our environment and users, and that our own domain isn't being spoofed and used for attacks.


It's also important for identifying unknown senders and safely moving toward enforcement



Authenticated Received Chain (ARC)

ARC is designed to preserve authentication results when email passes through intermediaries that legitimately modify messages, such as maillists, mail relays, secure gateways or any service that's directly forwarding emails ie. forwarders.


ARC exists to help legitimate intermediaries will keep SPF/DKIM intact on an email, ensuring alignment with DMARC allowing it to pass the requirements.


Each ARC-enabled intermediary (forwarder) adds a set of headers:


  1. ARC-Authentication-Results (AAR)

    • Records the SPF, DKIM, and DMARC results observed by that intermediary

  2. ARC-Message-Signature (AMS)

    • DKIM-like signature of the message at that hop

  3. ARC-Seal (AS)

    • Cryptographically seals the ARC set and links it into a chain using an instance number (i=1, i=2, etc.)


The final receiving server can validate the ARC chain and decide whether to trust the earlier authentication results.


Note that ARC does not override DMARC by itself and the trust is based on the reputation of the sealing forwarder.



Domain Name System Security Extensions (DNSSEC)

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


DNSSEC attempts to answer the "simple" question:


Is this DNS response authentic and unmodified?


With email so heavily relying on DNS, such as MX records for mail routing, SPF, DKIM & DMARC all utilizing DNS records for the policy configuration, and DANE requiring DNSSEC - It's a no brainer to utilize if your DNS Registrar supports it.


DNSSEC provides protection against DNS cache poisoning, redirections due to fake MX records, replace the DKIM keys, and alter or replace the SPF & DMARC policies.


How DNSSEC works

DNSSEC works by each DNS zone being signed with a private key, which is then stored in a Resource Record Signature (RRSIG) record and a public key, stored in a DNSKEY record, which in turn is stored in a Delegation Signer (DS) record at the parent dns zone.


All of these records, RRSIG, DNSKEY & DS, are then cryptographically verified by a DNSSEC capable resolver.


DNSSEC is usually handled at the DNS registrar, with the resolver being a part of the registrars infrastructure.


DNSSEC does not directly protect email, but the DNS records that's required for email protection - and is a direct requirement for the next feature we'll talk about.



DNS-Based Authentication of Named Entities (DANE)

DANE builds on DNSSEC to bind cryptographic information to domain names utilizing TLSA.

DANE ultimately allows a domain to say:


This is the exact TLS certificate or key you must see when connecting to my service.


That statement is published in DNS, and the cryptographic protection of DNS via DNSSEC makes it trustworthy and secure.


While DANE can be used for multiple services, in terms of email it's used to secure the SMTP protocol over TLS.


By default email is secured by opportunistic TLS, meaning emails are only protected by TLS encryption if both servers support it, and no errors occur instead of it being a requirement - it's attempted, not enforced.

This leads to a lot of emails being transported as clear text, prone to downgrade and MiTM attacks, or spoofing.


DANE changes the opportunistic TLS to mandatory TLS


How DANE works for SMTP

When using DANE with DNSSEC for inbound emails, the receiving domain publishes TLSA records to the DNS zone, which specify:


  • Which certificate or public key should be used, and

  • How it should be validated


When a remote mail server sends an email to your domain configured with DANE and DNSSEC:


  1. The sender server looks up the receiving domain's MX records

  2. The sender server connects to the receiving domain's MX over SMTP

  3. The sender server sees STARTTLS

  4. The sender server looks up a TLSA record

  5. The sender server validates DNSSEC

  6. The sender sever validates your TLS cert against TLSA


If any of these steps fails -> the email is not delivered

If all passes -> the email is delivered


This diagram shows the flow for a domain with DNSSEC & DANE

Flowchart for sending email to contoso.com, detailing DNSSEC, TLSA queries, DANE validation, and outcomes in blue, green, and red boxes.

TLSA Record example:

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

DANE looks a lot like MTA-STS, but it's not quite the same as DANE which builds on DNSSEC, and doesn't rely on public certificate authorities


Inbound SMTP DANE with DNSSEC for Exchange Online have 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 enforcing the use of TLS, verified over https, ensuring all emails are protected and blocking out bad actors.


MTA-STS upgrades the opportunistic TLS nature of SMTP, enforcing the use, ensuring no cleartext data is sent.

With this it's very similar to DANE, though less secure as it relies on DNS and public Certificate Authorities (CA). 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:


  1. Policy advertisement (via DNS)

  2. Policy retrieval (via HTTPS)


This tells the sending server:

Do not deliver mail to this domain in cleartext! Only deliver it over valid TLS.


Step 1: DNS TXT record

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

This TXT record does not contain any actual policy, simply a signal and versioning


Example:

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

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 is build up of CRLF-separated key/value pairs.

It supports the these 4 key/value pairs:


  • version

    • Only supports STSv1 as value currently

  • mode

    • Supports one of the following values:

    • enforce

    • testing

    • none

  • max_age

    • Max lifetime of the policy. This is typically expected to be in 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.

This provides second layer of trust compared to simple DNS, which in itself isn't enough.


Step 3: Caching and enforcement

The sending email server caches the fetched policy for the receiver domain for up to the max_age of the fetched policy.

Any future sending attempts to the domain will attempt to 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 fails for a policy with mode: enforce the delivery will fail.


These steps, enforcements and checks help protect against multiple attacks and exploits like:


  • STARTTLS downgrade attacks (fallback to no tls)

  • Passive eavesdropping

  • Invalid certificates (from misconfiguration or attack)

  • Accidental cleartext delivery


MTA-STS can be seen as a "lightweight" DANE solution which was implemented due to the slow rollout of DNSSEC protecting DNS records as we talked about earlier.

Both SMTP DANE & MTA-STS can be used for the same domain, at the same time. MTA-STS will always adhere to DANE, and will not interfere in the protection granted via DANE.


MTA-STS for Exchange Online have 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 the technologies can stand alone.

We therefore have to think about protecting our email services with a layered approach, and have to build using all of the lego pieces that we have at our disposal:


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 each other, and provides additional protections and guarantees.



Conclusion: Understanding the Modern Lego 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 post has focused primarily on Exchange Online, every mechanism covered here is based on open standards and applies just as much to any other email platform or environment.


At a high level, the responsibilities, that we've gone over, break down like this:


  • SPF, DKIM, DMARC, and ARC protect sender identity, message integrity, and domain alignment

  • DNSSEC protects the DNS data 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.


And now for a short mandatory break!


Why do cows have hooves instead of feet?

Because they lactose 😎


The most important takeaway is that no single control is sufficient on its own.

Email security works because these standards reinforce each other, compensate for edge cases, and create multiple points of validation and enforcement across the entire mail flow.


In the next post, we’ll go hands-on and walk through how to set up inbound SMTP DANE with DNSSEC within Microsoft Exchange Online, step by step, taking your environment from opportunistic to mandatory TLS for email delivery.


If you want to go deeper into modern email security, transport hardening, and real-world Exchange Online configurations, stay tuned - the fun is just getting started!


bottom of page