Email authentication for Amazon WorkMail: SPF, DKIM and DMARC

20 May 2026 · 13 min read

Amazon WorkMail is the slightly unusual member of the hosted-mailbox family. It gives you Exchange-style mailboxes and calendars, but under the bonnet it sends your outbound mail through Amazon SES (Simple Email Service). That detail shapes everything about authentication: the SPF include, the DKIM selectors, the return-path and, critically, why the WorkMail defaults will quietly fail DMARC alignment unless you change them. This guide is written specifically for WorkMail, with the real includes, the real selector format and the real per-region values, so you can get from a freshly verified domain to p=reject without an outage.

One housekeeping note before we start. AWS has announced that Amazon WorkMail support ends on 31 March 2027. If you are reading this in 2026 and you run WorkMail, you should be planning a migration. But authentication still matters until the day you switch off: a misconfigured DMARC record will bounce or junk your mail right up to the migration deadline, and you will want clean SPF, DKIM and DMARC on the new platform too. Everything below applies for as long as WorkMail is sending your email, and the alignment thinking carries straight over to whatever you migrate to.

What WorkMail sets up by default, and where it falls short

When you add and verify a domain in the WorkMail console, AWS walks you through publishing a set of DNS records. By the end you typically have:

• A _amazonses TXT record proving you own the domain.
• An MX record pointing at the regional inbound SES endpoint so WorkMail receives mail.
• Three DKIM CNAME records (if you ticked Generate DKIM Settings).
• An autodiscover CNAME so Outlook and mobile clients can find their settings.

That is enough to send and receive. It is not enough to pass DMARC. The gap is the return-path. By default WorkMail sends outbound through SES using a subdomain of amazonses.com as the envelope sender (the MAIL FROM, also called the return-path or bounce address). So SPF authenticates amazonses.com, not your domain. DKIM, once you have enabled it, does sign with your domain, but if you ever turn DKIM off or it silently breaks, you are relying on an SPF result that does not align.

DMARC does not reward a bare SPF or DKIM pass. It rewards a pass that aligns with the domain in the visible From header. If your From is you@yourcompany.com but SPF authenticates amazonses.com, that is a pass with no alignment, which DMARC treats as an SPF failure. So the WorkMail-specific job is not "switch on SPF and DKIM" in the abstract; it is "make at least one of them authenticate your domain so it aligns".

Before you touch anything, capture a baseline. Run your domain through the DMARC checker to see your current policy, the SPF checker for your sending record, and the DKIM checker to confirm whether WorkMail is actually signing. Knowing the starting point makes every later change measurable.

SPF for Amazon WorkMail: the exact include

Because WorkMail sends via SES, the SPF include you publish is the SES include, not a WorkMail-branded hostname. The mechanism is:

include:amazonses.com

That single include covers SES sending across AWS regions, so you do not normally need a region-specific include for the SPF record itself. A minimal SPF record for a domain that only sends through WorkMail looks like this:

yourcompany.com.   TXT   "v=spf1 include:amazonses.com -all"

If you send through anything else as well, you merge the includes into one record. WorkMail plus, say, a marketing tool that also rides on SES still only needs amazonses.com once, but WorkMail plus Google Workspace would be:

yourcompany.com.   TXT   "v=spf1 include:amazonses.com include:_spf.google.com -all"

A few WorkMail-specific points that trip people up:

• One SPF record only. SPF allows exactly one v=spf1 TXT record per domain. If you migrated to WorkMail from another host, delete the old provider's SPF record rather than adding a second one. Two v=spf1 records is a hard SPF permerror, and DMARC treats that as a fail.
• Mind the ten-lookup limit. include:amazonses.com itself is cheap, but every additional include counts, and SPF allows a maximum of ten DNS lookups before it returns permerror. If you are stacking several providers, you can run over the limit. The mechanics and the fix are covered in /blog/spf-10-lookup-limit and /blog/fix-spf-permerror, and our SPF checker counts your lookups for you.
• ~all versus -all. AWS examples often show ~all (softfail). -all (hardfail) is stronger and is what you want once you are confident every legitimate source is in the record. Move to -all after you have watched DMARC reports long enough to be sure nothing legitimate is sending from outside the record.

Here is the catch that makes SPF alone insufficient on WorkMail: even with a perfect SPF record, the default return-path is still a subdomain of amazonses.com. SPF will pass for amazonses.com, but it will not align with your From domain. To make SPF align, you need a custom MAIL FROM domain, which we cover further down. Until then, your DMARC alignment rests entirely on DKIM.

DKIM for Amazon WorkMail: Easy DKIM and the three CNAMEs

WorkMail uses SES's Easy DKIM. Instead of pasting a long public key into a TXT record, SES generates three DKIM tokens and you publish three CNAME records that point at SES-hosted keys. SES then signs every outbound message and can rotate the underlying keys without you editing DNS again.

You enable this when you verify the domain: in the SES or WorkMail console, tick Generate DKIM Settings, and the console gives you three CNAME records in this shape:

token1._domainkey.yourcompany.com.   CNAME   token1.dkim.amazonses.com
token2._domainkey.yourcompany.com.   CNAME   token2.dkim.amazonses.com
token3._domainkey.yourcompany.com.   CNAME   token3.dkim.amazonses.com

Each token is a unique string SES generated for your domain, something like ex4mpl3ac7ki6clelsdbiiudpavjpsk3. A real set looks like this:

ex4mpl3ac7ki6clelsdbiiudpavjpsk3._domainkey.yourcompany.com.   CNAME   ex4mpl3ac7ki6clelsdbiiudpavjpsk3.dkim.amazonses.com
y7v9d3jq2k8w5n1r6t4m0p7s2x5c8b1z._domainkey.yourcompany.com.   CNAME   y7v9d3jq2k8w5n1r6t4m0p7s2x5c8b1z.dkim.amazonses.com
a2b4c6d8e0f1g3h5i7j9k1l3m5n7o9p2._domainkey.yourcompany.com.   CNAME   a2b4c6d8e0f1g3h5i7j9k1l3m5n7o9p2.dkim.amazonses.com

Several WorkMail and SES specifics are worth spelling out:

• The selector is the token, not a friendly name. Unlike Google Workspace (google._domainkey) or Microsoft 365 (selector1/selector2), SES uses the random token as the selector. When you read a DMARC report or inspect a header, the DKIM signature carries d=yourcompany.com and a selector matching one of those tokens. That is exactly what you want: d= equal to your From domain means DKIM aligns. If you want to understand how selectors map to keys generally, see /blog/dkim-selectors-explained.
• CNAME, not TXT. A common error is to paste the token value into a TXT record. Easy DKIM is published as CNAMEs that delegate to *.dkim.amazonses.com. If your DNS host strips the trailing structure or appends your domain twice (turning token._domainkey.yourcompany.com into token._domainkey.yourcompany.com.yourcompany.com), the lookup fails. Add a trailing dot to fully qualify the name if your provider doubles it.
• All three must resolve. SES looks for all three CNAMEs and reports DKIM as verified only when it finds them. It will keep checking for up to 72 hours. If verification stalls, the usual cause is one of the three records being mistyped or the domain being appended twice.
• Don't disable DKIM later. On WorkMail, DKIM is your alignment anchor (see the next section for why). If someone tidies up DNS and removes the CNAMEs, signing stops, and with the default return-path your DMARC alignment collapses to nothing. Confirm signing is live with the DKIM checker after setup and after any DNS change.

Once the three CNAMEs resolve and SES marks DKIM verified, every message WorkMail sends is signed with d=yourcompany.com. That single fact is what lets DMARC pass on WorkMail even before you fix the return-path.

The custom MAIL FROM domain: fixing SPF alignment

Here is the WorkMail detail that most guides skip. By default the envelope sender is a subdomain of amazonses.com, so SPF authenticates Amazon's domain rather than yours. To make SPF align with your From domain, you configure a custom MAIL FROM domain, which is a subdomain of yours dedicated to bounce handling.

AWS is explicit about this in the WorkMail documentation: the default amazonses.com MAIL FROM "can cause delivery failure if the DMARC policy on your domain is only set up for SPF." A custom MAIL FROM domain is also required if you want to enable AutoDiscover for iOS devices, so for many WorkMail admins it is not optional anyway.

Pick a subdomain that you use for nothing else, for example mail.yourcompany.com or bounce.yourcompany.com. AWS requires that this subdomain is not used to send normal mail and not used to receive mail; it exists purely as the return-path. In the SES console, under the domain identity, set the custom MAIL FROM domain, then publish exactly two records.

First, an MX record so SES can route bounce and complaint notifications back to you. The endpoint is region-specific, using the feedback-smtp prefix:

mail.yourcompany.com.   MX   10 feedback-smtp.us-east-1.amazonses.com

Replace us-east-1 with the region your WorkMail and SES identity live in. For the three regions WorkMail supports, that is us-east-1 (N. Virginia), us-west-2 (Oregon) or eu-west-1 (Ireland). The 10 is the MX preference; enter it in the priority field your DNS provider gives you. Publish exactly one MX record on this subdomain. If the MAIL FROM subdomain has more than one MX record, SES fails the custom MAIL FROM setup outright.

Second, an SPF record on the MAIL FROM subdomain itself, authorising SES to send for it:

mail.yourcompany.com.   TXT   "v=spf1 include:amazonses.com ~all"

Note this SPF record sits on the subdomain, not your root domain. Your root domain keeps its own SPF record from earlier. With the custom MAIL FROM in place, the envelope sender becomes bounces@mail.yourcompany.com, SPF authenticates mail.yourcompany.com, and because that is a subdomain of yourcompany.com, it aligns with a From of you@yourcompany.com under DMARC's relaxed alignment. SPF now contributes to DMARC instead of being a dead end.

One configuration choice matters: Behavior on MX failure. SES offers "Use default MAIL FROM domain" (fall back to amazonses.com if the MX record is missing) or "Reject message" (refuse to send). For most WorkMail setups, leave it on the default-fallback option while you bed things in, then consider tightening once you trust the records. There is also a known foot-gun where WorkMail and SES fight over the MAIL FROM MX record during migration and SES reports "MX Record not found"; if that happens, confirm the MX sits on the dedicated subdomain and nowhere else.

SES takes up to 72 hours to detect the records and move the custom MAIL FROM state from Pending to Success. Until it reaches Success, your return-path is still amazonses.com and SPF will not align, so wait for confirmation before you lean on SPF alignment in your DMARC plan.

Verification, MX and AutoDiscover: the supporting records

For completeness, the records WorkMail asks for during domain setup, with their real per-region values:

Domain ownership (TXT). A single verification record:

_amazonses.yourcompany.com.   TXT   "fmxqxT/icOYx4aA/bEUrDPMeax9/s3frblS+niixmqk="

The value is unique to your domain. If your DNS host refuses underscores in TXT names, AWS allows you to omit _amazonses from the name.

Inbound mail (MX). WorkMail receives mail on a regional SES inbound endpoint:

yourcompany.com.   MX   10 inbound-smtp.us-east-1.amazonaws.com

Use inbound-smtp.us-west-2.amazonaws.com for Oregon or inbound-smtp.eu-west-1.amazonaws.com for Ireland. The 10 is the preference number. Do not confuse this inbound MX (inbound-smtp, on your root domain) with the MAIL FROM MX (feedback-smtp, on your bounce subdomain); they are different records for different jobs.

Client autoconfiguration (CNAME). So Outlook and mobile clients find their settings:

autodiscover.yourcompany.com.   CNAME   autodiscover.mail.us-east-1.awsapps.com

Match the region to your WorkMail organisation. AutoDiscover does not affect authentication, but it is part of a complete WorkMail setup, and on iOS it depends on the custom MAIL FROM domain being configured.

None of these three records changes your DMARC story directly. They are listed so you can tell them apart from the SPF, DKIM and MAIL FROM records that do, and so you do not accidentally treat the inbound MX as if it were the return-path.

Reaching DMARC enforcement on WorkMail

With your root SPF published, Easy DKIM verified and a custom MAIL FROM domain active, you have two aligned authentication methods. Now you stage the DMARC policy from monitoring to enforcement. Never jump straight to p=reject: publish, observe, then tighten.

Start at p=none. This changes no mail flow; it only asks receivers to send you reports:

_dmarc.yourcompany.com.   TXT   "v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com; fo=1"

The rua address collects aggregate reports; fo=1 asks for failure detail. Leave this running for a couple of weeks and read what comes back. WorkMail mailboxes will show as aligned via DKIM (d=yourcompany.com) and, once the custom MAIL FROM is Success, via SPF too. What you are hunting for is everything else that sends as your domain: a CRM, a helpdesk, a billing system, a marketing platform. Each of those needs its own SPF entry and its own DKIM before you tighten. The reports are XML; our DMARC report analyzer turns them into a readable source list. The general approach to alignment is in /blog/dmarc-alignment-explained, and the policy ladder in /blog/dmarc-policy-none-quarantine-reject.

When the reports show every legitimate source aligning, move to a sampled quarantine:

_dmarc.yourcompany.com.   TXT   "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourcompany.com; fo=1"

pct=25 applies quarantine to roughly a quarter of failing mail and treats the rest as p=none, so a missed source becomes obvious without junking everything at once. Raise it to pct=100 once you are confident, then go to full enforcement:

_dmarc.yourcompany.com.   TXT   "v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com; fo=1; adkim=s; aspf=s"

At p=reject, receivers refuse any mail failing DMARC. This is the policy Gmail, Yahoo and Microsoft expect from bulk senders, and the one that actually stops impersonation of your domain. The adkim=s and aspf=s tags switch alignment to strict (an exact domain match rather than an organisational one). On WorkMail, strict DKIM is safe because SES signs with your exact domain. Strict SPF is safe only if your custom MAIL FROM subdomain and your From share the same organisational domain, which they do in the setup above; if you ever send From a different subdomain, leave SPF alignment relaxed. The requirements the big mailbox providers impose are summarised at /requirements and /blog/sender-requirements-2024-2025, and the staged journey end to end is at /docs/the-enforcement-journey.

One WorkMail-specific caution about forwarding. If users auto-forward WorkMail mail elsewhere, or if your domain receives forwarded mail, SPF will break on the hop because the forwarding server is not in your SPF record. This is normal and is exactly why DKIM is your anchor: a DKIM signature survives forwarding, an SPF pass usually does not. Forwarding and its effect on DMARC is covered in /blog/forwarding-and-dmarc.

A clean WorkMail checklist

Putting it together, a fully authenticated WorkMail domain has:

1. Verified domain (_amazonses TXT) and the regional inbound MX (inbound-smtp.<region>.amazonaws.com) published.
2. One root SPF record: v=spf1 include:amazonses.com -all, with any non-WorkMail senders merged in and the total under ten lookups.
3. Easy DKIM enabled and all three ._domainkey CNAMEs resolving to .dkim.amazonses.com, so mail is signed with d=yourcompany.com.
4. A custom MAIL FROM domain (for example mail.yourcompany.com) with one feedback-smtp.<region>.amazonses.com MX and an include:amazonses.com SPF TXT, showing Success in SES, so SPF aligns.
5. Every other service that sends as your domain authenticated and aligned in its own right.
6. A DMARC record starting at p=none with rua reporting, advancing through sampled p=quarantine to p=reject only once reports prove every legitimate source aligns.

Why DKIM is your anchor on WorkMail, and what we automate

The thread running through all of this is that DKIM alignment is what makes DMARC pass reliably on WorkMail. SPF is necessary and you should configure both the root SPF and the custom MAIL FROM domain so SPF aligns too. But the default WorkMail return-path is amazonses.com, forwarding breaks SPF anyway, and a single tidy-up of DNS can drop a record. DKIM, signed by SES with your exact domain, is the mechanism you can depend on. Enable it, verify all three CNAMEs, keep it signing, and your domain has a solid path to enforcement.

The work that remains is mostly vigilance. SES include behaviour and regional endpoints can change; DKIM keys should be rotated periodically; a new tool can start sending unaligned mail without warning; and one fat-fingered DNS edit can quietly break the whole chain. With WorkMail's end of support set for March 2027, you also have a migration on the horizon, and you will want clean, monitored authentication on both sides of that move.

DMARC Engine handles the moving parts for you. We host your DMARC, SPF and DKIM records through a one-time delegation (see /docs/delegating-your-dns), keep your SPF flattened and under the ten-lookup limit as Amazon and your other providers change IPs, ingest and translate every aggregate report so you never read XML, and take the domain from p=none to p=reject in safe stages without dropping legitimate mail. After enforcement, we keep watching and email you the moment a record breaks, a policy weakens or a new failing source appears, as described in /monitor and /docs/monitoring-and-change-alerts.

If you would rather check your current state first, run your domain through the DMARC checker, SPF checker and DKIM checker. When you are ready to reach enforcement without babysitting DNS, start with DMARC Engine and let the platform carry your WorkMail-hosted domain the rest of the way, and onto whatever you migrate to next.