Hostinger Emails Landing in Spam: Fixing SPF, DKIM and DMARC

Why it happens

An email landing in spam is not one problem. It is a judgement made by the receiving server, based on three things: whether you are allowed to send for your domain, whether the message was tampered with in transit, and whether your sending reputation is good.

Hostinger gives you the tools for all three. What it does not do is configure them for you in every case. A domain that was added to hPanel without DNS authentication records will have mail accepted by some providers and filtered by others, and the difference is usually invisible until someone tells you your invoice never arrived.

There are four root causes worth checking, in order.

1. Missing or wrong DNS authentication records

SPF, DKIM and DMARC are DNS records that tell receiving servers what to expect. If SPF is missing, the receiver has no way to know that Hostinger’s mail servers are allowed to send for your domain. If DKIM is missing, the message carries no signature. If DMARC is missing, you have not told anyone what to do when either check fails.

Wrong is as bad as missing. A typo in the SPF include value, or a second SPF record added alongside the first, breaks authentication just as thoroughly as having no record at all. A domain may have only one SPF record.

2. Shared IP reputation

On shared hosting plans, your outbound mail leaves from an IP address shared with other Hostinger customers. If one of them sends spam, the reputation of that IP drops and your legitimate mail suffers. This is a structural feature of cheap shared hosting and it is one of the reasons a dedicated IP is included on Unlimited and Cloud Startup but not on Premium.

You cannot fix a shared IP reputation directly. What you can do is make sure every other signal is perfect, so that the receiver’s decision rests on your authentication and engagement rather than on the IP alone.

3. Sending through PHP mail() instead of SMTP

This is the biggest self-inflicted problem. WordPress sends email through PHP’s mail() function by default. Those messages are often sent without authentication, from the web server rather than from your mailbox, and with headers that look different from mail sent through a real mail server.

Receiving providers treat unauthenticated mail from a shared web server as suspicious, and they are right to. Switching to authenticated SMTP — using your Hostinger mailbox credentials — fixes the majority of spam-folder cases on its own.

4. The send cap

Hostinger limits server-based sending to 10 emails per minute and 100 emails per day, resetting on a rolling 24-hour basis. This is a hard constraint, and it is the one people hit without realising.

A WooCommerce store that emails every customer on every order status change will exceed 100 a day faster than you would think. A contact form that sends both a notification and an autoresponder doubles the count. When you exceed the cap, mail is not delivered — it is dropped or deferred, which looks exactly like “going to spam” from the outside.

If your mail “goes to spam” in bursts rather than consistently, suspect the send cap before you suspect the filters. Check your volume over a 24-hour window first. It takes two minutes and it is the most commonly missed cause.

The records to add

You will find the exact values for your domain in hPanel’s DNS zone editor and email settings. Use the values Hostinger shows you — the table below explains what each record does and what its value looks like, with placeholders where the value is domain-specific.

A few rules that save time:

• One SPF record only. If a record already exists, edit it and add the include. Do not create a second TXT record starting with v=spf1.
• TXT values have a length limit. Long DKIM keys are sometimes split into chunks by the DNS editor. Let hPanel generate the record rather than typing it.
• Do not guess the include host. Copy it from your email settings page.
• Keep the SPF lookup count low. Each include counts against a limit of ten DNS lookups. Adding every marketing tool you use to SPF will eventually break it for everyone.

How to verify it worked

Do not trust a green tick in a control panel. Test with a real message.

1. Send a message from your Hostinger mailbox to a Gmail address you control.
2. Open the message in Gmail, use the menu to show the original.
3. Find the Authentication-Results header.
4. Check for spf=pass, dkim=pass and dmarc=pass.

If any of the three fails, the header usually names the reason — a missing record, a failed alignment, or a signature that did not verify. That reason is your next step, and it is far more useful than guessing.

You can also send to a mail-tester style service, which scores the message and lists which records are missing. Use one of those alongside the header check: the header tells you what happened, the scorer tells you what is missing.

WordPress-specific checks

If WordPress is sending mail, also confirm:

• Your SMTP plugin is configured with the correct host, port and credentials.
• The From address matches your domain. Sending as a Gmail address from a Hostinger server fails alignment.
• Test emails actually arrive in the inbox, not just leave the queue.

The warm-up routine for a new domain

A brand-new domain has no sending history, and providers treat it cautiously. If you blast 500 emails on day one, you will land in spam regardless of your records.

1. Week one: send to your most engaged contacts only. People who reply, open and move your mail out of the promotions tab. Twenty to fifty messages a day.
2. Week two: expand to your full opt-in list in small batches. Keep the volume steady rather than spiking.
3. Week three onward: increase gradually. A doubling per week is a reasonable pace.
4. Never buy a list. Purchased lists generate complaints, and complaints damage the shared IP that every other Hostinger customer on it uses.
5. Make unsubscribing easy. A visible unsubscribe reduces spam reports, and spam reports are what actually destroy a reputation.

The practical fix list

1. Check your 24-hour send volume against the 10/minute and 100/day cap.
2. Move WordPress and contact forms from PHP mail() to authenticated SMTP.
3. Confirm one SPF record exists and contains the correct include value.
4. Enable DKIM in hPanel and publish the generated record.
5. Publish a DMARC record starting at p=none.
6. Wait for propagation, then verify with a real header check.
7. Warm the domain up if it is new.
8. For volume above 100/day, move automated mail to a dedicated transactional service and keep the hosting mailbox for human correspondence.

When it is not your fault

If your records are correct, your volume is within the cap, and you are sending through authenticated SMTP, and mail still lands in spam, the likely cause is the shared IP reputation. That is the moment to consider a plan with a dedicated IP — Unlimited, Cloud Startup and above include one, while Premium does not. Our Unlimited plan breakdown explains what else changes at that tier, and the Cloud Startup page covers the step above it.

If you are troubleshooting a site at the same time, the 503 error guide and the slow site checklist cover the most common hosting-side problems. For a broader view of what each plan includes, start with the pricing comparison.