Email is the backbone of business communication — and one of the oldest and most abused attack vectors in cybersecurity. Attackers can trivially forge a "From" address, making a message appear to come from your CEO, your bank, or a trusted vendor. The DMARC framework exists to close that gap by combining cryptographic signing with published policy, so any receiving server in the world can verify whether a message genuinely originated from the claimed domain.
This article walks through how SPF, DKIM, and DMARC work individually and how they compose into a complete email authentication system — along with the role of mail gateways as a final inspection layer.
Why Email Authentication Matters
The Simple Mail Transfer Protocol (SMTP), designed in 1982, has no built-in mechanism to verify that the sender is who they claim to be. A malicious actor can open a connection to any SMTP relay and declare any "From" address they like — there is nothing in the base protocol to stop them.
This gap enables two broad classes of attack:
- Brand impersonation — attackers send phishing emails that appear to come from your domain, deceiving your customers, partners, or employees.
- Business Email Compromise (BEC) — attackers forge an executive's address to trick finance teams into fraudulent wire transfers.
In October 2023, Google and Yahoo jointly announced that any bulk sender delivering mail to their platforms must have DMARC in place. The deadline pushed DMARC from a "best practice" to an operational requirement for any organization that sends email.
The Three Pillars: SPF, DKIM, and DMARC
These three mechanisms are not competing alternatives — they are layers. SPF defines which servers may send for your domain. DKIM proves a message was signed by your domain's private key. DMARC ties them together into a policy and tells receiving servers what to do when a message fails.
┌──────────────────────────────────────────────────────────────────────┐
│ EMAIL AUTHENTICATION STACK │
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ DMARC – Policy: what to do on failure + alignment check │ │
│ └────────────────────────┬────────────────────────────────────┘ │
│ │ depends on │
│ ┌───────────────┴───────────────┐ │
│ ▼ ▼ │
│ ┌─────────────────┐ ┌─────────────────────┐ │
│ │ SPF │ │ DKIM │ │
│ │ Authorized │ │ Cryptographic │ │
│ │ sending IPs │ │ message signature │ │
│ └─────────────────┘ └─────────────────────┘ │
│ │ │ │
│ └───────────────┬───────────────┘ │
│ ▼ │
│ DNS TXT Records │
│ (published by the sending domain) │
└──────────────────────────────────────────────────────────────────────┘
SPF — Sender Policy Framework
SPF answers one question: which mail servers are authorized to send email on behalf of this domain?
The domain owner publishes a DNS TXT record that lists every server — by IP address, CIDR range, or hostname — that is permitted to originate mail for that domain. When a receiving server gets a message claiming to be from example.com, it queries the DNS record for example.com and checks whether the connecting IP appears on the authorized list.
Reading an SPF Record
A real-world SPF record looks like this:
v=spf1 include:spf.protection.outlook.com -all
Breaking it down:
| Field | Meaning |
|---|---|
v=spf1 | SPF version 1 — required first token |
include:spf.protection.outlook.com | Delegate to Microsoft's IP list; any IP on that list is authorized |
-all | Hard fail — reject mail from any IP not covered by the preceding rules |
SPF Result Qualifiers
The final -all (or its variants) is the policy enforcement instruction:
| Qualifier | Syntax | Effect |
|---|---|---|
| Pass | +all | Accept mail from any server (effectively disables SPF — rarely used) |
| Fail | -all | Hard reject — discard unauthorized mail |
| SoftFail | ~all | Flag the message but deliver it — useful during a testing phase |
| Neutral | ?all | No assertion about authorization |
Most production domains use -all to enforce strict rejection, but ~all is common during initial deployment when operators are not yet confident they have captured every legitimate sending source.
SPF's Limitation
SPF only validates the envelope sender (the MAIL FROM address used in the SMTP handshake), not the From: header that end users see. An attacker can pass SPF on the envelope while still displaying a forged From: header — which is exactly why DKIM and DMARC are also needed.
DKIM — DomainKeys Identified Mail
DKIM answers a different question: was this message signed by the domain's private key?
Where SPF is about network path (which IP sent the message), DKIM is about cryptographic provenance (who signed the message content). It uses asymmetric key cryptography: the sending domain holds a private key used to sign outgoing messages, and the corresponding public key is published in DNS for any receiver to retrieve.
How DKIM Signing Works
SENDING SIDE
┌─────────────────────────────────┐
│ Mail Transfer Agent (MTA) │
│ │
│ 1. Hash selected headers │
│ and message body │
│ │
│ 2. Encrypt hash with │◀─── Private key (secret, held by
│ domain's private key the sending organization only)
│ │
│ 3. Embed signature in a │
│ DKIM-Signature header │
└─────────────────────────────────┘
│
│ Email with DKIM-Signature header
▼
──────── Internet ────────
│
▼
RECEIVING SIDE
┌─────────────────────────────────┐
│ Receiving MTA │
│ │
│ 1. Extract signing domain │
│ from DKIM-Signature header │
│ │
│ 2. Fetch public key from DNS │◀─── e.g. selector._domainkey.example.com
│ │
│ 3. Decrypt signature using │
│ the public key │
│ │
│ 4. Independently hash the │
│ headers and body │
│ │
│ 5. Compare: do the hashes │
│ match? │
└─────────────────────────────────┘
│
┌─────┴──────┐
▼ ▼
PASS FAIL
Signature Signature invalid or
valid missing — DKIM fails
Why Forgery Is Computationally Impossible
The security rests on a fundamental property of asymmetric cryptography: only the entity that holds the private key can produce a signature that the corresponding public key can verify. Cengage's private key exists only on Cengage's mail infrastructure. An attacker sending a forged message "from" cengage.com does not have that private key, so they cannot produce a valid signature — and any signature they fabricate will fail the verification step against Cengage's published public key.
This gives the receiving server non-repudiation: a DKIM-passing message is cryptographic proof that the claimed domain's infrastructure processed and signed it.
DKIM Selectors
A domain can publish multiple DKIM keys simultaneously, distinguished by a selector prefix in the DNS lookup path. This allows key rotation and separate keys for different mail streams (transactional, marketing, etc.) without disrupting active signatures.
DMARC — Domain-Based Message Authentication, Reporting, and Conformance
SPF and DKIM each independently verify aspects of a message's origin — but neither tells the receiving server what to do when they fail. DMARC closes that gap by:
- Adding an alignment check — the domain in the
From:header must match the domain that passed SPF or DKIM (not just any domain). - Declaring an explicit policy — the domain owner specifies what should happen to messages that fail the alignment check.
- Enabling aggregate and forensic reporting — receiving servers send anonymized reports back to the domain owner, providing visibility into who is sending mail on their behalf.
DMARC DNS Record Structure
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:forensics@example.com; pct=100
| Tag | Meaning |
|---|---|
v=DMARC1 | DMARC version — required |
p=reject | Policy: reject failing messages outright |
p=quarantine | Alternative policy: deliver to spam/junk folder |
p=none | Monitoring-only mode — collect reports without enforcing |
rua= | URI for aggregate reports (daily summaries) |
ruf= | URI for forensic/failure reports (individual message data) |
pct= | Percentage of mail to apply the policy to (100 = all mail) |
DMARC Alignment
DMARC alignment is the bridge that closes the SPF From: header gap. For a message to pass DMARC, at least one of the following must be true:
- SPF alignment: the domain in the
MAIL FROM(envelope sender) must match theFrom:header domain. - DKIM alignment: the
d=domain in the DKIM signature must match theFrom:header domain.
This means an attacker cannot pass SPF with their own domain while forging your From: address — DMARC will detect the mismatch.
DMARC Deployment Progression
Organizations typically roll out DMARC in three phases to avoid accidentally blocking legitimate mail:
Phase 1: Monitor Phase 2: Quarantine Phase 3: Enforce
p=none p=quarantine p=reject
│ │ │
│ Collect reports, │ Failing mail goes │ Failing mail is
│ discover all │ to spam folder — │ rejected outright
│ sending sources. │ visible but │ before delivery.
│ No enforcement. │ isolated. │
▼ ▼ ▼
Low risk Moderate risk Full protection
End-to-End: How a Legitimate Email Is Verified
The following diagram shows what happens when your mail server receives a genuine message from Cengage alongside a forged one from an attacker:
┌─────────────────────────────────────────────────────────────────────────┐
│ │
│ [2] ATTACKER SERVER [3] LEGITIMATE CENGAGE SERVER │
│ hacker.ru cengage.com │
│ (masquerading as cengage.com) (genuine) │
│ │ │ │
│ │ "From: admin@cengage.com" │ "From: prof@cengage.com" │
│ │ (no DKIM signature) │ (DKIM-signed with │
│ │ │ Cengage private key) │
│ └───────────────┐ ┌───────────────┘ │
│ ▼ ▼ │
│ ┌────────────────────┐ │
│ │ YOUR MAIL SERVER │ │
│ └────────┬───────────┘ │
│ │ │
│ ┌─────────────┴──────────────┐ │
│ ▼ ▼ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Forged Email │ │ Genuine Email │ │
│ │ SPF check: │ │ SPF check: │ │
│ │ hacker.ru IP │ │ Cengage IP │ │
│ │ not on cengage │ │ IS on cengage │ │
│ │ SPF list → FAIL│ │ SPF list → PASS│ │
│ │ │ │ │ │
│ │ DKIM check: │ │ DKIM check: │ │
│ │ no signature │ │ signed with │ │
│ │ (or invalid) → │ │ Cengage private│ │
│ │ FAIL │ │ key → PASS │ │
│ │ │ │ │ │
│ │ DMARC result: │ │ DMARC result: │ │
│ │ both checks │ │ at least one │ │
│ │ failed → │ │ check passed │ │
│ │ apply p=reject │ │ with alignment │ │
│ └────────┬────────┘ └────────┬────────┘ │
│ │ │ │
│ ▼ ▼ │
│ REJECTED DELIVERED │
│ (never reaches (lands in inbox) │
│ the inbox) │
│ │
└─────────────────────────────────────────────────────────────────────────┘
The key insight: the attacker's server cannot produce a valid DKIM signature because it does not possess Cengage's private key. Only Cengage holds that key. No amount of domain name spoofing compensates for the missing cryptographic proof.
DMARC Reporting: Visibility Into Your Email Ecosystem
One of DMARC's most underappreciated features is its reporting mechanism. Receiving servers that support DMARC send two types of reports back to the domain owner:
Aggregate Reports (RUA)
Sent daily in XML format, aggregate reports summarize all mail that claimed to be from your domain — including which IPs sent it, whether SPF and DKIM passed, and what policy was applied. This gives organizations a map of every service sending on their behalf, making it easy to spot:
- Unauthorized senders (potential spoofing campaigns)
- Legitimate third-party services that haven't been added to SPF records
- Misconfigurations in DKIM signing
Forensic Reports (RUF)
Sent per-failure event, forensic reports include headers and sometimes body content from messages that failed DMARC. They provide detailed intelligence about individual attack attempts but are transmitted less universally by receiving servers due to privacy considerations.
Mail Gateways: The Final Inspection Layer
Even with DMARC fully enforced, a determined attacker using their own legitimately configured domain — not spoofing yours — can still deliver phishing mail. This is where email gateways complete the defense-in-depth picture.
A mail gateway (also called a secure email gateway or SEG) sits at the perimeter of the organization's mail infrastructure. All inbound mail passes through it before reaching internal mail servers.
INBOUND EMAIL FLOW
┌────────────┐ ┌─────────────────────────────────────────┐ ┌──────────────┐
│ External │ │ MAIL GATEWAY │ │ Internal │
│ Mail │────▶│ │────▶│ Mail │
│ Servers │ │ • DMARC / SPF / DKIM verification │ │ Servers │
└────────────┘ │ • Anti-malware scanning │ └──────────────┘
│ • URL reputation and link rewriting │
│ • Attachment sandboxing │
│ • Content filtering │
│ • Spam scoring │
│ • Data loss prevention (DLP) │
└─────────────────────────────────────────┘
What Mail Gateways Catch
Mail gateways inspect email content rather than just origin authentication:
- Malware in attachments — PDFs, Office documents, and executables are scanned and sandboxed before delivery.
- Malicious URLs — links are evaluated against threat intelligence feeds; suspicious URLs are rewritten to route through real-time click-time analysis.
- Phishing signals — look-alike domains, urgency language, and impersonation of internal executives trigger additional scrutiny.
- Data exfiltration — outbound gateways can scan for sensitive data patterns (credit card numbers, PII) being emailed outside the organization.
Mail gateways and DMARC are complementary, not interchangeable. DMARC stops domain spoofing at the authentication layer; mail gateways catch threats in the content layer, including attacks sent from legitimately authenticated but malicious domains.
Putting It All Together
The complete email security picture for any organization looks like this:
| Layer | Technology | Stops |
|---|---|---|
| Network / DNS | SPF | Unauthorized sending servers |
| Cryptographic | DKIM | Forged or tampered messages |
| Policy / Alignment | DMARC | From-header impersonation; coordinates SPF + DKIM |
| Content inspection | Mail Gateway | Malware, phishing links, data exfiltration |
Deploying only one layer leaves exploitable gaps. An organization with SPF and DKIM but no DMARC collects no reports and enforces no policy. An organization with DMARC but no gateway is unprotected against BEC attacks from correctly authenticated attacker domains.
A mature email security posture requires all four working in concert.
Key Takeaways
- SPF publishes which IPs may send for your domain;
-allenforces hard rejection of unauthorized senders. - DKIM uses asymmetric cryptography to sign outgoing messages; only the domain holding the private key can produce a valid signature.
- DMARC adds an alignment check between the
From:header and whichever protocol passes, then enforces a policy (none / quarantine / reject) and routes forensic reports back to the domain owner. - Mail gateways provide content-level inspection that authentication protocols cannot — catching malware and phishing from legitimately authenticated but malicious senders.
- Google and Yahoo mandated DMARC compliance for bulk senders in early 2024, making it an operational baseline rather than an optional enhancement.
- These concepts appear on the CompTIA Security+ exam — know the purpose and interaction of each component, the SPF qualifier values, and the DMARC policy options.