You wired up password resets or a newsletter, the SMTP call returns 250 OK, and the messages still land in spam. The code is fine. What is missing is proof that your server is allowed to send for your domain, and Gmail, Outlook and Yahoo now check for that proof on every message.
Since 2024, Google and Yahoo require bulk senders, anyone sending more than 5,000 messages a day to their users, to publish DMARC, and Microsoft has followed with similar rules for Outlook. Three DNS records provide the proof, they take about an hour to set up, and they decide more about inbox placement than anything in your templates. This is the short developer version, the full walkthrough of every piece lives in our email deliverability guide.
SPF in One Record
SPF is a single TXT record on your root domain that lists every service allowed to send as you. List every source, because anything you forget fails the check:
v=spf1 include:_spf.google.com include:amazonses.com ~all
Three details catch developers. The check runs against the envelope sender, the Return-Path, not the From address your users see. You get exactly one SPF record per domain, so adding a second TXT record that starts with v=spf1 breaks both, merge new providers into the existing record instead. And SPF caps DNS lookups at 10, every include counts toward that, so a long list of providers can quietly push you over the limit.
DKIM Keys and Selectors
DKIM signs each message with a private key held by your provider. You publish the matching public key in DNS under a selector, a label the provider picks:
selector1._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
Most providers hand you the exact record in a setup wizard and verify it from their dashboard. The part worth understanding is that DKIM signs the message itself rather than vouching for a server, so it survives forwarding where SPF usually fails. That makes DKIM the record DMARC leans on most.
Rolling DMARC From None to Reject
DMARC passes when SPF or DKIM passes and the domain it checked aligns with the visible From domain. Start in monitoring mode:
_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"
Leave it there for a couple of weeks and read the daily XML reports. They list every IP sending as your domain, which is usually where you find the forgotten CRM or the old server still mailing invoices. Once every legitimate source passes, move to p=quarantine, then p=reject. Jumping straight to reject is how teams block their own billing email.
Reputation and Pacing After the DNS Work
Authentication gets you judged fairly, it does not make you trusted. A new domain has no reputation, so warm it up by sending small volumes to your most engaged users first and growing over a few weeks. Then keep volume steady per mailbox provider. Sending 50,000 messages to Gmail in one burst gets throttled even with perfect records, while the same volume spread across the day goes through.
Pacing and the bounce handling that goes with it are the parts most worth automating. We built both into Email Campaign Engine, a free open source broadcast tool that spreads sends across the business day and puts hard bounces and complaints on a permanent suppression list. The email broadcast system guide shows how it connects to Amazon SES, Mailgun or any SMTP relay.
The Short Version
Publish SPF with every sending source, turn on DKIM at your provider, start DMARC at p=none and read the reports before tightening it. After that, deliverability is about behavior: warm new domains slowly, pace your sends, and never mail an address that bounced. Get those right and your 250 OK finally means the message reached a person.
Top comments (0)