Email Security Architecture: SPF, DKIM, DMARC, and MTA-STS Implementation

By /

Introduction

Email remains the primary attack vector for most organizations, yet email authentication is frequently misconfigured or incomplete. A properly implemented email security stack — SPF, DKIM, DMARC, and MTA-STS — dramatically reduces phishing, spoofing, and business email compromise (BEC) attacks. This guide walks through implementing each layer with production-ready configurations.

SPF: Sender Policy Framework

SPF declares which IP addresses are authorized to send email for your domain. Receiving servers check the envelope sender against your SPF record to verify legitimacy.

Building Your SPF Record

Start by inventorying every system that sends email on behalf of your domain — mail servers, marketing platforms, ticketing systems, and transactional email services:

; SPF record for example-corp.com
; Authorize: mail server IP, backup MX, and SendGrid
example-corp.com.  IN  TXT  "v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 include:sendgrid.net -all"

Key SPF mechanisms:

  • ip4: / ip6: — authorize specific IP addresses or ranges
  • a: — authorize the IP of a hostname’s A record
  • include: — incorporate another domain’s SPF policy (for SaaS providers)
  • -all — hard fail: reject all unauthorized senders (recommended)
  • ~all — soft fail: mark as suspicious but accept (use during rollout only)

SPF Lookup Limit

SPF has a 10 DNS lookup limit. Each include:, a:, mx:, and redirect= counts as a lookup. Exceeding this limit causes SPF validation to fail entirely. Flatten your SPF record if approaching the limit:

# Check SPF lookup count
dig +short TXT example-corp.com | grep spf
# Use an online SPF checker to count lookups

DKIM: DomainKeys Identified Mail

DKIM adds a cryptographic signature to outbound emails, allowing receivers to verify the message wasn’t modified in transit and was sent by an authorized system.

Key Generation

Generate a 2048-bit RSA key pair for DKIM signing:

# Generate DKIM key pair
openssl genrsa -out dkim-private.key 2048
openssl rsa -in dkim-private.key -pubout -outform PEM -out dkim-public.key

# Extract the public key for DNS (remove headers, join lines)
grep -v "^-" dkim-public.key | tr -d '\n'

DNS Record

Publish the public key as a TXT record at selector._domainkey.example-corp.com:

default._domainkey.example-corp.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."

Mail Server Configuration

Configure your MTA to sign outbound messages. With Rspamd (recommended for modern deployments):

# /etc/rspamd/local.d/dkim_signing.conf
enabled = true;
path = "/var/lib/rspamd/dkim/$domain.key";
selector = "default";
sign_authenticated = true;
sign_local = true;
use_domain = "envelope";

DMARC: Domain-based Message Authentication

DMARC ties SPF and DKIM together with a policy that tells receivers what to do when authentication fails. It also provides aggregate reporting so you can monitor authentication results across all receiving servers.

Policy Progression

Roll out DMARC in stages to avoid disrupting legitimate email:

  1. Monitor — p=none with reporting to collect data without affecting delivery
  2. Quarantine — p=quarantine to send failing messages to spam
  3. Reject — p=reject to block all unauthorized messages (target state)
; Stage 1: Monitor (deploy first, analyze reports for 2-4 weeks)
_dmarc.example-corp.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"

; Stage 3: Reject (production target)
_dmarc.example-corp.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; fo=1"

Analyzing DMARC Reports

DMARC aggregate reports (RUA) are XML files sent daily by receiving servers. Use tools like parsedmarc to process them:

pip install parsedmarc
parsedmarc -o report.json /path/to/dmarc-report.xml.gz
# Outputs structured JSON with pass/fail statistics per source IP

MTA-STS: Mail Transfer Agent Strict Transport Security

MTA-STS forces sending servers to use TLS when delivering mail to your domain, preventing downgrade attacks and man-in-the-middle interception of email in transit.

Implementation

MTA-STS requires two components — a DNS TXT record and a policy file served over HTTPS:

; DNS record
_mta-sts.example-corp.com.  IN  TXT  "v=STSv1; id=20260413"

# Policy file at https://mta-sts.example-corp.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mail.example-corp.com
max_age: 604800

The mode: enforce directive tells sending MTAs to only deliver over verified TLS connections. If TLS negotiation fails, the message should not be delivered in plaintext.

Verification and Testing

After implementing all four layers, verify your configuration:

# Check SPF
dig +short TXT example-corp.com | grep spf

# Check DKIM
dig +short TXT default._domainkey.example-corp.com

# Check DMARC
dig +short TXT _dmarc.example-corp.com

# Check MTA-STS
dig +short TXT _mta-sts.example-corp.com
curl https://mta-sts.example-corp.com/.well-known/mta-sts.txt

# Send test email and check headers for:
# Authentication-Results: spf=pass dkim=pass dmarc=pass

Use mail-tester.com to get a comprehensive deliverability score that checks all authentication layers.

Conclusion

A complete email authentication stack — SPF with hard fail, DKIM with 2048-bit keys, DMARC at reject policy, and MTA-STS enforcing TLS — provides defense in depth against email-based attacks. Implement in stages, starting with SPF and DKIM, then DMARC in monitor mode, and finally MTA-STS. The aggregate reports from DMARC provide ongoing visibility into who is sending email on behalf of your domain, making it both a security control and an operational monitoring tool.

Scroll to Top