Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Managing Email Delivery Health: Migrating Away from Shared SES Identity and Implementing Role-Based Access Controls

During a recent maintenance session, we identified and resolved several critical issues with our email delivery infrastructure for queenofsandiego.com. The primary concerns were SES reputation damage from forensic report emails and the need to implement proper role-based access controls for team members. This post details the technical approach we used to remediate these issues.

The Problem: SES Configuration Drift and Reputation Risk

Our AWS SES account was sending unsolicited DMARC forensic reports to jada@queenofsandiego.com, triggering complaint reports from recipient mail servers. Each complaint degrades sender reputation and can eventually lead to SES sandbox restrictions. The root cause was a DMARC record configuration that included fo=1 (forensic report flag) and an overly broad ruf (reporting URI) parameter.

Additionally, we had a single shared email identity (jada@queenofsandiego.com) being used across multiple blast automation scripts, making it difficult to audit which processes were sending mail and preventing granular access controls for team members like Travis.

Infrastructure Audit and Remediation Steps

SES and DNS Configuration Review

We performed a comprehensive audit of our email infrastructure:

  • Listed all SES verified identities for the queenofsandiego.com domain
  • Checked Route53 hosted zone for queenofsandiego.com (zone ID and all DNS records)
  • Reviewed existing TXT records for DMARC, SPF, and DKIM configuration
  • Examined SES configuration sets to understand how bounces, complaints, and delivery events were being tracked
  • Verified DMARC forensic report settings in SES console

The audit revealed that our DMARC record contained:

v=DMARC1; p=quarantine; ruf=mailto:jada@queenofsandiego.com; fo=1

The fo=1 flag instructs DMARC reporters to send forensic reports on any DMARC failure, and the ruf parameter directed those reports to our own mailbox, creating a feedback loop where legitimate mail server notifications were being counted as complaints against our SES sending reputation.

DMARC Record Remediation

We updated the Route53 TXT record via the AWS console to remove the forensic reporting configuration:

# Before
v=DMARC1; p=quarantine; ruf=mailto:jada@queenofsandiego.com; fo=1

# After
v=DMARC1; p=quarantine;

This change prevents DMARC reporters from sending us forensic reports, eliminating the complaint feedback that was damaging our sender reputation. The p=quarantine policy remains in place to handle DMARC failures at the receiver's discretion.

Email Identity Architecture: From Shared to Role-Based

Identifying Active Blast Scripts

We searched the codebase to identify all active email-sending processes:

  • /Users/cb/Documents/repos/sites/queenofsandiego.com/tools/send_blast.py — Main blast sending utility
  • /Users/cb/Documents/repos/sites/queenofsandiego.com/tools/run_scheduled_blast.py — Cron-triggered blast scheduler
  • Legacy jada_blast.py processes (checked for active LaunchAgent configurations)

We confirmed that the legacy LaunchAgent was no longer active and that all production blasts route through the modern Python utilities.

Access Control Implementation

Rather than immediately changing the SES identity used by blast scripts (a breaking change), we implemented role-based access controls in our maintenance hub to support multiple team members with different permission levels:

  • Created environment-based role codes for staging and production environments
  • Implemented travisjada2026 as a role-based credential system (separate from email identities)
  • Modified the maintenance hub source to read and validate these role codes based on the deployment environment

The maintenance hub source code was updated to check an ENV variable at build time and embed the appropriate role codes:

# Pseudo-code representation
if ENV == "staging":
    VALID_ROLES = [STAGING_ROLE_CODES]
elif ENV == "prod":
    VALID_ROLES = [PRODUCTION_ROLE_CODES]

Deployment and Infrastructure Changes

Maintenance Hub Staging Deployment

We deployed an updated version of the maintenance hub to our staging environment with new role code support:

  • Source repository: /Users/cb/Documents/repos/sites/queenofsandiego.com/tools/maintenance/
  • Staging build artifact: staging-index.html
  • Validation: Confirmed role codes work in staging before production push

Production Deployment Pipeline

Once validated in staging, we deployed to production using our standard S3 + CloudFront pipeline:

  • Built production version with environment-specific role codes
  • Pushed to S3 bucket serving the maintenance hub
  • Invalidated CloudFront distribution cache to ensure edge nodes serve the updated version
  • Verified that travisjada2026 credentials work in production

Key Architectural Decisions

Why environment-based role codes instead of IAM users? Role codes are simpler to manage for web-based tools that can't use AWS credentials directly. They provide sufficient audit capability (all access is logged against the role) without the overhead of managing separate IAM principals.

Why not immediately change the SES identity? Changing the From:` address for blast emails requires careful planning — it affects deliverability (SPF/DKIM alignment) and user recognition. By implementing access controls first, we can plan a gradual migration to role-specific identities without operational disruption.

Why fix DMARC instead of disabling forensic reports in SES? SES forensic report settings apply account-wide. DNS-level DMARC controls are more granular and send a clear signal to mail servers that we don't want forensic reports. This approach is more "mail server friendly" and sets us up for future domain management.

What's Next

  • Monitor SES bounce and complaint metrics over the next 7-14 days to confirm reputation recovery
  • Plan migration from jada@queenofsandiego.com to role-specific identities (e.g., blasts@queenofsandiego.com) in send_blast.py
  • Document the new role-based access system in the maintenance hub README
  • Review other AWS SES configuration sets for similar forensic report leaks

This infrastructure cleanup eliminated a source of SES reputation damage while laying groundwork for better access controls and auditability in our email delivery system.

```