AWS SES DKIM and SPF Setup: Email Authentication That Protects Your Domain

Email authentication is the difference between your messages landing in the inbox and landing in spam — or not arriving at all. Gmail, Microsoft, and Yahoo have tightened authentication requirements for bulk senders substantially in the past two years, with explicit policies requiring DKIM signatures and SPF alignment for any domain sending significant email volume. DMARC builds on both standards to give you control over what happens when messages fail authentication.

AWS SES supports DKIM, SPF, and DMARC through standard DNS configuration. Getting the setup right is mostly a DNS problem — the records need to be correct and consistent with each other, which requires understanding how the three standards interact.

SPF: Authorizing SES to Send for Your Domain

SPF (Sender Policy Framework) is a DNS TXT record on your domain that lists the mail servers authorized to send email from that domain. When a receiving mail server gets a message claiming to be from your domain, it checks the SPF record and verifies that the sending server is on the authorized list. If it's not, the receiving server can reject the message or mark it as suspicious.

For SES, the SPF record needs to include SES's sending IP ranges or use the SES SPF include mechanism. The recommended approach is to include Amazon SES's SPF record rather than listing specific IP addresses:

v=spf1 include:amazonses.com ~all

The ~all mechanism at the end means "soft fail" for senders not in the authorized list — messages from unauthorized senders are marked suspicious but not rejected outright. Using -all (hard fail) is more aggressive and can cause legitimate mail to be rejected if your SPF record is ever incomplete. Start with ~all and move to -all only after verifying the record is comprehensive.

Important: if your domain already has an SPF record, don't add a second one. Multiple SPF records cause SPF failure. Merge the SES include into your existing record:

v=spf1 include:yourexistingprovider.com include:amazonses.com ~all

DKIM: Signing Messages with Cryptographic Keys

DKIM (DomainKeys Identified Mail) uses cryptographic signatures to verify that email content hasn't been tampered with and that the sending infrastructure is associated with the signing domain. SES handles the signing automatically once you configure the DNS records — you don't need to modify your application code.

In the SES console, navigate to Verified Identities and select your domain. Under the DKIM section, AWS provides either CNAME records (for Easy DKIM, where SES manages the key rotation) or a public key (for BYODKIM, where you bring your own key pair). For most use cases, Easy DKIM is the right choice — SES automatically rotates the signing keys on a regular basis, which is better practice than using the same key indefinitely.

Add the CNAME records to your domain's DNS. SES provides three CNAME records that point to SES-managed infrastructure. After DNS propagation (which can take up to 72 hours), SES will verify the records and begin signing messages. The SES console shows DKIM verification status under the identity — "Verified" means signing is active.

Verify the setup by sending a test email to a Gmail account and checking the message headers. In Gmail, click the three-dot menu and select "Show original." Look for DKIM=pass in the Authentication-Results header. If you see DKIM=fail, the CNAME records are either not yet propagated or contain errors.

DMARC: Tying SPF and DKIM Together

DMARC (Domain-based Message Authentication, Reporting & Conformance) is a policy that tells receiving mail servers what to do with messages that fail SPF and DKIM checks. It also provides reporting — receiving servers send XML reports back to your domain showing which messages passed and failed authentication and from what sending sources.

A basic DMARC record looks like this:

_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

Start with p=none (monitor mode). This causes DMARC failures to be reported without actually affecting message delivery. After reviewing reports for two to four weeks to understand your email sending patterns and confirm authentication is working correctly, gradually increase enforcement:

• p=quarantine: messages failing DMARC go to spam folder
• p=reject: messages failing DMARC are rejected outright

Use pct= to apply the policy to a percentage of messages during the transition — pct=10 with p=quarantine applies quarantine policy to 10% of failing messages while leaving 90% unaffected. Ramp up gradually to catch any sending sources you missed.

Common Setup Mistakes

The most frequent authentication setup errors, in order:

Mismatched domains. DMARC alignment requires that the domain in the DKIM signature or the SPF envelope sender matches the From header domain. If you send from addresses @yourdomain.com but sign with DKIM keys for @ses.yourdomain.com without proper subdomain alignment configuration, DMARC fails even though DKIM is technically passing.

Duplicate SPF records. Most DNS providers will create a second TXT record if you add SPF without removing or updating the existing one. Two SPF records cause SPF failure. Check your DNS records before adding the SES include.

SPF record exceeding the 10-lookup limit. SPF imposes a maximum of 10 DNS lookups per evaluation. If your SPF record includes many providers each of which triggers their own includes, you can hit this limit. Use an SPF flattening tool to convert includes into explicit IP ranges if you're approaching the limit.

Not adding all sending subdomains. If you send from multiple subdomains — notifications@mail.yourdomain.com, alerts@app.yourdomain.com — each subdomain needs its own SPF and DKIM configuration, or you need a DMARC policy that covers the organizational domain.

Related Reading

• SES reputation monitoring — how authentication affects deliverability metrics
• SES bounce rate management — authentication failures that look like bounces
• SES account suspension prevention — complete SES health management
• AWS S3 security best practices — managing DNS records securely for authentication

FAQ

Does SES automatically set up SPF for my domain?

SES sends email from SES infrastructure on your behalf, so messages sent through SES have an envelope sender in the amazonses.com domain by default, which passes SPF for that domain. If you want SPF to pass for your own From domain (required for DMARC alignment), you need to add the SES include to your domain's SPF record and configure SES to use your domain as the Return-Path.

Should I use Easy DKIM or BYODKIM?

Easy DKIM is recommended for most organizations. SES manages the key generation, rotation, and DNS record updates automatically. BYODKIM is appropriate when you have specific requirements around key management — for example, when your security policy requires control over the signing keys or when you need to coordinate DKIM setup with existing key management infrastructure.

Where do DMARC reports get sent?

DMARC reports go to the email address specified in the rua tag of your DMARC record. This address receives aggregate XML reports from participating receiving mail servers (Gmail, Yahoo, Microsoft, etc.) once per day. The raw XML is dense and not human-readable without a parsing tool. Services like Postmark's DMARC Digests, dmarcian, or Valimail parse and visualize the reports for easier analysis.