Where do I add SPF, DKIM, and DMARC records in Hostinger?

In hPanel, go to Domains, select your domain, open DNS / Nameservers, and use the DNS Zone editor's Manage DNS records / Add record form. SPF and DMARC are TXT records (Name @ and _dmarc); Hostinger Email's DKIM is three CNAME records. hPanel wording changes over time, so if a label doesn't match, look for the equivalent Type / Name / Value fields.

Is Hostinger's DKIM a CNAME or a TXT record?

For native Hostinger Email it's CNAME — three of them: hostingermail-a._domainkey, hostingermail-b._domainkey, and hostingermail-c._domainkey, each pointing at a …dkim.mail.hostinger.com target. Hostinger holds and rotates the actual key. There is a Custom DKIM option that lets advanced users publish their own key as TXT, but the default managed path is the three CNAMEs.

Does Hostinger add these records automatically?

If Hostinger runs your DNS, the Connect automatically button under Emails adds the MX, SPF, and DKIM records for you. It does not add DMARC — that's always manual. On external nameservers, nothing is automatic and you add all four record types yourself at whichever provider is authoritative.

What is the SPF record for Hostinger email?

v=spf1 include:_spf.mail.hostinger.com ~all, published as a single TXT record at your root (Name @). That include chains through Hostinger's relay and MailChannels, using three of SPF's ten lookups. If you send through other services too, merge their includes into this one record rather than publishing a second SPF.

My website is on Hostinger but I use Google Workspace for email — which records do I use?

Google Workspace's, not Hostinger's. Where your website is hosted has nothing to do with which servers send your mail. Publish Google's SPF include (include:_spf.google.com), Google's DKIM key from the Gmail admin console, and your own DMARC record — all in whichever DNS is authoritative for the domain.

How is Hostinger Reach different from Hostinger Email?

Reach is Hostinger's marketing/newsletter product and authenticates separately: SPF include _spf.reach.hostinger.com and DKIM CNAMEs reach-a._domainkey and reach-b._domainkey (targets under dkim.reach.hostinger.com). If you use both Reach and native Hostinger Email, add both DKIM sets and merge both SPF includes into your single root SPF record — don't let Reach's wizard replace your existing SPF.

Why isn't my Hostinger DNS record working yet?

Most often the domain isn't actually on Hostinger's nameservers, so your edits aren't authoritative — confirm ns1/ns2.dns-parking.com serve the domain first. Otherwise it's usually a full hostname typed into the Name field (use _dmarc or hostingermail-a._domainkey, not the version with your domain appended), DKIM entered as TXT instead of CNAME, a second v=spf1 record triggering a PermError, or simply propagation — Hostinger applies changes fast, but public resolvers can cache for up to 24–72 hours. Recheck with dig or an external checker once caches clear.

SPF setup guide

SPF, DKIM & DMARC for Hostinger.

On Hostinger, "authenticating your email" isn't one setup — it depends on who actually sends your mail. Hostinger Email (the native mailboxes that come with most plans) has its own SPF include and, unusually, ships DKIM as CNAME records that Hostinger manages the keys for. Hostinger Reach (the newsletter/marketing product) uses a completely different include and selectors. And if your website lives on Hostinger but your mailboxes are on Google Workspace, Microsoft 365, or an ESP, none of Hostinger's records apply at all — you publish that provider's records instead. The good news is that all of it lives in one screen (the DNS Zone editor in hPanel), and when Hostinger runs your DNS it can add most of it for you with a single click. This guide covers the native Hostinger Email path in full, flags where Reach and third-party mail differ, and gets the DMARC record — the one piece Hostinger never adds automatically — in place correctly.

SPF include

Your DNSAdd the CNAME / TXT records

HostingerSigns & sends as your domain

The inboxSPF · DKIM · DMARC pass

Why authenticate Hostinger?

SPF, DKIM, and DMARC are what let a receiving server prove a message claiming to be from your domain is really yours. SPF lists the servers allowed to send for you; DKIM cryptographically signs each message; DMARC ties both to the visible From address and tells receivers what to do on failure. Since February 2024, Google and Yahoo require all three from anyone sending in bulk to their users — mail from unauthenticated domains gets throttled or dropped. Even at low volume, a domain with no DMARC record is trivially spoofable, and a single phishing run in your name can poison your sender reputation for months. Publishing these three records is the entry ticket to the inbox; skipping them is why legitimate Hostinger mail so often lands in spam.

The SPF reality for Hostinger

Hostinger Email's SPF is a single TXT record at your root that includes `_spf.mail.hostinger.com`. That include is not a dead end: it chains through `relay.mail.hostinger.com` (Hostinger's own sending IPs) and `relay.mailchannels.net` — Hostinger routes outbound mail through MailChannels — so adding this one include actually consumes three of SPF's hard limit of ten DNS lookups. That still leaves plenty of room, but it matters once you stack senders. The cardinal rule is one SPF record per domain: a second TXT record starting with `v=spf1` makes SPF fail with a PermError for everything. So if you send through Hostinger Email and a third-party ESP and Hostinger Reach, you do not publish three SPF records — you merge every include into one string, for example `v=spf1 include:_spf.mail.hostinger.com include:_spf.reach.hostinger.com include:sendgrid.net ~all`. Watch out here: Hostinger Reach's own setup screen may tell you to replace your existing SPF with just its value — don't follow that literally, or you'll drop the `_spf.mail.hostinger.com` include and break SPF for your native mailboxes. Merge, never replace. Keep `~all` (soft fail) while you monitor; tighten to `-all` only once you are certain every legitimate source is listed.

Step by step

hPanel → Domains → your domain → DNS / Nameservers

1
Confirm Hostinger actually serves your DNS
Editing records in hPanel only does anything if your domain resolves through Hostinger's nameservers. Open your domain and check the Nameservers section — Hostinger's are typically ns1.dns-parking.com and ns2.dns-parking.com. If it shows Cloudflare, Route 53, your registrar, or anyone else, that provider is authoritative and you must add SPF, DKIM, and DMARC there instead; records added in Hostinger will be silently ignored.

hPanel → Emails (to see what's provisioned on the domain)

2
Decide which mail product you're authenticating
Native Hostinger Email, Hostinger Reach, and a third-party mailbox (Google Workspace, Microsoft 365, an ESP) each need different records. If your mailboxes are elsewhere, ignore Hostinger's values entirely and use that provider's — hosting your website on Hostinger does not mean your email uses Hostinger's servers. This guide's records are for native Hostinger Email; Reach's differ (see the SPF and DKIM notes).

hPanel → Emails → your domain → Connect automatically

3
Try the one-click automatic connect first
If Hostinger runs your DNS, open the domain under Emails and use Connect automatically, then confirm. Hostinger writes the MX, SPF, and DKIM records into your DNS zone for you — no copy-paste, no typos. This is the recommended path for the native email product. It does NOT add DMARC, so you still complete the DMARC step by hand. If your domain uses external nameservers, skip this and add every record manually.

DNS Zone → Manage DNS records → Add record (Type: TXT)

4
Add or merge the SPF record
If automatic connect didn't run, add a TXT record: Type TXT, Name @, value v=spf1 include:_spf.mail.hostinger.com ~all. Critically — if a v=spf1 TXT already exists (from Hostinger web hosting, a previous provider, or Reach), do not add a second. Edit the existing one and merge the new include into it. One SPF record only.

DNS Zone → Manage DNS records → Add record (Type: CNAME)

5
Add the three DKIM CNAME records
Hostinger Email's DKIM is not a pasted public key — it's three CNAME records pointing at Hostinger-hosted, auto-rotated keys. Add each with Type CNAME: hostingermail-a._domainkey → hostingermail-a.dkim.mail.hostinger.com, hostingermail-b._domainkey → hostingermail-b.dkim.mail.hostinger.com, and hostingermail-c._domainkey → hostingermail-c.dkim.mail.hostinger.com. Enter only the short host label in Name (Hostinger appends your domain) and the target host in the Points to / Target field. Do not wrap the target in quotes and do not convert these to TXT records.

DNS Zone → Manage DNS records → Add record (Type: TXT, Name: _dmarc)

6
Add the DMARC record — the piece Hostinger never adds
DMARC is always manual on Hostinger, even after automatic connect. Add a TXT record: Name _dmarc, value v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Start at p=none so you enforce nothing while you gather reports; point rua at a mailbox you actually read. Build the string with the DMARC generator so the tags are valid, then paste it.

DNS Zone → Manage DNS records

7
If you also use Reach or a third-party ESP, reconcile the SPF
Hostinger Reach uses include:_spf.reach.hostinger.com plus its own reach-a._domainkey and reach-b._domainkey CNAMEs (targets under dkim.reach.hostinger.com); an ESP has its own include and DKIM too. Add each provider's DKIM records as separate entries — DKIM stacks freely — but fold every SPF include into your single root SPF record. Reach's own screen may prompt you to replace your SPF with just its value; ignore that and merge instead, or you'll knock out your native Hostinger Email include. Never publish a second v=spf1 line.

External checker / your DMARC report inbox

8
Verify, then roll DMARC toward enforcement
Once the records have had time to propagate (Hostinger says allow up to 24–72 hours, though it's usually far faster), confirm all three resolve. Then watch DMARC aggregate reports for a week or two until every legitimate stream passes SPF or DKIM in alignment, and only then raise the policy to p=quarantine and finally p=reject.

Records to add

Hostinger generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.

Type	Host	Value
MX	@	mx1.hostinger.comPriority 5. Standard Hostinger Email inbound server — only needed if Hostinger hosts your mailboxes.
MX	@	mx2.hostinger.comPriority 10. The backup inbound server; add alongside mx1.
TXT	@	v=spf1 include:_spf.mail.hostinger.com ~allThe native Hostinger Email SPF. Publish exactly one SPF record — merge other senders' includes into this line rather than adding a second.
CNAME	hostingermail-a._domainkey	hostingermail-a.dkim.mail.hostinger.comDKIM selector 1 of 3. Hostinger manages and rotates the underlying key; you only publish the CNAME.
CNAME	hostingermail-b._domainkey	hostingermail-b.dkim.mail.hostinger.comDKIM selector 2 of 3. Add all three CNAMEs — signing stays valid as Hostinger rotates keys across the selectors.
CNAME	hostingermail-c._domainkey	hostingermail-c.dkim.mail.hostinger.comDKIM selector 3 of 3. Hostinger Reach uses different selectors (reach-a / reach-b) — don't mix them up.
TXT	_dmarc	v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comIllustrative — swap the rua address for a mailbox you read. Hostinger never adds this automatically; it's always manual.

Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.

The 10-lookup budget

SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what Hostinger's setup costs against that budget.

SPF 10-lookup budget3 used · 7 free

Hostinger adds 3 of your 10 lookups; ip4: and ip6: mechanisms are free.

DKIM

Hostinger Email handles DKIM differently from most registrars, and it's the detail people get wrong. Instead of generating a key pair and handing you a long TXT public key to paste, Hostinger publishes DKIM as three CNAME records — hostingermail-a._domainkey, hostingermail-b._domainkey, and hostingermail-c._domainkey — each pointing at a Hostinger-hosted target (…dkim.mail.hostinger.com). The actual key material lives on Hostinger's side, which means Hostinger can rotate keys without you ever touching DNS again. When Hostinger runs your DNS, the automatic connect adds all three for you; on external DNS you add them yourself as CNAME (not TXT), entering the short selector label in the Name field and the target host in Points to / Target, with no quotes. There is also a Custom DKIM option in the email deliverability panel for advanced users who want to bring their own key as a TXT record, but the default and recommended path is the three managed CNAMEs. If you additionally send through Hostinger Reach, add its reach-a._domainkey and reach-b._domainkey CNAMEs (they point at …dkim.reach.hostinger.com) as well — DKIM records stack, so every sending product gets its own selectors alongside the others.

DMARC

DMARC is the one record Hostinger will never create for you — not through automatic connect, not through the email wizard — so you always add it by hand as a TXT record at _dmarc. Start every domain at v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. The p=none policy enforces nothing; it simply switches on the daily aggregate XML reports that tell you which servers are sending as your domain and whether they pass SPF or DKIM in alignment. Point rua at a mailbox you can actually read (or a DMARC reporting service). Leave the policy at none until the reports confirm every legitimate stream — Hostinger Email, Reach, any ESP, your CRM — authenticates cleanly, then tighten to p=quarantine, watch again, and finally p=reject. Jumping straight to reject before monitoring is the fastest way to send your own invoices and newsletters to spam. Because DMARC alignment depends on the From domain matching your authenticated domain, this record is what actually turns your SPF and DKIM work into spoofing protection rather than just passing checks.

Check it actually worked

Give the records time to propagate first — Hostinger applies zone changes quickly, but caches across the internet mean a lookup can come back empty for anywhere from a few minutes up to the 24–72 hours Hostinger quotes. Once settled, confirm all three at once with an external SPF/DKIM/DMARC checker: paste your domain plus a DKIM selector (use hostingermail-a for native Hostinger Email) and it reports whether each record is found and well-formed. From a terminal you can spot-check with dig: dig TXT yourdomain.com for SPF, dig CNAME hostingermail-a._domainkey.yourdomain.com for DKIM, and dig TXT _dmarc.yourdomain.com for DMARC. If something's missing, check in this order: that Hostinger's nameservers actually serve the domain, that you entered short host labels (not the full hostname) in the Name field, that there's only one v=spf1 record, and that the DKIM records are CNAME rather than TXT with no stray quotes.

Domain health check DMARC report analyzer

Common gotchas

Coverage
Nameservers point elsewhere. If your domain uses Cloudflare, Route 53, or your registrar's DNS (not ns1/ns2.dns-parking.com), records added in hPanel do nothing — add them at the authoritative provider instead. This is the single most common reason Hostinger records 'don't work.'
DNS setup
Treating DKIM as a TXT key. Native Hostinger Email DKIM is three CNAME records pointing at Hostinger-hosted keys, not a public key you paste. Don't convert them to TXT, don't quote the target, and add all three selectors, not just one.
DNS setup
Assuming automatic connect finished the job. Connect automatically adds MX, SPF, and DKIM — but never DMARC. If you stop there, your domain has no DMARC policy and is still spoofable. Always add the _dmarc TXT record by hand.
Breaks auth
Two SPF records. Hostinger web hosting, a previous email provider, or Reach may have already left a v=spf1 TXT at your root. Adding a second makes SPF fail with a PermError for the whole domain — edit and merge includes into one record.
Coverage
Letting Reach replace your SPF. Reach's setup screen may prompt you to swap your existing SPF for its value alone — do that and you drop the _spf.mail.hostinger.com include, breaking SPF for your native mailboxes. Merge both includes into one line instead.
DNS setup
Confusing Hostinger Email with Hostinger Reach. They use different includes (_spf.mail vs _spf.reach) and different DKIM selectors (hostingermail-a/b/c vs reach-a/b). If you use both, merge the SPF includes into one line but publish both sets of DKIM CNAMEs.
DNS setup
Using Hostinger's records when your mail is actually on Google Workspace or Microsoft 365. Hosting your site on Hostinger doesn't route your email through Hostinger. Publish your mailbox provider's SPF and DKIM, not these.
Coverage
Typing the full hostname in Name. Hostinger appends your domain, so enter _dmarc, @, or hostingermail-a._domainkey — never _dmarc.yourdomain.com, which resolves to a doubled, dead hostname.
Coverage
Enforcing DMARC on day one. p=reject before you've read the aggregate reports buries your own legitimate mail. Start at p=none and tighten only after monitoring confirms alignment.

Build your SPF record

Hostinger is pre-selected below. Add any other platforms you send through, then publish the single merged record.

Sending sources

Search for each platform you send email through and tick it.

Selected

Hostingerinclude:_spf.mail.hostinger.comGuide →

This domain's own servers

Authorize the domain itself, if it sends mail directly (not through a platform above).

a — the domain's own A recordmx — the domain's MX hosts

Other senders & IPs

Anything not in the list — another provider's SPF host, or specific IP addresses.

Additional includes

We add the include: prefix — enter the hostname your provider documents.

IPv4 addresses

IPv6 addresses

Policy for everyone else

What receivers should do with mail from any server not listed above (the all mechanism).

-all (fail)Strict — receivers should reject mail from any server not listed.~all (softfail)Recommended default — unlisted senders are accepted but marked suspicious.?all (neutral)No opinion — provides almost no protection; use only while testing.

Your SPF record1/10 DNS lookups

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

Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.

Authentication published? The next step is sending to a clean, verified list.

Verify a list