Amazon Route 53 SPF, DKIM and DMARC setup, step by step

Use the authoritative public hosted zone in Route 53, preserve its existing records, and publish the exact TXT or CNAME values supplied by your sending service and domain-policy owner. Use TXT, not the legacy SPF record type. For a provider-issued DKIM CNAME, create an ordinary CNAME rather than substituting a Route 53 alias. Finish by checking public DNS, completing the sender's activation and testing the intended mail route. Saving records alone does not prove email authentication works.

This guide covers Route 53 DNS publishing for existing, approved sending services. It does not configure Amazon SES identities, WorkMail, sending credentials or a DNS migration. No AWS account, customer DNS zone or delivered message was tested or changed.

Confirm which hosted zone actually answers

A domain registered through AWS can use DNS elsewhere. Conversely, a domain registered elsewhere can use Route 53. Locate the public zone reached by the domain's actual delegation, not simply a familiar domain name in the account. Record the hosted-zone ID and compare its assigned nameservers with the parent delegation. If duplicate public zones exist, editing an undelegated copy will not update ordinary internet answers.

A private hosted zone serves associated VPC or connected hybrid resolver environments. It is not the publication destination for public mailbox providers. If the same name exists in public and private zones, a successful query inside your VPC may be misleading. Validate externally as well. AWS private-zone behavior.

For an already delegated child such as news.example.com, publish below that child in its authoritative zone. A parent-zone record below the cut is not a substitute. The same reasoning applies when _domainkey.news.example.com is separately delegated: the existing delegation determines where selector records belong. Preserve the NS and SOA records and any shared dependencies. AWS subdomain authority guidance.

If Route 53 is not authoritative, stop and use the actual DNS provider. Do not change registrar nameservers, remove a child delegation or disable DNSSEC merely to make these instructions fit. Those are separate infrastructure changes requiring a migration plan.

Collect an exact record plan before editing

Ask the sending-service owner for the current account, product, region and domain-specific instructions. The worksheet should include:

• Actual SMTP MAIL FROM domain and intended visible From domain.
• DKIM signing domain, selectors, complete public values and exact record types.
• Each full DNS owner and the authoritative zone responsible for it.
• Existing records, approved final values, TTL, change owner and recovery plan.
• Sender-side verification or signing activation still required after publication.
• Existing direct or inherited DMARC policy and authorized report recipients.

SPF evaluates the SMTP MAIL FROM identity, or HELO in the relevant cases, not automatically visible From. DKIM uses the signature's d= domain and s= selector. Obtain complete account-issued public keys or CNAME targets; never reuse another tenant's values or publish a private key. SPF identity rules and DKIM key lookup.

For a DNS-only task, the sender remains responsible for issuing and activating its records. No universal “AWS SPF include” or “Route 53 DKIM key” applies to every service hosted on AWS.

Map full owners to the selected zone

The following names are illustrative. Replace sender1 with the actual issued selector and use the approved domains. When a Route 53 record is at the hosted-zone apex, leave its Record name field blank, not @. Check the resulting full name before saving. AWS record-name fields.

Use only the row consistent with actual DNS authority. Do not create a second zone to avoid understanding an existing delegation. Check for duplicated suffixes such as example.com.example.com, particularly when copying a full owner into a field displaying a suffix.

Create or update the intended records

In the AWS console, open Route 53 > Hosted zones, select the verified public zone and inspect the existing record set. For a new owner/type, choose Create record. Select the required type, enter the mapped name and approved value, use Simple routing for this ordinary publishing task, review the TTL, then choose Create records. AWS creation workflow and simple-record values.

If the owner/type already exists, review and update that record set instead of trying to create a conflicting replacement. A TXT set can contain unrelated verification values alongside an SPF value. Preserve those unrelated values on their own rows. Do not use weighted, failover or geolocation policies to alternate authentication policies: receivers need consistent applicable records, not a random choice of competing SPF or DMARC values.

Work through the account's approved role. An access-denied error is a permissions question for the AWS administrator, not a reason to create long-lived credentials, grant broad administrator access or move the zone. Keep unrelated records unchanged.

SPF: preserve one complete policy

Publish the SPF policy as TXT. At the actual evaluated owner, retain exactly one value beginning v=spf1. Merge only authorized sending mechanisms into the existing policy, preserving other legitimate senders and the approved qualifier. A second v=spf1 value can cause permerror; putting the two values inside one Route 53 record set does not solve the duplicate-policy problem. SPF record selection.

Review the full ten evaluated DNS-dependent-term budget, including nested mechanisms, rather than counting only visible include terms. If a policy uses redirect=, retain its legitimate authorization and policy behavior. Any all mechanism makes redirect ignored. Adding a mechanism after a matching all also does not authorize the intended service. Have the mail owner approve the complete final policy rather than pasting an isolated example. SPF lookup limits and redirect processing.

DKIM TXT: one value can contain several strings

Route 53's console represents a long TXT value as adjacent quoted strings on one line. Keep each string at most 255 characters and the complete value within the documented 4,000-character limit. Multiple rows mean separate TXT values, not continuation of one DKIM key. Keep one complete DKIM key record at each selector; multiple key records at the same selector have undefined results. Use the console's TXT rules rather than a zone-file import recipe. AWS TXT formatting.

This is a nonfunctional formatting illustration, not a public key:

"v=DKIM1; k=rsa; p=FIRST_PART_OF_ISSUED_KEY" "REMAINDER_OF_ISSUED_KEY"

The two strings are concatenated without an added space. Preserve the exact original data at the split, including any space that belongs inside a string. Keep the full tagged value and key material; remove accidental editor line breaks, not meaningful characters. Compare the reconstructed DNS value byte-for-byte with the approved public record. DKIM TXT concatenation.

DKIM CNAME: keep the issued alias visible

For an issued CNAME, select CNAME, retain its exact owner and enter the full target hostname. Do not include https://, a path, TXT-style key material or a second target. A trailing dot in a console target is optional under AWS's documented name handling. AWS CNAME and record-type guidance.

Do not add TXT, A, AAAA, MX or another CNAME at that same CNAME owner. Preserve separate selectors. Route 53 does not permit a CNAME at a hosted-zone apex because the zone already has required records there. This also matters if someone delegated a zone at the exact selector owner. Stop and agree a supported design instead of deleting that delegation.

A Route 53 Alias is a distinct AWS feature with specific targets and response behavior. An A/AAAA alias is not a substitute for a sender's requested CNAME. Use an ordinary, non-alias CNAME when the sender requires a literal CNAME answer, including for a target in the same zone. Do not add a web redirect or proxy layer. This workflow does not require a global “flattening off” switch; verify the requested CNAME is actually returned. Preserve existing web aliases elsewhere. AWS alias versus CNAME comparison.

Preserve DMARC protection and reporting choices

Check the policy applicable to the visible From domain, including inherited policy, before proposing any change. Keep existing enforcement, alignment settings and authorized reports. Do not duplicate a DMARC record, replace p=reject with p=none for troubleshooting, or copy a reporting address from an example.

Only if no direct or applicable inherited policy exists and the owner approves a monitored start, an illustrative TXT value is:

"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Replace the destination with an approved working mailbox. Use the full/relative _dmarc owner mapping above for the actual domain. Monitoring does not request rejection and does not prove all sending services are configured. Do not add obsolete percentage-rollout tags. Current DMARC policy discovery.

Compare the Organizational Domain where the policy was found with the Organizational Domain of the report URI's destination host. When they differ, the report-generating receiver must check DNS authorization for that destination; a destination within the same Organizational Domain is excepted. Different hostnames alone do not establish external reporting. Coordinate the required authorization with the report operator. DNS authorization does not replace the owner's separate data-sharing approval. RFC 9990 section 4.

Leave mail routing and delegations intact

An SPF/DKIM publication task ordinarily does not require changing corporate MX, A/AAAA, NS or DNSSEC. Some senders issue an MX record for a dedicated bounce subdomain or require a separately delegated namespace. Before accepting that package, compare the exact owners, numeric MX priorities, targets and any addresses with the approved inbound or bounce-routing plan. Publishing a provider packet can redirect real traffic.

Do not replace apex employee-mail MX with a sender's bounce MX. Do not change nameservers simply because the sender also offers DNS hosting. If a record conflicts with shared infrastructure, stop for a scoped design decision. The current authoritative zone can usually publish records without transferring registration or changing the whole domain's DNS service.

Verify DNS, then verify the sender

AWS says changes generally reach its authoritative nameservers within 60 seconds; cached recursive answers can remain until their TTL expires. A change marked complete does not invalidate caches worldwide. Check current authoritative answers and an external recursive resolver rather than waiting an arbitrary number of days. AWS propagation guidance.

These are read-only patterns with placeholders, not executed results:

dig @AUTHORITATIVE_NAMESERVER TXT MAIL_FROM_DOMAIN +norecurse
dig @AUTHORITATIVE_NAMESERVER TXT ISSUED_SELECTOR._domainkey.SIGNING_DOMAIN +norecurse
dig @AUTHORITATIVE_NAMESERVER CNAME ISSUED_SELECTOR._domainkey.SIGNING_DOMAIN +norecurse
dig @AUTHORITATIVE_NAMESERVER TXT _dmarc.FROM_DOMAIN +norecurse
dig TXT MAIL_FROM_DOMAIN
dig CNAME ISSUED_SELECTOR._domainkey.SIGNING_DOMAIN

Use TXT or CNAME according to the issued DKIM type. Confirm the authoritative server belongs to the relevant parent, child or _domainkey zone. Inspect answer names, type, complete values, status and TTL. NXDOMAIN, an empty answer, SERVFAIL and timeout mean different things. For a CNAME, check both the literal alias and the target's eventual public-key lookup. Query any applicable inherited DMARC policy as well.

Return to the sending service and complete its documented verification and activation. Then send a harmless, authorized test through the actual intended application route to a controlled receiver. Obtain receiver-generated Authentication-Results from the known receiving service's processing boundary, using its documented handling of externally supplied fields. A familiar authserv-id or top-of-header position alone is not proof of trust. Ignore attacker-supplied results. RFC 8601 trust boundary.

For a newly configured branded DKIM route, require the intended signature to pass and align with the intended visible From under current policy, plus trusted dmarc=pass. A provider-rewritten From or an SPF-only DMARC pass does not validate that signing task. Relaxed alignment uses the same Organizational Domain; strict alignment requires an exact match. A child envelope domain is not automatically strict-SPF aligned. For an illustrative visible From of sender@example.com, a passing intended signature with d=mail.example.com is relaxed-aligned when both domains share the Organizational Domain example.com, but is not strict-aligned. A passing intended signature with d=example.com is exactly aligned under either mode. These identity examples are not measured message results. The EmailAuth raw-versus-aligned DKIM guide explains that distinction.

Record the actual SPF identity and result too. A passing but unaligned provider envelope is different from fail, temperror or permerror; investigate real SPF errors even if DKIM makes DMARC pass. Test representative production routes separately after changes, not only a dashboard-generated sample.

Troubleshooting and maintenance

• Saved but invisible externally: check public versus private zone, delegation and duplicated zone names before editing values again.
• Duplicate SPF: retain one reviewed policy while preserving unrelated TXT verification values. Do not concatenate two full policies.
• Long key rejected or split incorrectly: use adjacent quoted strings in one TXT value; compare reconstructed bytes with the sender's key.
• CNAME conflict: inventory records and delegations at that exact owner. Do not delete another service's selector or replace the CNAME with an A alias.
• DNS succeeds but DKIM is missing: check sender activation, account/region, signing domain and the actual route. DNS does not turn on signing.
• SPF permerror: investigate duplicate policies, syntax and the full dependency budget. For temperror, investigate transient DNS failures; for fail, compare the actual outbound route and authorization.
• DMARC passes but intended DKIM fails: aligned SPF may be masking the signing defect. Keep the DKIM work open.

Retain the before-state and a named rollback owner. Restore only the approved affected record set if needed. Coordinate selector retirement with the sender so queued or delayed messages can still validate. Review after sender, domain, region, route or DNS-authority changes. Authentication does not guarantee inbox placement or message safety.