How do you check an SPF record for application email?

Start with the identity SPF actually checks

An SPF check needs three inputs: the SMTP client's IP address, the domain whose authorization policy is being evaluated, and the sender identity. For ordinary application mail, that domain is taken from the SMTP MAIL FROM address, also called the envelope sender or return path. It can differ from the address people see in the message's From header. If MAIL FROM is empty, as it normally is for a delivery-status notification, SPF uses the HELO identity for the MAIL FROM check. Record the real connection IP and envelope identity from a received test message or sending-provider configuration before looking up DNS. Checking example.test because it appears in From is inconclusive when the application actually sends with MAIL FROM at bounce.provider.test or bounces.example.test.

Query TXT at the exact MAIL FROM domain

Query DNS TXT at the exact domain selected in the first step. RFC 7208 requires SPF version 1 policies to be published as TXT records at the owner name they govern. Ignore unrelated TXT values and select records whose version section is exactly v=spf1. No selected record produces an SPF none result. More than one selected SPF record produces permerror; publishing separate records for different vendors is not a valid way to combine them. A single TXT resource record may be split into quoted character strings by DNS tooling, but those strings are concatenated without inserted spaces before SPF is parsed. Capture the full answer, resolver, query time, and TTL so the check can be repeated after a change.

Validate syntax and evaluate terms from left to right

An SPF record is an ordered policy, not an unordered list of providers. After v=spf1, mechanisms are evaluated from left to right until one matches. A leading qualifier controls the result: + means pass and is the default, - means fail, ~ means softfail, and ? means neutral. The ip4 and ip6 mechanisms compare the client address with an address or network. The a and mx mechanisms resolve DNS, while include evaluates another domain's SPF policy and matches only under the include rules. exists performs a DNS-based test. all always matches and commonly terminates the record. Syntax errors anywhere cause permerror before normal evaluation. A useful checker should report which mechanism matched, its qualifier, and each expanded domain rather than returning only a colored badge.

Trace include and redirect without treating them as aliases

Follow every include and redirect through the same evaluation context. Include is a mechanism: it asks whether the included policy returns pass for the current client and sender, then continues in the original record if it does not match. Redirect is a modifier considered after the current record's mechanisms fail to match; it transfers evaluation to another policy while retaining the client IP and sender. A redirect is ignored if all appears anywhere in the record. These differences matter during migrations. Replacing include:vendor.test with redirect=vendor.test can replace the domain owner's entire fallback policy rather than merely adding a vendor. Detect cycles, missing targets, invalid targets, and nested permanent or transient errors, and preserve the dependency chain in the result so a provider-side policy change is visible.

Count the complete DNS-query budget

Count DNS-query-causing terms across the complete recursive evaluation, not just the top-level record. RFC 7208 limits include, a, mx, ptr, exists, and redirect terms to ten during one SPF evaluation; exceeding the limit requires permerror. The all, ip4, and ip6 mechanisms do not consume that term budget. MX and PTR processing have additional address-query limits. The RFC also recommends limiting void lookups, meaning successful empty answers or name errors, to two and producing permerror when that limit is exceeded. The ptr mechanism is discouraged because it is slow and unreliable. A record can look short while provider includes expand into enough nested terms to fail, so report the total, each contributing term, void lookups, and the exact branch taken for the tested IP.

Interpret the SPF result without overstating it

Use the standard result vocabulary. Pass means the tested client is authorized to use the checked SMTP identity. Fail means a matching negative authorization was found. Softfail is a weak negative statement, while neutral says the domain makes no assertion about that client. None means no selected SPF record. Temperror reflects a transient evaluation problem, commonly DNS; permerror reflects a policy that cannot be evaluated correctly. If no mechanism matches and no redirect applies, the result is neutral, equivalent to an implicit ?all. Report the result together with identity, client IP, matched term, DNS trace, and time. Do not translate pass into safe message, wanted mail, provider acceptance, mailbox delivery, or inbox placement, because SPF does not decide those outcomes.

Check a real message, not only the published record

A static record check answers whether a policy can be discovered and parsed. It does not prove that the application used the expected MAIL FROM domain or outbound IP. Send a controlled message through each real production path to a recipient account you administer, then inspect the received headers. Compare the connecting IP, envelope sender, and the receiver's Authentication-Results entry with the DNS evaluation. Repeat for each provider, region, dedicated or shared pool, fallback path, and message class that can change the return path. Preserve headers in restricted storage because addresses and routing details can be sensitive. If a provider dashboard and the received message disagree, the message is stronger evidence of the path that actually ran, while a single receiver's result still should not be generalized into universal delivery behavior.

Evaluate DMARC alignment as a separate step

SPF can pass for a provider-owned return-path domain while DMARC still cannot use that result. Current DMARC rules compare the successful SPF-authenticated RFC5321.MailFrom domain with the author domain in the visible RFC5322.From field. Strict alignment requires the same DNS domain. Relaxed alignment permits domains that resolve to the same organizational domain under DMARC's discovery rules. For example, bounces.example.test and example.test can align in relaxed mode, while bounce.provider.test and example.test do not. A DMARC result can instead rely on an aligned, verified DKIM signature, so an unaligned SPF result does not by itself mean DMARC fails. Report authentication and alignment independently, and use the current domain-discovery procedure rather than a hard-coded last-two-label comparison.

Test provider-specific MAIL FROM configuration

Provider setup determines which SPF identity appears on the wire. Amazon SES, for example, documents a custom MAIL FROM domain that needs its own MX record and SPF TXT record. SES can fall back to a region-dependent amazonses.com MAIL FROM domain when the custom domain's MX is misconfigured, or it can reject the send, depending on the configured behavior. That fallback can change DMARC alignment even when the visible From address is unchanged. For any provider, record the configured return-path domain, required DNS values, fallback behavior, sending regions, and ownership. After a DNS or provider change, wait for relevant cached answers to age out, then repeat DNS evaluation and controlled sends. Do not copy a vendor include into the visible From domain unless that is the actual identity and the domain's complete sender inventory supports it.

Use a reproducible SPF audit during changes

Maintain one row per sending path with an owner, application, message class, visible From domain, MAIL FROM domain, HELO domain, expected source ranges, provider dependency, and last controlled-test time. Store each SPF check with the selected record, recursive trace, DNS-query count, matched mechanism, result, alignment decision, and a non-sensitive test identifier. During a migration, keep old and new legitimate sources authorized only for the required transition window, verify the new path, then remove stale authorization deliberately. Monitor permanent and transient authentication errors rather than reacting only to rejects. Re-run the audit after provider changes, IP-pool moves, domain changes, DNS edits, or new applications. This workflow catches both overly narrow policies that block legitimate paths and overly broad policies that retain unused authorization.

Check SendHQ with the same evidence standard

SendHQ documents that a direct send must use an address on a verified workspace domain. That verifies the sender identity but does not replace an SPF evaluation. A controlled SendHQ message still needs the same DNS trace, received-header inspection, SPF result, and DMARC-alignment check described above.

Frequently asked questions

Sources

• RFC 7208: Sender Policy Framework — IETF
• RFC 5321: Simple Mail Transfer Protocol — IETF
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance — RFC Editor
• Using a custom MAIL FROM domain in Amazon SES — Amazon Web Services
• SendHQ OpenAPI contract — SendHQ