SPF, DKIM, and DMARC: Set Them Up Right Once
A plain SPF, DKIM, and DMARC setup guide for developers sending transactional email. What each record does, the order to add them, and the mistakes that cost you inboxing.
If your transactional email is landing in spam, the first thing to check is authentication. SPF, DKIM, and DMARC are three DNS records that prove your mail is really from you. Get them right and mailbox providers trust you. Get them wrong or leave them missing and even perfect content lands in the junk folder. Here is how the three fit together and the order I set them up in.
What do SPF, DKIM, and DMARC actually do
SPF is a list of servers allowed to send mail for your domain. You publish a TXT record naming your sending sources. When mail arrives, the receiver checks whether the sending server is on your list. If it is not, that is a red flag.
DKIM is a cryptographic signature. Your sending platform signs each message with a private key, and you publish the matching public key in DNS. The receiver verifies the signature, which proves the message was not tampered with in transit and really came from an authorized sender.
DMARC ties the two together and tells receivers what to do when a message fails. It also requires alignment, meaning the domain in the visible From address has to match the domain that passed SPF or DKIM. Without DMARC, a spammer can pass SPF on their own domain while forging your From line. DMARC closes that gap.
What order should I set them up in
Start with SPF. Publish one TXT record that includes every service sending on your behalf. One record only. Multiple SPF records for the same domain is an error that breaks the whole check.
Add DKIM next. Your provider gives you a public key and a selector. You add a record at selector._domainkey.yourdomain.com. A good transactional platform like Usermails generates the keys and hands you the exact record to paste, so this is usually copy and paste plus a propagation wait.
Turn on DMARC last, and start in monitor mode. Publish a record with p=none and a reporting address. That tells receivers to enforce nothing yet but send you reports on what passes and fails. Watch those reports until you are sure all your legitimate mail aligns.
How do I enforce DMARC without blocking my own email
Do not jump straight to p=reject. That is how people block their own receipts on day one. Move in stages.
Run p=none for a couple of weeks and read the aggregate reports. Confirm every legitimate sending source passes SPF or DKIM with alignment. Fix anything that does not.
Then move to p=quarantine, which sends failing mail to spam instead of the inbox. Watch again. When you are confident, move to p=reject, which tells receivers to drop failing mail entirely. Now a forger cannot spoof your domain, and your good mail sails through because it aligns.
This staged rollout is the same discipline I apply to any change that can take down a critical path. I do not flip the switch and hope. I watch the signal first, which is also how I think about migrating infrastructure without downtime.
The mistakes that quietly cost you
Two SPF records. People add a second one for a new service instead of merging into the existing record. The check fails and your SPF stops helping. Keep it to one record and include all sources inside it.
SPF too many lookups. SPF allows a maximum of ten DNS lookups. Chain enough include statements and you blow past it, and the whole record returns an error. Flatten it or reduce your sending sources.
No alignment. Your mail passes SPF on the provider's domain but your From address is your own domain, so DMARC alignment fails. Fix this by setting up a custom return-path and DKIM on your own domain, which any serious platform supports.
Forgetting subdomains. If you send transactional mail from a subdomain, it needs its own records. DMARC on the root does not automatically protect a subdomain the way people assume unless you set the subdomain policy explicitly.
Why this is worth doing carefully
Authentication is the foundation everything else sits on. You can write perfect content and warm your domain perfectly, but if SPF, DKIM, and DMARC are broken, none of it matters. It is also the part you set up once and mostly forget, which is why it pays to do it right the first time rather than debug it during an incident.
When you are choosing where to send from, pick a platform that makes these records easy and documents alignment clearly. That is one of the things worth evaluating before you commit to any email vendor. Do the three records in order, enforce DMARC in stages, and your transactional mail earns the trust it needs to reach the inbox.