Original Email System Analogy

The original email system is like an unsecured postcard where anyone could write any name in the “From” section, and the post office would deliver it without question. Modern protocols are like adding security features to that postcard after the fact:

  • <3Cstrong>SPF is like the post office checking a list of approved couriers.
  • DKIM is a tamper-evident wax seal on the message.
  • DMARC is the final inspector ensuring the name on the seal matches the name written on the front.
  • ARC is like a certified chain of custody log stamped onto the postcard by every intermediate post office that handles it. If the postcard is forwarded and the original seal (DKIM) must be broken to reroute it, the ARC stamps prove to the final recipient that the postcard was authentic when it first entered the system and has been handled by trusted intermediaries ever since.

SPF (Sender Policy Framework)

What SPF Solves (Fundamental context)

SPF prevents unauthorized sending infrastructure from sending mail on behalf of your domain.
It answers: “Is this sending IP allowed to send email for this domain?”

Design Flow

  1. Receiving MTA extracts MAIL FROM / Return-Path
  2. Queries DNS for SPF TXT record
  3. Compares sender IP against authorized IP mechanisms
  4. Returns result: Pass | Fail | SoftFail | Neutral | None

Key Architectural Point: SPF validates infrastructure identity. It does not validate the visible From header.

SPF Limitations (By Design)

  • Breaks on forwarding
  • DNS lookup limit (10)
  • Does not protect display name spoofing
  • Does not validate message integrity

Real Use Case

Think of SPF as a guest list at a building entrance. If your name (IP) isn’t on the list, security flags you.
Real-world: Prevents attackers from sending email “from your domain” using random servers.

DKIM (DomainKeys Identified Mail)

What DKIM Solves

DKIM ensures message integrity and domain accountability using cryptography.
It answers: “Was this message modified after it left the sender’s domain?”

Design Flow

  1. Sending MTA hashes selected headers + body
  2. Hash is signed with private key
  3. Signature added to DKIM-Signature header
  4. Receiver retrieves public key from DNS using selector
  5. Recalculates hash and verifies signature

Critical Architectural Insight: DKIM binds message content to sending domain. Survives forwarding (if content not modified).

DKIM Limitations

  • Body/header modification breaks DKIM
  • Does not enforce policy by itself
  • Alignment not mandatory without DMARC

Use Case

DKIM is like tamper-proof sealing wax on a letter. If broken, the receiver knows someone altered it.
Real-world: Ensures invoices, approvals, and legal emails are not modified in transit.

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

Why DMARC Was Necessary

SPF and DKIM existed but:

  • Not enforced
  • Not aligned with visible sender
  • No feedback loop

DMARC introduces policy, alignment, and reporting.

DMARC Architectural Design Flow

  1. Receiver evaluates SPF & DKIM
  2. Checks alignment with From domain
  3. Applies domain policy: none, quarantine, or reject
  4. Sends aggregate (RUA) and forensic (RUF) reports

Alignment (Critical for Architects)

  • SPF alignment: MAIL FROM domain = From domain
  • DKIM alignment: d= domain = From domain

DMARC Limitations

  • Forwarding breaks SPF alignment
  • Mailing lists modify content → DKIM fails
  • No trust propagation across hops

Use Case

DMARC is your written security policy: “If email fails checks, block it.”
Real-world: Stops brand spoofing and CEO fraud emails.

ARC (Authenticated Received Chain)

Why ARC Was Introduced

DMARC fails in legitimate multi-hop scenarios: Mailing lists, Forwarders, Secure email gateways.
ARC solves: “How can downstream receivers trust authentication that already happened upstream?”

ARC Deep Architectural Design

ARC vs DMARC – Architectural Reality

Scenario Without ARC With ARC Forwarded Mail DMARC Fail DMARC Context Preserved Mailing Lists Rejected Delivered Secure Gateway Rewrite Fail Trust-Based Allow

Implementing SPF, DKIM, and DMARC

Prerequisites (Non-Negotiable)

  1. You own and control the domain (DNS access required)
  2. You have identified all outbound mail sources (M365, Proofpoint, CRM, etc.)
  3. DNS provider supports TXT records and 2048-bit DKIM keys
  4. You understand DNS lookups and SMTP flow

SPF Implementation Steps

Step 1: Inventory All Sending Sources
Create a list of every system that sends mail as your domain (e.g., M365, Proofpoint, App servers).

Step 2: Create the SPF Record (Syntax)
v=spf1
Example: v=spf1 include:spf.protection.outlook.com include:_spf.pphosted.com ip4:203.0.113.10 -all

Step 3: Understand Each Mechanism

  • include: – Import another domain’s SPF
  • ip4: / ip6: – Explicitly allowed IP
  • -all – Hard fail for everything else

Step 4: Qualifier Logic
Start with ~all (SoftFail) then move to -all (HardFail) after validation.

Step 5: DNS Lookup Limit
Maximum 10 DNS lookups allowed (include, a, mx, exists, etc.).

DKIM Implementation Steps

Step 1: Enable DKIM in Sending Platform
(e.g., Enable in M365, Generate key in Proofpoint).

Step 2: Create DKIM DNS Record
Format: <selector>._domainkey.example.com
Value: v=DKIM1; k=rsa; p=... (Public Key)

Step 4: DKIM Signing Process

  1. Sending MTA hashes headers + body
  2. Hash is signed with private key
  3. DKIM-Signature header added

DMARC Implementation Steps

Step 1: Understand Alignment
SPF and DKIM must align with the visible From domain.

Step 2: Create Initial DMARC Record (Monitor Only)
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r;

Analyze DMARC Reports: Duration 2-4 weeks. Then move to enforcement (`p=quarantine`, then `p=reject`).

Reference Articles & RFCs

Core RFCs (Primary Standards – MUST READ)

Government / Research-Grade Whitepapers

Enterprise Deployment