Email Security Explained: DMARC, SPF, DKIM, DANE, and MTA-STS in Plain English
Business email impersonation attacks cost organizations billions of dollars annually. Attackers send emails that appear to come from your domain to your customers, partners, or employees. The email authentication standards described in this article were designed specifically to prevent this, and implementing them correctly is one of the highest-impact security steps any organization can take for its email infrastructure.
The Foundation: How Email Authentication Works
Email was designed in the 1970s without any mechanism to verify that a sender is who they claim to be. The address in the "From" field is entirely self-reported. Email authentication standards were layered on top of the existing email infrastructure to add these missing verification mechanisms. Understanding the problem is the starting point for understanding the solutions.
SPF: Sender Policy Framework
SPF is a DNS record that lists the mail servers authorized to send email on behalf of your domain. When a receiving mail server gets a message claiming to be from your domain, it checks the sending server's IP address against your SPF record. If the IP address is not in the list, the message fails SPF.
A basic SPF record looks like: v=spf1 include:_spf.google.com ~all. This says "servers included in Google's SPF definition are authorized to send for this domain; treat all others as suspicious (softfail)." Use -all (hardfail) rather than ~all (softfail) once you are confident your legitimate email infrastructure is fully included.
SPF has a critical limitation: it checks the envelope sender (the technical sending address, not the From header the user sees). Sophisticated attackers can pass SPF while still spoofing the visible From address. This is why DKIM and DMARC are also necessary.
DKIM: DomainKeys Identified Mail
DKIM uses public-key cryptography to sign outgoing messages. Your mail server signs each outgoing message with a private key. The corresponding public key is published in a DNS record under your domain. Receiving servers retrieve the public key and verify the signature, confirming that the message body was not modified in transit and that it was signed by a server with your private key.
DKIM protects against message tampering as well as sender spoofing. A valid DKIM signature means the message was signed by your mail server with its private key, not just that it came from an authorized IP address. This is significantly stronger than SPF alone.
DMARC: Domain-based Message Authentication, Reporting, and Conformance
DMARC is the policy layer that ties SPF and DKIM together. It tells receiving mail servers what to do when a message fails authentication: deliver it anyway (p=none), quarantine it (p=quarantine), or reject it outright (p=reject). It also specifies where to send reports about authentication failures.
Start with p=none to collect reports without affecting mail delivery. Monitor the reports using a DMARC reporting tool like DMARC Analyzer or MXToolbox to identify unauthorized senders and ensure your legitimate mail streams all pass. Once you have achieved clean reports (no unauthorized senders, no unexpected failures), move to p=reject. This is the configuration that actually prevents email impersonation attacks.
DANE: DNS-Based Authentication of Named Entities
DANE solves a different problem: it ensures that when mail is sent to your server, it is encrypted using a specific TLS certificate that you have published in DNS. This prevents man-in-the-middle attacks where an attacker downgrades the connection or presents a fraudulent certificate. DANE requires DNSSEC to be enabled on your domain, which adds operational complexity but significantly strengthens the mail delivery security model.
MTA-STS: Mail Transfer Agent Strict Transport Security
MTA-STS is a simpler alternative to DANE for enforcing TLS encryption on incoming mail. It publishes a policy via HTTPS (not DNSSEC) that tells sending servers to require TLS when delivering to your domain and to reject delivery if TLS cannot be established or the certificate is invalid. It is easier to implement than DANE and provides meaningful protection against opportunistic TLS downgrade attacks.
How to Verify Your Current Setup
Use MXToolbox to check all of these records for your domain. The SuperTool will show you your SPF, DKIM selector configuration, DMARC policy, MTA-STS policy, and any issues with each. Fix the issues in order: SPF and DKIM first, then DMARC at none, then advance to reject, then DANE or MTA-STS.
Custom Mail Server vs Managed Provider
These standards apply whether you run your own mail server or use a managed provider like Google Workspace or Microsoft 365. The difference is that with a managed provider, most of this configuration is handled for you. With a custom mail server, you configure each of these standards yourself. Innovativus's privacy-first mail server is built with all of these standards implemented and verified by default. Contact us if you want help auditing or improving your email security posture.
Written by
Prashant Mishra
Founder & MD, Innovativus Technologies · Creator of Pacibook
Technologist and AI engineer with a B.Tech in CSE (AI & ML) from VIT Bhopal. Builds production-grade AI applications, RAG pipelines, and digital publishing platforms from New Delhi, India.