Amazon SES

Amazon SES (Amazon Simple Email Service, AWS’s email-sending service) can, besides sending, report delivery events back — confirmed deliveries, bounces, and complaints — which powers the delivered state, webhooks like mail.delivered and mail.bounced, and automatic suppressions.

Before you start

• An SES account out of the sandbox (AWS’s sandbox only sends to verified addresses, at most 200 a day — fine for a first test to your own verified domain; request production access in the SES console before real traffic).
• Your sender domain verified in SES with DKIM enabled. This is standard SES setup and AWS’s wizard walks you through the DNS records — see Deliverability for what SPF, DKIM, and DMARC each prove and how to confirm alignment.
• An IAM access key for Mailway, created as below.

Create an IAM access key for Mailway

Mailway needs one thing from AWS: permission to send. It never reads your account, manages identities, or calls SNS (the delivery-event subscription below is confirmed over plain HTTPS, no AWS credentials involved). So give it a dedicated IAM user whose only rights are the two sending actions — not AmazonSESFullAccess, and never your root user’s keys. About five minutes.

1. Create the user. In the AWS console, open IAM → Users → Create user. Name it after its job (e.g. mailway-sender) and leave Provide user access to the AWS Management Console unticked — this user only ever signs API calls. Click Next, skip the permissions page for now, and Create user.

2. Allow sending, and nothing else. Open the new user → Permissions tab → Add permissions → Create inline policy → switch the editor to JSON and paste:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "MailwaySendOnly",
         "Effect": "Allow",
         "Action": ["ses:SendEmail", "ses:SendRawEmail"],
         "Resource": "*"
       }
     ]
   }

   Next, name it MailwaySendOnly, Create policy. ses:SendEmail covers Mailway’s API sends; ses:SendRawEmail covers SMTP, including the SMTP password Mailway derives from this key.

3. Create the access key. Same user → Security credentials tab → Access keys → Create access key. For the use case pick Application running outside AWS, add a description tag such as Mailway, and Create access key.

4. Copy both values now. AWS shows the Access key ID (AKIA…) and the Secret access key exactly once — copy them straight into Mailway (next section), or use Download .csv file and delete the file after pasting.

5. Note your region. The key works in every region. The region you choose in Mailway picks which SES you send through. Use the one shown top-right in the SES console where your domain is verified and production access is granted (for example eu-central-1, Frankfurt). SES has an SMTP endpoint in fewer regions than its API, so with SMTP only under Send via, the list shows just those.

Tip

Rotating the key takes a minute and drops nothing: create a second access key on the same user (IAM allows two), paste it into the provider in Mailway (Configure), then deactivate and delete the old one.

Add the account in Mailway

1. Have the access key ready — the ID and secret from the section above. Use a key dedicated to Mailway so you can rotate or revoke it independently.

   The one access key gives the account both transports: the API uses it directly, and Mailway derives the SES SMTP password from it (AWS’s documented conversion), so there’s no separate SMTP login to create. The two are equivalent for fidelity: SES’s API is raw-capable — SendRawEmail carries mail relayed through Mailway’s SMTP relay byte-for-byte, exactly like SMTP.

   Alternative: if you already use per-region SES SMTP credentials, paste those into the provider’s SES SMTP credentials fields instead — the account then sends over SMTP only.

   Note

   Which one do you have? SES SMTP credentials are an IAM access key too: the SES console’s Create SMTP credentials makes an IAM user (named like ses-smtp-user.…) whose access key ID (AKIA…) is the SMTP username. The SMTP password it shows is computed from that key’s secret, not the secret itself, and can’t be turned back into it. So if the pair you hold came from Create SMTP credentials (IAM then lists the key’s last-used service as ses-smtp), it goes in the SMTP fields. The secret access key goes in the IAM fields only if you created the key in IAM yourself, as in the section above.

2. Add the provider.

   In the console, open Providers → New provider, pick Amazon SES, choose the region, and paste the credentials. Secrets are encrypted at rest.

3. Attach it to a project.

   Open the project, attach the provider, and position it in the failover order. Send something — the console’s provider health panel starts filling in.

Delivery events

Without delivery events, SES only reports that it accepted the mail. With them, SES tells Mailway what happened afterwards. Fifteen minutes, once.

1. Open delivery tracking. In the console, open the provider → Delivery tracking (beside Configure). Mailway creates a secret webhook URL of the form https://hook.mailway.net/v1/amazon-ses/… and shows it ready to copy, with the AWS steps below. Treat it like a password.

2. Create a configuration set in the SES console (any name, e.g. mailway).

3. Wire SNS. In AWS: create an SNS topic, then add an event destination to your configuration set publishing Delivery, Bounce, and Complaint events to that topic. Subscribe the topic to your Mailway webhook URL (protocol: HTTPS). Mailway confirms the subscription automatically and pins the topic.

4. Tell Mailway the configuration set. In the same dialog, enter the set’s name in the Tell Mailway the configuration set step. Mailway now stamps every SES send with it (X-SES-CONFIGURATION-SET). If your app already sets that header, the account’s configuration set replaces it; SES reads the header and removes it before delivery.

From then on: deliveries flip mails to delivered, hard bounces and complaints land in the project’s suppression list automatically, and the corresponding webhook events fire to your endpoints. Every inbound event is signature-verified against AWS before Mailway trusts it.

What each event does in Mailway

SES event	Mailway outcome
Delivery	The mail turns delivered (confirmed by the provider’s event).
Bounce (Permanent)	The mail turns bounced; the address is auto-suppressed for the project.
Bounce (Transient)	Recorded as soft_bounced (temporary; a later delivery outranks it).
Complaint	The mail turns complained; the address is auto-suppressed.

Check the connection

• Connection check. The provider page’s connection check logs in over SMTP with the password derived from your key pair, which proves the key, without sending anything. SES’s API can’t be read under the send-only policy above, so the API side shows as unverifiable; a test email proves it.
• Delivery events. Send a test email from the Delivery tracking dialog’s last step: it waits for SES’s first event and ticks when it arrives.
• A real mail. Send one and watch it flip from accepted to delivered in the console within a few seconds. If it stays accepted, the SNS subscription or configuration set isn’t reaching Mailway — troubleshooting walks through the usual causes.

What Amazon SES changes

On either transport, SES replaces the message’s Message-ID and Date, so a DKIM signature your app applied won’t verify at the inbox. SES signs with its own DKIM for your domain. Tested results: What providers change.

Limits

SES caps a message at 50 recipients, counting every To/Cc/Bcc header address. Mailway handles bigger sends automatically — see the fan-out note and 554 Recipient count exceeds 50. Until AWS grants production access, the sandbox limits above apply (verified addresses only, 200 a day).