Key Concepts
Understanding the fundamentals of email authentication protocols and how they work together to protect your domain from spoofing and phishing attacks.
Why Email Authentication Matters
Without email authentication, anyone can send emails that appear to come from your domain. This enables phishing attacks, business email compromise, and damages your brand reputation. Email authentication verifies that emails genuinely originate from authorized sources.
- SMTP never verified the visible From address — forging it takes no privileged access
- SPF and DKIM authenticate other identifiers; only DMARC ties them to the address a person reads
- Without a rua address you get no feedback at all — you cannot see spoofing you are not told about
For measured figures on how domains actually behave, see our State of Email Security study, which reports on the DNS posture of the Tranco top 10,000 domains.
How Protocols Work Together
Email authentication uses a layered approach. SPF and DKIM provide the foundation, DMARC unifies them with policy and reporting, while MTA-STS and BIMI add transport security and brand visibility.
Authentication Flow
- 1Email Sent: Your server sends an email signed with DKIM over TLS (enforced by MTA-STS)
- 2SPF Check: Receiver verifies the sending IP is authorized in your SPF record
- 3DKIM Check: Receiver verifies the DKIM signature using your public key
- 4DMARC Evaluation: Receiver checks if SPF or DKIM pass AND align with the From domain
- 5Policy Applied: Based on your DMARC policy, the email is delivered, quarantined, or rejected
- 6BIMI Display: If DMARC passes with p=quarantine or p=reject, your logo is shown
Protocol Deep Dive
SPF
Sender Policy Framework
Purpose
Authorizes which servers can send email for your domain
How It Works
SPF defines a list of IP addresses and hostnames authorized to send email on behalf of your domain. When an email is received, the receiver checks if the sending server's IP is listed in your SPF record.
Example Record
v=spf1 include:_spf.google.com include:sendgrid.net -allTXT record at your domain root
Advantages
- Easy to implement
- Widely supported
- Blocks unauthorized servers
Considerations
- Breaks with email forwarding
- 10 DNS lookup limit
- Doesn't verify From header
DKIM
DomainKeys Identified Mail
Purpose
Cryptographically signs emails to verify integrity and authenticity
How It Works
DKIM adds a digital signature to email headers using a private key. Receivers verify the signature using your public key published in DNS. This proves the email wasn't modified in transit.
Example Record
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ...TXT record at selector._domainkey.yourdomain.com
Advantages
- Survives forwarding
- Verifies message integrity
- Proves domain ownership
Considerations
- More complex setup
- Requires signing infrastructure
- Key rotation needed
DMARC
Domain-based Message Authentication, Reporting & Conformance
Purpose
Unifies SPF and DKIM, adds policy enforcement and reporting
How It Works
DMARC builds on SPF and DKIM by checking that the 'From' domain aligns with authenticated domains. It tells receivers what to do with failing emails (none/quarantine/reject) and sends you reports.
Example Record
v=DMARC1; p=reject; rua=mailto:your-rua-token@rua.ddmarc.comTXT record at _dmarc.yourdomain.com
Advantages
- Policy enforcement
- Aggregate reports
- Protects visible From address
Considerations
- Requires SPF and/or DKIM first
- Gradual deployment needed
- Complex third-party setup
MTA-STS
Mail Transfer Agent Strict Transport Security
Purpose
Enforces TLS encryption for email in transit
How It Works
MTA-STS tells sending servers that your domain requires encrypted connections. It publishes a policy file that mandates TLS, preventing downgrade attacks and man-in-the-middle interception.
Example Record
version: STSv1\nmode: enforce\nmx: mail.yourdomain.com\nmax_age: 604800DNS TXT record + HTTPS-hosted policy file
Advantages
- Prevents eavesdropping
- Stops downgrade attacks
- Managed policy hosting included from Growth
Considerations
- Requires valid TLS certificates
- Policy hosting needed
- Not universally supported yet
TLS-RPT
SMTP TLS Reporting
Purpose
Reports failed or downgraded TLS connections to your mail servers
How It Works
TLS-RPT publishes an address where sending servers post a daily summary of the TLS connections they made to your MX hosts, including any that failed to negotiate or could not be verified. It is how you find TLS problems before switching MTA-STS to enforce mode and breaking mail.
Example Record
v=TLSRPTv1; rua=mailto:your-rua-token@rua.ddmarc.comTXT record at _smtp._tls.yourdomain.com
Advantages
- Early warning before enforcing TLS
- Names the sending networks that failed
- Parsed and charted in DDMARC from Protect
Considerations
- Reporting only — enforces nothing on its own
- Not every sender emits reports
- The address is per-domain: copy it from the dashboard
ARC
Authenticated Received Chain
Purpose
Preserves authentication results across forwarders and mailing lists
How It Works
When a message is forwarded or passed through a mailing list, SPF usually breaks and DKIM may too. ARC lets each intermediary record the authentication result it saw and sign that record, so the final receiver can choose to trust the chain rather than fail the message outright.
Example Record
ARC-Seal / ARC-Message-Signature / ARC-Authentication-ResultsMessage headers added by intermediaries — nothing for you to publish
Advantages
- Rescues legitimate forwarded mail
- No DNS record to maintain
- DDMARC monitors chains from Growth
Considerations
- Only helps if the forwarder implements it
- Receivers decide whether to trust a chain
- Does not replace SPF or DKIM
BIMI
Brand Indicators for Message Identification
Purpose
Displays your brand logo next to authenticated emails
How It Works
BIMI allows you to publish a logo that email clients display next to your emails when they pass DMARC. This increases brand visibility and recipient trust in legitimate emails.
Example Record
v=BIMI1; l=https://yourdomain.com/logo.svg; a=https://yourdomain.com/vmc.pemTXT record at default._bimi.yourdomain.com
Advantages
- Brand visibility
- Increases trust
- Marketing benefit
Considerations
- Requires p=quarantine or p=reject
- VMC certificate recommended
- Limited client support
DNSSEC and DANE — advisory posture checks
Two further controls sit underneath everything above. Neither is required for DMARC, and in DDMARC both are reported for information only.
DNSSEC
Cryptographically signs your DNS zone so a resolver can detect tampered answers. Without it, every record on this page — including your DMARC policy — can in principle be forged in transit. DDMARC reports your zone as secure, unsigned, bogus or indeterminate.
DANE / TLSA
Pins the certificate your mail servers present, anchored in DNSSEC rather than in the public certificate authorities. It complements MTA-STS. DDMARC looks up your TLSA records and probes each MX to confirm the live certificate really matches.
Informational, not scored. Both checks appear in the DNS health card as advisory findings and are deliberately excluded from the security grade — adding or removing DNSSEC or DANE will not move your score in either direction.
Understanding DMARC Alignment
Alignment is the key concept that makes DMARC effective. It ensures that the domain in the visible "From" header matches the domains authenticated by SPF and/or DKIM.
What is Alignment?
SPF Alignment
The domain in the MAIL FROM (envelope sender) must match or be a subdomain of the From header domain.
DKIM Alignment
The domain in the DKIM signature (d= tag) must match or be a subdomain of the From header domain.
DMARC Pass Requirements
For an email to pass DMARC, it needs:
- SPF pass AND SPF alignment
- — OR —
- DKIM pass AND DKIM alignment
adkim=r / aspf=rRecommendedRelaxed Alignment
Allows subdomains to pass alignment
Example: email from mail.example.com passes for example.com
adkim=s / aspf=sStrict Alignment
Exact domain match required
Example: email from mail.example.com fails for example.com
DMARC Policies Explained
The DMARC policy (p=) tells receivers what to do with emails that fail authentication.
p=noneMonitorNo action taken on failing emails. Use this to gather data before enforcement.
Best for: Starting DMARC deployment, identifying all email sources
p=quarantineQuarantineFailing emails are marked as suspicious (typically sent to spam/junk folder).
Best for: Intermediate step, testing enforcement before full reject
p=rejectRejectFailing emails are rejected outright and not delivered.
Best for: Full protection, maximum domain security
Understanding DMARC Reports
DMARC provides two types of reports to help you monitor your email authentication.
Aggregate Reports (RUA)
rua=mailto:...- Sent daily by email receivers
- XML format with statistical data
- Shows pass/fail rates by source IP
- Essential for monitoring deployment
Forensic Reports (RUF)
ruf=mailto:...- Sent per failing email (real-time)
- Contains redacted email samples
- Helpful for debugging specific failures
- Not sent by all providers (privacy)
With DDMARC, both addresses are generated per domain. Adding a domain mints a random token, and your rua and ruf mailboxes are built from it — that token is how an incoming report is matched back to your domain. Copy the record from Domains → your domain → DNS & Setup rather than typing one from an example. Forensic (RUF) report analysis is available from the Protect plan upward.
Key Takeaways
- SPF authorizes sending servers, DKIM verifies message integrity
- DMARC unifies SPF and DKIM with policy enforcement and reporting
- Start with p=none to monitor, then gradually move to p=reject
- Alignment ensures the visible From domain matches authenticated domains — relaxed (adkim=r/aspf=r) is the sensible default
- MTA-STS adds transport encryption, TLS-RPT tells you when it fails, BIMI adds brand visibility
- DNSSEC and DANE are worth having, but DDMARC treats them as advisory and never scores them
- Use DDMARC to automatically collect, parse, and visualize reports