TABLE OF CONTENTS



About Amazon SES

If your team is reviewing email being sent on your behalf "via Amazon", it helps to know what AWS SES is:

  • One of the largest email systems in the world. Amazon SES is among the top global email senders, handling very high volumes of legitimate mail for a large number of organisations.
  • Used by reputable, security-conscious companies. Many well-known senders publish include:amazonses.com in their own SPF records — for example Netflix, Reddit, Datadog, Twitch, Auth0, Zoom and Robinhood — i.e. the same configuration described in this FAQ.
  • Sending reputation is actively protected. Senders must prove domain ownership before sending, and addresses that hard-bounce or mark mail as spam are automatically suppressed to keep deliverability high.
  • Strong verification and isolation. An SES account can only send for domains it has explicitly verified, and AWS enforces strict separation between accounts.

1. Domain configuration: subdomain vs. root domain

Can we use our main (root) domain instead of a subdomain?

The address your recipients see in the From field can use your primary domain (for example noreply@yourdomain.com). However, the MAIL FROM domain — the technical Return-Path / envelope-from used for bounce and complaint handling — must be a dedicated subdomain of your verified domain. AWS SES requires this so that bounces and complaints are processed correctly and your root domain's reputation is protected.

Can we use our root domain for the Return-Path?

No. AWS SES will not set the Return-Path on a root domain — it requires an MX record on a dedicated subdomain to manage bounce and feedback handling.

What are the rules for the MAIL FROM subdomain?

This is a standard AWS SES requirement (AWS documentation). The subdomain:

  1. Must be a subdomain of your verified sending domain (for example aml.yourdomain.com).
  2. Must not be a domain you currently use to send other outbound mail.
  3. Must not be a domain you use to receive inbound mail.

You are free to choose any subdomain name.

2. DNS records you need to publish

Which DNS records are required?

There are two parts to the records. First AML will provide the exact values once configuration begins in AWS:

  1. DKIM records — a set of DKIM CNAME records (provided by AWS SES) that verify your domain and allow SES to sign mail for it. These prove domain ownership and must be published.
  2. MX record on the MAIL FROM subdomain (bounce / feedback handling):

aml.yourdomain.com.  MX 10 feedback-smtp.amazonses.com

  1. SPF (TXT) record on the MAIL FROM subdomain (authorises SES to send for the subdomain):

aml.yourdomain.com.  TXT "v=spf1 include:amazonses.com ~all"

Always publish the exact records First AML sends you (including the DKIM CNAMEs), rather than copying the examples above.

Do we need to change our existing DMARC settings?

No. No changes to your existing root-domain DMARC are required. The DKIM records above are added as part of the SES setup and do not alter your existing mail flows or DMARC policy.

Can we tweak or "harden" the SPF record after it's published?

No — publish the SPF record exactly as provided and do not modify it. This is an AWS requirement, not a preference, so there is no alternative configuration here.

Do not change the SPF record we provide. In particular, do not change the qualifier from ~all (softfail) to -all (hardfail) — this has previously broken mail delivery when a record was "tidied up". The record must be published exactly as supplied for SES to work.

3. Why a custom MAIL FROM domain is required

Why do we still see delivery failures or dkim temperror when we only change our root SPF record?

Adjusting your root domain's SPF alone does not achieve alignment if the envelope sender (Return-Path) still resolves to amazonses.com. To pass strict verification checks, the custom MAIL FROM domain must be configured against a dedicated subdomain.

Is there a simpler alternative to setting up the subdomain?

First AML has explored the alternatives, and they do not reliably resolve the underlying alignment issue. The only reliable solution is configuring the custom MAIL FROM domain — the dedicated subdomain with its required DNS records (see section 2). For the SPF portion we use include:amazonses.com, the same approach used by many major senders (see About Amazon SES).

4. Return-Path and bounce ("Mailer Daemon") errors

We're receiving Mailer Daemon bounce errors or intermittent non-delivery even though the address is correct. Why?

This is caused by Return-Path alignment failing — typically when only the root SPF has been changed and the envelope sender still resolves to Amazon. It can appear intermittently (mail works one day and fails the next). Configuring the custom MAIL FROM subdomain resolves it by routing bounce and feedback handling correctly.

How are bounces handled?

Bounces are directed to the Return-Path subdomain, where the MX record routes them to AWS SES for automated bounce and complaint handling — so they do not clutter your corporate inbox.

5. Security: can anyone send email as our domain?

If we add include:amazonses.com to our SPF, can any AWS/SES customer send email as our domain?

No.

Technically "allowed" by SPF, but permission is enforced in AWS's control plane. At the DNS/SPF layer, include:amazonses.com does list Amazon's shared sending infrastructure as an authorised source — so, on paper, the AWS range is "permitted". That alone is not what grants sending. AWS SES separately enforces which account may send as a given domain: only the account that has completed domain-ownership verification for that domain can send as it. Any other account's attempt is rejected before a message is sent, even though SPF would have "passed" the IP.

In short: SPF answers "did an AWS host send this?"; the control plane answers "is this specific account allowed to send as this domain?" — and both must be satisfied.

  • An SES account cannot send as your domain unless your domain is verified in that account, which requires publishing AWS-provided DNS records that only you control.
  • The only way another party could send as your domain would be to first gain control of your DNS — at which point SPF is not the weak point.

This is the same configuration used by many large, security-conscious organisations including slack and Netflix. You can verify it against their own domains with dig.

These domains include the same amazonses.com mechanism and are not impersonated by other AWS customers — because the actual send permission is gated in the SES control plane, not by the SPF record.

6. Display name, from-address and multiple offices

Can we set our own display name and from-address?

Yes. You choose the display name and from-address shown to your recipients. These are independent of other customers — only the underlying AWS sending infrastructure is shared.

Can different offices use different display names or from-addresses?

Yes. Each office can have its own display name and mailbox/from-address on the same domain. Only one set of DNS records is required, regardless of how many offices you have. If an office is not given its own address, it uses your default.

Can we set a custom Reply-To address?

Not currently. A separate custom Reply-To address is on the First AML roadmap but is not available today.

Can two related entities (for example two regional businesses in the same group) send from the same domain?

Yes. Related entities within the same organisation can send from the same verified domain, each keeping its own display name and from-address. Once the domain is verified, additional related entities can be enabled by First AML without further DNS changes on your side. To prevent incorrect linking, First AML confirms that the entity's users belong to that domain's organisation before enabling it.

8. Why not route through our own mail gateway?

Why can't First AML send through our corporate mail gateway / SMTP smart host instead of AWS SES?

The platform is built natively on AWS SES, which provides delivery tracking, auditability and integrated bounce/complaint handling. Relaying outbound mail through a third-party gateway or SMTP smart host is not supported

9. Email flagged as spoofed (e.g. Mimecast)

Our mail security gateway (e.g. Mimecast) is flagging First AML emails as spoofed. How do we fix it?

Some gateways flag our mail because our sending IPs are not yet trusted on your side. Allow-listing First AML's sending IPs in your gateway resolves this. Use the set that matches your First AML environment:

EnvironmentSending IPs
APAC24.110.73.148, 69.169.234.46
EU24.110.76.71, 24.110.76.70

10. Emails not arriving

A user isn't receiving emails (invitations, verification codes, password resets) even though everything looks correct. What could it be?

There are two common causes:

  • Suppression. If a message previously hard-bounced (for example, the mailbox didn't exist yet) or was marked as spam, the address may be suppressed by AWS and further messages withheld to protect sending reputation. Contact First AML support to have the address reviewed and removed.
  • Receiving-side filtering. If delivery records show the message was sent and accepted, the cause is usually filtering, quarantine or junk handling on the recipient side. Ask your IT team to allow-list First AML's sending domain and IPs (see section 9).

A new user was added before their mailbox existed and now never receives email. Why?

If a user is created before their mailbox exists, the first email can hard-bounce and place the address on the suppression list, so later emails (including password resets) are withheld. Contact First AML support to have the address cleared.

11. Timing: DNS verification window

How quickly do we need to publish the DNS records?

After First AML issues the records, AWS actively checks for them for approximately 24 hours. If they are in place within that window, configuration completes automatically. If they are not added in time, AWS stops checking and verification must be manually restarted, which can delay go-live. Please publish the records promptly once you receive them.