SPF, DKIM, and DMARC: A Developer's Setup Guide
Step-by-step instructions for configuring SPF, DKIM, and DMARC records for your sending domain — including common mistakes and how to verify each one is working correctly.
Email authentication is a DNS configuration problem. That means it is solvable with the right commands and the right understanding of what each record does. This guide walks through exactly what to add to your DNS records, how to verify each one, and what to do when things go wrong.
SPF setup
An SPF record is a DNS TXT record on your root domain. It lists the IP addresses and services authorised to send email on your behalf. A typical SPF record for a company using Sendbound looks like this: v=spf1 include:sendbound.com ~all
The ~all at the end means "soft fail" — messages from unlisted IPs will pass but be marked as suspicious. You can use -all for a hard fail, which is more strict but also more likely to cause false positives during migration. Start with ~all and move to -all once you are confident your entire sending infrastructure is covered.
One critical SPF constraint: you cannot have more than 10 DNS lookups in a single SPF record. Each include: directive counts as one lookup. If you are using multiple email services (transactional, marketing, support), you may hit this limit. SPF flattening services like AutoSPF can help.
DKIM setup
DKIM requires publishing a public key in DNS. Your email provider generates an RSA key pair — they keep the private key, you publish the public key as a DNS TXT record on a subdomain like mail._domainkey.yourdomain.com.
Use a 2048-bit key. 1024-bit keys were deprecated by most providers in 2024 and 2025. If you set up DKIM more than two years ago, check whether your key is 1024-bit and rotate to 2048-bit.
DMARC setup
DMARC is a DNS TXT record on _dmarc.yourdomain.com. A minimal DMARC record looks like: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
Start with p=none to collect reports without blocking any email. After 30 days of reports, review what's sending from your domain. Move to p=quarantine, then p=reject when you are confident your legitimate senders are all covered by SPF and DKIM.
"The most common DMARC mistake is moving to p=reject too quickly. Run p=none for at least 30 days first so you can audit all of your sending sources."
Verification commands
After publishing your records, use dig or nslookup to verify they're live: dig TXT yourdomain.com for SPF, dig TXT mail._domainkey.yourdomain.com for DKIM, and dig TXT _dmarc.yourdomain.com for DMARC. You can also use MXToolbox or mail-tester.com to run an all-in-one check against a test email send.
Common mistakes
The most frequent SPF mistake: publishing multiple SPF records. DNS only allows one TXT record per name starting with v=spf1. If you add a second one, only one will be used (unpredictably), and some providers will reject the configuration entirely. Combine all of your include: directives into a single record.
The most frequent DKIM mistake: not rotating keys. DKIM keys should be rotated every 6–12 months. Most providers let you generate a new key pair and publish a new selector, then retire the old key after the new one has propagated.