Skip to content
NewHosted MCP server live for Claude Desktop & CursorExplore guide →
SadaSend
Start free
Free deliverability tool

Free SPF Record Merger & Lookup Flattener

RFC 7208 §3.2 strictly states that a domain MUST NOT publish more than one SPF TXT record. If you publish two records, receiving mail servers (Gmail, Outlook, Yahoo) throw a fatal PermError and drop legitimate mail. Use this tool to merge existing mail providers into a single, valid SPF record and verify you stay strictly under the 10-lookup ceiling.

Predefined real examples:Click to test live

No signup · we do not record what you check

Worked example — example.com

Sample demonstration
  • PassMerged SPF TXT valuev=spf1 include:_spf.google.com include:spf.sadasend.com ~all
  • PassRecord count1 unified TXT record

    RFC 7208 §3.2 forbids publishing two SPF TXT records on a single domain.

  • PassDNS lookup count5 of 10 maximum (RFC 7208 §4.6.4)

    5 lookups remaining. Headroom for roughly 2 more providers.

  • PassDetected mail providersGoogle Workspace, SadaSend
  • PassAll mechanism qualifier~all (SoftFail)

    SoftFail (~all) is recommended during migration to prevent dropped messages.

Merged successfully into a single RFC-compliant TXT record with 5 DNS lookups, leaving headroom under the 10-lookup ceiling.

SadaSend runs these checks continuously on your sending domains, and refuses to send until they pass — so mail Gmail would reject never leaves.

Start free

Technical Reference & RFC 7208 Specifications

The RFC 7208 10-DNS-Lookup Limit Explained

Sender Policy Framework (RFC 7208) authorizes which servers may send mail on behalf of your domain. To protect internet nameservers from denial-of-service amplification loops, the specification strictly caps recursive DNS evaluations to 10 lookups maximum. Exceeding this limit causes an immediate PermError.

Counts Against 10-Lookup Limit (+1 each)Lookup Cost
  • • include: (resolves another domain's SPF record, including nested lookups)
  • • a or a:domain (performs forward A/AAAA DNS query)
  • • mx or mx:domain (queries MX records and their target IPs)
  • • ptr (deprecated by RFC 7208, queries reverse DNS)
  • • exists: and redirect= (queries target domains)
Zero DNS Lookups (Free / No Cost)0 Cost
  • • ip4:198.51.100.0/24 (authorizes IPv4 addresses directly with zero DNS queries)
  • • ip6:2001:db8::/32 (authorizes IPv6 ranges directly with zero DNS queries)
  • • all (evaluation qualifier tag at the end of the record)
  • • v=spf1 (protocol version identifier)

Top 3 Ways to Resolve SPF PermErrors

1. Eliminate Multiple Records: Never publish two TXT records beginning with v=spf1. Receiving servers treat multiple records as an immediate PermError. Merge all mechanisms into a single record.

2. Audit and Remove Dead Includes: Former helpdesks, decommissioned marketing tools, or legacy CRMs often leave nested includes that consume 2–4 lookups each.

3. Subdomain Segmentation: Route transactional notifications through a dedicated subdomain (such as mail.yourdomain.com). Subdomains receive their own independent 10-lookup allocation, keeping root domain DNS clean.

Predefined Real-World Test Scenarios

Live verification vectors
Google Workspace + SadaSendRecommended
v=spf1 include:_spf.google.com ~all

Combines Google Workspace office mail with SadaSend transactional email relay.

Microsoft 365 + SadaSendEnterprise
v=spf1 include:spf.protection.outlook.com -all

Merges Outlook corporate sending with SadaSend developer API infrastructure.

Parked Domain RecoveryRecovery
v=spf1 -all

Replaces restrictive parked-domain block with active authorized sending infrastructure.

What this checks

  • Validates syntax according to RFC 7208
  • Merges existing providers into exactly one TXT record
  • Calculates total DNS lookups against the 10-lookup limit
  • Prevents fatal PermError caused by multiple SPF records
Production Email Infrastructure

Ready for rock-solid transactional email?

Automated 2048-bit DKIM key rotation, domain-level SPF alignment, and suppression firewalls. Send 6,000 free emails every month with zero credit card required.

Start freeView pricing

Questions

RFC 7208 §3.2 explicitly dictates that a domain MUST NOT have more than one SPF TXT record. When receiving servers (like Gmail or Microsoft 365) detect two or more SPF records for the same domain, evaluation halts with a fatal PermError. This causes legitimate emails from both providers to fail authentication and land in Spam or bounce entirely.

Under RFC 7208 §4.6.4, an SPF evaluator aborts evaluation if resolving the record requires more than 10 DNS queries. Mechanisms that count against the limit include: include, a, mx, ptr, exists, and redirect. Nested includes count towards your total (for example, Google Workspace includes 3 sub-records, consuming 4 lookups total).

If your record exceeds 10 lookups, you must flatten it. Replace nested include mechanisms with direct ip4 or ip6 blocks, or remove legacy and unused third-party services from your SPF string.

We recommend starting with ~all (SoftFail) while integrating a new sender to ensure uninterrupted delivery. Once your SPF record has been verified across all active outbound systems and your DMARC policy is established, you can safely transition to -all (HardFail).

Other tools