Bring your AWS account.
Connect SES while keeping your usage, permissions and sending reputation under your control.
1. Prepare SES in the right region
Open your AWS SES console and note the region you intend to use. Your sending identities, quotas and production-access state are region-specific. Select that same region from the supported choices in Mailat setup.
SES sandbox accounts restrict recipients and sending volume. To send to unverified recipients, request production access in AWS. Approval is an AWS decision, not something a Mailat subscription bypasses. See AWS’s production-access guide.
Review AWS pricing and quotas for the resources you enable. A successful connection does not guarantee inbox placement or unlimited sending.
2. Create dedicated application credentials
- In the IAM console, create or select an IAM user dedicated to this Mailat instance. Do not use root-account access keys.
- Assign the permissions needed for the capabilities below, scoped to the relevant resources where AWS supports it.
- Create an access key for an application running outside AWS. Save the Secret Access Key securely; AWS only displays it when created.
- Enter the key, secret and region in Mailat setup. Do not send credentials in support tickets, paste them into DNS records or save them in screenshots.
The current setup supports long-lived IAM access keys. Temporary STS credentials require a session token and are not supported by this form.
3. Match permissions to what you enable
AWS permissions should cover the operations your Mailat instance performs. Avoid granting unrelated account-wide access just to make a connection check pass.
| Capability | What needs permission |
|---|---|
| Connection check | ses:GetSendQuota in the selected region |
| Sending & domains | SES sending, identity verification, DKIM and custom MAIL FROM configuration |
| Mail storage & attachments | The S3 bucket and object operations required by your instance’s storage setup |
| Delivery feedback | The SES notification and SNS topic/subscription operations required by feedback setup |
| Optional receiving | SES receipt rules plus the S3/SNS resources configured for inbound mail |
Use AWS’s IAM guidance for SES and the setup diagnostics in your Mailat instance to review the exact policy for your resources. If you need help, contact support with the denied action and resource name, never your secret.
Mailat’s managed instance uses its configured web TLS setup; you do not need to grant blanket AWS Certificate Manager access for the website certificate.
4. Validate the connection
In your Mailat.co dashboard, open setup, enter your credentials and choose Validate credentials. The current check calls ses:GetSendQuota. It confirms that this read operation works and reports the quota returned by AWS.
It does not prove permission to send, create identities, configure storage or subscribe to feedback. It also does not confirm that a domain’s DNS is verified. Those capabilities must be configured and checked inside the deployed Mailat instance.
If you change a key, secret or region after validation, run the check again. Continue only with the configuration you actually validated.
When a check fails
- Invalid credentials: check that the key is active, the secret matches, and neither field has extra whitespace.
- Access denied: review the denied IAM action and the selected region. Grant only the missing permission for the intended resource.
- Sending still restricted: check SES sandbox status, production access, quotas and the sender identity in the same region.
- Receiving unavailable: receiving support varies by region and requires a separate receiving setup; sending access alone is insufficient.
Once the instance is deployed, continue with Domains & DNS.