SPF Lookup

An SPF (Sender Policy Framework) record is a DNS TXT entry published on your domain that lists which mail servers are authorized to send email on your behalf. When a receiving server gets an email claiming to be from your domain, it checks your SPF record to see if the sending server's IP address is on the approved list. If it's not, the message may be flagged as suspicious or rejected.

An SPF record starts with v=spf1 and contains a series of mechanisms that define authorized senders — typically ip4: or ip6: for specific IP addresses, include: for third-party services (like Google Workspace or Mailchimp), and a or mx to authorize your domain's own servers. The record ends with a qualifier, usually ~all (soft fail) or -all (hard fail), which tells receivers what to do with messages from unlisted sources.

SPF misconfigurations are one of the most common causes of email deliverability problems — and they're usually invisible until someone tells you their emails from you are landing in spam. Running an SPF lookup lets you verify that your record exists, the syntax is valid, all your legitimate sending services are included, and you haven't exceeded the protocol's limits.

SPF is also a prerequisite for DMARC. Your DMARC policy evaluates SPF results (along with DKIM) to determine whether an email passes authentication. If your SPF record is broken or incomplete, it directly undermines your DMARC enforcement. Checking SPF is typically the first step when troubleshooting DMARC alignment failures in tools like Viewleaf.

The SPF specification (RFC 7208) limits each SPF evaluation to a maximum of 10 DNS lookups. Every include:, a, mx, redirect, and exists mechanism in your record triggers a DNS lookup — and include: mechanisms can nest further lookups inside them. If your record exceeds 10 total lookups, receiving servers will return a permerror and treat the SPF check as failed.

This limit is easy to hit if you use multiple third-party email services. For example, Google Workspace's include:_spf.google.com alone accounts for several nested lookups. Add Mailchimp, HubSpot, SendGrid, and a transactional email provider, and you can quickly blow past 10.

The fix is called SPF flattening — replacing include: mechanisms with the underlying IP addresses they resolve to. This reduces the lookup count but requires ongoing maintenance since those IPs can change. Some DNS providers and SPF management tools handle flattening automatically.

The mechanism at the end of your SPF record tells receiving servers how to treat messages from sources not listed in the record:

-all (hard fail) means "reject any email not from my authorized senders." This is the strictest setting and provides the strongest protection against spoofing.

~all (soft fail) means "flag but don't reject email from unlisted senders." In practice, most receiving servers treat soft fail as a negative signal that increases a message's spam score, but they won't outright reject it.

?all (neutral) means "I make no assertion about unlisted senders." This effectively disables SPF enforcement and is rarely useful.

Most domains should use ~all while setting up and testing, then move to -all once they're confident all legitimate sending sources are included. If you're running DMARC monitoring with Viewleaf, your aggregate reports will show you exactly which sources are passing and failing SPF — making it safe to tighten your policy.

SPF and DMARC work together but serve different purposes. SPF verifies that the sending server's IP address is authorized by the domain in the envelope sender (the Return-Path header). DMARC adds a critical extra check: it requires that the domain verified by SPF aligns with the domain in the From header — the address the recipient actually sees.

This alignment requirement matters because without it, an attacker could pass SPF using their own domain in the Return-Path while spoofing your domain in the From header. DMARC closes that gap by requiring either SPF or DKIM to both pass and align with the visible From domain.

In practice, this means a valid SPF record alone isn't enough to pass DMARC. The domain authenticated by SPF must match (or be a subdomain of, in relaxed mode) the From domain. When you see SPF-pass but DMARC-fail in your Viewleaf reports, misalignment is almost always the reason.

Multiple SPF records. A domain must have exactly one SPF TXT record. If you have two (which can happen when switching email providers), the SPF check returns a permerror and fails entirely. This is one of the most frequent and damaging SPF mistakes.

Exceeding the 10-lookup limit. As described above, too many include: mechanisms will silently break your SPF. The tricky part is that nested lookups inside includes count toward the limit, so the actual count isn't always obvious from looking at your record.

Forgetting a sending service. Every service that sends email on your behalf — your email provider, marketing platform, CRM, transactional email service, helpdesk — needs to be included in your SPF record. A missing include means messages from that service fail SPF, which can cascade into DMARC failures.

Using +all. The +all mechanism explicitly authorizes every server on the internet to send as your domain. This completely defeats the purpose of SPF and is sometimes added by mistake during misconfiguration. If you see +all in any SPF record, it needs to be fixed immediately.

Not updating after provider changes. When you switch email providers or add new sending services, the old includes often get left behind (wasting lookups) and the new ones don't get added (causing failures). SPF records need to be maintained as your email infrastructure evolves.