Amazon SES (Simple Email Service)¶

Email categories SES handles:
  Transactional:  order confirmations, password resets, receipts, alerts
  Marketing:      newsletters, promotions, announcements
  Bulk:           large-scale campaigns to opt-in mailing lists
  Notification:   system alerts, CloudWatch alarms via email

SES does NOT:
  Provide a GUI email client (that's an MUA — use Gmail, Outlook)
  Replace an Exchange server (that's Microsoft 365 / WorkMail)
  Send SMS (that's SNS)

Self-managed SMTP server:
  Maintain server 24/7 → patches, uptime, scaling
  Build/maintain IP reputation from scratch
  Handle bounces, complaints, blacklists manually
  Complex DKIM/SPF/DMARC setup

Amazon SES:
  Fully managed — no servers to maintain
  AWS-managed IP reputation (warm IPs with established reputation)
  Built-in bounce/complaint handling + suppression lists
  Easy DKIM with automatic key rotation every 90 days [captaindns](https://www.captaindns.com/en/blog/amazon-ses-transactional-email-technical-guide)
  Cost: $0.10 per 1,000 emails

Verify a single email address:
  SES → Verified Identities → Create → Email address
  → SES sends verification link to that email
  → Click link → verified ✅

Limitation: can only send FROM this exact email address
Use case: quick testing, single-sender applications

Verify an entire domain:
  SES → Verified Identities → Create → Domain
  → SES provides DNS records to add to your domain (Route 53 or other)
  → DNS propagates → domain verified ✅

Benefit: send from ANY address at that domain
  noreply@ibtisam-iq.com ✅
  support@ibtisam-iq.com ✅
  orders@ibtisam-iq.com  ✅

1. DKIM records (3 CNAME records for Easy DKIM)
   Automatically used for both domain verification AND DKIM signing

2. Optional MAIL FROM (custom MX record)
   Required for SPF DMARC alignment (see Section 4)

3. DMARC TXT record (you add manually)
   Not generated by SES — you write it based on your policy

Can only send TO: verified email addresses or domains (you own both sides)
Sending limit: 200 emails/day
Send rate:     1 email/second
Cannot send to: random email addresses (would get AccessDenied error)

New AWS accounts are untrusted — SES cannot know if you will spam.
Sandbox forces you to prove:
  → You own the sending domain (verified identity)
  → You know who you're sending to (verified recipients)
  → You have basic bounce/complaint handling

Required in your request:
  1. Website / use case description
     → "We send order confirmation emails to paying customers"

  2. Email type
     → Transactional / Marketing / Notification

  3. Opt-in mechanism
     → "Users check a box at registration confirming they want emails"
     → Double opt-in preferred (confirm email address via link)

  4. Bounce handling
     → "We have SNS + Lambda processing bounces in real-time
        and suppressing bounced addresses from future sends"

  5. Complaint handling
     → "We process SES complaint notifications and unsubscribe
        complainants immediately"

  6. Sending volume estimate
     → Daily and peak volumes

  7. Unsubscribe mechanism (for marketing)
     → One-click unsubscribe link in every email

Best practices to guarantee approval:
  → Verify domain (not just email address)
  → Configure bounce + complaint notifications (SNS)
  → Enable account-level suppression list [docs.aws.amazon](https://docs.aws.amazon.com/ses/latest/APIReference-V2/API_PutConfigurationSetSuppressionOptions.html)
  → Set up DKIM (Easy DKIM)
  → Have a real application/website to show

What: DNS TXT record listing which mail servers may send on behalf of your domain
How:  Receiving mail server checks MAIL FROM domain → looks up SPF record
      → is the sending IP in the allowed list? YES → SPF pass

DNS TXT record:
  Name: mail.ibtisam-iq.com    ← your custom MAIL FROM subdomain
  Value: "v=spf1 include:amazonses.com ~all"
    v=spf1           → SPF version
    include:amazonses.com → SES IP ranges are authorized
    ~all             → soft fail (mark suspicious, don't reject)
    -all             → hard fail (reject outright — use after testing)

Critical: SPF checks MAIL FROM domain (Return-Path / envelope sender)
          NOT the From: address you see in your email client
          → Must use custom MAIL FROM for SPF DMARC alignment [easydmarc](https://easydmarc.com/blog/amazon-ses-spf-and-dkim-configuration/)

What: cryptographic signature on outgoing emails proving content wasn't modified
How:
  SES (sender): signs email with private key
  Receiving server: retrieves public key from DNS → verifies signature
  → Signature valid? Content intact? → DKIM pass

Easy DKIM (recommended): [docs.aws.amazon](https://docs.aws.amazon.com/ses/latest/dg/send-email-authentication-dkim.html)
  SES generates 2048-bit RSA key pair automatically
  Provides 3 CNAME records to add to your DNS:
    abc123._domainkey.ibtisam-iq.com → CNAME → abc123.dkim.amazonses.com
    def456._domainkey.ibtisam-iq.com → CNAME → def456.dkim.amazonses.com
    ghi789._domainkey.ibtisam-iq.com → CNAME → ghi789.dkim.amazonses.com
  → AWS rotates keys automatically every 90 days ← no manual maintenance [captaindns](https://www.captaindns.com/en/blog/amazon-ses-transactional-email-technical-guide)
  → These 3 CNAMEs also serve as domain verification records

BYODKIM (Bring Your Own DKIM):
  You generate 1024–2048 bit RSA key pair
  Add TXT record with public key to DNS
  Upload private key to SES
  You are responsible for rotation

What: policy that tells receiving servers what to do when SPF or DKIM fail
      AND ensures the From: address domain matches the authenticated domain

DMARC requires ALIGNMENT:
  SPF alignment:  MAIL FROM domain must match From: domain
  DKIM alignment: d= in DKIM signature must match From: domain
  At least one must align and pass → DMARC pass

DMARC DNS TXT record:
  Name:  _dmarc.ibtisam-iq.com
  Value: "v=DMARC1; p=quarantine; rua=mailto:dmarc@ibtisam-iq.com; pct=100"
    v=DMARC1        → DMARC version
    p=none          → policy: monitor only (start here — no rejection)
    p=quarantine    → send to spam folder if DMARC fails
    p=reject        → reject email entirely if DMARC fails (most strict)
    rua=mailto:...  → aggregate reports sent here (daily digest)
    ruf=mailto:...  → forensic reports (individual failures)
    pct=100         → apply policy to 100% of email

Rollout strategy:
  Phase 1: p=none → collect reports, find legitimate sources
  Phase 2: p=quarantine → test with pct=10, increase gradually
  Phase 3: p=reject → full protection against spoofing

Receiving server checks email from ibtisam@ibtisam-iq.com:

SPF check:
  Looks at MAIL FROM (Return-Path): mail.ibtisam-iq.com
  → DNS TXT lookup: mail.ibtisam-iq.com SPF record
  → SES IP in allowed list? → SPF PASS ✅
  → mail.ibtisam-iq.com matches ibtisam-iq.com? → SPF ALIGNMENT ✅

DKIM check:
  Finds DKIM-Signature header in email
  → d=ibtisam-iq.com in signature
  → DNS CNAME lookup: public key
  → Verifies signature → DKIM PASS ✅
  → d=ibtisam-iq.com matches From: ibtisam-iq.com? → DKIM ALIGNMENT ✅

DMARC check:
  Looks up _dmarc.ibtisam-iq.com
  → SPF aligned + passed OR DKIM aligned + passed → DMARC PASS ✅
  → p=reject but DMARC passed → deliver normally ✅

If DMARC FAILS (someone spoofing your domain):
  p=none:       deliver, send report to rua address
  p=quarantine: move to spam, send report
  p=reject:     refuse delivery, send report

Default (no custom MAIL FROM):
  From:         ibtisam@ibtisam-iq.com     ← what user sees
  Return-Path:  bounce@amazonses.com       ← SPF checks THIS domain
  SPF passes for amazonses.com but fails alignment with ibtisam-iq.com
  → DMARC FAILS for SPF (only DKIM can save it)

With custom MAIL FROM (mail.ibtisam-iq.com):
  From:         ibtisam@ibtisam-iq.com
  Return-Path:  bounce@mail.ibtisam-iq.com ← SPF checks THIS domain
  → mail.ibtisam-iq.com is subdomain of ibtisam-iq.com → ALIGNMENT ✅
  → DMARC passes via SPF ✅

DNS records to add:
  MX:  mail.ibtisam-iq.com  10  feedback-smtp.us-east-1.amazonses.com
  TXT: mail.ibtisam-iq.com  "v=spf1 include:amazonses.com ~all"

Use any application that supports SMTP:
  Host:     email-smtp.us-east-1.amazonaws.com
  Port:     587 (STARTTLS) or 465 (SSL) or 25
  Auth:     SMTP credentials (separate from IAM — generate in SES console)
  Username: SMTP username (starts with AKIA...)
  Password: SMTP password (different from access key secret)

Use case:
  Existing apps that use SMTP (WordPress, Jira, Jenkins notifications)
  CMS systems with built-in SMTP configuration

import boto3

ses = boto3.client('sesv2', region_name='us-east-1')

response = ses.send_email(
    FromEmailAddress='noreply@ibtisam-iq.com',
    Destination={
        'ToAddresses': ['customer@example.com'],
        'CcAddresses': [],
        'BccAddresses': []
    },
    Content={
        'Simple': {
            'Subject': {'Data': 'Your order has shipped', 'Charset': 'UTF-8'},
            'Body': {
                'Text': {'Data': 'Your order #1234 has shipped.', 'Charset': 'UTF-8'},
                'Html': {
                    'Data': '<h1>Order Shipped</h1><p>Your order #1234 is on its way.</p>',
                    'Charset': 'UTF-8'
                }
            }
        }
    },
    ConfigurationSetName='production-tracking'   # ← always use a configuration set
)

# Lambda → SES → customer email
# IAM role must have: ses:SendEmail or ses:SendRawEmail permission

import boto3, os

def handler(event, context):
    ses = boto3.client('sesv2')
    ses.send_email(
        FromEmailAddress=os.environ['FROM_EMAIL'],
        Destination={'ToAddresses': [event['customerEmail']]},
        Content={
            'Simple': {
                'Subject': {'Data': f"Order #{event['orderId']} confirmed"},
                'Body': {'Html': {'Data': build_html_email(event)}}
            }
        },
        ConfigurationSetName='prod-config-set'
    )

Configuration Set: "production-tracking"

Components:
  Event destinations → where to send email events (see below)
  Reputation options → track bounce/complaint rates
  Sending options    → enable/disable sending for this config set
  Suppression options → override account-level suppression (see Section 8)
  TLS policy         → REQUIRE TLS or OPTIONAL
  Virtual Deliverability Manager → ML deliverability insights

Route events to:
  SNS   → real-time processing (Lambda → update DB, suppress address)
  Kinesis Firehose → stream to S3/analytics
  CloudWatch → metrics and alarms on delivery rates
  EventBridge → route to any downstream service

Essential configuration: [oneuptime](https://oneuptime.com/blog/post/2026-02-12-move-amazon-ses-out-of-sandbox/view)
  aws sesv2 create-configuration-set-event-destination \
    --configuration-set-name "production-tracking" \
    --event-destination-name "bounces-and-complaints" \
    --event-destination '{
      "Enabled": true,
      "MatchingEventTypes": ["BOUNCE", "COMPLAINT"],
      "SnsDestination": {
        "TopicArn": "arn:aws:sns:us-east-1:123456789012:ses-bounces"
      }
    }'

Hard bounce (permanent failure):
  Address does not exist: user@nonexistentdomain.com
  Address permanently rejected: mailbox closed, blocked sender
  → NEVER send to this address again
  → Sending repeatedly → reputation destroyed → SES may suspend account

Soft bounce (temporary failure):
  Mailbox full, server temporarily unavailable
  → SES retries automatically for up to 72 hours
  → After exhausting retries → treated like hard bounce

Recipient clicks "Mark as Spam" in Gmail/Outlook
→ ISP sends complaint notification to SES via Feedback Loop
→ SES triggers COMPLAINT event
→ You must stop sending to this person immediately
→ Continuing to send to complainants = major reputation damage

Bounce rate:
  < 2%  → Healthy
  2–5%  → Warning — AWS may pause sending
  > 5%  → Account sending suspended

Complaint rate:
  < 0.08% → Healthy (Gmail threshold: below 0.1%)
  0.08–0.1% → Warning
  > 0.1%  → Risk of suspension, deliverability severely impacted

These metrics in CloudWatch: AWS/SES namespace
  Reputation.BounceRate
  Reputation.ComplaintRate
  → Set alarms on both at warning thresholds

Account-level suppression list:
  Automatically adds addresses that result in hard bounce or complaint
  SES will not attempt delivery to suppressed addresses
  Suppressed addresses NOT counted toward bounce/complaint rate metrics

Enable:
  aws sesv2 put-account-suppression-attributes \
    --suppressed-reasons BOUNCE COMPLAINT

Configuration-set-level suppression override: [docs.aws.amazon](https://docs.aws.amazon.com/ses/latest/dg/sending-email-suppression-list-config-level.html)
  You can override account-level suppression per configuration set
  Example:
    Account: suppress BOUNCE + COMPLAINT
    Config set "transactional": suppress BOUNCE only
    → Transactional emails ignore complaint suppression
       (transactional emails like password resets are expected)

Manually add/remove addresses:
  Add:    aws sesv2 put-suppressed-destination --email-address bad@example.com --reason BOUNCE
  Remove: aws sesv2 delete-suppressed-destination --email-address recover@example.com
  List:   aws sesv2 list-suppressed-destinations

Global AWS suppression list:
  AWS maintains a list of addresses that bounced across ALL SES customers
  Addresses on this global list → SES suppresses even if not on your list
  Cannot override global suppression

Setup:
  1. Add MX record: ibtisam-iq.com MX 10 inbound-smtp.us-east-1.amazonaws.com
  2. Create receipt rules defining what to do with incoming email

Receipt rule actions:
  S3:         save raw email to S3 bucket
  Lambda:     invoke function with email content (process, parse, respond)
  SNS:        publish notification
  SES:        forward to another email address (bounce if unverified)
  WorkMail:   deliver to Amazon WorkMail
  Stop:       stop processing further rules

Receipt rule example:
  Rule: emails to support@ibtisam-iq.com
    → S3: save to my-email-bucket/support/
    → Lambda: parse email → create Jira ticket
    → SNS: notify on-call engineer

Use cases:
  Auto-reply system
  Email-to-ticket integration
  Email-based workflow triggers
  Catch-all inbox with Lambda processing

Shared IPs:
  AWS manages reputation
  Good for low-to-medium volume
  Cheaper (no extra cost)
  Reputation affected by other customers' behavior (rare but possible)

Dedicated IPs:
  IP assigned exclusively to your account
  You own the reputation → send consistently to build it
  Required for: high volume, strict deliverability requirements
  Cost: ~$24.95/month per dedicated IP (plus usage)
  Warm-up: must gradually increase volume over weeks to build reputation

Dedicated IP Pools:
  Group dedicated IPs → use different pools for different email types
  Pool "transactional": high-reputation IPs for password resets
  Pool "marketing":     separate IPs for campaigns (isolate reputation)

ML-powered dashboard showing deliverability health:
  Open rates, click rates per ISP (Gmail, Outlook, Yahoo)
  Inbox placement rate
  Deliverability recommendations
  Optimal time-to-send suggestions

Enable per configuration set or account-level
Additional cost per processed email
Use for: large-scale senders needing per-ISP deliverability insights

Sending:
  $0.10 per 1,000 emails
  Free tier: 3,000 emails/month free when sent from EC2 or Lambda

Attachments: $0.12 per GB of attachments sent

Receiving: $0.10 per 1,000 received emails
           First 1,000 received/month: FREE

Dedicated IPs: ~$24.95/month per IP

Virtual Deliverability Manager: $0.0015 per message processed

No charge for:
  Bounces/complaints to your SNS topics
  SES console usage
  Sandbox emails within limits