email authentication: SPF, DKIM, and DMARC explained

You set up a new domain, configured your mail server, and sent your first batch of messages. Half bounced. The rest landed in spam. The content was fine, the addresses were valid, and nothing in the logs screamed "error." The problem is simpler than that: you never proved to the receiving servers that you're allowed to send from that domain.

That proof comes from three DNS-based protocols that work together as a single authentication system: SPF, DKIM, and DMARC. Each handles a different piece of verification. Together, they tell receiving mail servers "yes, this sender is who they claim to be." Without all three, your email is unverified. And in 2026, unverified email doesn't reach inboxes.

What problem does email authentication solve?#

Email was designed in the 1970s with zero identity verification built into the protocol. SMTP lets anyone claim to send from any address. There's nothing in the original spec stopping someone from firing off a message that appears to come from ceo@yourcompany.com. That's the gap phishing exploits, and it's the gap these three protocols were built to close.

SPF checks whether the sending server is authorized for the domain. DKIM verifies that the message was genuinely produced by the claimed domain and hasn't been altered in transit. DMARC sets the policy for what happens when SPF or DKIM fails, and sends you reports about it. Three separate DNS records, one authentication system.

SPF: authorizing your sending servers#

Sender Policy Framework (SPF) is a DNS TXT record that lists every IP address and mail server authorized to send email on behalf of your domain. When a receiving server gets a message from you@yourdomain.com, it looks up the SPF record for yourdomain.com and checks whether the sending server's IP appears on the list.

A typical SPF record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net -all
Breaking that down:

- `v=spf1` identifies the record type
- Each `include:` directive authorizes a specific service's mail servers
- `-all` at the end means "reject anything not covered by the includes"

That -all ending is the enforcement mechanism. A tilde version (~all) signals a soft fail, which flags the message as suspicious but doesn't block it. The hyphen version (-all) is a hard fail: reject the message outright.

The most common SPF mistake is also the simplest: forgetting to add a new sending service. If you start using a newsletter platform or transactional email provider and don't update your SPF record, every email sent through that service fails authentication. I've seen this break outreach campaigns overnight. One missed include and suddenly nothing from your new tool reaches anyone.

SPF also has a hard limit of 10 DNS lookups. Each include directive can trigger nested lookups under the hood, and once the total exceeds 10, your entire SPF record becomes invalid. This catches businesses using five or six third-party email tools. The record looks fine when you read it, but it silently fails because of nested lookup chains you never see. Tools like MXToolbox and dmarcian offer free SPF checkers if you want to audit your lookup count.

DKIM: signing your messages#

DomainKeys Identified Mail (DKIM) takes a different approach from SPF. Instead of checking the sending server, it checks the message itself using cryptographic signatures.

The process works like this:

1. You generate a public/private key pair for your domain
2. The public key gets published as a DNS TXT record under a selector subdomain (something like selector1._domainkey.yourdomain.com)
3. When your server sends an email, it signs specific headers and the message body with the private key
4. The receiving server retrieves the public key from DNS and verifies the signature

A DKIM DNS record looks something like:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

If the signature checks out, the receiving server knows two things: the message genuinely originated from a server holding the private key for that domain, and the content hasn't been tampered with during transit. If someone intercepts and modifies the email between servers, the signature breaks and the check fails.

DKIM doesn't prevent someone from attempting to send as your domain. It gives the receiving server a way to verify whether a specific message is authentic. The enforcement piece, where failed checks actually result in blocked messages, comes from DMARC.

One detail people overlook: DKIM keys should be rotated periodically. Every 6 to 12 months is a reasonable cadence. If a private key is compromised, anyone holding it can sign messages that pass DKIM verification for your domain. Regular rotation limits the damage window.

DMARC: the policy and reporting layer#

Domain-based Message Authentication, Reporting & Conformance (DMARC) sits on top of SPF and DKIM. It handles two things neither protocol provides on its own: a policy for what happens when authentication fails, and a reporting mechanism that shows you who's sending email using your domain.

A DMARC record is a DNS TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; pct=100

The key fields:

• p=reject tells receiving servers to block messages that fail both SPF and DKIM. Other options are quarantine (route to spam) and none (monitor without enforcing)
• rua=mailto:... is the address where aggregate reports get sent. These XML reports detail every server that sent mail using your domain and whether each message passed or failed
• pct=100 applies the policy to 100% of failing messages

The concept most setups get wrong is DMARC alignment. It's not enough for SPF or DKIM to pass independently. DMARC requires that the domain in the visible From: header matches the domain that passed SPF or DKIM. Without alignment, an attacker could configure valid SPF and DKIM records for their own infrastructure while spoofing your domain in the From: field that the recipient actually sees.

Alignment comes in two modes: strict (exact domain match required) and relaxed (subdomains of the organizational domain count as matching). Relaxed is the default and works for most configurations.

The authentication sequence#

When an email arrives at Gmail, Outlook, or any major provider, the receiving server runs through these checks in sequence:

1. SPF check: Is the sending server's IP authorized for this domain? Pass or fail.
2. DKIM check: Does the cryptographic signature verify against the public key in DNS? Pass or fail.
3. DMARC evaluation: Did at least one of SPF or DKIM pass with domain alignment? If neither passed with alignment, apply the DMARC policy (none, quarantine, or reject).

An email only needs one of SPF or DKIM to pass with alignment in order to satisfy DMARC. But having both pass produces the strongest signal to receiving servers. If you're sending transactional email, outreach, or anything at volume, you want all three checks green.

Mistakes that will cost you#

Starting DMARC at p=reject without monitoring first. If your SPF record is missing a legitimate sending source, a reject policy blocks your own email. Start with p=none, review the aggregate reports for two to four weeks, close any authentication gaps you find, then move to quarantine and eventually reject.

Blowing past the SPF lookup limit. Every include can cascade into nested DNS lookups. Once you exceed 10 total, your SPF record silently becomes invalid. No error, no warning, just failed checks. Test your lookup count before and after adding any new email service.

Ignoring subdomains. DMARC policies don't automatically apply to subdomains. If you send email from notifications.yourdomain.com, you need either a separate DMARC record for that subdomain or an sp=reject directive in your root domain's DMARC record.

Treating authentication as a one-time setup. Every time you add or remove an email sending service, your SPF record needs updating. Every infrastructure change means DKIM keys may need refreshing. If you're running into 550 errors, stale authentication records are one of the first things to check.

Never reading DMARC reports. The rua address receives aggregate reports showing exactly what's happening with your domain's email. If a spammer starts using your domain, or if a legitimate service is failing authentication, the reports will show it. Most people set the address and never look at it.

Set it up before you send#

SPF says who can send. DKIM proves the message is real. DMARC tells receiving servers what to do when those checks fail. All three are required for reliable email delivery in 2026, whether you're running a SaaS product, an e-commerce store, or an AI agent that provisions its own inbox.

If you're building agents that send email, this matters even more. An agent spinning up a fresh domain starts with zero reputation and zero authentication records. Services like LobsterMail handle SPF, DKIM, and DMARC configuration automatically when an agent provisions an inbox, so the agent doesn't have to wrangle DNS records. But whether you use a managed service or set it up yourself, the records need to be correct and complete before the first message goes out.

Monitor your DMARC reports weekly. Rotate your DKIM keys every six months. Audit your SPF lookup count when you add new tools. Email authentication is not something you configure once and walk away from.