Overview
Publish SPF, DKIM, and DMARC DNS records that align with your From domain before you send a single transactional email; mailbox providers route unauthenticated mail to spam regardless of content. This page is the house standard for any provider (Resend, Postmark, AWS SES). Each provider’s dashboard shows the exact record values to copy; the rules below tell you which records, where they go, and how to verify them. Add the records at your DNS host: see cloudflare-dns and namecheap-dns.
Send from a dedicated subdomain, not the root domain
Use a subdomain like mail.example.com or send.example.com as the sending identity. This isolates sending reputation from your root domain, so a spam complaint against marketing mail does not poison the root domain that serves your site and corporate email. Verify the subdomain as the identity in your provider; the From header becomes noreply@mail.example.com.
Publish exactly one SPF record on the sending domain
SPF is a single TXT record on the sending domain that authorizes which servers may send for it. Publish one and only one SPF record per domain; multiple v=spf1 records are a permanent error and SPF fails outright (dmarc.org).
mail.example.com. TXT "v=spf1 include:amazonses.com ~all"Use the provider’s include mechanism (include:amazonses.com for AWS SES, the value Resend or Postmark shows you). ~all is softfail; -all is hardfail. Most providers also have you add an MX record on the sending subdomain so bounce and complaint feedback can be processed (Resend).
Publish the provider’s DKIM keys and confirm they verify
DKIM signs each message with a private key the provider holds; receivers fetch the matching public key from DNS. Add the provider-issued records exactly as shown, then confirm the provider reports them verified. AWS SES Easy DKIM issues three CNAME records (AWS SES docs); Postmark issues a TXT record (Postmark).
xxxx._domainkey.mail.example.com. CNAME xxxx.dkim.amazonses.com.Verification can take up to 48 to 72 hours to propagate. Do not send production mail until DKIM shows verified, or messages go unsigned.
Publish a _dmarc TXT record and raise the policy over time
DMARC tells receivers what to do when SPF and DKIM fail, and where to send reports. Put a TXT record at _dmarc.<domain>:
_dmarc.mail.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s"Start at p=none to collect aggregate reports (rua=) without affecting delivery. Read the reports, confirm your real mail passes, then raise the policy as confidence grows: none -> quarantine -> reject (dmarc.org). Only reject actually stops spoofing.
Make DKIM and SPF align with the From domain
DMARC passes only when an authenticated identity aligns with the domain in the From header. DKIM aligns when the signing d= domain matches (or is a subdomain of) the From domain. SPF aligns when the Return-Path domain matches the From domain, which is why providers offer a custom Return-Path or custom MAIL FROM subdomain (Postmark). The common failure is transactional mail landing in spam because DKIM and DMARC are unset, or because SPF passes on the provider’s bounce domain but does not align with your From domain, so DMARC fails.
Warm up a new domain gradually
A brand-new sending domain has no reputation. Ramp volume over days to weeks rather than blasting your full list on day one; sudden volume from an unknown domain looks like a compromised account and trips spam filters. Send to engaged recipients first and watch bounce and complaint rates.
Related
- cloudflare-dns and namecheap-dns: where to add these TXT, CNAME, and MX records.
- secrets-and-env: store provider API keys outside source control.
- webhooks: handle provider bounce and complaint webhooks.
- auth-sessions: transactional email backs password reset and magic-link flows.
- launch-a-new-site: deliverability setup as part of launch.