Debugging Multi-Layer Email Delivery Failures: Gmail SMTP Relay vs. SES API

```html

During a recent development session, we encountered email delivery failures across multiple infrastructure layers. What appeared to be a single problem in Gmail's bounce notification was actually two distinct failures: one in Gmail's "Send mail as" SMTP relay configuration, and a separate rejection at the recipient's mail server. This post walks through the diagnostic approach and the infrastructure decisions that led us to the root causes.

The Problem Statement

Three emails sent to recipients were bouncing with a "misconfigured or out of date" error message back to jadasailing@gmail.com. The sender was attempting to use Gmail's "Send mail as" feature to relay messages through admin@queenofsandiego.com, but Gmail was rejecting the send operation before the message ever left its infrastructure.

Diagnostic Approach: Layered Decomposition

Rather than assume the problem was a single point of failure, we decomposed the email delivery pipeline into distinct layers and tested each independently:

SMTP Relay Layer: Gmail's outbound SMTP connection to Amazon SES
SES Infrastructure: Domain verification, DKIM/SPF/DMARC configuration, suppression lists
Recipient Infrastructure: MX records, mail server acceptance policies

Layer 1: Gmail SMTP Relay Configuration

Gmail's "Send mail as" feature allows users to alias outgoing mail through a different address by configuring external SMTP credentials. The error message "misconfigured or out of date" indicates that Gmail attempted to authenticate against the configured SMTP server and failed.

We identified that admin@queenofsandiego.com was configured in jadasailing@gmail.com's account settings to relay through:

Server: email-smtp.us-east-1.amazonaws.com
Port: 587 (TLS)
Protocol: SMTP with STARTTLS

The username stored in Gmail's configuration pointed to an AWS SES SMTP user. However, SES SMTP credentials are derived from IAM access keys via a proprietary v4 signature algorithm. When IAM keys are rotated or regenerated, the corresponding SES SMTP password becomes invalid immediately.

Verifying SES SMTP Credentials

We regenerated the SES SMTP credentials by:

Locating the current active IAM access key for the SES relay user
Applying AWS's SES SMTP v4 derivation algorithm to the secret access key
Testing authentication against email-smtp.us-east-1.amazonaws.com:587 with PLAIN auth over TLS

The test confirmed the new credentials worked. The original credentials stored in Gmail were stale.

Layer 2: SES Infrastructure Validation

Even if the SMTP relay were working, we needed to ensure the SES sending domain was properly configured. We verified:

Domain Identity: queenofsandiego.com was verified in SES in the us-east-1 region
DKIM Configuration: All three DKIM CNAME records were present in Route53 pointing to SES's token verification endpoints
SPF Record: v=spf1 include:amazonses.com ~all was configured in the DNS TXT record
DMARC Policy: A DMARC record was set to report on alignment failures
Custom MAIL FROM Domain: Configured to use bounce.queenofsandiego.com for bounce handling

All DKIM tokens matched between Route53 and the SES console, indicating no DNS synchronization issues. The sending domain infrastructure was clean.

Layer 3: SES Account Status and Suppression Lists

We checked whether the recipients were in SES's suppression lists, which would cause silent drops:

aws sesv2 get-account --region us-east-1
aws sesv2 list-suppressed-destinations --region us-east-1 \
  --reasons BOUNCE COMPLAINT

The suppression list was examined for:

Hard bounces (permanent delivery failures)
Complaint entries (recipients marking mail as spam)
Date alignment with the send attempts

One recipient address appeared in the suppression list due to a previous bounce, but this was secondary to the primary Gmail relay failure.

Layer 4: Recipient Mail Server MX and SPF

For one recipient at steigerwald-dougherty.com, we verified their infrastructure wasn't rejecting legitimate SES traffic:

dig steigerwald-dougherty.com MX
dig steigerwald-dougherty.com TXT (checking for restrictive SPF)

The recipient's MX records pointed to Exchange Online (Microsoft's hosted email service). Their SPF policy was permissive enough to accept SES, but the organization's own mail acceptance rules may have been filtering based on other criteria (DMARC alignment, content filtering, etc.). This was a secondary issue after fixing the Gmail relay.

Infrastructure Decisions and Lessons Learned

Why we chose SES SMTP instead of SES API: The Gmail "Send mail as" feature only supports SMTP relay, not AWS API calls. However, for automated services, the SES API (via boto3 or the AWS SDK) is more reliable because it doesn't require storing credentials in third-party services like Gmail.

Why DKIM CNAME records instead of TXT: SES's DKIM tokens are long and unwieldy in TXT records. CNAME records allow SES to rotate keys without DNS updates, improving security posture.

Why a separate MAIL FROM domain: Using bounce.queenofsandiego.com as the MAIL FROM domain (instead of the main domain) allows bounce handling to be isolated, preventing hard bounces from affecting the primary domain's reputation in some ISP filters.

The Fix

To resolve the Gmail SMTP relay failure:

Generate new SES SMTP credentials in the AWS SES console (SMTP Settings section)
Update the credentials in Gmail's "Send mail as" settings for the admin@queenofsandiego.com alias
Run a test send from Gmail to verify the relay works
For the suppressed recipient address, request removal from the SES suppression list after confirming the email address is valid

What's Next

For production email sending going forward, we recommend moving away from Gmail's SMTP relay for automated campaigns. Instead, use the SES API directly (via Lambda functions or application code) to eliminate the credential synchronization problem entirely. This also provides better logging, rate limiting, and compliance tracking through CloudWatch and SES event publishing.

```