What SPF, DKIM, and DMARC actually do

Three DNS records, three different jobs. Together they tell receivers (Gmail, Outlook, Yahoo, corporate mail gateways) which servers are allowed to send mail claiming to be from your domain, and what to do when someone lies. If any of these is missing or misconfigured, your Amazon SES mail is likely getting filed as spam or rejected outright.

SPF — Sender Policy Framework. A TXT record on the bare domain that lists which IPs or hostnames are authorized to send mail as you. For SES, the usual entry is include:amazonses.com.
DKIM — DomainKeys Identified Mail. Cryptographic signatures on outbound mail that prove the message wasn't tampered with and actually came from an authorized sender. SES Easy DKIM publishes three CNAME records at unique token-based selectors under _domainkey.your-domain.
DMARC — Domain-based Message Authentication, Reporting, and Conformance. A TXT record at _dmarc.your-domain that tells receivers what to do when SPF or DKIM fails, and optionally where to mail aggregate reports about what they're seeing.

Getting each one right for Amazon SES

SPF for SES

The minimum SPF record for a domain that sends exclusively via SES looks like this:

v=spf1 include:amazonses.com -all

If you also send via Google Workspace, Mailchimp, etc., chain multiple include: directives, but mind the 10-DNS-lookup limit from RFC 7208 — past that, receivers will PermError your SPF. The terminal -all (hard fail) or ~all (soft fail) tells receivers what to do about unlisted senders. Use -all for production once you're confident.

DKIM for SES (Easy DKIM)

When you verify a domain identity in SES, AWS gives you three CNAME records to add to DNS — they point at {token}.dkim.amazonses.com hosts. SES handles key rotation automatically. This tool can't enumerate the unique selectors SES assigns to your domain (they're per-identity tokens), so the DKIM section above only reports whether common selectors have records. To verify SES DKIM specifically, open the SES console → Verified identities → your domain → DKIM and confirm all three CNAMEs show as "Successful."

DMARC for SES

Start with monitoring-only, graduate once you trust the data:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

After 2–4 weeks of clean aggregate reports (pointing at a real mailbox, or a DMARC-report service like Postmark, dmarcian, Valimail), move to p=quarantine, then p=reject. Don't leave production domains at p=none indefinitely — that's a signal to sophisticated phishers that you're not enforcing.

Custom MAIL FROM domain (optional but recommended)

By default, SES uses a MAIL FROM domain like amazonses.com, which causes SPF to fail alignment with your From: domain even when SES is authorized. Configuring a custom MAIL FROM subdomain (e.g. mail.yourdomain.com) in SES and adding its SPF + MX records aligns SPF with your From: domain and significantly improves deliverability under DMARC. This tool doesn't probe custom MAIL FROM subdomains yet — plan to add it based on usage.

Common mistakes we see

Multiple SPF records. Pasted a second one instead of merging. RFC 7208 requires exactly one; receivers treat multiples as PermError.
SPF lookup limit breach. Adding another include: for every tool that sends mail eventually pushes you past 10 DNS lookups. Use SPF flattening (static IPs via a service like autospf or scl.lu) to stay under.
Forgetting DMARC after setting up SPF and DKIM. Receivers that respect DMARC will treat you gently without it, but Gmail and Yahoo now require DMARC for bulk senders (5000+ messages/day).
DMARC pointing at a mailbox you don't read. The aggregate reports are how you catch alignment failures; if nobody's reading them, you'll deploy strict DMARC and watch legitimate mail disappear.
Testing from the wrong sending service. If SES is verified for your root domain but a different SaaS is sending newsletters from that same domain, those newsletters will fail SPF alignment. Authorize the SaaS explicitly or give it a dedicated subdomain.

Frequently asked questions

My SPF includes SES but mail still goes to spam — why?

SPF passing ≠ deliverability. Check DKIM is signing (all three SES Easy DKIM CNAMEs verified), DMARC is published, MAIL FROM domain is aligned with your From:, and the content itself isn't triggering filters. Warmup matters too — a new sending IP or domain needs gradual volume ramp before receivers trust it. The SES console's "Reputation metrics" page shows bounce and complaint rates; keep both under 5% and 0.1% respectively.

Do I need DKIM if I have SPF?

Yes. SPF only authenticates the envelope sender and breaks when mail is forwarded (forwarding servers change the envelope-from). DKIM survives forwarding because it's a cryptographic signature on the message content itself. DMARC combines both and fails-closed when either is absent — having only SPF will cause DMARC alignment failures for any forwarded mail.

Can I use this tool for non-SES domains?

Yes — SPF/DMARC analysis is provider-agnostic. The DKIM section is tuned toward SES (it doesn't know about your specific provider's selector naming), but you can read the records shown and verify them manually in your provider's console.

Is the domain I check logged anywhere?

No. The lookup goes through standard public DNS; our server doesn't record the queries or results.

What about BIMI?

BIMI (Brand Indicators for Message Identification) is a newer record that lets your brand logo show in supporting inboxes once you have DMARC at p=quarantine or p=reject. We may add BIMI checks later if usage justifies it. Get to strict DMARC first — BIMI without it does nothing.