How to set up SPF, DKIM and DMARC on Hostinger

Hostinger sets up most of this for you — and stops one record short. Its automatic setup adds MX, SPF and DKIM, and about DMARC it says, in its own words, that you should add it "manually" and that it is "not mandatory for basic email operations." So the fastest honest path is: let Hostinger do the first three, then publish your own _dmarc record.

The path is hPanel → Domains → DNS → your domain, or on a hosting plan Websites → your site → Advanced → DNS Zone Editor. In the Name field you type @ for your root domain or _dmarc for DMARC — never the full hostname.

These records let receiving mail servers check that a message claiming to be from you really is from you. They do not guarantee your email reaches the inbox — your content and your sending reputation matter at least as much — but without them, anyone can send email in your name.

What we don't do: we never touch your DNS zone. This guide tells you what to type and where. You're the one who saves it, in your own account, with your own credentials.

Before anything else: Hostinger will let you edit a zone that does nothing

This is the most expensive trap on Hostinger, and it's not a bug — it's a documented feature that behaves exactly like a bug if you don't know about it.

If your domain's nameservers point somewhere else — Cloudflare, another host, a registrar — hPanel still lets you add and save DNS records. Hostinger's wording: "You can access and manage DNS records in hPanel's DNS Zone Editor even if your domain's nameservers currently point to an external provider. Any changes you make will be saved and will take effect once the nameservers are pointed back to Hostinger."

Read that again with a user's eyes. You add SPF, DKIM and DMARC. Everything saves. Nothing appears green. Nothing resolves. No error, no warning, no banner — because from Hostinger's point of view nothing went wrong: you've staged records for a future that may never come.

Hostinger says the operative part elsewhere, more bluntly: "To modify a domain's active DNS records, the domain must use Hostinger nameservers. If your domain points elsewhere via nameservers, use the management tools provided by that specific platform." And in its troubleshooting: "You may have updated DNS at the wrong provider. Always update DNS where your nameservers point."

So check your nameservers first. The values below don't change — only the panel does.

The records to copy and paste

1. SPF — who is allowed to send as you

Hostinger sells three different email products, and each has its own value. Getting this wrong is the single most common Hostinger mistake, because most tutorials only know the first one.

What you must replace: the include:, if you're not on Hostinger Email. Here is the full set, each one taken from Hostinger's own article for that product:

If several services send on your behalf, they all go in one single line. Hostinger is explicit about this — "To avoid delivery issues, you must have only one SPF record on your domain" — and gives the pattern itself:

v=spf1 include:_spf.mail.hostinger.com include:emailmktprovider.tld ~all

⚠️ One SPF record per domain. Always. Two v=spf1 lines don't mean double protection, they mean no SPF at all — not for the new tool, and not for the mailboxes that worked yesterday. When you add a sending tool, you edit the line you already have.

If you use Hostinger Reach, check before you merge. Hostinger notes that "if you're already using another email service that requires an SPF record (for example, Titan Email), the SPF record shown in your Reach dashboard is already properly combined and ready to use." Copy what Reach shows you rather than merging by hand.

⚠️ One value you may find in Hostinger's own developer docs is wrong. Its DNS reference page shows include:_spf.hostinger.com — without the mail. part. Three separate Hostinger help-centre articles give _spf.mail.hostinger.com. Use the one with mail.

On the final qualifier: every Hostinger product uses ~all (softfail), and no Hostinger page recommends -all. That's the safe default while you're still discovering who sends on your behalf. Some providers — Microsoft, GoDaddy — recommend -all instead. Neither is wrong; ~all is more forgiving of the sender you forgot.

2. DKIM — the signature on your messages

If you use Hostinger Email, the records are fixed and published, which is unusual and helpful. Three CNAME records:

What you must replace: nothing — these are Hostinger's defaults for every domain on Hostinger Email. For a subdomain, add it after the host: hostingermail-a._domainkey.shop for shop.yourdomain.com.

⚠️ Hostinger Reach uses different records — two, not three, with a different prefix and target: reach-a._domainkey → reach-a.dkim.reach.hostinger.com, and the same for reach-b. Two products, two sets. Don't mix them.

If you use Titan Email, the key is generated for your domain: go to Emails → Mailboxes → Email Reputation, expand Add DKIM record, and copy what's shown. It's a TXT record, not a CNAME.

If your email is elsewhere: Google Workspace gives you a single TXT record with the selector google by default; most campaign tools give you one to three records. Same rule every time: copy what your own screen shows.

⚠️ Never trust a tutorial that hands you a ready-made Microsoft 365 DKIM value. Since May 2025, Microsoft uses a new CNAME format for custom domains added after that date, with a partition character assigned dynamically — it is genuinely impossible to guess.

Hostinger flags the classic mistake itself, and it's worth quoting because it's the one that breaks DKIM most often: "Some DNS providers automatically append your domain name to the 'Host' field. Make sure you enter only hostingermail-a._domainkey, not the full hostname. Ensure there are no trailing dots, spaces, or uppercase letters." It adds: "DKIM must be added as CNAME. If added as TXT or with a typo, signing fails and messages may be treated as unsafe."

Want your own key instead? Hostinger supports a custom DKIM — Custom DKIM section, Generate button. Two details from its documentation: "If the Generate button is grayed out, you must delete any existing DKIM records that are in your DNS zone to use this feature", and "Custom and default DKIM records can be enabled at the same time – they do not conflict."

3. DMARC — the instruction you give to inboxes

What you must replace: YOU@YOUR-DOMAIN.com with an address you actually read. That's where your reports land, and a DMARC record without a rua= is a report you'll never see.

Type _dmarc on its own, not _dmarc.yourdomain.com.

Why p=none first. It means "watch and tell me". Nobody gets blocked, nothing changes for your recipients, and you start receiving a list of everything sending in your name — including the tools you'd forgotten about. You watch for two to four weeks, confirm every legitimate sender is recognised, and only then tighten one notch to p=quarantine, then p=reject.

⚠️ One DMARC record per domain too. If you already have one, you edit it. You don't add a second.

Hostinger's own DMARC article doesn't give you a value at all. It says: "Refer to DMARC Record Generator or DMARC Record Wizard to generate values for your DMARC record", linking to two third-party tools, and in the Value column of its table it literally tells you to "paste the value generated by the tool." That's a strange place for a host to stop — and it's exactly why the record above exists on this page. Mistake 3 below covers what those generators tend to hand you.

The click path

Hostinger has more than one panel generation live at once, and its own documentation doesn't fully agree with itself on the labels. Both paths lead to the same place.

If you have a hosting plan:

1. Go to Websites, select your site.
2. Open Advanced, then DNS Zone Editor.

If you have a domain without hosting (the newer path):

1. In the hPanel left sidebar, choose Domains, then DNS.
2. Select your domain. You land on the DNS records page, with tabs for DNS records, Child nameservers, DNSSEC and DNS history.

Then, in either case:

3. Choose the record Type.
4. In Name, enter @ for your root domain, or the prefix on its own (_dmarc, hostingermail-a._domainkey).
5. Fill in the value. For a TXT record the field is labelled TXT value; for a CNAME it's Points to. On the newer screens you may see Content or Target instead — same field.
6. Leave TTL on its default.
7. Click Add Record.

The Name field wants the prefix only. Hostinger: "Use @ (or leave the field empty) for the root domain when adding records." And for subdomains: "for the subdomain shop.domain.tld you should enter shop as a host."

Prefer the automatic setup for the first three records. Emails → Mailboxes → Domain settings → Connect automatically → Yes, proceed. Hostinger then "adds the required MX, SPF, and DKIM records for you". Come back to Emails → Mailboxes → Domain settings to see the domain marked as connected. Then add your DMARC by hand — that one is not included.

On TTL: Hostinger's articles disagree with each other — its TXT guidance says "the default TTL value of 14400 seconds (four hours)", while its SPF and DKIM tables show 300. Leave it on default and don't spend time on it.

The 3 mistakes we see most often on Hostinger

1. A green "connected" screen with no DMARC behind it

Hostinger's automatic setup is genuinely good, and that's the problem. It adds MX, SPF and DKIM, the domain shows as connected, and everything you were asked to do is done.

But DMARC isn't in that set. Hostinger says so itself: "Additionally, we recommend you add a DMARC record to your domain's DNS zone manually. While not mandatory for basic email operations, it's highly recommended for enhanced security." Its setup table repeats the same line — "Not mandatory for basic email operations."

That's a defensible thing for a mailbox provider to say and a bad thing for a domain owner to believe. Your mail working and your name being protected are different problems. Nothing about a connected mailbox stops someone else sending as you.

How you spot it: your Hostinger email works perfectly, the panel is green, and a lookup of _dmarc.yourdomain.com returns nothing.

The fix: add the _dmarc record from section 3. It takes a minute and it's the only one of the four nobody adds for you.

2. Records saved in hPanel that never leave the building

You add everything, you click Add Record, the list updates, and weeks later nothing has changed. Your nameservers point to Cloudflare, or to another host, and Hostinger is holding a perfectly good zone that no resolver ever queries.

Hostinger is unusually permissive here: it lets you save into an inactive zone on purpose, so the records are ready if you switch nameservers back. Useful if that's your plan, quietly maddening if it isn't.

How you spot it: the records look right in hPanel, but any outside lookup of your domain returns something different — or nothing. Check your nameservers first, always.

The fix: add the records wherever your nameservers actually point. Same values, different panel. And from then on, that's your real DNS home.

3. Pasting whatever a DMARC generator produces

Since Hostinger's DMARC article sends you to third-party generators without giving you a value, what you end up publishing depends entirely on which generator you land on and which boxes you tick. Two things to watch for.

Tags that no longer exist. RFC 9989, published in May 2026, is the current DMARC standard, and it removed pct=, rf= and ri=. Generators built before that date still offer all three. A line like v=DMARC1; p=none; sp=none; rf=afrf; pct=100; ri=86400 isn't dangerous, but three of its six tags are now noise that standard-following servers ignore. Worse, if a generator offers you pct=5 as a gentle rollout, it isn't one — that mechanism no longer exists, and you'd be publishing a policy you think is partial when it isn't.

A policy that's too strict on day one. Some generators default to p=quarantine or offer p=reject as the "recommended" secure option. Publishing that before you've read a single report means any legitimate sender you've forgotten — invoicing tool, contact form, CRM — stops being delivered.

How you spot it: your _dmarc value contains pct=, rf= or ri=, or it starts at p=reject and you've never looked at a report.

The fix: use the value in section 3, exactly as written, with your own address in the rua=. Four tags is a complete DMARC record. Then tighten in steps — our full method is linked below.

⚠️ And while you're in there, don't mix up two opposite traps. Typing the full hostname in the Name field creates a duplicated domain (_dmarc.yourdomain.com.yourdomain.com) and the fix is to shorten it. At some other hosts (OVH, Gandi), the symmetrical trap sits on a CNAME target, where the fix is to add a trailing dot. Same look, opposite fixes.

How long before it takes effect

• In hPanel: saved as soon as you click Add Record.
• On the internet: Hostinger's headline figure is up to 24 hours — "The propagation process is fully automatic and can take up to 24 hours" — and it notes that "in rare cases, a certain record might take up to 72 hours to propagate." Its developer docs quote shorter numbers for some checks. In practice most changes resolve much faster than 24 hours.
• The old value can stay cached for as long as the TTL you had set before the change.
• For a custom DKIM: Hostinger documents up to six hours, with the record showing Unverified → Verifying → Verified.
• For your provider's "Verify" button: wait an hour before clicking, then wait again. Clicking twelve times in five minutes only adds doubt.
• For DMARC reports: the first ones arrive 24 to 72 hours after you publish, then roughly once a day.

Next steps

• How to set up SPF, DKIM and DMARC on GoDaddy
• How to set up SPF, DKIM and DMARC on Namecheap
• How to set up SPF, DKIM and DMARC on Cloudflare
• How to move your DMARC policy to p=reject safely
• My emails go to spam even though SPF, DKIM and DMARC pass