SPF

How SPF works

SPF starts with a DNS TXT record on the sending domain. That record names the hosts or services allowed to send mail that uses the domain in the SMTP MAIL FROM, also called the envelope sender 1. When a message arrives, the receiver looks up the SPF record and tests whether the connecting IP is authorized 1.

Amazon SES frames SPF as an email validation standard designed to help prevent spoofing 2. Domain owners tell providers which servers may send for their domains 2. On SES, mail that uses the default SES MAIL FROM subdomain can pass SPF without extra setup, because that subdomain already matches the SES sending infrastructure 2. Brands that want a custom MAIL FROM domain publish SPF for that custom domain instead 2.

A pass does not mean the message is wanted. It means the IP was allowed to use that envelope domain. A fail means the IP was not authorized. Softfail and other results exist in the SPF language, and receivers choose how harshly to treat them 1. That is why teams read SPF alongside DKIM and DMARC, not as a solo score.

Outbound teams meet SPF when a new ESP, marketing tool, or agency IP starts sending. If the new host is missing from the SPF record, receivers may treat the mail as unauthorized even when the content is fine. The fix is to add the vendor include mechanism or IP range, then wait for DNS to propagate before raising volume.

SPF also has a lookup limit. Nested includes can exceed the RFC 7208 lookup limit and cause unexpected fails 1. Keeping the record short, and retiring dead vendors, is part of ordinary mail hygiene next to sender reputation work.

List quality still matters after SPF passes. Authentication does not stop a hard bounce from a dead mailbox. RichAPI Email verifier returns status and mxFound for 2 credits per verdict so teams can drop dead domains before the send 4. Waterfall misses bill zero credits 4. New accounts start with 100 free credits 4.

Receivers differ in how they weight softfail versus fail, so the same DNS mistake can look mild in one mailbox and harsh in another 1. That variance is another reason to keep SPF includes accurate and to confirm passes with seeds across major mailbox providers before a cold ramp 1.

Custom MAIL FROM domains deserve their own SPF record, separate from the root marketing domain, when the ESP supports that split 2. The split keeps transactional and cold streams from sharing one brittle include list.

Why SPF matters for outbound domains

Outbound domains live or die on trust signals receivers can check in milliseconds. SPF is one of the first of those signals because it answers a simple question: was this IP allowed to speak for this envelope domain 1?

Agencies that onboard a client domain should read the current SPF record before connecting any new ESP. A record that still includes three retired tools and omits the active ESP is a softfail factory. Clean the includes. Publish only what still sends. Then confirm a pass with a controlled test to a seed inbox.

Product and lifecycle teams often share a root domain with sales. When sales adds a cold ESP without updating SPF, both streams can suffer. Split sending identities when needed, and keep SPF accurate for each MAIL FROM domain that actually sends 2.

Google asks senders to authenticate mail as part of staying in good standing with Gmail 3. SPF is necessary but not sufficient on its own for modern policy. Pair it with DKIM signatures and a DMARC policy so the visible From domain has a clear authentication path 3.

When SPF fails in production, stop the new volume first. Fix DNS. Retest. Only then resume the ramp. Sending harder into SPF failures teaches filters the wrong lesson about the domain.

Domain reputation and email warm-up sit next to SPF on the same launch checklist. Authentication is the gate. Warm volume and clean lists are what keep the gate open after the first week of traffic.

Document every include in the same place the ESP inventory lives. When a contract ends, remove the include the same week. Orphan includes are how lookup limits get blown and how forgotten vendors keep a shadow claim on the domain 1.

Example of fixing SPF before a cold outbound ramp

A sales ops lead prepares a new subdomain for cold outbound. The ESP gives an include string for SPF. The lead publishes a TXT record that authorizes only that ESP and a transactional path still needed for replies 2.

Before any sequence goes live, the team sends a handful of test messages to personal and work seed inboxes 3. SPF shows pass. DKIM is aligned. DMARC is at least p=none with reporting so they can watch early failures 3.

They also verify the first few thousand prospect rows with RichAPI Email verifier 4. Rows with mxFound false leave the list 4. Disposable domains leave next. The send starts only after authentication and list hygiene both look clean.

Cost for verification is 2 credits per verdict 4. Misses cost zero 4. The 100 free credits on a new RichAPI account cover a small proof sample of the same flow 4. That is SPF treated as a launch gate, not as a checkbox someone remembered after the first softfail spike.

A week later, a second ESP is evaluated for a regional team. The ops lead refuses to connect it until the SPF include is staged in a pull request style DNS change with a rollback plan. That discipline is what keeps SPF from becoming knowledge stuck on one laptop.

SPF vs DKIM

SPF authorizes sending IPs for the envelope domain. DKIM signs message content with a domain key so receivers can detect tampering and confirm the signing domain.