Why is the Repair button in cPanel's Email Deliverability greyed out?

Because cPanel does not control your DNS zone. Repair writes records directly into the zone, so it is only available when the domain points at that server's nameservers. If your DNS is at Cloudflare, your registrar or another provider, copy the suggested SPF and DKIM values from the same screen and create the records there by hand instead.

Why does DKIM fail on Hostinger even though I added the record?

The most common cause is record type. Hostinger's default DKIM records for Hostinger Email are CNAME records, not TXT, and people add them as TXT out of habit because that is how other providers publish DKIM. Signing then fails and receivers can treat the message as unsafe. Delete the TXT version, add the CNAME with the exact host and target the panel shows, and re-test.

Do I need all three records if I only send a few emails a week?

Yes. Gmail's published requirements put the strictest bar on senders above 5,000 messages a day, but low volume does not exempt you from filtering, and on shared hosting you are borrowing the reputation of every other tenant on the server. SPF, DKIM and DMARC are the only part of that equation you own, and they cost nothing but three DNS records.

SPF, DKIM and DMARC on Hostinger hPanel and cPanel

The email came with the hosting. One plan, one panel, a website and five mailboxes, and for two years nobody thought about it. Then a customer says the quote never arrived, you find it in their spam folder, and the invoices your accounting system sends are bouncing with something about authentication.

Mail on shared hosting fails in a specific, repeatable way, and the fix is the same three DNS records everyone else publishes. What changes is where the panel hides them, and how much of your zone the panel actually controls. This is the working version for the two panels we see most across Latin America: Hostinger's hPanel, and cPanel on whichever host resells it.

Why shared hosting is its own problem

Your website and your mailboxes sit on a machine you share with hundreds of other sites. Outbound mail leaves from an IP address that belongs to the host, and its reputation is the sum of everyone's behaviour, not just yours. One customer on that server running a bad campaign moves your mail too.

That part you do not control. Two things you do control matter more than most people expect.

Authentication. SPF, DKIM and DMARC are yours, they live in your DNS zone, and on shared hosting at least one of the three is usually missing or broken.
Which server sends. A contact form using the local PHP mail function and a mailbox sending through authenticated SMTP are two different senders, and receivers judge them separately.

Gmail's sender guidelines set the bar you are being measured against. Senders above 5,000 messages a day to Gmail accounts have to have SPF and DKIM both set up, a DMARC record on the sending domain (an enforcement policy of none is accepted), valid forward and reverse DNS on the sending IP, a TLS connection for transmission, and a spam rate in Postmaster Tools kept below 0.30 percent. Small senders are not exempt from the ideas, only from the threshold. The reverse DNS requirement is worth noting because on shared hosting the PTR record belongs to your host, so if that is wrong, it is a support ticket, not a DNS edit.

First, find out which zone the internet actually reads

This one check saves more wasted afternoons than anything else in this article. Your panel has a DNS editor. That editor only matters if the domain's nameservers point at that panel.

If the nameservers point at Cloudflare, at your registrar or at a previous host, the records you add in hPanel or cPanel will look perfectly correct and will never be queried by anyone. Check the nameservers first, then edit the zone they point to. Everything below assumes you have done that.

Hostinger: hPanel, the DNS zone, and the automatic path

In hPanel, DNS records live under Domains, then the domain, then DNS Zone. That is where the MX, SPF, DKIM and DMARC records go.

Take the automatic path when it is available. If the domain uses Hostinger's nameservers, Hostinger's own guidance is to use the connect option on the domain page rather than typing records by hand, and the Hostinger Email domain settings screen publishes the MX, SPF, DKIM and DMARC set for you.

If you are adding them manually, two details decide whether it works.

SPF is a single TXT record on the root. The value Hostinger documents for Hostinger Email is:

Type  Name  Value
TXT   @     v=spf1 include:_spf.mail.hostinger.com ~all

If another platform also sends as your domain, you do not add a second record. You add its include to the one you have, keeping a single all mechanism at the end:

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

Two TXT records starting with v=spf1 on the same name is a hard failure, not a warning. Receivers get an ambiguous result and can reject the message.

DKIM for Hostinger Email is a CNAME, not a TXT record. This is the single most common Hostinger mistake we see. People know DKIM as a long TXT value from other providers, choose TXT out of habit, and signing quietly never works. Copy the host and target exactly as the panel shows them, and set the type to CNAME.

The website is also a sender

A WordPress contact form, a WooCommerce order confirmation or a booking plugin usually sends through the server's local mail function rather than your mailbox. That path is not necessarily covered by the include above, and it is why order confirmations land in spam while replies from a person do not. Make the site authenticate as a real mailbox: install an SMTP plugin and point it at your own mail account. Then one set of records covers everything.

cPanel: the Email Deliverability screen does most of the work

In cPanel, go to the Email section and open Email Deliverability. It lists every domain on the account with a status, and it beats editing the zone by hand because it generates the records for you.

cPanel creates a 2048-bit DKIM keypair, keeps the private half on the server where Exim signs with it, and publishes the public half as a TXT record at default._domainkey under your domain. The selector is default unless someone changed it.

Name   default._domainkey
Type   TXT
Value  v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

Next to each problem the interface shows a Repair button. Press it and cPanel writes the suggested records into the DNS zone itself, which the documentation notes can take a few minutes to complete depending on the server.

When Repair is greyed out

Repair only works when the system controls your DNS, which means the domain points at that server's nameservers. If your DNS lives at Cloudflare, at your registrar or anywhere else, cPanel can generate a correct record but cannot publish it, so the button is unavailable.

That is not a dead end. The screen still shows the suggested SPF and DKIM values. Copy them and create the records wherever the zone lives. One thing to watch: a 2048-bit DKIM public key is longer than the 255-character limit on a single TXT string, so paste it as one line with no added breaks. cPanel offers a full value and a split version for providers that need the string chunked. Pick the one your DNS host expects.

DMARC: the record that makes the other two mean something

SPF and DKIM produce results. DMARC is what tells receivers to compare those results against the domain in the From line your recipient sees, and what to do when they disagree. Without it, a passing SPF check on a completely different domain still counts as a pass, which is precisely the gap spoofing walks through.

Start in reporting mode. Add one TXT record:

Name   _dmarc
Type   TXT
Value  v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1

In hPanel the Name field takes _dmarc on its own, and the zone appends your domain. Pasting the full hostname creates a record one level too deep that nothing will ever read.

Leave it at p=none for two or three weeks and read what comes back. The aggregate reports are XML, so paste one into our DMARC analyzer rather than reading it by eye. Once the reports show every legitimate sender aligned, tighten the policy in steps. We wrote the full sequence in moving DMARC from p=none to p=reject, and skipping the reporting phase is how invoicing systems and the office scanner stop being delivered on a Monday morning.

The SPF lookup budget, which shared hosting burns through fast

RFC 7208 limits an SPF evaluation to ten DNS-querying terms. Every include, a, mx, redirect and exists counts, including the ones nested inside somebody else's include. Go over and the result is permerror, which most receivers treat as no SPF at all. The ip4, ip6 and all mechanisms cost nothing, and the same section caps void lookups at two.

A shared hosting domain gets there faster than people expect: the host's include, a mail provider's include, a CRM, a newsletter tool and an invoicing platform is already five, and each may expand into several more. The counting method and the four ways out are in SPF too many DNS lookups. Merging two records does not help, because the limit applies to the evaluation, not to the record.

What none of this fixes, and when to move the mail

Authentication makes your mail provably yours. It does not give you a clean sending IP. If your host's shared address is rate limited or filtered because of other tenants, you see it as intermittent delays and spam placement that no DNS change improves, and it shows up as IP reputation rather than domain reputation in Postmaster Tools.

The honest signals that shared hosting mail has stopped being the right tool:

Rejections that name the sending IP rather than your domain or your authentication.
No usable audit trail, no device control and no way to recover an account when someone leaves.
Delivery that changes week to week with nothing changing on your side.

At that point the fix is to separate mail from web hosting. Google Workspace is the route we take most, and the mechanics of moving without losing messages are in our migration guide. Keep the website where it is. Only the MX records and the authentication move.

Verify before you call it done

Panels report on themselves, which makes them the wrong place to confirm your own work. Three checks, in order.

Does the record resolve where you think? Query the exact hostname, selector included, and confirm there is exactly one v=spf1 TXT record on the root.
Is the provider side switched on? A published DKIM record signs nothing until the mail platform is actually signing. In cPanel that is Email Deliverability showing a valid state, not just a record in the zone.
Does a real message pass? Send one to an outside address, open the raw source and read the Authentication-Results header. Our header analyzer reads it for you, and it is the only check that tests the path your customers' mail actually takes.

Then give it time. DNS changes on either panel can take up to 24 hours to reach every resolver, so a failure five minutes after saving proves nothing yet.

How Guanacos Tech helps

We are an independent consultancy with Google-certified engineers, and email deliverability is the work we do most. Shared hosting cases are usually quick: the records are half right, one sender was never authorised, and the panel has been reporting success on a zone nobody queries. The useful first step is a diagnosis rather than a rewrite. Our troubleshooter and DMARC analyzer are free and will tell you most of it in a minute. If you would rather hand it over, see how we work or book a short call, and bring one bounce message with you.

SPF, DKIM and DMARC on Hostinger (hPanel) and cPanel: authenticating mail on shared hosting