
If you’ve ever wondered why some emails claiming to be from a company land safely in an inbox while others get flagged as suspicious, SPF is a big part of that answer.
It’s one of the quieter pieces of email setup, invisible when it works, and a real problem when it’s missing or broken.
Below, I’ll explain what SPF actually does, how to find and verify Hostinger’s record, and how to expand it safely without breaking anything.
What Is an SPF Record?
SPF, short for Sender Policy Framework, is a DNS record that lists exactly which mail servers are allowed to send email claiming to come from your domain.
When another mail server receives a message from “you,” it checks your domain’s SPF record to confirm the message actually came from an authorized source. Without one, there’s nothing stopping someone else from sending mail that appears to be from your address, since receiving servers have no reference to check it against.
Hostinger’s SPF record looks like this:
v=spf1 include:_spf.mail.hostinger.com ~all
Each piece does something specific.
v=spf1 marks it as an SPF record.
include:_spf.mail.hostinger.com tells receiving servers to also check Hostinger’s own list of authorized senders.
The ~all at the end is a soft fail, meaning mail from an unauthorized source gets flagged as suspicious but not automatically rejected outright. That’s a deliberate, more forgiving default compared to -all, a hard fail that instructs receiving servers to reject unauthorized mail outright.
Hostinger’s softer default reduces the risk of legitimate mail getting blocked during setup or migration, at the cost of being slightly less strict against spoofing.
With the concept clear, here’s where to actually find this record and how to confirm it’s working correctly.
Step 1: Find or Add Hostinger’s SPF Record
If your domain uses Hostinger’s nameservers, this record already exists. Check under Emails > Domain settings in hPanel, where it appears alongside your MX, DKIM, and DMARC records.

If your domain’s DNS is managed elsewhere, you’ll need to add this as a TXT record manually. Our Hostinger MX records guide covers the registrar-specific steps for adding DNS records if your domain isn’t on Hostinger’s nameservers.
Seeing the record in hPanel confirms it exists, but not whether it’s actually valid. That’s worth checking properly rather than assuming.
Step 2: Verify the Record With a Real Syntax Check
Confirming an SPF record exists isn’t the same as confirming it’s actually valid. I ran a dedicated SPF check, not a general MX lookup, using MXToolbox’s SPF Record Lookup tool, a separate tool from the basic MX lookup, built to validate SPF syntax and structure directly.
- Go to mxtoolbox.com
- Select the SPF Record Lookup tool, not MX Lookup
- Enter your domain and run the check

The tool ran twelve separate tests against webhostpro.io’s SPF record, and every one passed:
| Test | Result | What It’s Actually Checking |
|---|---|---|
| SPF Record Published | SPF Record found | Confirms the record exists at all |
| SPF Record Deprecated | No deprecated records found | Checks for an old SPF record type (a DNS “SPF” record type) phased out years ago in favor of TXT records |
| SPF Multiple Records | Less than two records found | Confirms only one SPF record exists, since a domain with two active SPF records causes validation failures rather than combining permissions |
| SPF Contains characters after ALL | No items after ‘ALL’ | Confirms nothing was mistakenly added after the closing ~all or -all, which invalidates everything following it |
| SPF Syntax Check | The record is valid | General syntax validation |
| SPF Included Lookups | Number of included lookups is OK | Tracks how many DNS lookups the record triggers, tied to the 10-lookup limit covered in Step 3 |
| SPF Recursive Loop | No recursive loops on includes | Confirms an included domain doesn’t loop back and reference itself |
| SPF Duplicate Include | No duplicate includes found | Checks for the same service accidentally included twice |
| SPF Type PTR Check | No type PTR found | Flags use of the PTR mechanism, a legacy method most SPF guidance discourages today |
| SPF Void Lookups | Number of void lookups is OK | Checks for lookups that return no result, which still count against the 10-lookup limit even though they find nothing |
| SPF MX Resource Records | Number of MX Resource Records is OK | Confirms MX-based lookups within the record stay within reasonable limits |
| SPF Record Null Value | No Null DNS Lookups found | Confirms no lookup in the chain resolves to an empty value |

That’s covered in more depth in our Hostinger email setup guide, but it’s worth knowing this SPF-specific tool surfaces DMARC status alongside SPF results, since the two are closely related in how receiving servers evaluate trust.
Step 3: Understand the 10-Lookup Limit Before You Add Anything Else
SPF has a hard technical ceiling: no more than 10 DNS lookups total, counting every include, a, mx, exists mechanism, and any lookups nested inside those.
Go over that limit, and the SPF check doesn’t just ignore the excess; it returns a permanent error, which many receiving mail providers treat as a failed check entirely, even for otherwise legitimate senders included earlier in the record.
This matters the moment you’re using more than just Hostinger to send mail, which is common. A single include:_spf.mail.hostinger.com uses up part of that budget on its own, and every additional service you add, a CRM, a marketing tool, a second mailbox provider, adds more.
Step 4: Combine Multiple Senders Into One Record, Never Two
This is the single most common real-world SPF problem, and it’s worth addressing directly rather than leaving to guesswork: what do you do if you’re sending from Hostinger and something else, say Google Workspace or a marketing platform like Mailchimp?
I asked Hostinger’s Kodee AI assistant this exact question, since it’s the scenario most likely to trip someone up. The answer is unambiguous: use one SPF record only, and list every sending service inside it using multiple include mechanisms. For Hostinger alongside Google Workspace and Mailchimp, that looks like this:
v=spf1 include:_spf.mail.hostinger.com include:_spf.google.com include:servers.mcsv.net ~all

To stay under the 10-lookup limit while combining services, Kodee recommended:
- Remove any service from the record that you’re no longer actually sending from
- Avoid including the same provider more than once, even indirectly through a different subdomain reference
- Consider using a separate subdomain just for marketing email, which can carry its own SPF record independent of your main domain’s lookup budget
- Use an SPF flattening tool if your DNS provider supports it, which resolves nested includes down into direct IP addresses to reduce the lookup count
Hostinger’s own SPF record is simple and passes every validation check MXToolbox runs against it.
The real complexity shows up the moment you add a second sending service, and the fix is always one combined record with multiple includes, never two separate records, while keeping an eye on the 10-lookup ceiling as you add each one.
Troubleshooting Common SPF Issues
- SPF check shows multiple records found. Merge every service into a single TXT record using multiple include mechanisms rather than maintaining two separate SPF records, which will cause validation failures.
- Exceeded the 10-lookup limit. Remove unused service includes first, then consider SPF flattening or a separate subdomain for high-lookup services like marketing platforms.
- Mail from a legitimate third-party service is failing SPF. Confirm that service’s specific include value is actually present in your SPF record, and that it’s the correct value for that provider rather than a similar-looking one.
- Unsure whether to use ~all or -all. Hostinger defaults to ~all (soft fail), which flags unauthorized mail without outright rejecting it. Only move to -all (hard fail) once you’re fully confident every legitimate sending source is already included, since a hard fail will block mail from anything missed.
- DMARC flagged as not enabled during an SPF check. This is a separate but related setting. Our Hostinger email setup guide covers DMARC configuration directly.

