Truvo Free Tools

SPF record check

An SPF record is your domain's public list of the servers allowed to send email in its name. This checker reads the record, shows how it ends (hard fail, soft fail or neutral), and names the SOC 2 and ISO 27001 controls the answer affects.

SOC 2 CC6.1SOC 2 CC6.7SOC 2 CC7.2ISO 27001 A.5.14ISO 27001 A.8.20

Talk to a security specialist

Share what you need and a consultant will follow up to book a call.

How the SPF record checker works

The check is passive: it reads your domain's public TXT records through DNS over HTTPS and looks for the v=spf1 policy, without sending any email.

01

Query

You enter a domain. The tool asks a public DNS over HTTPS resolver for the domain's TXT records and picks out the one that starts with v=spf1. Nothing is sent to your mail servers.

02

Read

The result shows the policy and how it ends: -all (hard fail), ~all (soft fail) or ?all (neutral). A missing record, or a soft or neutral ending, is flagged, because receivers are then told to accept or merely suspect spoofed mail rather than reject it.

03

Map

Each finding names the controls it speaks to: SOC 2 CC6.1, CC6.7 and CC7.2, and ISO 27001:2022 A.5.14 (information transfer) and A.8.20 (networks security). A hard-fail policy is evidence; a missing one is a gap to close.

Found a gap? We fix it for you.

Truvo's security engineers harden mail, DNS and TLS, and hand you the evidence an auditor asks for. Tell us the domain and we will scope the fix.

Contact us

  • SPF hard-fail policy

  • DKIM signing

  • DMARC enforcement

  • Redundant MX hosts

  • Audit evidence

  • Fixed-price scope

SPF record check: frequently asked questions

It reads the TXT record at your domain that begins with v=spf1 and reports what it finds: whether a record exists, which sending services it authorizes, and how it ends. The ending matters most. -all tells receivers to reject mail from unlisted servers, ~all tells them to treat it as suspicious, and ?all expresses no opinion.

Truvo maps SPF findings to SOC 2 CC6.1, CC6.7 and CC7.2, and to ISO 27001:2022 Annex A controls A.5.14 (information transfer) and A.8.20 (networks security). The mapping is advisory: it shows which control a finding gives evidence for or signals a gap against. It is not a substitute for an audit.

Yes. The check queries public DNS over DNS over HTTPS for records your domain already publishes to the whole internet. Nothing connects to your servers and nothing is written or changed. Any mail server that receives a message claiming to be from you performs the same lookup.

Without a record, anyone can put your domain on a phishing email and most receivers will accept it. With a soft-fail ending, receivers are told the mail is suspicious but not to reject it, so spoofed messages often still reach inboxes. The fix is one TXT record that lists every service that legitimately sends mail for you, ending in -all once you have confirmed nothing is missed.

No. SPF says which servers may send as your domain, DKIM signs the messages, and DMARC tells receivers what to do when either check fails and where to send reports. Most domains need all three. The DMARC checker below covers the enforcement side.

Sender Policy Framework (SPF), defined in RFC 7208, is a TXT record at your domain that lists the servers allowed to send mail on its behalf. Receiving servers compare the sending IP against that list. It authorizes senders only; it does not sign the message, which is what DKIM does, and it does not tell receivers what to do on failure, which is what DMARC does.

One TXT record starting with v=spf1, followed by mechanisms such as ip4:, ip6:, include: and a:, and ending with an all qualifier: -all (fail) or ~all (soft fail). A domain must publish exactly one SPF record, and the include, a, mx, ptr, exists and redirect mechanisms together may not exceed 10 DNS lookups. For Google Workspace the include is _spf.google.com; for Microsoft 365 it is spf.protection.outlook.com.