SPF, DKIM, and DMARC Explained: Email Authentication for AWS Users

Why email authentication matters

If you've ever had a legitimate email land in someone's spam folder, email authentication is probably why. SPF, DKIM, and DMARC are three DNS-based protocols that prove your emails are actually from you. Without them, receiving servers treat your mail as suspicious.

As of 2024, Google and Yahoo require proper authentication for bulk senders. Even for small teams, misconfigured records mean lower deliverability and a higher chance of ending up in spam.

SPF — Sender Policy Framework

SPF tells receiving mail servers which IP addresses are allowed to send email on behalf of your domain. It's a single DNS TXT record.

For AWS SES, a basic SPF record looks like:

v=spf1 include:amazonses.com ~all

This says: "Amazon SES is authorized to send mail for this domain. Treat everything else with suspicion (~all)."

Common mistakes:

• Having multiple SPF records (you can only have one per domain)
• Using +all instead of ~all or -all (this authorizes everyone)
• Forgetting to include all your sending services (SES, marketing tools, etc.)

DKIM — DomainKeys Identified Mail

DKIM adds a cryptographic signature to every outgoing email. The receiving server checks this signature against a public key published in your DNS. If it matches, the email hasn't been tampered with in transit.

With SES, you verify your domain and AWS generates DKIM keys automatically. You add three CNAME records to your DNS:

selector1._domainkey.example.com → selector1.dkim.amazonses.com
selector2._domainkey.example.com → selector2.dkim.amazonses.com
selector3._domainkey.example.com → selector3.dkim.amazonses.com

Why it matters: DKIM is the foundation of DMARC alignment (see below). Without it, DMARC can't verify that the "From" address matches the actual sender.

DMARC — Domain-based Message Authentication

DMARC ties SPF and DKIM together. It tells receiving servers what to do when an email fails authentication: nothing, quarantine it, or reject it outright.

A basic DMARC record:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

This says: "If SPF and DKIM both fail, quarantine the message. Send aggregate reports to this address."

The three policies:

• p=none — Monitor only. Good for starting out.
• p=quarantine — Send failing emails to spam. The recommended middle ground.
• p=reject — Block failing emails entirely. The gold standard, but make sure everything is aligned first.

How they work together

Think of it as layers:

1. SPF checks if the sending server is authorized
2. DKIM checks if the email content is unmodified and the domain matches
3. DMARC checks if at least one of SPF or DKIM passes and aligns with the "From" domain, then applies your policy

All three are DNS records. All three are required for modern email deliverability. And all three need to be correct — a misconfigured SPF record can be worse than no SPF record at all.

Setting this up on AWS

If you're managing this manually with SES and Route 53, here's what you need:

1. Verify your domain in SES
2. Add the three DKIM CNAME records to Route 53
3. Add an SPF TXT record to Route 53
4. Add a DMARC TXT record to Route 53
5. Request production SES access (out of sandbox)
6. Set up SES receipt rules for incoming mail

It's about 15-20 minutes of careful DNS editing if you know what you're doing. One typo and your email breaks.

Or let inbox.camp handle it

inbox.camp configures all of this automatically during setup. We detect your Route 53 domains, create the correct MX, SPF, DKIM, and DMARC records, verify everything with SES, and confirm deliverability — all in about 2 minutes.

No Googling DNS record formats. No copy-paste errors. No wondering if you got the DKIM selector right.

Join the waitlist and skip the DNS homework.