Defaults.Exposed

Defaults.Exposed › Setup walkthroughs › DMARC › Hostinger

Add a DMARC record in Hostinger hPanel

hPanel’s DNS (Domain Name System) Zone editor will save this record whether or not the domain’s nameservers point at Hostinger. There is no warning, the row appears in the list, and nothing about the screen suggests a problem. So the nameserver check comes first, before anything is typed.

The DMARC record for Hostinger

v=DMARC1; p=none; rua=mailto:you@yourdomain.com

v=DMARC1 is the version tag and comes first. p=none is the policy. rua=mailto: is where aggregate reports arrive.

At p=none nothing is blocked. What the record does is start the reports, and the reports are the only thing that makes a stricter policy safe to publish later.

In the October 2026 census, 35,049,364 domains sitting at p=none, 80.17% of them, carry no rua= at all, so those records neither collect reports nor change how mail is handled.

Check that Hostinger answers DNS for the domain

In hPanel, open Domains, select the domain, and check the DNS / Nameservers section. If the nameservers point to Hostinger, the record you add here will take effect. If they point to another host, Cloudflare or the email provider, add the record at whichever provider runs DNS instead.

Hostinger is the DNS host here, the console you use to add a record to the domain’s DNS zone. It publishes exactly the TXT (Text) record typed into the Name and TXT value fields, and that record only counts if Hostinger also runs the domain’s nameservers. It does not add SPF (Sender Policy Framework) or DKIM (DomainKeys Identified Mail) records, generate a reporting address or choose a policy: you supply the full value and the mailbox.

Add the record in the Hostinger console

  1. Sign in to Hostinger and open hPanel.
  2. Go to Domains, select the domain, then open the DNS / Nameservers (DNS Zone) section.
  3. Find the area for adding a record, labelled Add Record or Manage DNS records.
  4. Set the type to TXT.
  5. In the Name field, enter exactly _dmarc and do not type the domain name after it, because Hostinger appends the domain itself.
  6. In the TXT value field, enter the record starting with v=DMARC1; p=none; rua=mailto:you@yourdomain.com, replacing the address with a mailbox that is read.
  7. Leave the TTL (Time to Live) field at its default value.
  8. Click Add Record to save the entry.

In the Name field enter only _dmarc, since Hostinger appends the domain automatically and typing _dmarc.yourdomain.com is the common mistake. In the TXT value field paste the plain string beginning v=DMARC1; with no surrounding quotation marks, since Hostinger handles the quoting itself.

Traps in the Hostinger form

Where to point the reporting address

Pick the rua= mailbox on purpose.

Aggregate reports arrive daily from every large receiver, as XML attachments, and they will fill an ordinary inbox quickly. A dedicated address such as dmarc@yourdomain.com keeps them out of the way of actual correspondence, and it survives the person who set this up leaving the company, which a personal address does not.

You can list more than one address by separating them with commas, which is how people send a copy to a reporting service and keep a copy themselves. If any of those addresses is on a domain you do not control, that domain has to publish a record authorising it: a TXT record at yourdomain.com._report._dmarc.theirdomain.com. Reporting services document exactly what to publish. An address on your own domain needs nothing extra.

There is also ruf=, for forensic reports on individual failing messages. Very few receivers send them, and those that do strip most of the content for privacy reasons, so it is rarely worth adding.

Alignment, the part that decides the result

DMARC asks whether SPF or DKIM passed for a domain that matches the domain in the From address a reader sees. That match is alignment, and it accounts for most of the confusing rows in a report.

The case that catches people: a mailing platform sends on your behalf, SPF passes because the envelope sender is the platform’s own domain and their record authorises their servers, and DMARC fails anyway because your domain is what appears in the From line. Nothing is broken; the two domains simply do not line up. Adding another include: to your SPF record does not fix it either, because the SPF check was never evaluating your domain in the first place.

The fix is DKIM. Ask the platform to sign with a key published on your domain, which most established senders support, and the signature then aligns with your From address and DMARC passes on that leg.

The same mechanism explains why forwarding survives. A forwarded message fails SPF, since the forwarding server was never on your list, and passes on DKIM because the signature travels with the message. DMARC needs only one of the two, so DKIM covers the gap SPF cannot.

Wait, then read the result

The change takes a few minutes up to a couple of hours to take effect. The saved entry appears in the DNS / Nameservers (DNS Zone) section of hPanel alongside the domain’s other records.

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

When the reports show your legitimate senders passing and aligned, move the policy to p=quarantine and then to p=reject. Receivers act on the record only at p=quarantine or p=reject. The DMARC guide covers the tags this page has not needed.

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.