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

Email spoofing - where someone sends emails using your domain as the sender address - is the most common entry point for phishing attacks targeting customers and employees. The solution has been available for years: SPF, DKIM, and DMARC together form a multi-layered email authentication architecture. When properly configured, it prevents attackers from misusing your domain.

The Email Spoofing Problem

Why email spoofing is possible:

SMTP (Simple Mail Transfer Protocol) from 1982 has no built-in authentication:

• Any SMTP server can set any "From:" header
• "From: ceo@yourcompany.com" can be set by any attacker

Technical SMTP exchange (attacker's perspective):

[Attacker's server] EHLO evil.server.com
                    MAIL FROM: <ceo@yourcompany.com>
                    RCPT TO: <employee@yourcompany.com>
                    DATA
                    From: CEO <ceo@yourcompany.com>
                    Subject: Urgent: Wire transfer!
                    .

Recipient sees: "From: CEO ceo@yourcompany.com"

Without SPF/DKIM/DMARC there is no way to tell if it is legitimate!

Solution - Three-step authentication model:

SPF: Which IP addresses are allowed to send emails for my domain?

• DNS record, contains authorized sender IPs/hosts
• Recipient checks: does the email come from an allowed IP?

DKIM: Has the real domain owner cryptographically signed this email?

• Private key on the sending server
• Public key in the sender domain's DNS
• Recipient verifies signature

DMARC: What should happen if SPF/DKIM fails?

• Policy: none (monitoring only) / quarantine / reject
• Combines SPF+DKIM via "alignment"
• Reporting: Aggregate reports (who is sending on behalf of my domain)

SPF (Sender Policy Framework)

SPF implementation:

DNS record (Type: TXT, Name: @ or yourdomain.com):

v=spf1 [mechanisms] -all

Mechanisms (Authorization Rules):

Qualifiers (What happens on a match):

Typical example:

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

Meaning: IP 185.220.101.x (own mail server), Microsoft 365, and Google Workspace are authorized; all others FAIL!

SPF limits and common errors:

Lookup limit: max. 10 DNS lookups!

• include: counts as a lookup + all those contained within
• Too many includes → "too many DNS lookups" → SPF error
• Solution: SPF flattening tools (substitute IP ranges)

SPF only protects the Envelope-From (Return-Path)!

• NOT the Header-From (visible sender)
• DMARC solves the problem via "alignment"

Forwarding breaks SPF!

• Email forwarding: new sender IP not in SPF
• Solution: SRS (Sender Rewriting Scheme) or DKIM-only policy

-all vs. ~all:

• ~all (Soft-Fail): Emails are delivered, marked
• -all (Hard-Fail): Emails are rejected
• Recommendation: Start with ~all, migrate to -all once stable

DKIM (DomainKeys Identified Mail)

DKIM Implementation:

How it works:

1. Sending server creates signature using email content + headers
2. Signature is appended as a DKIM-Signature header
3. Recipient reads selector from signature → finds DNS record
4. Public key from DNS → verify signature

DKIM Header Example:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=yourdomain.com; s=mail2026;
  h=from:to:subject:date:message-id;
  bh=BASE64_BODY_HASH;
  b=BASE64_SIGNATURE

DNS record for DKIM (Type: TXT, Name: {selector}._domainkey.{domain}):

mail2026._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G..."

• selector: mail2026 (freely selectable, e.g., "google", "mail", date)
• Multiple selectors possible → Rotation without downtime!

Key generation (Postfix example):

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

# Extract public key for DNS:
openssl rsa -in dkim_private.pem -pubout -outform DER | base64 -w 0

DKIM Best Practices:

• RSA keys: min. 2048 bits (4096 recommended, check header limits!)
• Ed25519 as an alternative: shorter, faster, modern
• Key rotation: every 6-12 months
• DO NOT delete old selectors immediately (in-transit emails!)
• Signing: sign all outgoing emails (including transactional ones!)

DKIM alignment (important for DMARC):

The DKIM signature domain (d=yourdomain.com) must match the From: header domain. Both must contain "yourdomain.com" for PASS.

• Relaxed Alignment (default): Subdomains allowed - sub.yourdomain.com matches yourdomain.com ✓
• Strict Alignment: exact match required - sub.yourdomain.com does NOT match yourdomain.com ✗

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

DMARC - The Link:

DMARC combines SPF + DKIM and defines:

1. What should happen if BOTH (SPF and DKIM) fail?
2. Where should aggregate reports be sent?
3. How strict should the policy be?

DNS Record:

Type: TXT
Name: _dmarc.yourdomain.com
Value: "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com;
       ruf=mailto:dmarc-forensic@yourdomain.com; pct=100; adkim=r; aspf=r"

DMARC tags:

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)

Examples:

• SPF fail (Forwarding) + DKIM pass + DKIM aligned - DMARC PASS!
• SPF pass + DKIM fail - DMARC PASS (if SPF aligned)

DMARC rollout (CRITICAL - do not set to reject immediately!):

Step 1: none (Monitoring, 2-4 weeks) p=none; rua=mailto:dmarc@yourdomain.com

• Collects reports: WHO is sending emails from your domain?
• No blocking! Visibility only.
• Analysis: known senders? Unknown? Third-party providers?

Step 2: quarantine with low pct (2-4 weeks) p=quarantine; pct=10; rua=mailto:dmarc@yourdomain.com

• 10% of failed emails - Spam folder
• Monitor: legitimate emails in spam?
• Gradually increase pct: 10 - 25 - 50 - 100

Step 3: Quarantine at 100% (1-2 weeks) p=quarantine; pct=100

• All failed emails - Spam
• Final check: Are all legitimate senders configured?

Step 4: Reject (Goal!) p=reject; pct=100

• Failed emails are rejected (SMTP error)
• Complete protection against spoofing!
• Continue monitoring reports

Understanding DMARC Reports:

Aggregate Reports (XML via email daily/weekly):

• From: receiving email providers (Gmail, Microsoft, etc.)
• Content: Source IP, SPF result, DKIM result, DMARC result, number of emails
• Visualization tools: Postmark DMARC, MxToolbox, Dmarcian

Sample report data:

• IP 203.0.113.1: 500 emails, SPF pass, DKIM pass - DMARC pass
• IP 198.51.100.5: 3 emails, SPF fail, DKIM fail - DMARC fail
• Unknown IP is sending emails as your domain! - Spoofing attempt!

BIMI (Brand Indicators for Message Identification)

BIMI - Logo display as a trust signal:

What is BIMI?

• Standard for displaying logos directly in email clients (Gmail, Apple Mail, Yahoo)
• Logo appears next to sender address - Trust signal for recipients
• Prerequisite: DMARC p=quarantine or p=reject!

Advantages:

• Clear sender identification: genuine emails are recognizable
• Phishing detection: fake emails have no logo
• Brand awareness: logo in every email inbox

DNS record (Type: TXT, Name: default._bimi.yourdomain.com):

v=BIMI1; l=https://yourdomain.com/bimi-logo.svg; a=https://yourdomain.com/vmc.pem

• l=: URL to the SVG logo (Tiny PS spec, hosted on HTTPS)
• a=: URL to the VMC (Verified Mark Certificate), required for Gmail!

VMC (Verified Mark Certificate):

• Issued by: Entrust or DigiCert
• Requires: registered trademark (trademark registration!)
• Cost: ~$1,000-1,500/year
• Verifies: logo matches trademark, domain ownership

Logo requirements:

• SVG format (Scalable Vector Graphics)
• Tiny PS (SVG Profile)
• Square aspect ratio (1:1)
• Hosted under HTTPS on your own domain
• Publicly accessible (no authentication required)

SVG validation: https://bimigroup.org/bimi-svg-validator/

BIMI support:

MTA-STS and TLS-RPT

MTA-STS (Mail Transfer Agent Strict Transport Security):

Problem without MTA-STS:

• SMTP-TLS is opportunistic: Servers ask if TLS is possible
• An attacker can force a TLS downgrade → Plaintext transmission!
• STARTTLS stripping attacks possible

MTA-STS solves this:

• Receiving domain publishes policy: "I accept ONLY TLS!"
• Sending mail servers cache this policy
• If TLS is not possible: Email IS NOT sent (instead of being sent insecurely!)

Implementation:

1. Policy file under HTTPS: https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

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

2. DNS record (Type: TXT, Name: _mta-sts.yourdomain.com):

v=STSv1; id=20260304001

id= changes when the policy changes (cache invalidation!).

Modes:

TLS-RPT (TLS Reporting):

Sending servers report TLS connection issues. DNS record (Type: TXT, Name: _smtp._tls.yourdomain.com):

v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com

Reports include:

• TLS connection errors (certificate errors, downgrade attempts)
• Number of successful TLS connections
• MTA-STS policy violations
• Useful for diagnosing email delivery issues!

Implementation Roadmap

Phased rollout (recommended):

Weeks 1-2: Inventory

• 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 your own mail server

Weeks 3-4: Activation with none policy

• Activate DMARC p=none with rua= for reports
• Collect reports (DMARC Analyzer, Postmark DMARC)
• Identify and configure unknown senders

Weeks 5-8: Quarantine rollout

• p=quarantine pct=10 - increase to 25 - 50 - 100
• Monitoring: Are legitimate emails ending up in recipients' spam folders?
• All third-party senders: Is SPF include + DKIM configured?
• Check subdomains: sp= Policy for *.yourdomain.com

Weeks 9-12: Reject and Hardening

• p=reject pct=100 - FULL PROTECTION!
• MTA-STS: testing - enforce
• Enable TLS-RPT
• Prepare BIMI (Order VMC, prepare SVG)
• Set up monitoring dashboard

Ongoing:

• Evaluate DMARC reports weekly
• Configure new email senders immediately
• DKIM key rotation: annually
• Keep SPF up to date (new services, migrations)

DNS Configuration Quick Overview:

yourdomain.com              TXT  "v=spf1 ... -all"
mail2026._domainkey.domain  TXT  "v=DKIM1; k=rsa; p=..."
_dmarc.yourdomain.com       TXT  "v=DMARC1; p=reject; rua=mailto:..."
_mta-sts.yourdomain.com     TXT  "v=STSv1; id=20260304001"
mta-sts.yourdomain.com      HTTPS-hosted policy file
_smtp._tls.yourdomain.com   TXT  "v=TLSRPTv1; rua=mailto:..."
default._bimi.yourdomain.com TXT "v=BIMI1; l=...; a=..."

Testing Tools:

• MxToolbox: https://mxtoolbox.com/SPFRecordViewer.aspx
• DMARC Analyzer: https://dmarcanalyzer.com
• Mail-Tester: https://www.mail-tester.com (overall email score)
• Check-Auth: checkdmarc (Python CLI tool for all records)

---

Email authentication is no longer 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 but also reduced deliverability of legitimate emails. AWARE7 audits email security configurations and supports the DMARC rollout until full p=reject is achieved.

Request an email security check | Phishing simulation/ceo@yourcompany.com/ceo@yourcompany.com/employee@yourcompany.com/ceo@yourcompany.com