Skip to main content

AWS SES Domain Verification Stuck: How to Fix 'DKIM Pending' Status

 Few infrastructure tasks are more deceptively simple than verifying a domain in AWS Simple Email Service (SES). You enter your domain, AWS generates three CNAME records, you copy-paste them into your DNS provider, and you wait.

And wait.

If your domain identity status has hung on "Verification Pending" or "DKIM Pending" for more than 72 hours, you aren't just dealing with slow DNS propagation. You likely have a specific, syntax-based configuration error that prevents AWS from locating your keys.

This guide details the root cause of the infamous "stuck verification" issue, specifically regarding the "Double Domain" DNS anomaly, and provides the diagnostic steps to resolve it immediately.

The Root Cause: Absolute vs. Relative DNS Names

To understand why verification fails, you must understand how AWS SES performs validation.

When you enable Easy DKIM, SES generates three CNAME records. These point specific subdomains on your domain (e.g., a1b2c3._domainkey.yourdomain.com) to AWS-hosted public keys. AWS periodically queries these specific subdomains. If the query returns the expected CNAME, the domain is verified.

The "Double Domain" Trap

The failure occurs at the intersection of the AWS Console UI and your DNS provider's interface (e.g., GoDaddy, Namecheap, Cloudflare).

  1. AWS Display: The AWS console displays the Name field as the Fully Qualified Domain Name (FQDN).
    • Example: 54321._domainkey.example.com
  2. DNS Provider Behavior: Many DNS providers treat the "Host" or "Name" field as relative to the root domain automatically.
  3. The Error: If you copy the full string 54321._domainkey.example.com into a provider that expects a relative name, the provider appends your domain again.

Your record unknowingly becomes: 54321._domainkey.example.com.example.com

AWS queries the correct FQDN, receives an NXDOMAIN (non-existent domain) response, and leaves your status as "Pending" indefinitely.

Diagnostic Phase: Confirming the Error

Before changing configurations, verify that the "Double Domain" issue is the culprit. We will use dig, a standard network administration tool, to query DNS records directly.

Step 1: Query the Intended Record

Open your terminal and run a query for the record AWS gave you. Replace the hash and domain with your specific values from the SES console.

# Syntax: dig +short CNAME [Selector]._domainkey.[YourDomain]

dig +short CNAME x4y5z6._domainkey.example.com

Result Analysis:

  • If you get a value (e.g., x4y5z6.dkim.amazonses.com): DNS is correct. The delay is likely on the AWS side or TTL caching.
  • If you get no output: The record does not exist where AWS is looking. Proceed to Step 2.

Step 2: Query the "Doubled" Record

Now, intentionally append your domain name a second time to check for the configuration error.

# Append the domain an extra time at the end
dig +short CNAME x4y5z6._domainkey.example.com.example.com

Result Analysis:

  • If you get a value: You have confirmed the "Double Domain" error. Your DNS provider appended the domain automatically.
  • If you still get no output: You may have created the record as a TXT record instead of CNAME, or there is a typo in the selector string.

The Fix: Correcting DNS Syntax

The solution requires modifying the record in your DNS provider's dashboard.

1. Locate the DNS Management Console

Log in to your registrar (GoDaddy, Namecheap, Google Domains, etc.) or DNS host (Cloudflare, Route53).

2. Edit the CNAME Records

Locate the three CNAME records provided by SES.

Incorrect Configuration (What you likely have):

  • Type: CNAME
  • Host/Name: x4y5z6._domainkey.example.com
  • Value/Target: x4y5z6.dkim.amazonses.com

Correct Configuration: Remove the domain suffix from the Host field.

  • Type: CNAME
  • Host/Name: x4y5z6._domainkey
  • Value/Target: x4y5z6.dkim.amazonses.com

Note: Some providers (like Cloudflare) are smart enough to proxy or flatten CNAMEs. Ensure "Proxy Status" is set to DNS Only (Grey Cloud) for these specific records to ensure AWS sees the raw CNAME values.

3. Verify the Fix

Wait 60 seconds (or up to the TTL value previously set), then run the verification command from Step 1 again.

dig +short CNAME x4y5z6._domainkey.example.com

Once this command returns the AWS SES target url, AWS will detect it on the next polling cycle.

Force-Refreshing AWS Verification

AWS SES uses an exponential backoff strategy for checking DNS records. If your domain has been pending for days, the polling frequency has likely decreased significantly.

To force a faster re-check, you can re-initiate the verification process using the AWS CLI.

Prerequisites

Ensure you have the AWS CLI v2 installed and configured with appropriate permissions (ses:VerifyDomainDkim or ses:VerifyDomainIdentity).

Retry Command

You do not need to delete and recreate the identity. You can simply toggle the DKIM signing attribute to trigger a state refresh.

# 1. Disable DKIM Signing temporarily
aws ses set-identity-dkim-enabled \
    --identity example.com \
    --no-dkim-enabled

# 2. Re-enable DKIM Signing immediately
aws ses set-identity-dkim-enabled \
    --identity example.com \
    --dkim-enabled

This sequence forces SES to re-evaluate the verification status. In most cases, the console status will change from "Pending" to "Success" within 5 to 15 minutes.

Edge Case: Route53 Hosted Zones

If you are using AWS Route53 as your DNS provider and logged into the same AWS account as your SES setup, you can avoid this entirely.

When creating the Identity in SES:

  1. Look for the button labeled "Publish to Route53".
  2. Clicking this allows SES to write the records directly to your Hosted Zone.
  3. Route53 automatically handles the relative vs. absolute domain syntax correctly.

However, if your Route53 Hosted Zone is in a different AWS account (a common multi-account security pattern), you must follow the manual steps above, ensuring you do not duplicate the domain name in the Record Set "Name" field.

Summary

The "Pending Verification" status is rarely a mysterious propagation delay and almost always a specific data entry error.

  1. Diagnose: Use dig to check if the record exists at selector._domainkey.domain.com.domain.com.
  2. Fix: Edit your DNS records to remove the domain suffix from the "Host" field.
  3. Verify: Confirm the fix with dig before waiting on AWS.

By validating the DNS resolution yourself, you remove the guesswork and can unblock your email infrastructure immediately.

Labels: