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

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:
  → No built-in authentication mechanism
  → Any SMTP server can set any "From:" header
  → "From: ceo@yourcompany.com" → Controlled by the attacker!

  Technical process:
  [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: &quot;From: CEO <ceo@yourcompany.com>&quot;
  → Without SPF/DKIM/DMARC: no way to tell if it’s 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)
  Value: "v=spf1 [mechanisms] -all"

Mechanisms (Authorization Rules):
  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                   → Authorized MX records of the domain
  include:spf.google.com → Include Google Workspace servers
  include:servers.mcsv.net → Include Mailchimp

Qualifiers (What happens on a match):
  +all   → authorized (default if no qualifier)
  -all   → not authorized (FAIL!) → recommended for the final entry
  ~all   → soft-fail (suspicious, but do not block)
  ?all   → neutral (no statement) → BAD! Provides no security

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: authorized (own mail server)
  → Microsoft 365: authorized
  → Google Workspace: 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: mail2026._domainkey.yourdomain.com
  Value: "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G..."

  Structure:
  {selector}._domainkey.{domain}
  → 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):
  → DKIM signature: d=yourdomain.com
  → From header:   from@yourdomain.com
  → Alignment: both must contain "yourdomain.com" → 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:
  v=DMARC1          → Required, version
  p=none             → Policy: none/quarantine/reject
  rua=mailto:...     → Aggregate reports to this address
  ruf=mailto:...     → Forensic reports (optional, privacy implications!)
  pct=100            → % of emails to which the policy applies (rollout!)
  adkim=r            → DKIM alignment: r=relaxed, s=strict
  aspf=r             → SPF alignment: r=relaxed, s=strict
  sp=reject          → Policy for subdomains

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:
  → 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
  Value: "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:
  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 progress (2026)
  Microsoft 365: Not yet

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:
     URL: https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
     Content:
       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
     Value: "v=STSv1; id=20260304001"
     → id= changes when the policy changes (cache invalidation!)

  Modes:
    testing:  Policy violated → Send anyway, report only
    enforce:  Policy violated → Send denied (Target!)
    none:     Disabled

TLS-RPT (TLS Reporting):

  Sending servers report TLS connection issues:
  DNS record:
    Type: TXT
    Name: _smtp._tls.yourdomain.com
    Value: "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