# Proofpoint SPF checker: check and validate an SPF record > Proofpoint SPF checker workflow: check a published SPF record, interpret SPF outcomes, repair DNS evidence, and validate a delivered message. A Proofpoint SPF checker can help you inspect the public SPF record for one or more domains, but its result is DNS evidence only. Use the public Proofpoint form to check the published domain, then compare the record with the sender configuration and a real delivered message. SPF authorizes the envelope sender or HELO identity, not the visible From address by itself. ## Quick takeaways - Proofpoint's public Japanese DMARC and SPF tool accepts one domain per line, with up to 100 domains in one check. - An SPF record is a DNS TXT record that authorizes hosts for the MAIL FROM or HELO identity. - A published SPF record does not prove that a production service uses that record successfully. - SPF can pass while failing DMARC alignment if its authenticated domain does not align with the visible From domain. - Check DNS, the sending-service status, a delivered message, and DMARC reports before calling a production path complete. ## What this tool checks The [Proofpoint DMARC/SPF creation and check tool](https://www.proofpoint.com/jp/cybersecurity-tools/dmarc-spf-creation-wizard) has an SPF section headed `チェックするドメイン名を入力して下さい`. Its published instructions state that each line can contain one domain and that you can enter up to 100 domains before selecting `Check`. That form checks information visible in public DNS. It can help establish whether a domain publishes an SPF-related configuration, but it cannot inspect a Proofpoint tenant, a sending application's settings, the private logic used by a receiving mailbox provider, or the authentication result for one delivered message. Proofpoint also documents [Hosted Sender Policy Framework](https://www.proofpoint.com/sites/default/files/product-overview/pfpt-us-to-hosted-spf.pdf) as a DNS service for Proofpoint Email Fraud Defense customers, administered through a customer portal. That product brief does not establish that visitors to the public checker have Hosted SPF access or that a public result reflects a customer's tenant configuration. For a separate public lookup, use the [Palisade SPF checker](/tools/spf). A public record check cannot prove the production sending path, message signing, continuous state, or why a particular receiver rejected a message. ![Decision map for checking a published SPF record, validating the production path, and reviewing DMARC evidence](/images/editorial/proofpoint-spf-checker/proofpoint-spf-checker-result-map.webp "1200x829") *Source: Palisade.* ## How to run the check ### 1. Identify the domain that SPF actually evaluates Start with a delivered message if one is available. SPF evaluates the SMTP `MAIL FROM` identity, also called the envelope sender, or the SMTP `HELO` identity when the MAIL FROM identity is empty. [RFC 7208 defines those SPF identities and the evaluation model](https://www.rfc-editor.org/rfc/rfc7208.html). Do not substitute the visible From domain for the envelope sender without checking the message headers. The two domains may differ. ### 2. Submit the domain to the Proofpoint public form Open Proofpoint's public checker and enter the domain you want to inspect. Keep each domain on its own line. For an operational check involving multiple domains, record the time of the run and preserve which domain produced which result. Use a public DNS query alongside the form so you can compare the visible TXT answer yourself: ```bash dig +short TXT yourdomain.com ``` The command queries a resolver, not necessarily the authoritative DNS server. If results differ during a change, query the authoritative nameserver for the domain as well. ### 3. Isolate the SPF TXT record A domain can publish several TXT records for unrelated purposes. Locate the record that begins with `v=spf1`. [RFC 7208 requires SPF records to be published as DNS TXT records](https://www.rfc-editor.org/rfc/rfc7208.html). An illustrative record shape is: ```text v=spf1 include:spf.example-mail-provider.com -all ``` > Do not copy this record into DNS. Your sending service generates the include domains, IP addresses, and mechanisms that belong to your own sending path. If the domain sends through more than one service, inventory each service before editing. Replacing an existing record with a single provider's example can remove authorization for other legitimate mail. ## How to interpret the results ### The domain has no SPF record If the public lookup finds no TXT record beginning with `v=spf1`, SPF cannot find an authorization policy for that domain. Confirm that the queried domain is the envelope sender domain or HELO domain from the message, rather than assuming the visible From domain is the SPF identity. Then check the sending-service setup. A service may use a provider-owned envelope domain, or it may require you to publish an SPF record for your own domain. The [SPF record mechanics explained in this SPF guide](/learning/what-is-spf) help separate those two cases. ### The domain has more than one SPF record RFC 7208 says a domain must not have multiple SPF records. Multiple records that begin with `v=spf1` create an SPF `permerror` condition. Consolidate authorized mechanisms into one record only after identifying every legitimate sender that currently uses the domain. Do not merge DNS records by guessing which include statements are safe. Compare each mechanism with the current configuration in the sending service and with message evidence. ### The SPF record authorizes the sending host A record can authorize a host and still be incomplete evidence. SPF evaluation can return `pass` only for the MAIL FROM or HELO identity being tested. A valid public record does not show that the application emitted that envelope sender, that DNS was reachable when the receiver evaluated it, or that the receiver accepted the message. Send a new message through the exact production path and inspect its receiver-added `Authentication-Results` field. [RFC 8601 defines the message header field used to report authentication results](https://www.rfc-editor.org/rfc/rfc8601.html). Record the SPF result and the identity shown beside it, such as `smtp.mailfrom` or `smtp.helo`. ### The SPF record has an error or exceeds a processing limit RFC 7208 defines SPF outcomes including `none`, `neutral`, `pass`, `fail`, `softfail`, `temperror`, and `permerror`. It also limits SPF evaluation to ten DNS-query-causing terms. A record can look plausible in a DNS response but fail because recursive `include`, `a`, `mx`, `exists`, `redirect`, or `ptr` processing exceeds that limit. Treat a DNS-processing failure as a record-design issue until message evidence shows otherwise. Trace the include chain from the actual record, identify which sending services require each mechanism, and remove only mechanisms that no longer represent a legitimate sender. ### The SPF result passes but DMARC still fails SPF pass is only one possible DMARC authentication path. For SPF to support DMARC, the domain authenticated by SPF must align with the domain in the visible From address. A provider-owned bounce domain may pass SPF without aligning to your From domain. Check the message's `Authentication-Results` fields and compare the visible From domain with `smtp.mailfrom`. If they do not align, examine DKIM as the alternate DMARC path. The [difference between DKIM and SPF](/learning/dkim-vs-spf-difference) explains why a message can have a useful DKIM result even when SPF alignment is unavailable. ## How to act on the result Work from the narrowest evidence outward. - For a missing record, confirm which identity the sending service uses. Publish only the DNS record generated for your account and sending domain. - For multiple SPF records, make one inventory of every authorized sender, then combine valid mechanisms into one `v=spf1` record. Retain unrelated TXT records. - For a DNS-limit or syntax problem, trace the existing record before shortening it. Removing an include can break mail from a service that still uses it. - For a passing record with an SPF failure in a delivered message, compare the message's envelope identity with the DNS owner you checked. Then inspect the sender's verification or authentication status in its own interface. - For an SPF pass that does not align, validate DKIM on the same message. Do not change the DMARC policy based only on a public SPF lookup. Keep the four evidence layers separate: - DNS: query the published record through the authoritative server and at least one public resolver. - Vendor: confirm the sender's current domain or authentication status in the sending provider's interface. - Message: send a real message through the same production application, sender identity, gateway, and recipient path. - DMARC: review aggregate reports after data accumulates to identify sources and alignment outcomes across the domain. A green DNS result is not a delivered-message test. A sender interface indicator is not proof that a receiving mailbox provider evaluated the same path successfully. ## How to retest After a DNS correction, rerun the same Proofpoint public form with the same domain and repeat the public lookup: ```bash dig +short TXT yourdomain.com ``` Next, send a fresh message through the exact sender you changed. Inspect the delivered message's `Authentication-Results` header and compare the SPF identity with the visible From domain. Finally, review DMARC aggregate-report data after reports have had time to arrive. The expected change is a corrected DNS answer first, then a matching delivered-message result. These observations may not appear at the same time. ## Move from a one-time SPF check to sender inventory A Proofpoint SPF check can show the public record at one point in time. It does not identify every production source that uses the domain, track later DNS drift, or determine when the domain is ready for a DMARC policy change. Palisade is agent-first DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It proposes the next policy step for human review, but it does not autonomously change your DMARC policy or guarantee delivery. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=proofpoint&utm_content=proofpoint-spf-checker) Palisade does not grant access to Proofpoint Hosted SPF, repair a public SPF record automatically, or prove that every future message will authenticate. ## Sources and further reading - [Proofpoint DMARC/SPF creation and check tool](https://www.proofpoint.com/jp/cybersecurity-tools/dmarc-spf-creation-wizard) - [Proofpoint Hosted Sender Policy Framework technical brief](https://www.proofpoint.com/sites/default/files/product-overview/pfpt-us-to-hosted-spf.pdf) - [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.html) - [RFC 8601: Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) - [Palisade SPF checker](/tools/spf) ## Frequently asked questions ### Can I use the Proofpoint SPF checker for several domains? Yes. Proofpoint's public Japanese checker states that you can enter one domain per line and check up to 100 domains. Treat each result as a public DNS observation for that domain, then validate important senders with a delivered message. ### Does a published SPF record prove that mail passes SPF? No. A published record proves only that a DNS record is visible. SPF pass depends on the MAIL FROM or HELO identity used by the actual message, DNS processing during evaluation, and the receiver's evaluation of that message. ### Does SPF pass mean DMARC passes? No. SPF must pass and the authenticated SPF domain must align with the visible From domain to satisfy the SPF branch of DMARC. DKIM can independently provide an aligned authentication path. ### Should I create a second SPF record for a new email provider? No. RFC 7208 permits only one SPF record for a domain. Add the new provider's required mechanism to the existing SPF record after confirming that it belongs to an active sender. ### Can a public SPF checker show my Proofpoint Hosted SPF settings? No. A public checker can inspect public DNS. Proofpoint describes Hosted SPF as a service for Email Fraud Defense customers with a customer portal, and public DNS results do not reveal tenant access or portal settings.