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. 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 .amazonaws.com suffix. 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.
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 your own delivery outcomes. 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 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.
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. SES-receiving domains generally should not be on a marketing list at all: the address exists to feed an application. When such addresses appear in a signup form, they usually indicate an automated integration or a test, and the free risky verdict plus the domain intelligence endpoint's mx_provider field let you filter them without spending credits.
For a live look at any domain, run it through the free MX lookup and the SPF and DMARC checker.