SMTP — the protocol carrying every email you send — has no built-in sender verification. Anyone can forge the From: header to read ceo@yourcompany.com without touching your infrastructure. The defense against this is a three-layer authentication stack: SPF (which servers are allowed to send for you), DKIM (cryptographic proof the message wasn't tampered with), and DMARC (which binds the two to the visible From address and tells receivers what to do when they fail). Since February 2024, Google and Yahoo require all bulk senders to have this stack deployed — not as a recommendation, but as a delivery prerequisite.
1. SPF — Who Is Allowed to Send For Your Domain
SPF (RFC 7208) publishes a list of authorized sending IP addresses and services in a DNS TXT record at your root domain. Receiving mail servers compare the sending server's IP against this record when processing inbound email.
v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::/32 include:_spf.google.com include:sendgrid.net -allSyntax breakdown:
| Mechanism | Function | Example |
|---|---|---|
v=spf1 | Identifies the record as SPF version 1 | Required; must be first |
ip4: / ip6: | Explicit IP address or subnet authorized to send | ip4:203.0.113.5 |
include: | Inherits the authorized IPs from a third-party's SPF record | include:_spf.google.com |
a: | Authorizes the IP(s) in the domain's A/AAAA record | a:mail.yourdomain.com |
mx: | Authorizes the IP(s) in the domain's MX records | mx (uses root domain) |
-all | Hard fail: reject mail from any IP not listed above | Recommended for all production domains |
~all | Soft fail: mark unauthorized mail as suspicious but don't reject | Use only during initial deployment |
The 10-Lookup Limit — SPF's Most Common Misconfiguration
SPF allows a maximum of 10 DNS lookups to evaluate a record. Each include:, a:, mx:, and redirect= mechanism counts as one lookup. Exceeding 10 causes SPF to return a permerror, which DMARC treats as an SPF fail.
Most organizations exceed the limit when they accumulate multiple SaaS platforms over time: Google Workspace, Salesforce, HubSpot, Mailchimp, Zendesk, SendGrid, and a corporate mail relay can easily combine to 15+ lookups. The fix is either SPF flattening (manually resolving all includes to their current IP ranges and listing them as ip4: entries) or a dynamic SPF provider that handles resolution automatically.
Critical SPF Limitation
SPF validates the Return-Path (Envelope From) address — not the From: header that recipients see in their inbox. An attacker can craft a message where the Return-Path passes SPF but the visible From shows ceo@yourcompany.com. SPF alone does not stop spoofing. This gap is exactly what DMARC alignment closes.
2. DKIM — Cryptographic Proof of Message Integrity
DKIM (RFC 6376) lets the sending mail server sign outbound messages using an RSA or Ed25519 private key. The corresponding public key is published in DNS at [selector]._domainkey.yourdomain.com. Receiving servers retrieve the public key and verify the signature — confirming that the message headers and body were not modified in transit.
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3...The DKIM-Signature header added to each outbound message specifies:
d=— the signing domain (must match or be parent of theFrom:domain for DMARC alignment)s=— the selector (allows multiple keys per domain; usegoogle,s1,mailetc.)h=— the headers included in the signature (must includeFrom:)bh=— Base64 hash of the canonicalized message bodyb=— Base64 RSA signature over the specified headers
DKIM Key Rotation
DKIM private keys should be rotated annually, or immediately if a key compromise is suspected. Rotation procedure: generate a new key pair, publish the new public key at a new selector in DNS, configure your mail server to sign with the new key, wait for DNS propagation (~48 hours), then remove the old selector. Do not remove the old selector until you're certain no messages signed with it are still in transit or being replayed.
Key length matters: RSA-1024 is considered weak by modern standards. NIST recommends RSA-2048 as the minimum. Ed25519 keys are shorter and faster to verify — some modern mail servers support DKIM Ed25519 (check your vendor's documentation).
3. DMARC — Alignment, Policy, and Reporting
DMARC (RFC 7489) does two things that SPF and DKIM individually cannot: it requires the authenticated domain to match the visible From: header (alignment), and it tells receiving servers what to do when alignment fails (policy enforcement).
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; pct=100; adkim=s; aspf=sIdentifier Alignment — The Critical Mechanism
| Protocol | What Must Align | Relaxed (r) | Strict (s) |
|---|---|---|---|
| SPF | Return-Path domain vs From: domain | Subdomains allowed: mail.example.com aligns with example.com | Exact match only: example.com = example.com |
| DKIM | d= signing domain vs From: domain | Subdomains allowed | Exact match only |
DMARC passes if at least one of SPF alignment or DKIM alignment succeeds. Relying on only SPF alignment is fragile — forwarded messages break SPF alignment because the forwarding server's IP isn't in the original sender's SPF record. DKIM alignment survives forwarding (as long as the forwarder doesn't modify headers or body). For robust DMARC coverage, configure DKIM signing on all legitimate mail streams.
4. Rollout Timeline: p=none to p=reject
Rushing to p=reject without auditing your mail streams first blocks legitimate email. The standard phased rollout:
| Phase | Policy | Duration | Goal | Done When |
|---|---|---|---|---|
| 1 — Monitoring | p=none | 2–4 weeks | Discover all legitimate sending sources from aggregate reports | No new sending sources appearing in weekly report analysis |
| 2 — Partial Enforcement | p=quarantine; pct=25 | 1–2 weeks | Test quarantine policy on 25% of failing mail without blocking everything | No unexpected legitimate mail being quarantined |
| 3 — Full Quarantine | p=quarantine; pct=100 | 2–4 weeks | Confirm all legitimate streams pass DMARC before hard-blocking | Aggregate reports show >99% DMARC pass rate for legitimate mail |
| 4 — Full Enforcement | p=reject; pct=100 | Permanent | Reject all unauthenticated mail claiming to come from your domain | Final state; monitor aggregate reports weekly for anomalies |
5. Reading DMARC Aggregate Reports
Aggregate reports (rua=) arrive as gzip-compressed XML files. The key fields to watch:
<source_ip>— the sending IP. If you see IPs you don't recognize, a third-party service is sending email as your domain without your knowledge.<count>— how many messages came from that IP during the reporting period (usually 24 hours).<policy_evaluated><disposition>— what the receiving server did:none,quarantine, orreject.<auth_results>— the SPF and DKIM results for that source. Adkim=failfrom a legitimate sending service means DKIM isn't configured on that service yet.
Use a DMARC report parser (dmarcian, Valimail, Google Postmaster Tools, or IncogSay's aggregate report endpoint) rather than reading raw XML. The XML schema is consistent but verbose — parsers extract the actionable information directly.
6. Google and Yahoo Bulk Sender Requirements (February 2024)
As of February 2024, Google and Yahoo require all senders of more than 5,000 messages per day to Gmail/Yahoo addresses to:
- Have SPF or DKIM authentication configured (one is sufficient; both is strongly recommended)
- Have a DMARC record published with at least
p=none(Google) orp=nonewith anruaaddress (Yahoo) - Provide a one-click unsubscribe mechanism in marketing email headers (
List-UnsubscribeandList-Unsubscribe-Post) - Maintain a spam complaint rate below 0.10% (deliverability impact) and below 0.30% (mail blocking threshold) as measured in Google Postmaster Tools
Non-compliance results in mail being rejected or routed to spam, with an error code referencing the missing requirement. This makes email authentication infrastructure a delivery prerequisite, not just a security best practice.
7. Test Your Domain's Email Authentication Stack
IncogSay provides dedicated tools for each layer of the stack:
- SPF Checker — validates SPF syntax, counts DNS lookups, verifies IP authorization against your record, and flags
permerrorconditions before they affect delivery. - DKIM Checker — queries public DKIM selectors, verifies RSA/Ed25519 key lengths, and confirms the key is correctly formatted for receiver validation.
- DMARC Checker — parses your DMARC policy, evaluates alignment mode, checks aggregate report destinations, and flags missing or misconfigured fields.
- Email Security Score — generates a consolidated 0–100 rating for your domain's full email authentication posture, combining SPF, DKIM, DMARC, BIMI, and MTA-STS coverage into one actionable score.