Setting Up DMARC for Amazon SES: A Step-by-Step Guide
Set up DMARC, DKIM and SPF for Amazon SES: DNS records, custom MAIL FROM subdomains, alignment, and how to read your first DMARC XML reports.
For engineering and DevOps teams, Amazon Simple Email Service (SES) is often the default choice for reliability and cost efficiency. But because SES operates as raw infrastructure rather than a managed application platform, your team needs to configure domain authentication and monitor delivery alongside the tools AWS provides.
If application emails fail authentication, start with three standards: SPF, DKIM, and DMARC.
Major mailbox providers require DMARC for bulk senders, making it a practical part of an SES setup. This guide walks through configuring DMARC, DKIM, and SPF specifically for Amazon SES to keep your domains secure and your deliverability high.
Why DMARC Matters for Amazon SES Senders
DMARC helps receivers distinguish authorized use of your visible From domain from spoofing. It combines authentication results with a policy you publish in DNS.
For example, Google’s sender guidelines require SPF, DKIM, and DMARC for senders exceeding 5,000 messages a day to personal Gmail accounts. Check each receiving provider’s requirements separately. Authentication is essential, but it does not guarantee inbox placement.
The Three Authentication Records: SPF, DKIM, and DMARC
To understand how these records work together, it helps to know what each layer validates:
- SPF (Sender Policy Framework): Specifies which mail servers are authorized to send email on behalf of your domain. It is published as a DNS TXT record. During validation, receiving servers look at the domain in the “Return-Path” header to find the SPF record, verifying it against the sending IP address.
- DKIM (DomainKeys Identified Mail): Adds a DKIM-Signature header covering the message body and selected headers. The receiving server retrieves the public key from DNS and verifies the signature.
- DMARC: Connects authentication to the visible From domain. It requests a policy for messages that fail DMARC and can request aggregate XML reports.
A message passes DMARC when at least one of these paths succeeds: SPF passes and its MAIL FROM domain aligns with the visible From domain, or DKIM passes and its signing domain aligns with that From domain. Both paths need not pass for DMARC to pass. Relaxed alignment permits related subdomains under the same organizational domain; strict alignment requires an exact match. See AWS’s DMARC guide.
Step-by-Step: Configuring DMARC for Your SES Domain
Configure aligned DKIM first. A custom MAIL FROM domain can add aligned SPF as another authentication path.
Step 1: Verify Your Domain in SES and Enable DKIM
For a standard Easy DKIM setup, publish the DNS records SES supplies and wait for verification before relying on its signatures.
- Go to the AWS Console, navigate to Amazon SES, and select Verified identities.
- Click Create identity, select Domain, and enter your domain name.
- Keep Easy DKIM enabled. Choose your DKIM signatures key length (RSA 2048-bit is recommended).
- Publish the generated CNAME records to your DNS provider. These records point to AWS-managed keys, enabling automatic DKIM rotation.
For a deeper look into initial SES configurations, read our guide on what is Amazon SES.
Step 2: Configure a Custom MAIL FROM Domain for SPF Alignment
By default, SES uses a subdomain of amazonses.com as the MAIL FROM (Return-Path) address. This can pass SPF authentication, but it does not provide SPF alignment with your own From domain. Your message can still pass DMARC through aligned DKIM.
To add SPF alignment, set up a custom MAIL FROM subdomain (e.g., mail.yourdomain.com). This works with relaxed SPF alignment for a From address at yourdomain.com; it is not an exact match under strict alignment.
- In your verified identity settings in SES, find the MAIL FROM domain tab and click Set MAIL FROM domain.
- Enter your chosen subdomain.
- Publish the MX and SPF (TXT) records provided by AWS to your DNS host.
Your new SPF record for the subdomain will look like this:
v=spf1 include:amazonses.com ~all
DNS check: Publish the SPF record at the MAIL FROM subdomain, along with the exact regional MX record SES supplies. Do not add a second SPF policy at the same name. Review SES’s MAIL FROM failure behavior before relying on this path. See AWS’s custom MAIL FROM instructions.
Step 3: Create Your DMARC TXT Record
Once an aligned authentication path is working, create your DMARC record. Go to your DNS provider and add a new TXT record:
- Host/Name:
_dmarc.yourdomain.com - Value:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com;
Start with p=none while inventorying legitimate sending sources. This requests no quarantine or rejection because of DMARC failure; receivers still apply their own spam and security policies. It does not guarantee delivery. Use a working reporting mailbox or a DMARC report processor for the rua address.
Step 4: Validate DNS and Message Authentication
Once your DNS changes propagate, use a DNS TXT lookup to check that the _dmarc record is visible and formatted correctly. A simple dig command can confirm this:
dig TXT _dmarc.yourdomain.com
Then send a test message and inspect the receiving mailbox’s authentication results. Confirm dmarc=pass and identify which aligned SPF or DKIM path produced the pass; a visible DNS record alone does not prove that your messages align.
Reading Your First DMARC Report
Participating receivers commonly send aggregate reports daily; timing and coverage vary. You may start receiving XML reports at your rua email address. These reports contain critical metadata about your sending sources:
- The IP addresses of servers sending mail using your domain.
- Whether those IPs passed or failed SPF and DKIM checks.
- Whether those checks aligned with your header “From” domain.
Look out for alignment failures. For example, if you use third-party mailer services for marketing campaigns or newsletters, they may fail DMARC alignment unless you have configured custom subdomains and DKIM keys specifically for them.
Aggregate DMARC reports can reveal unexpected sending sources and alignment failures. They do not diagnose individual recipient typos or bounce loops; use SES delivery and bounce events for that investigation.
After identifying legitimate senders and resolving their alignment failures, move toward p=quarantine and then p=reject, checking reports and delivery after each change. These policies request quarantine or rejection of DMARC-failing mail; receivers retain discretion. A high aggregate pass rate is useful evidence, but it can hide a small legitimate sender that is still failing.
Common Mistakes to Avoid on AWS SES
- Assuming Custom MAIL FROM Is Required for DMARC: SES’s default MAIL FROM does not align with your own domain, but aligned DKIM can still pass DMARC under
p=reject. Custom MAIL FROM adds an SPF alignment path; it is not a prerequisite for that policy. - Enforcing p=reject Too Early: If you request rejection before validating all legitimate sending sources, including support tools, CRM systems, and internal scripts, receivers may reject legitimate messages that fail DMARC.
- Missing Unsubscribe Mechanics: DMARC handles security, but deliverability also relies on recipient behavior. High complaint rates will ruin your reputation even with perfect DMARC alignment. Always pair strong authentication with clear sender practices, such as an easy-to-use unsubscribe footer in marketing materials.
Maintain Visibility Over Your SES Reputation
Configuring DMARC, DKIM, and SPF protects your domain identity, but maintaining high inbox placement requires continuous monitoring. SES provides reputation metrics and optional Virtual Deliverability Manager dashboards and message search. These help investigate delivery; SendOps adds a workspace for audience management, campaigns, and lifecycle workflows.
For a deeper dive into maintaining high deliverability rates, see our technical breakdown on how to fix AWS SES bounce and complaint rate.
SendOps connects to your AWS account and combines message reporting, deliverability alerts, and email workflows. Sending uses your SES resources; contacts, consent, events, and campaign content are held by SendOps. Start with our SES monitoring guide to decide which signals your team needs.