Amazon WorkMail SPF and DKIM setup

What you are setting up

Amazon WorkMail is a hosted mailbox and calendar service: users read mail in Outlook, the web client, or a phone, and the domain is configured in the WorkMail console rather than in an application. Under the hood, AWS states that WorkMail uses Amazon SES to send all outgoing email, and that your domains are available for management in the SES console too. Adding a domain to WorkMail automatically attaches an SES sending authorization policy to the domain identity. So the authentication story is the SES one, which our Amazon SES guide covers in depth: DKIM is signed by SES with your domain and aligns; SPF only aligns once you configure a custom MAIL FROM domain. What WorkMail adds is a domain page that gathers every record in one place, plus the MX and AutoDiscover records a mailbox product needs.

Read this first if you are new here: AWS has announced the end of support for Amazon WorkMail on March 31, 2027. It stopped accepting new customers on April 30, 2026, existing organizations keep working until the end date, and after that the console and the mailboxes are gone. The records below keep your mail authenticated until you migrate; the gotcha section covers what to do with them when you leave.

Publish SPF and DKIM

Open the Amazon WorkMail console, pick the correct AWS Region in the top bar, and in the navigation pane choose Organizations, then the organization name, then Domains, then Add domain. Enter the domain (a Route 53 hosted zone in the same account appears in a dropdown as you type) and choose Add domain. The page that follows lists the DNS records in four sections, Domain ownership, WorkMail configuration, Improved security, and Improved email delivery, each with a Status column. If Route 53 hosts the zone, Update all in Route 53 publishes everything in one click. Otherwise Copy all produces a zone file to import, or copy records one at a time with the icon next to each name. The shape:

Type:  TXT     (Domain ownership)
Host:  _amazonses
Value: (the token shown in the WorkMail console)

Type:  MX      (WorkMail configuration, inbound mail)
Host:  @
Value: 10 inbound-smtp.<region>.amazonaws.com

Type:  CNAME   (WorkMail configuration, AutoDiscover)
Host:  autodiscover
Value: autodiscover-service.mail.<region>.awsapps.com

Type:  CNAME   (Improved security, DKIM; three of these)
Host:  <token>._domainkey
Value: <token>.dkim.amazonses.com

Type:  TXT     (Improved security, SPF)
Host:  @
Value: v=spf1 include:amazonses.com ~all

Type:  TXT     (Improved security, DMARC)
Host:  _dmarc
Value: (see the DMARC section below)

Type:  MX      (Improved email delivery, MAIL FROM; publish only ONE MX here)
Host:  mail                 (the subdomain you chose as MAIL FROM)
Value: 10 feedback-smtp.<region>.amazonses.com

Type:  TXT     (Improved email delivery, MAIL FROM SPF)
Host:  mail
Value: v=spf1 include:amazonses.com ~all

The DKIM records are SES Easy DKIM: three CNAMEs, 2048-bit keys by default, each host a token followed by ._domainkey and each value the same token followed by .dkim.amazonses.com (some Regions use a longer, Region-specific hosted zone, so copy the value rather than typing it). The SPF TXT goes on the root domain; if you already have one, merge include:amazonses.com into it instead of adding a second record. AWS recommends a TTL of 3600 on the MX and AutoDiscover records, and says not to switch the MX to WorkMail until your users exist and mailboxes are migrated.

The MAIL FROM pair at the bottom is the part that makes SPF align. WorkMail itself only shows its status; you configure it in the SES console under Configuration > Identities, open the domain, and edit Custom MAIL FROM domain. Pick a subdomain you use for nothing else, such as mail.yourdomain.com, and publish exactly one MX plus the SPF TXT on it. AWS also states a custom MAIL FROM domain is required for AutoDiscover on iOS devices, so it is not optional for a mailbox deployment. Then use the refresh icon on the WorkMail domain page until each record reads Verified. AWS says DNS updates can take up to 48 hours, and allows up to 72 hours for ownership verification.

Add DMARC

The WorkMail domain page includes a DMARC TXT row and proposes a value for it; AWS's documentation does not print that value in text, so we will not guess at it here. Any valid record you own satisfies the check. Start in monitor-only mode and ramp up:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Two SES-specific rules carry over. Do not add aspf=s: SES aligns SPF through a MAIL FROM subdomain, which only counts under relaxed alignment. DKIM is the other way round; SES signs with exactly your domain, so adkim=s is safe but gains you nothing. Build the record with our DMARC builder and progress past p=none once your reports are clean.

The Amazon WorkMail gotcha

The root SPF record the console asks for does not align by itself. By default WorkMail sends with a subdomain of amazonses.com as the MAIL FROM, so SPF authenticates Amazon, not you. AWS's own WorkMail guide says this can cause delivery failure when your DMARC policy is only satisfied by SPF, and the fix is the custom MAIL FROM domain above. Publish the root SPF TXT anyway (the console marks the domain Missing without it, and it is correct once the MAIL FROM is in place), but understand that DKIM is what carries DMARC until then.

Everything is per Region, and the MX will read Inconsistent while you move. A WorkMail organization lives in one Region (US East, US West Oregon, or Europe Ireland), and the MX target, the AutoDiscover target, the DKIM tokens, and the feedback-smtp host all carry that Region. Copy them from the console rather than from a colleague's zone. During a migration from another mail system the MX row shows Inconsistent until it points at WorkMail; AWS says the same status is safe to ignore if a third-party mail proxy sits in front of WorkMail on purpose. The other classic: a DNS host that appends your domain to _amazonses.yourdomain.com. Add a trailing period to the name to mark it fully qualified, and if your host refuses underscores, AWS says to omit _amazonses and publish the TXT on the bare domain.

Plan the exit now. Because WorkMail closes on March 31, 2027, every record here has a shelf life. Keep DMARC at whatever policy you have earned through the migration; a move to a new mailbox provider is exactly when spoofers try their luck and exactly when your own new sender can fail alignment. Once the last mailbox has left, remove the three DKIM CNAMEs, the WorkMail MX and AutoDiscover records, the MAIL FROM pair, and the include:amazonses.com from SPF (unless an application still sends through SES from this domain, in which case the SES identity and its DKIM stay). A stale include authorizes infrastructure you no longer control.

Confirm it worked

• Check the domain page. Every row should read Verified after a refresh: ownership TXT, MX, AutoDiscover, all three DKIM CNAMEs, SPF, DMARC, and the two MAIL FROM records. The same domain appears under Verified identities in the SES console with DKIM marked Successful.
• Send a test and read the headers. Send from a WorkMail mailbox to an outside address, open the message, and confirm the DKIM signature shows d=yourdomain.com, the Return-Path is on mail.yourdomain.com (not amazonses.com), and the result is dmarc=pass on both SPF and DKIM. Our header analyzer reads it back plainly.
• Watch the reports. WorkMail mail shows up in your DMARC aggregate reports from Amazon SES's sending infrastructure, because that is what delivered it, aligned and passing on both signals once the MAIL FROM is live. trustyourinbox labels it as a known sender, so a Region you forgot to configure stands out as an unsigned Amazon source.