🔒 OSH.co.za Domain Deliverability Checker

SPF (Sender Policy Framework) is a DNS-based email authentication mechanism defined in RFC 7208. It lets a domain owner publish a list of mail servers that are authorised to send email on behalf of that domain. When a receiving mail server gets an email claiming to come from your domain, it looks up your SPF record and checks whether the sending server's IP address is in the authorised list. If the check fails, the receiving server can reject or flag the message as suspicious. SPF is published as a TXT record at the root of your domain (e.g. example.com) with a value that starts with v=spf1.

The all mechanism at the end of an SPF record defines what happens to mail sent from servers not listed in the record. The qualifier before all controls the result: -all (fail) means the domain explicitly rejects mail from unlisted servers — these messages should be rejected. ~all (softfail) means mail from unlisted servers should be accepted but marked as suspicious — this is the recommended setting because it avoids blocking legitimate mail that has been forwarded. +all (pass) allows any server to send mail for the domain — this is dangerous and effectively disables SPF protection. ?all (neutral) provides no guidance, offering no protection at all. Most organisations should use ~all for compatibility with email forwarding scenarios.

RFC 7208 limits SPF evaluation to a maximum of 10 DNS lookups per check. This limit exists to prevent denial-of-service attacks where a malicious SPF record causes a receiving server to make an enormous number of DNS queries when checking a single message. Each include:, a, mx, ptr, exists, and redirect= mechanism in an SPF record (and within any included records) counts toward this limit. If the limit is exceeded, the SPF check returns a permerror result, which many receivers treat as a failure. As you add more email service providers, each of which may add their own include: references with further nesting, it becomes easy to exceed 10 lookups.

If your SPF record exceeds 10 DNS lookups, you have several options. The most straightforward is to audit and remove unused mechanisms: if you no longer use a particular email provider, remove their include: from your record. You can also replace include: references with explicit IP ranges using ip4: and ip6: mechanisms — these do not count toward the DNS lookup limit. Another option is SPF flattening, which resolves all include: references to their underlying IP ranges at publish time and rewrites your SPF record as a flat list of ip4: entries. However, flattened records must be kept up to date when providers change their IP ranges, so automated flattening tools are usually required for this approach.

SPF flattening is the process of resolving all DNS-lookup-requiring mechanisms in your SPF record — such as include:, a, and mx — into their underlying IP addresses at publication time. The result is a single SPF record containing only ip4: and ip6: entries, which require zero DNS lookups during evaluation. This guarantees you will never exceed the 10-lookup limit. The downside is maintenance: when one of your email providers changes their IP ranges, your flattened record becomes out of date and valid mail may start failing SPF. To manage this effectively, use an automated SPF flattening service (such as AutoSPF, EasyDMARC, or dmarcian) that monitors upstream changes and updates your record automatically. Manual flattening is fragile and is only practical for organisations with very stable, self-hosted mail infrastructure.