SPF, DKIM, and DMARC: Setting Up Your Domain for Email Deliverability

If email sent from your domain is landing in spam folders — or bouncing outright — the most common cause isn't your content or your sending volume. It's missing DNS authentication records. Every major inbox provider now expects three specific records before it will fully trust mail from a domain, and none of them are enabled by default when you register a domain.

The three records, in plain terms

SPF (Sender Policy Framework) — a DNS TXT record listing which mail servers are allowed to send email on your domain's behalf. Without it, any server anywhere could claim to send as you@yourdomain.com, and receiving servers have no way to check whether that's legitimate.

v=spf1 include:_spf.yourprovider.com ~all

DKIM (DomainKeys Identified Mail) — a cryptographic signature added to outgoing mail, verified against a public key published in your DNS. It proves the message wasn't altered in transit and genuinely came from a server authorized to sign for your domain.

DMARC (Domain-based Message Authentication, Reporting & Conformance) — a policy record that tells receiving servers what to do when a message fails SPF or DKIM checks (quarantine it, reject it outright, or just monitor), and where to send reports about those failures.

v=DMARC1; p=quarantine; rua=mailto:reports@yourdomain.com

Why all three, and not just one

SPF alone is easy to spoof around in specific attack patterns. DKIM alone doesn't tell a receiving server what to do about mail that fails verification. DMARC ties the two together and gives receiving mail servers explicit instructions — which is exactly what major providers (Gmail, Outlook, Yahoo) now require for any domain sending meaningful volume, with bulk senders facing outright rejection without them as of recent provider policy changes.

A practical rollout order

1. Publish SPF first, listing every legitimate service that sends mail as your domain — your email provider, your transactional email service (if separate), your CRM, anything that sends on your behalf. Missing one here is the most common cause of legitimate mail suddenly failing.
2. Enable DKIM through your email provider's dashboard — most providers generate the key pair and give you the exact DNS record to publish.
3. Start DMARC in monitor-only mode (p=none) with reporting enabled. This costs you nothing in deliverability but starts collecting real data on what's passing and failing.
4. Review the reports for at least a couple of weeks. You're looking for legitimate senders that are failing — often a forgotten transactional email tool — before you tighten the policy.
5. Move to p=quarantine, then eventually p=reject once you're confident every legitimate sender is passing cleanly. Jumping straight to p=reject without this staging step is the most common way well-intentioned DMARC rollouts break real, wanted email.

Common mistakes worth avoiding

• Multiple SPF records on one domain — DNS only allows one, and having two is treated as a failure, not a merge. Combine them into a single record with multiple include: entries instead.
• Forgetting subdomains. A subdomain used for marketing email or a separate app doesn't automatically inherit the root domain's records — each needs its own SPF/DKIM/DMARC setup if it sends mail independently.
• Setting DMARC to p=reject immediately on a domain with unknown or unaudited senders, which can silently break legitimate mail (invoices, password resets, internal tools) with no warning until someone notices it never arrived.

The payoff

None of this is exciting infrastructure work, but it's the difference between "my email actually reaches the inbox" and "my email quietly disappears into spam with no error message telling me why." For any domain sending real business email — transactional, marketing, or otherwise — it's not optional anymore; it's table stakes.