Amazon Web Services receives mail in two ways. Amazon SES email receiving delivers incoming messages to S3, Lambda or SNS through rules the customer writes, and Amazon WorkMail is a hosted mailbox service for organisations that runs on the same inbound endpoints. AWS stopped taking new WorkMail customers on 30 April 2026 and ends the service on 31 March 2027. Both publish MX records under amazonaws.com, and Spaw reports them as mx_provider: "amazon-ses".
How Amazon shows up in DNS
A domain receiving through SES or WorkMail publishes a single regional MX record such as inbound-smtp.us-east-1.amazonaws.com or inbound-smtp.eu-west-1.amazonaws.com at priority 10. Custom MAIL FROM subdomains used for sending publish an MX of the form feedback-smtp.{region}.amazonses.com, which is a different zone and is not matched by this pattern. Spaw matches the inbound endpoints, inbound-smtp.{region}.amazonaws.com. Other mail servers with names under amazonaws.com (an EC2 instance, a load balancer, an SES Mail Manager ingress endpoint) are reported as other: they are the domain's own server or a gateway, not SES receiving. Amazon's own consumer-facing domains (amazon.com, audible.com) run on Amazon's internal mail platform and are classified as other.
Whether the domain is a mailbox host or an inbound-routing service depends on what sits behind the endpoint: WorkMail stores mail in mailboxes, SES receiving hands it to software. That software may be an application's own pipeline or a forwarding service: Firefox Relay (mozmail.com, relay.firefox.com) and Brave Email Aliases (bravealias.com) both receive on SES and pass each message on to a person's own inbox.
How Amazon answers a verification handshake
SES email receiving accepts every recipient that matches a receipt rule, and receipt rules commonly match a whole domain, so from the outside the domain is a catch-all and no probe can prove that a specific address is handled. WorkMail knows its mailboxes and typically rejects unknown recipients at RCPT TO, so WorkMail domains answer cleanly unless the organisation configured a catch-all. The inbound endpoints are shared infrastructure with conventional rate limiting; deferred probes are uncommon but possible.
What that means for your verdicts
Domains on SES receiving answer risky with reason: catch_all and mailbox_exists: null; Spaw remembers the catch-all for seven days and returns mailbox_confidence, which without the established-provider bonus leans on the domain's DMARC and SPF, its age, the shape of the username and the delivery outcomes every account has reported for the domain, once there are at least five. A relay on SES answers the same way and also carries is_relay: true, its relay_service and the relay weight of 5, and its mailbox_confidence stays at 50: the domain's records describe the relay operator, not the alias. WorkMail domains mostly answer deliverable with mailbox_exists: true or undeliverable with reason: mailbox_not_found. There are no consumer username rules for these domains.
Addresses on SES-receiving domains other than relays are frequently machine endpoints: support tickets, reply tracking, notification ingestion. is_gibberish: true and role-shaped usernames are common there, and a risky catch-all verdict on such an address is a reason to leave it out of human-facing campaigns. A relay address is the opposite case, a person reading mail through an alias they chose, so check is_relay before treating an SES address as a machine endpoint.
SPF and DMARC at Amazon
Sending through SES uses a subdomain of amazonses.com as the default MAIL FROM domain, so SPF passes on the envelope without any record from the customer; customers who want alignment set up a custom MAIL FROM subdomain and publish the SPF TXT record and the single MX record that the SES console shows for their region, and SES provides DKIM through Easy DKIM CNAME records. DMARC alignment can then be met through DKIM, SPF or both, as the SES documentation describes. Spaw reports the live state of any domain in has_spf and dmarc_policy.
Practical notes for sending to Amazon-hosted domains
WorkMail organisations behave like any business mailbox host and can be sent to normally until the service ends. Other SES-receiving domains typically feed an application rather than a person, so their addresses rarely belong on a marketing list, and one in a signup form typically indicates an automated integration or a test. Relays are the exception: an address that answers is_relay: true is a person's alias, so treat it like any other signup.
mx_provider alone cannot separate these cases, because WorkMail, SES receiving and the relays all report amazon-ses. Read is_relay and the verdict with it: WorkMail typically answers deliverable or undeliverable, where SES receiving answers risky with reason: catch_all. These answers are billed like any other: a risky catch-all answer costs 1 credit, with repeats of the same address free for seven days, and the domain intelligence endpoint costs 1 credit when the domain has mail servers.
For a live look at any domain, run it through the free MX lookup and the SPF and DMARC checker.