SPF, DKIM, DMARC: Email Authentication Trilogy

## Why Email Authentication Exists Email was designed in the 1970s without authentication. Anyone could send a message claiming to be from any address — a fundamental design flaw that modern spammers, phishers, and fraudsters exploit daily. Three DNS (Domain Name System)-based standards emerged to address this: SPF, DKIM, and DMARC. Together they form a framework that lets domain owners declare who is authorized to send email on their behalf and instruct receiving servers what to do when unauthorized email appears. This isn't optional infrastructure for serious email senders. Gmail, Microsoft, and Yahoo now require all senders above certain volume thresholds to have SPF and DKIM configured — and strongly recommend DMARC. Without these records, your email ends up in spam folders or is rejected entirely. ## SPF: Sender Policy Framework SPF Record (RFC 7208) is the oldest and simplest of the three. It answers the question: "Which mail servers are authorized to send email from this domain?" ### How SPF Works 1. You publish a TXT Record at your domain declaring authorized sending IPs or services 2. When a receiving server gets a message claiming to be from `[email protected]`, it looks up the SPF record for `yourdomain.com` 3. The receiving server checks whether the sending server's IP address is listed 4. If authorized: SPF passes. If not: SPF fails (outcome depends on your policy) ### SPF Record Syntax ``` v=spf1 [mechanisms] [qualifier]all ``` **Common mechanisms:** | Mechanism | Meaning | |---|---| | `ip4:192.168.1.1` | Authorize a specific IPv4 address | | `ip4:192.168.1.0/24` | Authorize an IP range | | `include:_spf.google.com` | Include another domain's SPF policy | | `a` | Authorize the domain's A record IP | | `mx` | Authorize the domain's MX record IPs | **Qualifiers (what happens on match/mismatch):** | Qualifier | Meaning | Example | |---|---|---| | `+` (default) | Pass — authorized | `+all` | | `~` | Soft fail — suspicious but deliver | `~all` | | `-` | Hard fail — reject | `-all` | | `?` | Neutral — no assertion | `?all` | ### Example SPF Records **Google Workspace only:** ``` v=spf1 include:_spf.google.com ~all ``` **Multiple services:** ``` v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com ip4:203.0.113.1 ~all ``` **Strict (reject anything not listed):** ``` v=spf1 include:_spf.google.com -all ``` ### The 10-Lookup Limit SPF records may trigger at most **10 DNS lookups** during evaluation. Each `include:`, `a`, `mx`, and `redirect=` counts as one lookup. Exceeding this limit causes SPF processing to fail with a `permerror`, which receiving servers may treat as a fail. If you use many services, you may hit this limit. SPF flattening (replacing `include:` with explicit `ip4:` entries from the included domains) reduces lookup count at the expense of manual maintenance when providers change their IPs. ### One SPF Record Per Domain Only one SPF Record TXT record is allowed per domain name (per RFC 7208). If you add a second one, SPF processing returns `permerror`. If you need to add a new service, edit your existing SPF record rather than creating a new one. ## DKIM: DomainKeys Identified Mail DKIM (RFC 6376) adds a cryptographic signature to email headers and body. Unlike SPF (which checks the sending server's IP), DKIM provides proof that the message content was signed by someone with access to the domain's private key — and that it wasn't modified in transit. ### How DKIM Works 1. **Key generation**: The email provider generates an RSA key pair (public + private) 2. **Private key**: Stored securely on the mail server, never shared 3. **Public key**: Published in your DNS as a TXT Record 4. **Signing**: When you send an email, the mail server computes a hash of specific headers and body content, then signs it with the private key 5. **Signature header**: The signature is added to the email as a `DKIM-Signature` header 6. **Verification**: The receiving server extracts the signature, looks up your DKIM public key in DNS, and verifies the signature against the email content 7. **Result**: If the signature matches, the email hasn't been tampered with and came from an authorized sender ### DKIM Record Location DKIM records are published as TXT records at a specific Subdomain using this format: ``` {selector}._domainkey.{domain} ``` The **selector** is a label that identifies which key pair to use. Multiple selectors allow key rotation without downtime. Providers name their selectors variously: - Google Workspace: `google` - Microsoft 365: `selector1` and `selector2` - SendGrid: `s1` and `s2` Example DNS entry: ``` Type: TXT Host: google._domainkey Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC... ``` The `p=` value is the base64-encoded public key — a long string provided by your email service. ### Generating DKIM Keys You don't generate DKIM keys manually (usually). Your email provider generates them: - **Google Workspace**: Admin Console → Apps → Gmail → Authenticate email → Generate new record - **Microsoft 365**: Microsoft 365 Defender → Email authentication settings → Enable DKIM - **Zoho**: Admin Console → Mail Admin → Email Authentication After generating, the provider shows you exactly what to add to DNS. ### DKIM vs SPF: Key Differences | | SPF | DKIM | |---|---|---| | What it checks | Sending server IP | Message content signature | | Survives forwarding | No | Yes (signature travels with message) | | Checks | Envelope From | Header From | | Storage in DNS | Single TXT record | TXT record per selector | ## DMARC: Domain-based Message Authentication, Reporting & Conformance DMARC (RFC 7489) is the policy layer that coordinates SPF and DKIM. It tells receiving servers what to do when either check fails, and provides reporting back to you about how your domain is being used (and abused). ### How DMARC Works DMARC introduces a concept called **alignment**: it checks that the domain in the message's `From:` header aligns with the domain that passed SPF or DKIM. This is important because SPF alone checks the "envelope From" (the technical sender address, invisible to most recipients) rather than the "header From" (what you see in your email client). Phishers can set up SPF for a domain they control while spoofing a different `From:` address. DMARC closes this loophole. **DMARC passes when:** - SPF passes AND the SPF domain aligns with the `From:` domain, OR - DKIM passes AND the DKIM signing domain aligns with the `From:` domain ### DMARC Record Syntax DMARC records are TXT records published at `_dmarc.yourdomain.com`: ``` v=DMARC1; p=none; rua=mailto:[email protected]; fo=1 ``` **Key tags:** | Tag | Description | Values | |---|---|---| | `v` | Version | `DMARC1` (required) | | `p` | Policy | `none`, `quarantine`, `reject` | | `sp` | Subdomain policy | `none`, `quarantine`, `reject` | | `rua` | Aggregate report URI | Email address | | `ruf` | Forensic report URI | Email address | | `pct` | Percentage to apply policy | 1–100 (default: 100) | | `adkim` | DKIM alignment mode | `r` (relaxed), `s` (strict) | | `aspf` | SPF alignment mode | `r` (relaxed), `s` (strict) | | `fo` | Failure reporting options | `0`, `1`, `d`, `s` | ### Policy Values - **`p=none`**: Monitor only. Failing messages are delivered normally, but reports are sent to `rua`. Start here. - **`p=quarantine`**: Failing messages go to the spam/junk folder. Use after reviewing reports. - **`p=reject`**: Failing messages are rejected outright. The strongest protection — use after confirming all legitimate email passes authentication. ### Implementing DMARC Gradually The recommended progression: **Phase 1 — Monitor (weeks 1–4):** ``` v=DMARC1; p=none; rua=mailto:[email protected] ``` Review aggregate reports. Identify all services sending email from your domain. Ensure they all have proper SPF Record and DKIM configured. **Phase 2 — Quarantine (weeks 4–8):** ``` v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected] ``` Apply quarantine policy to 10% of failing messages. Increase the `pct` value gradually as confidence grows. **Phase 3 — Reject:** ``` v=DMARC1; p=reject; rua=mailto:[email protected] ``` Full protection. Unauthorized senders cannot spoof your domain. ### Reading DMARC Reports Aggregate reports (RUA) arrive as XML attachments, usually once daily. They're not human-readable without a tool. Free DMARC analysis services include: - dmarcian.com (free tier available) - postmarkapp.com/tools/dmarc (free) - easydmarc.com (free tier) These services parse the XML and present visualizations showing which sources are sending as your domain and whether they're passing authentication. ## How All Three Work Together ``` Incoming email claiming to be from [email protected] | v SPF Check DKIM Check ───────── ────────── Is the sending IP Is the DKIM signature in SPF record? valid and aligned? | | Pass/Fail Pass/Fail | | └──────────┬─────────────────┘ v DMARC Evaluation ────────────────── Did SPF or DKIM pass with alignment? | Yes No | | Deliver Apply p= policy (none/quarantine/reject) ``` ## Checking Your Authentication Configuration Use these tools to verify your records are correct: - **MXToolbox** (mxtoolbox.com) — Check SPF, DKIM, DMARC, and MX records - **Google Admin Toolbox** (toolbox.googleapps.com/apps/checkmx/) — Comprehensive email health check - **DNS Record Helper** — Verify records are visible globally - **mail-tester.com** — Send a test email and get a full authentication report ## Common Mistakes **Two SPF records**: Only one TXT record with `v=spf1` is allowed per domain. **Never advancing DMARC policy**: Staying at `p=none` indefinitely provides no protection. Move to `p=reject` after your monitoring phase. **Missing subdomains**: By default, DMARC applies to your root domain but not subdomains. Add `sp=reject` to cover subdomains, or implement separate DMARC records for each subdomain that sends email. **Forgetting third-party senders**: Marketing tools, CRMs, and ticketing systems send email on your behalf. Each needs to be authorized in SPF and should support DKIM signing with your domain's key. ## Next Steps - **Email Deliverability: How Domain Reputation Matters** — How authentication affects your sender reputation - **Domain-Based Email Security Best Practices** — Broader security practices beyond authentication - **Troubleshooting Email Delivery Issues** — Debug authentication failures - **MX Records Deep Dive: Email Routing Explained** — The MX records that route email to your server