Defaults.Exposed › Setup walkthroughs › SPF › Hostinger

Hostinger SPF record, and why yours may not work

If your SPF (Sender Policy Framework) record is not working, the likeliest reason is that there are two of them. Hostinger often pre-populates a basic SPF line on its own zones, so somebody adding their mail provider’s record on top ends up with a domain publishing two lines that begin v=spf1. Receivers do not pick one of the two. They stop evaluating and the check fails for every message you send.

Look before you add

In hPanel, open the DNS (Domain Name System) Zone editor and read the Manage DNS records section for an existing record starting with v=spf1. If one is there, this job is an edit. If not, it is an addition. Either way the outcome is a single line at the domain root.

Hostinger publishes nothing for this record on its own beyond the default SPF line it sometimes pre-populates on new zones. For Hostinger Email, Hostinger’s help pages give that line as v=spf1 include:_spf.mail.hostinger.com ~all. Every other value in the record comes from your other mail senders and is typed in by you.

Check the nameservers point here

Hostinger is the domain registrar and DNS host for domains that use its own nameservers. It stores the TXT (Text) record in the domain’s DNS zone through hPanel, and it does not choose or generate the SPF value itself.

In hPanel, open Domains and check the DNS / Nameservers area for the domain. If that area shows Hostinger’s own nameservers, the record belongs in Hostinger’s zone editor. If it shows another company’s nameservers, the record has to go into that other company’s DNS instead, and adding it in Hostinger has no effect.

Add or edit the record

1. Sign in to Hostinger and open hPanel.
2. Go to Domains, select the domain, and open DNS / Nameservers, which is the DNS Zone editor.
3. Look at the Manage DNS records section for an existing record starting with v=spf1 before adding a new one.
4. To add a record, set Type to TXT.
5. In the Name field, which Hostinger also labels Host, enter @ rather than the full domain name.
6. In the TXT value field, which Hostinger also labels Content or Value, type the SPF string the mail provider supplied, without wrapping it in quotes.
7. Leave TTL (Time to Live) at the default setting Hostinger offers.
8. Click Add Record, or Save if editing an existing record.

The Name field, labelled Host in some Hostinger screens, takes @ on its own, because Hostinger appends the domain name automatically and typing the full domain there creates the record at the wrong location. The TXT value field, labelled Content or Value elsewhere in hPanel, takes the plain SPF string with no surrounding quotes. TTL stays at whatever default Hostinger sets for the record.

Traps on this console

• Hostinger often pre-populates a basic SPF record on its own zones, so the Manage DNS records section needs checking for an existing v=spf1 line before a new one is added.
• Two v=spf1 records on the same domain break SPF entirely, because receivers stop evaluating the record rather than picking one of the two.
• Hostinger handles the quoting of the TXT value itself, so wrapping the value in double quotes when pasting it can save as a broken record.
• Adding a further sender, such as a newsletter tool, means adding another include: entry inside the one existing record rather than creating a second TXT record.
• A line that needs more than ten DNS lookups to evaluate fails with a permanent error. Each include:, a and mx term spends from that budget, and nested includes cost more than they appear to.

What the ending means

-all lets a receiver reject mail from an unlisted server on SPF alone, which can bounce forwarded mail before DKIM (DomainKeys Identified Mail) is checked. ~all marks that mail as a soft fail and leaves the decision to your DMARC (Domain-based Message Authentication, Reporting and Conformance) policy. Both endings are defensible; whichever you choose, list every sender first. For scale, the October 2026 census found 87,173,390 domains (26.2%) ending on softfail and 175,426,748 (52.8%) publishing no SPF record.

What the default line covers

If the zone already held a record when you arrived, read it before you decide whether to keep it. If it carries include:_spf.mail.hostinger.com, it authorises Hostinger’s mail servers, and you keep that include for as long as Hostinger mailboxes or the site send mail. A line built from a and mx terms authorises the hosting account itself and nothing else.

a authorises whatever address the domain’s A record points at, which is the web server. mx covers whatever host answers mail for the domain. ip4: names an address or range directly. include: pulls in a third party’s published list, which is the form mail providers hand you.

So a default record typically covers a contact form or an order confirmation sent by the site itself, and covers none of your mailboxes if they are at Google Workspace or Microsoft 365. Adding the provider’s include to that same line closes the gap. Keeping the a and mx terms is what stops you breaking the form that already worked.

The reverse case matters too. If the site has since moved off Hostinger while the DNS stayed, a and mx may now authorise servers that have nothing to do with you. Removing terms that no longer describe your senders keeps the record accurate and frees lookups against the ten that a receiver allows before it fails the whole record.

Wait, then check it

Changes made in the DNS Zone editor take from a few minutes up to a couple of hours to show everywhere. The saved record appears listed in the Manage DNS records section of the same DNS / Nameservers screen.

When it appears there, run the free scan against your domain. Because it resolves the record from outside rather than reading your console, it catches the duplicate-record problem this page opens with.

How the scan grades this record: the SPF record check, with its pass and fail rules and how many domains pass it.

Publishing an SPF record does not stop anyone forging the domain, and it does not protect it on its own. SPF states which servers may send, and it is checked against the envelope sender. Some receivers reject on an SPF hard fail by itself; a receiver that applies DMARC follows your DMARC policy, which is what ties the check to the From address a reader sees. The SPF guide covers how the evaluation runs.

Figures from the defaults.exposed census, data as of 12 October 2026. Census numbers move every month; the current values are on the census data page.