MailRoundupSPF, DKIM, And DMARC Explained For Developers
If you send transactional email in 2026, the receiving side has already decided how much to trust you before your subject line renders. Here is what the three standards actually do.
Three protocols do most of the work of proving a message is really from the domain it claims to be from: SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 7489). They stack, and if any of them is misconfigured for your sending domain, your mail will be treated as untrusted regardless of how clean the content is.
SPF: Who Is Allowed To Send As You
SPF is a TXT record on your domain that lists the IP addresses and hostnames authorized to send mail using that domain in the SMTP envelope MAIL FROM. When a receiving server accepts a message, it looks up the SPF record for the envelope sender's domain and checks whether the connecting IP is on the list.
A typical record looks like v=spf1 include:_spf.example-provider.com -all. The -all at the end means “anything not listed above, reject.” SPF alone is fragile because it breaks on forwarding. It is a necessary input to DMARC, not a complete story.
DKIM: A Cryptographic Signature On The Message
DKIM signs selected headers and the body with a private key held by the sender. The public key lives in DNS at <selector>._domainkey.<domain>. The receiver recomputes the signature and, if it matches, knows the message was not tampered with in transit and that the signing domain vouches for it.
Unlike SPF, DKIM survives most forwarding because the signature travels with the message. Use 2048-bit keys and rotate them periodically. Most providers, including MailRoundup, publish the selector records for you and handle signing on every send.
DMARC: Alignment And Policy
DMARC is where the two stitch together. A DMARC record on your domain (_dmarc.example.com) tells receivers what to do when a message claiming to be from your domain fails authentication, and where to send reports about it.
The key concept is alignment. It is not enough for SPF or DKIM to pass on some domain: the domain they pass on has to match the visible From: header the user sees. A DMARC pass requires at least one of SPF or DKIM to authenticate and align with the From domain.
A minimal record: v=DMARC1; p=none; rua=mailto:dmarc@example.com. Start at p=none to gather reports, move to p=quarantine when you can account for every legitimate stream, and eventually to p=reject. Gmail and Yahoo both require at least p=none for bulk senders since February 2024.
What This Means For A Transactional Pipe
- Use a dedicated sending subdomain like
mail.yourapp.com. Keeps your transactional reputation separate from anything else running on the apex. - Publish SPF, DKIM, and DMARC before you send a single message. Mailbox providers score first impressions harshly.
- Monitor DMARC aggregate reports. They are XML and noisy, but they tell you the truth about what is being sent as you, from where.
- Verify alignment, not just pass. A DKIM pass on your provider's domain instead of yours does not help you build reputation.
References
- RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC)
- Google — Email sender guidelines (support.google.com/mail/answer/81126)
- Yahoo Sender Hub — 2024 Sender Requirements
Send transactional email that lands.
MailRoundup is a transactional-only pipe for receipts, confirmations, password resets, and alerts. One endpoint, honest logs, no marketing traffic in the way.