Email security: SPF, DKIM, DMARC, BIMI and MTA-STS in detail

Email is the primary entry point for cyberattacks—94% of all malware is distributed via email (Verizon DBIR 2024). The problem stems from the protocol itself: SMTP, which dates back to 1982, lacks a built-in authentication mechanism. SPF, DKIM, DMARC, BIMI, and MTA-STS are the extensions that close this structural gap.

The Email Spoofing Problem

SMTP (Simple Mail Transfer Protocol) has no mechanism to verify whether the specified sender is actually the real sender:

telnet mail.example.com 25
EHLO attacker.com
MAIL FROM: ceo@ihrfirma.de   ← Can be set arbitrarily, no check!
RCPT TO: buchhaltung@ihrfirma.de
DATA
From: CEO<ceo@ihrfirma.de>
Subject: Urgent: Bank Transfer
...
.

Without protective measures, this email ends up in the inbox. The solution is a three-step authentication model:

SPF:    Which IP addresses are allowed to send emails for my domain?
        → DNS record with authorized sender IPs and hosts

DKIM:   Has the real domain owner cryptographically signed this email?
        → Private key on the sending server
        → Public key in the sender domain’s DNS

DMARC:  What should happen if SPF/DKIM fails?
        → Policy: none (monitoring only) / quarantine / reject
        → Combines SPF+DKIM via “alignment”
        → Reporting: who is sending on behalf of the domain?

SPF (Sender Policy Framework)

SPF specifies which servers are authorized to send emails from a domain.

SPF Record Structure

yourcompany.com.  IN  TXT  "v=spf1 ip4:185.220.101.0/24 include:spf.protection.outlook.com include:_spf.google.com -all"

Mechanisms:

ip4:203.0.113.0/24   → Authorized IPv4 address range
ip6:2001:db8::/32    → Authorized IPv6 address range
a                    → Authorized A record of your own domain
mx                   → Domain's MX records authorized
include:spf.google.com  → Include Google Workspace servers
include:servers.mcsv.net → Include Mailchimp
redirect=_spf.example.com → Full redirection

Qualifiers:

+ (pass)     → IP allowed (default if no qualifier)
- (fail)     → IP explicitly prohibited (Hard Fail) → recommended for -all
~ (softfail) → IP suspicious (Soft Fail) → Rollout stage
? (neutral)  → No statement → NEVER use as a final value

Complete examples:

# Google Workspace:
v=spf1 include:_spf.google.com -all

# Microsoft 365:
v=spf1 include:spf.protection.outlook.com -all

# Own IPs + Google + Newsletter:
v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:mailchimp.com -all

What SPF protects and does not protect

SPF protects:      Envelope-From (Return-Path, technical sender address)
SPF does NOT protect: Header-From (visible sender in the email client)

Attacker's trick:
  Envelope-From: phisher@legitdomain.com  ← SPF pass
  Header-From:   ceo@ihrfirma.de           ← Visible to users
→ SPF alone is not enough – DMARC resolves this via alignment

Email forwarding breaks SPF: The forwarding server is not listed in the original domain’s SPF record. Solution: SRS (Sender Rewriting Scheme) or a DKIM-only policy in DMARC.

SPF limits and common errors

Lookup limit: max. 10 DNS lookups!
  → include: counts as a lookup + all those contained within it
  → Too many includes → "too many DNS lookups" → SPF PermError
  → Solution: SPF flattening tools (enter IPs directly)
    Tools: spflatten.com, dmarcly.com

Common errors:
  WRONG: v=spf1 +all   ← All IPs allowed! No protection whatsoever!
  WRONG: ~all permanently → Soft Fail = warning only, no block
  CORRECT: -all as the final value

DKIM (DomainKeys Identified Mail)

DKIM cryptographically signs outgoing emails with a private key. Recipients verify the signature using the public key in DNS.

How DKIM Works

1. Sending server: signs email header + body with private RSA key
2. Signature: inserted into the email as a DKIM-Signature header
3. Receiving server: reads selector from signature, fetches public key from DNS
4. Checks: Is the signature valid? Is the body unchanged?

DKIM Header Example:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=yourcompany.com; s=mail2026;
  h=from:to:subject:date:message-id;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=abc123...signaturebytes...xyz456

Set up DKIM record

# DNS record:
# Name: {selector}._domainkey.{domain}
mail2026._domainkey.yourcompany.de  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G..."

# Microsoft 365 (CNAME variant):
selector1._domainkey.yourcompany.de  CNAME  selector1-yourcompany-de._domainkey.yourcompany.onmicrosoft.com
selector2._domainkey.yourcompany.de  CNAME  selector2-yourcompany-de._domainkey.yourcompany.onmicrosoft.com

Generate keys (Postfix example):

# RSA 2048-bit (minimum), 4096-bit recommended:
openssl genrsa -out dkim-private.pem 2048
openssl rsa -in dkim-private.pem -pubout -out dkim-public.pem

# Public key for DNS (remove header/footer, remove newlines):
cat dkim-public.pem | grep -v "^-" | tr -d '\n'

DKIM key rotation

Rotation without downtime:
  1. Publish new selector "selector2" in DNS
  2. Switch MTA to selector2
  3. Remove selector1 from DNS (after 48h TTL)
  → Advantage: DKIM key compromised → only rotation needed!

DO NOT delete old selectors immediately (in-transit emails!)

DKIM Alignment (important for DMARC)

Relaxed Alignment (adkim=r, default):
  → DKIM signature: d=yourcompany.com
  → From header:   user@ihrfirma.de
  → Subdomains allowed: mail.yourcompany.de matches yourcompany.de

Strict Alignment (adkim=s):
  → Exact match required
  → mail.yourcompany.de does NOT match yourcompany.de

Mailing list issue: Mailing lists modify the Subject/Body, which invalidates the DKIM signature. Solution: Use DMARC with adkim=r (relaxed) or resign mailing lists with their own DKIM.

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

DMARC combines SPF and DKIM and instructs receiving servers on what to do with non-compliant emails.

DMARC Record

_dmarc.yourcompany.de.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@ihrfirma.de; ruf=mailto:dmarc-forensics@ihrfirma.de; fo=1; adkim=r; aspf=r; pct=100; sp=reject"

Parameters:

v=DMARC1          → Required, version
p=none            → Policy: none/quarantine/reject
rua=mailto:...    → Aggregate Reports (daily, XML)
ruf=mailto:...    → Forensic Reports (per email; note privacy implications!)
fo=0|1|d|s        → Forensic Options (when to send forensic report?)
adkim=r|s         → DKIM Alignment: r=relaxed, s=strict
aspf=r|s          → SPF Alignment: r=relaxed, s=strict
pct=0-100         → Enforcement percentage (for phased rollout)
sp=none|quarantine|reject → Policy for subdomains
ri=86400          → Report interval in seconds (default: 1 day)

DMARC Alignment Logic

Email PASSES DMARC if AT LEAST ONE of the following applies:
  1. SPF Pass + SPF Aligned (Return-Path-Domain = From-Domain)
  2. DKIM Pass + DKIM Aligned (d= Domain = From-Domain)

Both can fail independently:
  → SPF fail (e.g., due to forwarding) + DKIM pass + DKIM aligned → DMARC PASS
  → SPF pass + DKIM fail → DMARC PASS (if SPF is aligned)

DMARC Rollout Strategy

Immediate activation of p=reject often blocks legitimate emails. A phased rollout is mandatory:

Step 1: Monitoring (p=none) - 2–4 weeks
  → Reports only, no action
  → Which systems are sending emails on behalf of your domain?
  → Analyze RUA reports: known senders? Unknown? Third-party providers?

Step 2: Quarantine with low pct - 2–4 weeks
  → p=quarantine; pct=10
  → 10% of failed emails → Spam folder
  → Monitor: legitimate emails in spam?
  → Gradually increase pct: 10 → 25 → 50 → 100

Step 3: Quarantine with 100% - 1-2 weeks
  → p=quarantine; pct=100
  → Final check: all legitimate senders configured?

Step 4: Reject (Goal!)
  → p=reject; pct=100
  → Failed emails are rejected (SMTP error)
  → Complete protection against email spoofing
  → Continue monitoring DMARC reports

Evaluating DMARC Reports

Aggregate Reports (rua) - XML Format:

<!-- Beispiel DMARC Aggregate Report -->

<feedback>
  <record>
    <row>
      <source_ip>40.107.22.15</source_ip>
        <!-- Microsoft IP -->
      <count>1250</count>
      
      <policy_evaluated>
        <disposition>none</disposition>
        
        <dkim>pass</dkim>
        
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <row>
      <source_ip>185.220.101.55</source_ip>
        <!-- Unbekannte IP! -->
      <count>12</count>
      
      <policy_evaluated>
        <disposition>none</disposition>
        
        <dkim>fail</dkim>
        
        <spf>fail</spf>
      </policy_evaluated>
    </row>
  </record>
</feedback>
<!-- Interpretation:
  1. Eintrag: legitime M365-Mails (alles PASS) → OK
  2. Eintrag: unbekannte IP, SPF+DKIM fail → Spoofing-Versuch!
     Maßnahme: IP prüfen, ggf. p=reject aktivieren
-->

Tools for Report Evaluation and Visualization:

dmarcian.com      → DMARC report visualization
dmarcanalyzer.com → GDPR-compliant, European provider
postmark          → DMARC wizard
easydmarc.com     → Guided DMARC rollout
parsedmarc        → Python CLI, SIEM integration
  pip install parsedmarc
  parsedmarc -c /etc/parsedmarc.ini --imap-host imap.example.com

BIMI (Brand Indicators for Message Identification)

BIMI displays the company logo next to emails in supported email clients.

BIMI DNS Record

default._bimi.yourcompany.com  IN  TXT  "v=BIMI1; l=https://ihrfirma.de/logo.svg; a=https://ihrfirma.de/VMC.pem"

Prerequisites:

1. DMARC p=quarantine or p=reject (pct=100)
2. SVG logo in "SVG Tiny PS" format
   → Square aspect ratio (1:1)
   → Max. 32 KB
   → No embedded JavaScript, no external resources
   → Hosted on HTTPS, publicly accessible
   → Validation: bimigroup.org/bimi-svg-validator/
3. VMC (Verified Mark Certificate) – required for Gmail!
   → Issued by: Entrust or DigiCert
   → Requires a registered trademark
   → Cost: approx. 1,000–1,500 EUR/year

Client Support:

Gmail:           Yes (VMC required for blue checkmark)
Apple Mail:      Yes (since iOS 16 / macOS Ventura)
Yahoo Mail:      Yes (VMC recommended, but not required)
Outlook.com:     In preparation (2026)
Microsoft 365:   Not yet

Benefits: Emails with a verified company logo are perceived as significantly more trustworthy and are opened more frequently. At the same time, fake emails lack the logo—a visible warning sign for recipients.

MTA-STS (Mail Transfer Agent Strict Transport Security)

MTA-STS prevents TLS downgrade attacks during email transport (relay-to-relay). Without MTA-STS, STARTTLS is opportunistic and can be disabled by MITM attacks.

MTA-STS Implementation

Step 1: Deploy policy file via HTTPS

URL: https://mta-sts.ihrfirma.de/.well-known/mta-sts.txt

version: STSv1
mode: enforce
mx: mail.yourcompany.com
mx: mx2.yourcompany.com
max_age: 604800

Modes:

testing:  Policy violated → Send email anyway, but generate a report
enforce:  Policy violated → DO NOT send email (Target!)
none:     Policy disabled

Step 2: Set DNS record

_mta-sts.yourcompany.de  IN  TXT  "v=STSv1; id=20260308001"

The id= field must change when the policy file changes (cache invalidation).

TLSRPT (TLS Reporting)

TLSRPT provides reports on failed TLS connections during email transport:

_smtp._tls.yourcompany.de  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@ihrfirma.de"

Reports include TLS connection errors, certificate errors, downgrade attempts, and MTA-STS policy violations.

DANE (DNS-based Authentication of Named Entities)

DANE is an alternative transport security mechanism that stores a TLS certificate directly in DNSSEC-secured DNS records.

_25._tcp.mail.yourcompany.de.  IN  TLSA  3 1 1 [SHA-256-HASH-DES-CERTIFICATE]

TLSA fields: 3 1 1 = Domain-Issued Certificate (DANE-EE), SubjectPublicKeyInfo, SHA-256 hash.

Prerequisite: DNSSEC must be enabled for the domain. Without DNSSEC, DANE offers no added value, as the TLSA record itself would be vulnerable to attack.

# Generate TLSA record hash:
openssl x509 -in mail.crt -pubkey -noout | \
  openssl pkey -pubin -outform DER | \
  openssl dgst -sha256 -binary | \
  xxd -p | tr -d '\n'

Common Misconfigurations

1. SPF too broad:
   WRONG: v=spf1 +all   ← All IPs allowed, no protection whatsoever!
   WRONG: v=spf1 ?all   ← Neutral, no security statement
   CORRECT: v=spf1 ... -all

2. SPF with ~all as a permanent solution:
   → Soft Fail = warning only; email is often delivered anyway
   → OK as a temporary rollout phase, but not as a final state

3. DKIM key too small:
   → 1024-bit: no longer secure (factoring possible)
   → Minimum: 2048 bits; Recommendation: 4096 bits or Ed25519

4. DMARC p=none permanently:
   → Collects data, but offers NO protection
   → Attackers can still spoof!
   → Goal: p=reject

5. DMARC rua address not monitored:
   → Reports arrive daily → are ignored
   → Unknown third-party senders and configuration issues remain undetected

6. Missing subdomain policy:
   → DMARC for yourcompany.com does NOT automatically protect test.yourcompany.com
   → Add sp=reject for complete subdomain protection

7. BIMI without VMC on Gmail:
   → Logo does not appear (Gmail requires VMC)
   → Yahoo Mail supports BIMI even without VMC

8. MTA-STS without DNSSEC:
   → The MTA-STS DNS record itself is vulnerable without DNSSEC
   → DNSSEC is strongly recommended

Implementation Roadmap

Weeks 1–2: Assessment
  □ Which systems send emails on behalf of your domain?
    - Your own mail servers
    - Transactional email (SendGrid, Mailgun, AWS SES)
    - Marketing email (Mailchimp, HubSpot, Brevo)
    - CRM systems, ERP, HR software
    - Customer portal notifications
  □ Set up SPF records for all legitimate senders
  □ Configure and test DKIM for all sender systems

Weeks 3–4: Activation with none policy
  □ Enable DMARC p=none with rua= for reports
  □ Collect and analyze reports (dmarcian, Postmark DMARC)
  □ Identify unknown senders and reconfigure them

Weeks 5–8: Quarantine rollout
  □ p=quarantine; pct=10 → gradually increase to 100
  □ Monitoring: legitimate emails ending up in recipients’ spam folders?
  □ All third-party senders: SPF include + DKIM configured?
  □ Check subdomains: set sp= Policy

Weeks 9–12: Reject and hardening
  □ p=reject; pct=100 → full protection
  □ MTA-STS: testing → enforce
  □ Enable TLSRPT
  □ Prepare BIMI (order VMC, validate SVG logo)

Ongoing:
  □ Evaluate DMARC reports weekly
  □ Configure new email services in SPF and DKIM immediately
  □ DKIM key rotation: every 6–12 months
  □ Keep SPF up to date during migrations and with new services

DNS Configuration: Overview

# SPF:
yourcompany.com              TXT  "v=spf1 ip4:185.220.101.0/24 include:spf.protection.outlook.com -all"

# DKIM:
mail2026._domainkey.yourcompany.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0..."

# DMARC:
_dmarc.yourcompany.com       TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@ihrfirma.de; pct=100; sp=reject"

# MTA-STS:
_mta-sts.yourcompany.de     TXT  "v=STSv1; id=20260308001"

# TLSRPT:
_smtp._tls.yourcompany.de   TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@ihrfirma.de"

# BIMI:
default._bimi.yourcompany.de  TXT  "v=BIMI1; l=https://ihrfirma.de/logo.svg; a=https://ihrfirma.de/VMC.pem"

# MTA-STS Policy File (HTTPS):
# https://mta-sts.ihrfirma.de/.well-known/mta-sts.txt

Tools for Testing and Debugging

# Test SPF:
dig TXT yourcompany.de | grep spf
nslookup -type=TXT yourcompany.de

# Test DKIM:
dig TXT mail2026._domainkey.yourcompany.de

# Test DMARC:
dig TXT _dmarc.yourcompany.de

# Test BIMI:
dig TXT default._bimi.yourcompany.de

# Test MTA-STS:
dig TXT _mta-sts.yourcompany.de

Online Tools:

mxtoolbox.com/SuperTool.aspx  → Check SPF, DKIM, DMARC
mail-tester.com               → Overall email score (send test email)
dmarcian.com/dmarc-inspector/ → Analyze DMARC record
internet.nl                   → BSI-recommended checker
postmaster.google.com         → Google Postmaster Tools
toolbox.googleapps.com/apps/checkmx/ → Google Admin Toolbox

Email Security Checklist

SPF:
  □ SPF record present
  □ Ends with -all (Hard Fail)
  □ All email services listed (Mailchimp, HubSpot, etc.)
  □ Under 10 DNS lookups

DKIM:
  □ DKIM configured for all sender systems
  □ Key length at least 2048 bits
  □ Key rotation scheduled (6–12 months)

DMARC:
  □ DMARC set to p=reject (after monitoring phase)
  □ rua= set for aggregate reports
  □ sp= set for subdomains
  □ Reports are evaluated regularly

Transport Security:
  □ MTA-STS set to mode=enforce
  □ TLSRPT enabled

Optional (recommended):
  □ BIMI configured (SVG logo, VMC)
  □ DNSSEC active for the domain
  □ DANE (TLSA record) for own mail servers

---

Email authentication is not an optional security measure. Google and Yahoo have required DMARC for bulk senders since 2024, and Microsoft 365 is gradually increasing its requirements. Companies without DMARC risk not only spoofing attacks against customers and partners, but also reduced deliverability of legitimate emails./ceo@ihrfirma.de