SPF, DKIM, and DMARC explained for SaaS founders
Every mailbox provider (Gmail, Outlook, Yahoo) runs the same basic question against every message that arrives: is this sender who they claim to be? SPF, DKIM, and DMARC are the three DNS records that answer that question. Get them wrong and your password-reset emails land in spam. Get them right and they're invisible, which is exactly the point.
SPF: who's allowed to send
SPF (Sender Policy Framework) is a DNS TXT record listing which mail servers are allowed to send email claiming to be from your domain. When a receiving server gets a message from acme.eu, it checks whether the sending IP is on acme.eu's approved list.
A typical record looks like: v=spf1 include:_spf.envello.dev ~all. The include tells receivers to also trust our sending IPs. The ~all at the end is a soft-fail: messages from unlisted servers get flagged, not outright rejected.
DKIM: a cryptographic signature
DKIM (DomainKeys Identified Mail) signs each outgoing message with a private key. The receiving server looks up your public key in DNS and verifies the signature matches. If anything in the message changed in transit, the signature breaks and the receiver knows.
Unlike SPF, which checks the sending server, DKIM checks the message itself, so it survives forwarding in a way SPF doesn't.
DMARC: the enforcement policy
DMARC ties SPF and DKIM together and tells receivers what to do when a message fails both: quarantine it, reject it outright, or do nothing and just report on it. It also gives you an aggregate report of who's sending email as your domain, including anyone spoofing you.
Start with p=none while you confirm your legitimate senders pass, then move to p=quarantine and eventually p=reject once you're confident.
Why this got stricter in 2024
Google and Yahoo's 2024 bulk-sender requirements made all three effectively mandatory for anyone sending meaningful volume: valid SPF and DKIM, a DMARC policy, and a one-click unsubscribe header even on some transactional mail. Providers that handle this configuration for you (generating the records, verifying propagation, monitoring DMARC reports) save you from finding out the hard way that a typo in a TXT record quietly tanked your delivery rate.
The two-alignment problem: SPF and DKIM aren't interchangeable
A message can pass SPF and fail DKIM, or the reverse, and DMARC only counts a pass if at least one of them is both valid and aligned with the visible From domain. Alignment means the domain that signed (DKIM) or authorized (SPF) the message matches, exactly or by subdomain, the domain your recipient actually sees in their inbox. A message sent through a third-party ESP whose SPF record covers its own sending domain, not yours, will fail SPF alignment even if SPF itself technically passes for the ESP.
This is the most common reason a setup that looks correct in isolation still fails DMARC: SPF passes for the sending infrastructure, DKIM passes for the sending infrastructure's own signing domain, but neither aligns with the From address the recipient sees. The fix is making sure your provider signs with a DKIM key under your domain (a CNAME to their key, typically) rather than their own.
Reading a DMARC aggregate report
DMARC's rua tag points receivers at an address (or, more commonly, a report-processing service) where they send daily XML aggregate reports. Raw, these are dense: rows of source IP, message count, and pass/fail status for SPF and DKIM, individually and in alignment. In practice almost nobody reads raw DMARC XML by hand. What matters is watching for two patterns: legitimate sending sources failing (a misconfigured subdomain, a forgotten mail server) and unfamiliar sending sources appearing at all, which is usually either a forwarding service mangling headers or an actual spoofing attempt.
Start p=none long enough to see a full reporting cycle (a week is a reasonable minimum, a full month is safer for anything with weekly billing or digest emails) before moving to quarantine. Skipping straight to reject on day one is the most common way teams accidentally block their own legitimate mail.
What changes if you switch providers
Migrating email providers means re-doing all three records for the new provider's infrastructure, and it's worth doing it as an overlap rather than a hard cutover: add the new provider's SPF include and DKIM CNAMEs alongside the old ones, confirm the new provider's messages pass DMARC alignment, then remove the old provider's records only once cutover is confirmed. Running two providers' SPF includes simultaneously is fine, SPF has no penalty for listing multiple authorized senders, as long as you stay under the 10 DNS lookup limit the spec imposes.