Setting up DMARC at Hostinger — Step-by-Step Guide (2026)

Last updated: July 2026

In short: DMARC ties your SPF and DKIM checks together to establish definitive email protection. You set up your policy inside Hostinger hPanel under Domains in the DNS Zone by publishing a TXT record on the _dmarc subdomain.

Prerequisites

A domain managed in Hostinger hPanel with an active email service
Access to your Hostinger dashboard (https://hpanel.hostinger.com)
Functional SPF and DKIM records already deployed on your domain

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) dictates how receiving mail servers (such as Gmail, Outlook, or Yahoo) should handle messages that fail SPF or DKIM alignment checks.

As Hostinger highlights in their technical overview: It’s a DNS record (of TXT type) that helps protect email domains from phishing and spoofing attacks. Furthermore, support clearly notes that DMARC Informs recipients what to do if SPF or DKIM checks fail when receiving your emails

By setting the policy directive (p=) in your DMARC record, you control receiver enforcement:

p=none: Monitoring mode. Messages are delivered normally, and receiving servers send daily XML reports for auditing.
p=quarantine: Messages failing authentication are sent to the recipient’s spam or quarantine folder.
p=reject: Strict rejection of unauthenticated emails during the initial SMTP handshake.

The starting point at Hostinger

Configuration inside hPanel is quick and straightforward (It’s only two steps to create a DMARC record :).

Your policy is created as a TXT record attached to the technical subdomain _dmarc. For an initial deployment in observation mode, use:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Step-by-step guide

1. Check whether a DMARC policy already exists

Open your terminal to see if your domain is currently serving a DMARC record:

dig TXT _dmarc.example.com +short

If the returned string begins with v=DMARC1, a policy is active. If the output is empty, proceed with creating a new entry.

2. Open the DNS Zone in hPanel

3. Add the TXT record for _dmarc

Inside your DNS management table (It’s only two steps to create a DMARC record :), add a new entry with the following parameters:

Type: TXT
Name / Host: _dmarc

Value / Content:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

(Replace dmarc@example.com with the email address where you wish to receive daily XML diagnostic reports).

Save your new record.

4. Progressively tighten your policy

After analyzing daily XML reports for several weeks and confirming that all legitimate corporate sending services pass SPF and DKIM alignment, upgrade your policy from p=none to p=quarantine, and eventually to strict p=reject (It’s a DNS record (of TXT type) that helps protect email domains from phishing and spoofing attacks.).

The components of the DMARC record

Component	Meaning
`_dmarc`	Dedicated technical subdomain where receiving mail servers check for your DMARC policy
`v=DMARC1`	Protocol version tag (must strictly be the first element in the record string)
`p=none`	The enforcement directive (`none` for monitoring, `quarantine` for spam, `reject` for outright block)
`rua=mailto:...`	Target URI and email address where daily aggregated XML reports are delivered

Verification

After saving the record in Hostinger hPanel, immediately verify your configuration using the free MXAudit scanner — check your DMARC syntax and confirm exact domain alignment.

You can also use your terminal to confirm that nameservers are serving the updated policy:

dig TXT _dmarc.example.com +short

The output should match "v=DMARC1; p=none; rua=mailto:dmarc@example.com".

Common mistakes

Creating the record on root (@): If you place the TXT record on your root domain instead of the _dmarc subdomain, external mail servers will not discover your policy (Informs recipients what to do if SPF or DKIM checks fail when receiving your emails).
Leaving out the mailto: prefix: The rua= attribute requires the mailto: URI scheme right before your email address. Without it, report delivery fails silently.
Deploying p=reject immediately: Switching directly to strict rejection without an observation phase (p=none) risks blocking legitimate emails from third-party tools that haven’t been configured with proper DKIM or SPF alignment.