Email authentication 101
Master the protocols that protect email senders and help receivers identify forged mail.
Why email authentication matters
Email is vulnerable by design. Any server can claim to be any sender—there's nothing in SMTP that stops an attacker from saying "I'm admin@yourcompany.com." Email authentication protocols solve this by proving that an email actually came from someone authorized to send on behalf of a domain.
Organizations that publish email authentication records and enforce strict policies see dramatically fewer phishing attempts, credential theft campaigns, and brand-impersonation attacks. For senders, it means your legitimate mail lands in inboxes, not spam folders. For receivers, it means they can trust the From address.
The three protocols
Modern email authentication rests on three pillars: SPF, DKIM, and DMARC. Each solves a different problem; together, they form a complete trust layer.
SPF (Sender Policy Framework)
SPF answers the question: Is this server allowed to send mail for this domain? You publish a TXT record on your domain listing all the IP addresses and mail servers that are authorized to send on your behalf. When a receiver gets an email from your domain, they query that record and check if the sender's IP is in the list. Simple, effective, and the oldest of the three.
SPF's Achilles heel: the RFC 7208 10-DNS-lookup limit. Each `include:` directive counts as a lookup. Add too many vendors (Google Workspace, Microsoft 365, SendGrid, Mailgun, etc.) and you hit the limit, causing SPF to fail with permerror.
DKIM (DomainKeys Identified Mail)
DKIM signs every email with a cryptographic signature. A public key published in your DNS lets receivers verify that the email wasn't modified in transit and was sent by someone who holds your private key. DKIM is immune to the 10-lookup limit and incredibly robust—it's the closest thing to perfect sender authentication.
The trade-off: DKIM requires key rotation, selector management, and coordination between your mail infrastructure and DNS. It's also harder to troubleshoot when something breaks.
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
DMARC builds on SPF and DKIM. It says: I require that emails from my domain pass DKIM and/or SPF, and alignment must hold. But DMARC's real power is reporting—it collects feedback about which emails passed, failed, and why. This visibility is essential for moving safely from monitor (`p=none`) to enforcement (`p=quarantine`, then `p=reject`).
The practical path
Most organizations start with SPF and DKIM, then layer in DMARC. The typical progression looks like this:
-
Publish SPF
List all your authorized senders (mail servers, cloud services, APIs) in a single TXT record. If you hit the 10-lookup limit, you need a solution like UglyDMARC.
-
Deploy DKIM
Generate signing keys, configure your mail infrastructure to sign outgoing mail, and publish the public key in DNS.
-
Set DMARC to monitor
Publish `p=none` and request that receivers send daily reports. Let it run for 1–2 weeks while you collect data on alignment, failures, and sources.
-
Move to quarantine, then reject
Once you're confident that legitimate mail passes SPF/DKIM, tighten the policy: `p=quarantine` (suspect mail goes to spam), then `p=reject` (outright rejection). DMARC reports guide each step.
Going deeper
These guides cover the protocols in detail, common pitfalls, and advanced topics:
What is SPF
Mechanisms, qualifiers, alignment, and the myth of flattening.
What is DKIM
Cryptographic signing, selectors, key rotation, and alignment.
What is DMARC
Policy modes, alignment modes, and the staged rollout to rejection.
The SPF 10-lookup limit
Why it happens, why DIY flattening fails, and how to beat it.
Understanding DMARC reports
Reading the XML, interpreting results, and why raw reports are painful.
Getting started with UglyDMARC
UglyDMARC handles the two biggest challenges in email authentication: the SPF 10-lookup limit and DMARC reporting at scale. You publish one synthetic include on your domain, and we pre-flatten your entire vendor tree into a cached CIDR set. Receivers see a single-IP SPF response—always under the limit, always deterministic.
For DMARC, you point your reporting address at UglyDMARC and the aggregate reports flow straight to us. We parse them into a searchable dashboard and show you exactly who is (and isn't) authorized to send as your domain. No XML-parsing scripts, no spreadsheets—just clarity.