Should I use the TXT or SPF record type in Route 53?

Always TXT. The dedicated SPF record type is deprecated and ignored by modern mail receivers, so publishing one gives you a false sense of configuration while receivers see nothing.

Can I have more than one SPF record for a domain?

No. A domain must have exactly one SPF record. If you add a new sender, merge its include into the existing SPF string rather than creating a second TXT record, which would cause a permerror.

Why does my SPF work for some senders but not others?

Often the ten-lookup limit. If your combined includes exceed ten DNS lookups, receivers return a permerror and treat SPF as absent. Audit your includes and remove or flatten heavy ones to get back under the cap.

How to Add an SPF Record in AWS Route 53

VigilDog Team · September 1, 2026 · 6 min read

Adding an SPF record in Route 53 looks like a two-minute job, create a record, paste a string, save, and it mostly is. But the small details are exactly where deliverability breaks: choosing the wrong record type, ending up with two SPF records, or quietly blowing past the ten-lookup limit that silently fails your mail. This guide covers how to add an SPF record in Route 53 correctly, from the console clicks to the rules that keep it valid.

SPF lives in a TXT record, not an 'SPF' record

There was once a dedicated DNS record type for SPF, but it was deprecated years ago, and every modern mail provider reads SPF from a TXT record. Route 53 still lets you pick a legacy SPF type from the dropdown, don't. Choose TXT. A published SPF-type record is effectively invisible to receivers today and will make you think you've configured something that isn't there.

So the entire job is: publish one TXT record, at the domain you send mail from, whose value is a valid SPF string. Everything else in this guide is about getting that one record right.

Create the record in the Route 53 console

Open the Route 53 console, go to Hosted zones, and select the zone for your domain. Click Create record and fill it in as follows. Save, and Route 53 will publish it to its authoritative nameservers within a minute or two, though caching resolvers elsewhere may take until the TTL expires to catch up.

One Route 53 quirk to remember: TXT values must be wrapped in double quotes in the console. Route 53 stores them that way, and if you forget the quotes it will usually add them, but pasting a value that already contains stray quotes is a common way to publish a malformed record.

Record name: leave blank for the apex (example.com), or enter a subdomain if you send from mail.example.com
Record type: TXT
TTL: 300 seconds is fine while you're testing; raise it later
Value: "v=spf1 include:amazonses.com include:_spf.google.com -all" (adjust to your actual senders)

One SPF record, and mind the -all

A domain may have exactly one SPF record. If you already send through, say, Google Workspace and now add Amazon SES, you do not create a second TXT record, you merge the includes into the single existing SPF string. Two separate SPF records is a hard permerror, and receivers will treat your SPF as broken rather than picking one.

The mechanism at the end decides what happens to mail from unlisted servers. -all (hard fail) tells receivers to reject anything not authorized, the strongest and recommended posture once you're confident every legitimate sender is listed. ~all (soft fail) marks it suspicious but usually still delivers, which is a reasonable setting while you're still discovering all your senders. Avoid +all, which authorizes the entire internet and defeats the point.

The ten-lookup limit is where SPF quietly fails

This is the rule that catches people. Every include:, a, mx, ptr, and exists mechanism in your SPF record forces the receiver to perform a DNS lookup, and the spec caps the total at ten. Cross it and receivers return a permerror, your SPF is treated as if it doesn't exist, no matter how carefully you wrote it. And it's easy to cross: a single include: for a large provider can itself expand into several nested lookups.

The fix is to audit what your includes actually cost and remove senders you no longer use, or 'flatten' heavy includes into the underlying IP ranges (accepting that you then have to maintain those IPs by hand). The diagram below shows how SPF and DMARC work together, SPF proving the sending server is authorized, DMARC deciding what to do about a failure, which is why keeping SPF valid matters beyond SPF alone. Our guide to fixing SPF, DKIM, and DMARC walks through the lookup math in detail.

How SPF, DKIM and DMARC verify an email

Verify before you trust it

Never assume a DNS change is live just because the console saved it. Query it directly: dig +short TXT example.com should return your single SPF string in quotes and nothing else. If you see two SPF lines, or none, or the value truncated, fix it before moving on. Remember that resolvers cache, so if you just changed an existing record, allow up to the old TTL for the world to see the new value.

For a check that also flags lookup-count problems and shows how SPF sits alongside DKIM and DMARC, run your domain through the free DMARC checker, it reads the live records the way a receiving mail server would.

SPF is one leg of a three-legged stool

SPF on its own proves a server is allowed to send for your domain, but it doesn't survive forwarding and says nothing about the visible From address a recipient reads. That's why it only earns its keep alongside DKIM (a cryptographic signature) and DMARC (the policy that ties them to your domain and tells receivers what to do on failure). Get all three right and your mail authenticates reliably; get one wrong and deliverability degrades in ways that are maddening to diagnose after the fact.

Keeping those three records correct as providers change and includes drift is exactly the kind of quiet, easy-to-miss work VigilDog's monitoring handles, watching your SPF, DKIM, and DMARC records for breakage and alerting you before a change starts sending your mail to spam.