Do SPF records expire?

How SPF record persistence works

Sender Policy Framework (SPF) records are published as standard TXT records within your domain's Domain Name System (DNS). The SPF specification (RFC 7208) contains no mechanism, tag, or field for an expiration date. Once you publish an SPF record, it remains in effect indefinitely until you update or delete the DNS entry.

While the record itself does not expire, receiving mail servers do not query your nameservers for every single incoming message. Instead, they cache the record according to the Time to Live (TTL) value configured on the DNS entry.

The role of DNS TTL in SPF updates

TTL determines how long a resolver caches your SPF record before requesting a fresh copy from your authoritative DNS servers. Common TTL settings range from 300 seconds (5 minutes) to 86,400 seconds (24 hours).

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"

In this example, the number 3600 represents the TTL in seconds. Resolvers used by receiving mail servers may cache this record for up to one hour. If you update your authorized senders, some servers can keep using the old record until their cached copy reaches its TTL.

How an SPF record becomes obsolete

Even though an SPF record does not have a formal expiration date, it can decay and cause authentication failures if left unmaintained. This decay happens through operational changes across your organization's messaging infrastructure.

• Decommissioned services: When you stop using an email marketing provider or CRM platform, leaving its include: directive in your record leaves authorization active for services you no longer control.
• Changed provider IPs: If you authorize servers using direct ip4 or ip6 mechanisms rather than provider-managed include: directives, provider IP changes can break authentication.
• Dead includes: If a third-party vendor shuts down or deletes their published SPF record, the SPF check that reaches your include: for that domain ends in a PermError, so the check fails.

The 10 DNS lookup limit

SPF records do not expire, but adding more services over time often pushes a domain over the strict 10 DNS lookup limit defined in RFC 7208. When an evaluation needs more than 10 DNS lookups, counting the include, a, mx, ptr and exists mechanisms and the redirect modifier, including those nested inside included records, the check fails with a permanent error (PermError).

v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org include:servers.mcsv.net ~all

As teams accumulate services without pruning old ones, records can exceed this threshold, and the SPF check then fails even though the DNS record still exists.

Working alongside DKIM and DMARC

Because SPF configurations can change or fail when messages are forwarded, domain security relies on deploying SPF alongside DKIM and orchestrating them through DMARC.

DMARC allows receiving mail servers to authenticate messages via either SPF or DKIM alignment. When an SPF record breaks due to stale IPs or intermediate forwarding, valid DKIM signatures can keep legitimate messages authenticated while you audit and correct your records.

Maintenance best practices for SPF records

To prevent stale or broken SPF records, audit your DNS settings whenever you onboard or offboard external software tools. Remove unneeded include: mechanisms to keep your total lookup count well below 10, and lower your DNS TTL temporarily to 300 seconds, at least one old TTL period before a major email routing change, so the change spreads quickly.