Email security is on everyone’s radar—companies are closing every gap for threat actors to come in and exploit their email sending sources. Using SPF’s ‘-all’ mechanism is one of the strongest defense measures that domain owners and CISOs advocate to block email phishing attempts made on their behalf.
While this hard defense layer ensures that illegitimate emails sent from your domain don’t land in the targeted recipients’ inboxes, they can sometimes backfire!
So, before setting your SPF record to ‘-all’ (Hardfail), which tells receiving mail servers to reject any email that does not come from an explicitly authorized IP, you should carefully consider the following 3 critical points:
1. Impact on forwarding and legacy systems
Setting your SPF record to ‘-all’ can do more harm than good if you frequently forward emails, especially using legacy systems or external servers. When an email is forwarded, the receiving server sees the IP of the forwarder—not the original sender—which often causes SPF to fail unless the forwarder uses SRS (Sender Rewriting Scheme).
This triggers instances of false positives if a former employee uses auto-forwarding or if you still have outdated CRMs in place.
2. Business-critical email deliverability
If you have implemented the ‘HardFail’ mechanism in haste, and without setting it to the ‘SoftFail’ first, then there are chances that business-critical communications, like client inquiries, password reset links, order confirmations, CRM replies, and transactional updates, will get blocked.
Let’s say a third-party platform sends customer notifications on your behalf, but its mail server isn’t listed in your SPF record, then those emails will be rejected outright. Similarly, internal tools or overlooked marketing platforms may fail to deliver time-sensitive messages.
This will simply translate into missed sales opportunities, frustrated clients, and reputational damage. Hence, it’s encouraged to audit every platform that sends emails on your behalf before you jump to the strictest SPF mechanism.
3. DNS lookup limit
SPF has a DNS lookup limit of 10 to keep things fast, safe, and under control during email delivery. Every time a receiving server checks your SPF record, it has to look up all the `include`, `a`, `mx`, and similar mechanisms—basically chasing down every possible sender you’ve authorized.
Without a limit, things could get messy fast. Attackers could abuse this by creating endless or deeply nested lookups, which can slow down servers, cause timeouts, or even trigger Denial-of-Service (DoS) attacks. So, the 10-lookup cap is there to keep email flowing smoothly and prevent anyone from overwhelming the system.
If you have set your SPF record to ‘-all,’ then evaluation errors can cause an outright rejection of genuine emails.
AutoSPF to the rescue!
SPF records of large companies are more likely to hit the DNS lookup limit of 10. So, if your SPF record is also facing this issue, then simply use our automatic SPF flattening tool. It works by resolving all ‘include:’ mechanisms into direct IP addresses.
Reach out to us at AutoSPF to sort out anything related to email authentication through SPF, DKIM, and DMARC.
