SPF, DKIM, and DMARC explained for email senders

If you send email — transactional receipts, newsletters, cold outreach, anything — three DNS records shape whether mailbox providers trust you: SPF, DKIM, and DMARC. They are the standard answer to a simple question every receiving server asks: is this message really from the domain it claims to be from? Spammers and phishers can spoof a From: address for free, so receivers won't take your word for it. These three standards let you prove it cryptographically and at the DNS level.

Here's the one-line version of each, before we go deeper. SPF lists the IP addresses allowed to send mail for your domain. DKIM attaches a digital signature receivers can verify against a public key in your DNS. DMARC ties those two results back to the address your recipient actually sees, sets a policy for what to do when they fail, and sends you reports. They are layers, not alternatives — you want all three.

SPF (Sender Policy Framework) is a published list of who may send on your behalf. You add one DNS TXT record to your domain naming the IP ranges and services authorized to send mail. A minimal record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

When a receiving server gets a message, it checks the envelope sender — the MAIL FROM address from the SMTP conversation, also called the Return-Path — and asks whether the connecting IP is permitted by that domain's SPF record. The trailing mechanism matters: ~all is a softfail (the domain says the sender is probably not authorized, but receivers usually still accept), while -all is a fail (an explicit statement that the host is not authorized).

SPF has two real limits. First, it authenticates the envelope sender, not the From: header your recipient sees — those can differ. Second, SPF breaks on forwarding: when a mailing list or a forwarder relays your message, the connecting IP changes and SPF fails through no fault of yours. That fragility is a big part of why DKIM and DMARC exist.

DKIM (DomainKeys Identified Mail) addresses SPF's forwarding problem by signing the message itself rather than trusting the connection. Your sending service holds a private key and adds a DKIM-Signature header that signs selected headers and the body. The matching public key lives in your DNS as a TXT record at a selector under the _domainkey subdomain, e.g. selector1._domainkey.yourdomain.com.

The receiver fetches that public key, recomputes the hashes over the same headers and body, and checks the signature. If it verifies, two things are asserted: the message came from a holder of your private key, and the signed content was not modified since it was signed. Because the proof travels inside the message, DKIM can keep passing even after a forwarder relays it from a different IP.

Two practical notes. Use a 2048-bit key where your provider supports it (Google's stated minimum is 1024-bit, but longer is stronger), and rotate keys periodically by publishing a new selector and cutting over. DKIM alone still doesn't connect the signature to the visible From: address — a spammer can validly DKIM-sign mail for their-own-domain.com while spoofing your From: header. Closing that gap is DMARC's job.

DMARC (Domain-based Message Authentication, Reporting & Conformance) is the layer that makes SPF and DKIM actually protect the address your recipient reads. It does three things: it requires alignment, it publishes a policy, and it requests reports.

Alignment is the key idea. DMARC checks that the domain validated by SPF or DKIM matches the domain in the visible From: header. A message passes DMARC when at least one supported mechanism produces a pass result and that result is based on an aligned identifier — that is, when either:

• SPF passes and the Return-Path domain aligns with the From: domain, or
• DKIM passes and the signing domain aligns with the From: domain.

Only one needs to align, but at least one must. This is why an SPF or DKIM "pass" by itself means little — without alignment to From:, it doesn't stop spoofing. A DMARC record is one more TXT entry at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s

The p= policy tells receivers what to do when a message fails DMARC: none (monitor only), quarantine (treat as suspicious, e.g. route to spam), or reject (refuse during the SMTP transaction). The rua= address receives aggregate XML reports — typically sent daily — showing who is sending under your domain and how authentication is faring. That's your map of the territory before you tighten policy. (The adkim and aspf tags control whether alignment is strict, s, or relaxed, r, the default.)

The failure mode people fear is publishing a strict policy and blackholing their own legitimate mail. Avoid it by going in order and watching the data.

• 1. Inventory every sender. List every service that sends as your domain — your ESP, your app's transactional mail, your CRM, invoicing, support desk. Each needs to be in SPF and DKIM-signing.
• 2. Publish SPF with the right include: mechanisms, and confirm you're under the 10 DNS-lookup limit SPF imposes (exceeding it forces a permerror, which makes SPF effectively fail).
• 3. Enable DKIM on each sending service and publish each provider's public-key selector record.
• 4. Publish DMARC at p=none with a rua= address. This changes nothing about delivery — it only starts the reports flowing.
• 5. Read the aggregate reports for a few weeks. Find sources that fail alignment and fix them (a forgotten subdomain, a vendor not yet DKIM-signing).
• 6. Tighten to p=quarantine, then p=reject, optionally ramping with pct=, once the reports show your legitimate mail aligning cleanly.

The raw XML reports are hard to read by eye; a DMARC reporting tool or service that parses rua= data into a dashboard makes step 5 far less painful.

Authentication is no longer optional politeness. Major mailbox providers — Google and Yahoo among them — now require SPF, DKIM, and, for bulk senders, a DMARC policy, and unauthenticated mail is increasingly filtered to spam or rejected outright. Beyond the hard requirement, consistent alignment is a useful reputation signal: a domain that authenticates the same way every time is one providers can build a stable reputation for, which is what actually earns the inbox over time.

There's a second payoff. A published p=reject policy means attackers can't send convincing phishing from your exact domain — protecting your brand and your recipients, which feeds back into reputation. Getting authentication right is among the cheapest and most durable deliverability work you can do.

One honest boundary: authentication proves who sent a message. It says nothing about whether the recipient address you're sending to actually exists. Mailing to dead or invalid addresses generates bounces and spam-trap hits that damage the very reputation SPF, DKIM, and DMARC help you build. That's the complementary half of deliverability, and it's where verification comes in.

SPF, DKIM, and DMARC keep your domain trusted on the way out. MailBounce handles the other side: confirming that the addresses on your list are real before you send to them. It runs syntax checks, MX-over-DoH lookups, disposable/role detection, and a live SMTP RCPT TO probe to classify each address as valid, invalid, catch-all, or unknown — so you keep bounce rates low and protect the sender reputation your authentication setup earns you. See how email verification actually works, or sign up free to try it. Authentication and verification are two halves of the same goal: mail that lands.