Last updated: July 2026

In short: After this guide your Route 53 hosted zone publishes a correct SPF record for your mail server. Receiving servers can then tell who’s allowed to send in your name.

Prerequisites

  • A public hosted zone in Amazon Route 53
  • You know which servers send email for your domain (your own mail server, Amazon SES, a newsletter service)

What is SPF?

SPF (Sender Policy Framework) is a TXT record in your domain’s DNS. It lists the SMTP servers authorized to send for your domain. Receiving mail servers check on every incoming message whether the delivering server is on this list. Without SPF, any server can send mail in your name — and your legitimate mail lands in spam faster.

For context: SPF alone is not complete protection. Only together with DKIM and DMARC does it become a solid foundation. But SPF is the easiest entry point.

The starting point at Route 53

Route 53 is a pure DNS service: unlike shared hosts, there is no ready-made SPF switch, because Route 53 doesn’t know where your mail runs. You write the record yourself — which fits well here, since as a Route 53 user you typically run your own infrastructure or Amazon SES anyway.

One AWS-specific note up front: Route 53 once offered a dedicated SPF record type, but AWS retired it. Its docs are explicit: “Instead of an SPF record, we recommend that you create a TXT record that contains the applicable value.” So you always publish SPF as a TXT record — never as the legacy SPF type.

Step-by-step guide

1. Check whether SPF is already active

Fastest via the terminal:

dig TXT example.com +short | grep spf1

Alternatively, drop your domain into the free MXAudit scanner — it checks the record for syntax and lookup limits at the same time.

2. Build the record for your setup

The classic case, when the same servers send that also receive (your MX points to your mail server):

v=spf1 mx -all

The mx mechanism authorizes the IP addresses of all your domain’s MX hostnames — if the server IP changes, the SPF record stays correct automatically, as long as the MX record is right.

AWS’s own documented console example for a fixed IP range looks like this:

v=spf1 ip4:192.168.0.1/16 -all
MechanismEffect
mxallows the servers behind your domain’s MX records
ip4: / ip6:allows a fixed IP address or subnet
a:hostallows the IP behind the A/AAAA record of the given hostname
include:pulls in a sending service’s SPF (e.g. Amazon SES)
-allhardfail: only the explicitly listed servers may send

With your own infrastructure, -all is the right choice — you know your sending paths. If you’re unsure during a rebuild, start with ~all and tighten to -all after a few days.

3. Enter the record in the Route 53 console

Sign in to the AWS Management Console and open the Route 53 console. In the navigation pane choose Hosted zones, open your zone, and choose Create record:

FieldValue
Record name(leave empty for the root domain)
Record typeTXT
Value"v=spf1 mx -all"

The Route 53 quirk from the docs: “A TXT record contains one or more strings that are enclosed in double quotation marks” — so the value goes in double quotes in the Value box. Then choose Create records.

4. Add external sending services (if needed)

A newsletter tool, CRM, or Amazon SES needs its include: value in the same record (from that service’s docs, search for “SPF”). The rule holds: only one SPF record per domain — edit the existing one, never create a second.

5. Wait until the change is live

Route 53 is fast here: per the AWS docs, “Changes generally propagate to all Route 53 name servers within 60 seconds.” Downstream resolvers may still cache the old answer until the TTL expires.

Verify the result

Check your configuration with the free MXAudit scanner — it shows immediately whether your SPF record is syntactically correct and how many DNS lookups it consumes (the limit is 10).

Or directly in the terminal:

dig TXT example.com +short | grep spf1

The output must contain exactly one record with v=spf1.

Common mistakes

Using the legacy SPF record type. Route 53 still shows an SPF type, but AWS recommends against it — publish SPF as a TXT record instead.

Forgetting the quotation marks. In the Route 53 Value box the string belongs in double quotes.

Two SPF records. Two TXT entries with v=spf1 cause a permerror — receiving servers then ignore SPF entirely. All sources belong in a single record.

mx without matching MX records. v=spf1 mx -all authorizes exactly the servers from your MX records. If a machine sends that doesn’t appear there, it’s rejected — add it via ip4: or a:.

+all at the end. A +all allows any server to send and makes the whole record useless — don’t copy it.

Exceeded the DNS lookup limit. SPF allows a maximum of 10 DNS lookups per check; mx, a:, and every include: count. With many external services it gets tight — MXAudit counts along for you.

Further reading