Amazon SES for WordPress: Verify Identity, Sending Access and Delivery

WordPress relies by default on the built-in PHP mail() function to dispatch transactional messages, including password resets, account notifications, and administrator alerts. On unmanaged or shared hosting environments, this default mechanism frequently results in silent drop-offs or spam folder placement because the sending web server lacks cryptographic sender authentication. Integrating Amazon Simple Email Service (Amazon SES) provides an infrastructure-grade relay, but configuring it requires a clear understanding of identity verification, cloud permissions, and DNS protocols.

A critical distinction to maintain throughout this setup is the difference between a successful API request and actual delivery. When WordPress hands off an email via an SES plugin or SMTP relay, a successful response code merely confirms that Amazon SES has accepted the payload for processing. It does not confirm that the recipient’s mail exchange server has accepted the transmission, nor does it guarantee inbox visibility.

Identity Verification: Domains versus Single Addresses

Before any message can be processed by Amazon SES, you must prove ownership of the sending vector. As outlined in the AWS guide on verified identities in Amazon SES, a verified identity is an email address or domain that you establish as an authorized sending source. Verifying an identity confirms ownership and prevents unauthorized parties from spoofing your communication channels.

While Amazon SES permits the verification of individual email addresses (such as notifications@example.ca), domain-level verification is substantially more practical for WordPress installations. Verifying an entire domain authorizes any email address under that root or subdomain without requiring individual inbox confirmations for separate plugin notifications.

According to the AWS documentation on creating and verifying identities in Amazon SES, establishing a domain identity involves configuring DomainKeys Identified Mail (DKIM). Amazon SES primarily uses Easy DKIM, which generates three CNAME records that you must publish in your DNS management console. These records enable receiving mail transfer agents to validate that the cryptographic signatures appended to outbound headers genuinely originate from your domain.

In addition to DKIM, review Sender Policy Framework (SPF) and Domain-based Message Authentication, Reporting, and Conformance (DMARC) alignment. As detailed in the AWS documentation on configuring identities in Amazon SES, SPF checks whether the sending server is authorized for the envelope sender domain. DMARC evaluates alignment with the visible From domain; it can pass through aligned DKIM or aligned SPF. Establishing these records at your DNS host aligns your WordPress outbound stream with modern security requirements.

Navigating the SES Sandbox and Sending Authorization

Every newly provisioned Amazon SES account starts in a restricted testing sandbox. While in the sandbox, an account can send a maximum of 200 messages per 24-hour period at a rate of one message per second. More crucially, your account cannot send messages to arbitrary public recipients. You may only dispatch email to verified recipient identities, or to designated addresses provided by the Amazon SES mailbox simulator.

Attempting to launch an e-commerce store or membership platform while still restricted to the sandbox will cause immediate delivery failures for new customer registrations. To lift these constraints, you must follow the formal procedure to request production access. AWS evaluates this request based on your planned sending volume, bounce handling procedures, and spam mitigation policies. Approval is not instantaneous, so this step should be planned well ahead of any production site launch.

Bridging WordPress and Amazon SES

WordPress core does not provide a native integration layer for the Amazon SES REST API or authenticated SMTP credentials. Connecting the two requires an extension. Popular candidates to evaluate for this role include dedicated transactional mail plugins such as WP Mail SMTP, FluentSMTP, or a documented custom AWS SDK integration. These tools replace the default wp_mail() transport mechanism with either a direct REST API call or an authenticated TLS connection to the regional SES SMTP endpoint.

When provisioning credentials for your WordPress integration, follow the principle of least privilege within AWS Identity and Access Management (IAM):

• Create a dedicated IAM user specifically for the website rather than using root credentials.
• Attach a restricted inline policy permitting only the ses:SendEmail and ses:SendRawEmail actions.
• Restrict the resource ARN to your specific verified domain identity.
• Store access keys securely. Storing API secrets in the WordPress database exposes them to administrators or compromised plugins; a plugin-supported configuration file or secret-management mechanism may reduce exposure in settings screens, but PHP code executing on the site may still read those secrets. Protect backups and logs and rotate credentials when needed.

Securing these credentials internally is as crucial as external DNS configuration. Reviewing your administrative tiering through WordPress roles, capabilities, and permission changes helps ensure that unauthorized site managers cannot alter transmission keys or redirect administrative notices.

Choose API or SMTP credentials to match the integration. SES SMTP credentials are region-specific and the SMTP password is different from an AWS secret access key. Match identity verification, production access and endpoint to the intended region; do not mix API access keys with SMTP login fields.

Troubleshooting Outbound Deliverability

When an expected email from WordPress does not arrive, investigate the failure systematically across the chain:

• Sandbox Rejection: If your log displays an error such as 554 Message rejected: Email address is not verified, check both the sending identity and recipient restrictions in the selected region. This error can also concern an unverified sender.
• Header Mismatches: Ensure that the “From” email address configured in your WordPress form plugins matches the verified identity in Amazon SES. If a plugin attempts to send from an unverified address, SES will drop or reject the payload. This frequently happens when building transactional workflows; for example, integrating checkout handoffs as outlined in our guide on WordPress order form plugins and handoff structures requires verifying that order receipts use the correct domain alias.
• DNS Propagation Delays: DKIM records can take several hours to propagate across global nameservers. Check the Amazon SES console to confirm that the verification status shows “Verified” rather than “Pending”.
• Spam Folder Placement: If Amazon SES accepts the transmission without error but recipients find messages in their junk folders, inspect your DMARC alignment and verify that your domain has not adopted a custom MAIL FROM domain with missing MX records.

Hypothetical Implementation Scenario

Consider a hypothetical Canadian specialty retailer, Northern Gear Supply, operating on WordPress. They need to send automated order confirmations from orders@northerngearsupply.ca and password resets from support@northerngearsupply.ca.

Rather than verifying each address individually, the site administrator creates a domain identity for northerngearsupply.ca in the ca-central-1 (Montreal) AWS Region. The administrator publishes the three generated CNAME records for Easy DKIM into their DNS management console along with a standard DMARC TXT record. While awaiting propagation, they submit a production access request outlining their customer notification model.

Once approved, the administrator creates an IAM user restricted strictly to sending permissions for that domain ARN. In WordPress, they evaluate a dedicated SMTP plugin candidate, input the regional endpoint and credentials via wp-config.php, and send a test message to the Amazon SES mailbox simulator. The simulator confirms the tested SES handling scenario. The team also tests delivery to controlled real inboxes, bounce handling and the actual WordPress notification before launch.

Deployment Checklist