Validate SPF records for email authentication. Build new records with include, ip4, ip6, and redirect mechanisms.
SPF (Sender Policy Framework) tells receiving mail servers which hosts may send mail for your domain, published as a v=spf1 TXT record in DNS. This tool works both ways: enter a domain and it pulls the live record, breaks it into mechanisms, and shows what each authorizes; or build a new record from ip4, ip6, include, and redirect choices and copy out the finished TXT string. The usual surprise: SPF checks the MAIL FROM envelope address, not the From: header you see in the message, and every include, a, mx, or redirect term spends one of a hard 10-DNS-lookup budget.
A concrete input and expected output from the current implementation.
Input
ip4:198.51.100.7, include:_spf.example.net, ending qualifier ~all
Expected output
v=spf1 ip4:198.51.100.7 include:_spf.example.net ~all ip4:198.51.100.7 - matches only mail from that address (0 lookups) include:_spf.example.net - defers to that domain's record (1 lookup) ~all - softfail for every other sender (0 lookups) Total: 1 of 10 DNS lookups, syntax valid.
A bare ip4 address counts as a /32, so only mail from 198.51.100.7 matches; the include costs the record's one DNS lookup; ~all softfails everything else. The record reads in first-match order - the specific address first, the delegated provider second, the catch-all last.
Enter a domain and the tool fetches its TXT records, isolates the one beginning with v=spf1, and splits it into whitespace-separated terms. It reports what each mechanism authorizes, counts DNS lookups (a, mx, include, exists, ptr, and redirect each cost one), and flags records that exceed the 10-lookup cap, publish more than one v=spf1 record, or end without an all mechanism. Order matters: the first matching mechanism wins.
Choose mechanisms - ip4 and ip6 ranges, include:domain, or redirect:domain - plus a final all qualifier: ~all softfails unlisted senders, -all rejects them, ?all stays neutral, +all lets everyone through. The builder prepends v=spf1, rejects malformed terms, keeps redirect last (the spec requires it), and totals the DNS lookups the record will consume so you stay under the 10-lookup cap before publishing the single TXT string.
Because forwarding rewrites the envelope sender, the recipient's check runs against the forwarder's domain, not yours, so your record is never consulted. SPF cannot fix this alone - DMARC was designed to compensate by aligning the visible From header with the authenticated domain, and ARC lets forwarders preserve the original results.
DNS resolvers cache records for the old value's TTL - commonly minutes, sometimes hours - and the checker reads what resolvers currently return, so your change appears only once the cached copy expires. Re-check after the TTL passes, and confirm the record sits at the exact domain used in MAIL FROM: subdomains do not inherit the parent's record.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.