How to Add SPF, DKIM, DMARC, and Return-Path Records in Hostinger

If you need to add SPF DKIM DMARC records in Hostinger, the DNS work itself is straightforward—but small hostname and record-value mistakes can prevent domain verification or leave your mail unauthenticated. This guide explains exactly where to manage DNS in Hostinger hPanel, how each record should look, and how to verify the finished setup safely.

What SPF, DKIM, DMARC, and a return-path record actually do

Email authentication is not one setting. It is a group of DNS-based controls that help receiving mail systems decide whether a message sent as you@example.com is legitimate.

Each control answers a different question:

• SPF says which servers or services may send mail using a particular envelope-sender domain.
• DKIM adds a cryptographic signature to an email, allowing recipients to verify that an authorized sender signed it and that relevant parts of the message were not altered after signing.
• DMARC tells receivers how to evaluate SPF and DKIM in relation to the visible From: domain, and what to do when alignment fails.
• A custom return-path puts the technical bounce address on a subdomain you control. Depending on the email provider, this may be set up with a CNAME alone or with a combination of CNAME, MX, and TXT records.

These records work together rather than replacing one another. SPF can pass while DMARC fails if the SPF-authenticated envelope domain is not aligned with the domain shown in the message’s visible From: address. DKIM can also satisfy DMARC when the DKIM signing domain aligns with the visible From: domain.

That distinction matters for transactional email. A password-reset message might visibly come from support@example.com, while its bounce address uses bounce.example.com. A properly configured return-path subdomain lets the sending platform handle bounces while retaining domain alignment where the provider supports it.

Do not treat the examples in this article as universal production values. Your email platform generates the authoritative selector names, targets, and SPF mechanisms for your account. Copy those provider-generated values exactly; use the examples here to understand where each piece goes in Hostinger.

Before editing Hostinger DNS, confirm where DNS is authoritative

Buying a domain from Hostinger does not always mean Hostinger is the active DNS provider. A domain can be registered at Hostinger while its nameservers point to Cloudflare, a website platform, another hosting company, or an enterprise DNS service.

That is the first thing to check because DNS changes must be made where the active nameservers are hosted. Creating a record in Hostinger while your domain is delegated elsewhere does not immediately publish that record to the internet.

Hostinger’s current documentation explains that you can still save records in hPanel even when external nameservers are in use, but those records do not take effect until the nameservers are pointed back to Hostinger. (hostinger.com)

The Hostinger navigation path, as of writing

Hostinger has more than one hPanel route depending on whether you have a hosting plan attached to the account. As of writing, use the route that matches your setup:

1. Domain-only account or registrar DNS management: sign in to hPanel, open Domains, select the domain, then open DNS / Nameservers.
2. Account with a web hosting plan: open Websites, select the relevant site, then go to Advanced and choose DNS Zone Editor.
3. In some current hPanel layouts, Hostinger also documents the shortcut Domains in the left sidebar, then DNS, followed by selecting the domain you want to edit.

The labels can move as hPanel changes, so look for either DNS / Nameservers or DNS Zone Editor after selecting the relevant domain or website. Hostinger documents the domain-only path as Domains → select your domain → DNS / Nameservers, and the hosting-plan path as Websites → select your site → Advanced → DNS Zone Editor. (hostinger.com)

Before adding anything, inspect the existing DNS zone. In particular, look for existing:

• SPF TXT records beginning with v=spf1
• DKIM records containing _domainkey
• A DMARC TXT record at _dmarc
• CNAME records for bounce, mail, sending, tracking, or provider-specific subdomains
• MX records for your regular inbox provider

Do not delete existing records merely because they look unfamiliar. Website, inbound email, and another sending service may rely on them.

The Hostinger DNS record shapes you need

Hostinger’s DNS form normally asks for a record type, a Name field, a record value field such as TXT value or Target, and a TTL. In this guide, “Host” means the same practical input as Hostinger’s Name field.

Assume your domain is example.com. The following table shows the normal record shape for email authentication.

The table deliberately includes alternatives. DKIM is not always a TXT record, and a custom return-path is not always a single CNAME. Your provider’s domain-verification screen is the source of truth for the exact records it requires.

For example, one provider may issue a TXT DKIM record named s1._domainkey, while another may issue three CNAME records with different selectors. One provider may have you add a CNAME at pm_bounces, while another may request a return-path subdomain with both MX and TXT records. The underlying purpose is similar; the DNS implementation is provider-specific.

Add SPF records in Hostinger without creating duplicate SPF policies

SPF is published as a TXT record. It starts with v=spf1 and ends in a mechanism that states what should happen when no authorization mechanism matches, commonly ~all during a cautious setup or -all for a stricter policy.

A simple illustrative SPF record might be:

v=spf1 include:spf.example-email-provider.com ~all

That is only an example. Do not replace your real provider’s value with it.

Use one SPF record per hostname

The most important SPF rule is that a hostname must not have multiple independent TXT records beginning with v=spf1. A recipient evaluating SPF can treat multiple SPF policies as a permanent error, which can undermine authentication.

If you send mail through more than one legitimate source, combine the authorizations into one record. For example, if your employee mail provider and transactional-email platform both send with the root envelope domain, the combined record may conceptually resemble this:

v=spf1 include:mailbox-provider.example include:transactional-provider.example ~all

Only merge mechanisms that your actual providers tell you to use. Do not guess include domains, IP ranges, or a and mx mechanisms.

Root-domain SPF versus sending-subdomain SPF

A common clean architecture is to send application mail from a dedicated subdomain such as notify.example.com or mail.example.com. In that case, the provider may ask you to publish SPF on that subdomain rather than at the root domain.

This can reduce the chance of modifying an SPF record used by employee mail. It also separates reputation and operational responsibility: marketing, product notifications, and corporate mail do not need to share every sending control.

If the provider’s record is for send.example.com, enter send in Hostinger’s Name field—not the complete send.example.com hostname unless the interface clearly shows it expects a full domain name. The same relative-hostname principle applies to _dmarc, DKIM selectors, and return-path labels.

Keep SPF within lookup limits

SPF has an important practical limit: evaluation can trigger no more than 10 DNS lookups. Each include, a, mx, exists, and redirect can contribute lookups, sometimes indirectly through another provider’s SPF policy.

This means “just add another include” eventually stops being safe. If your organization has accumulated many vendors, consider whether every vendor still sends with that exact envelope domain. Retire unused sending paths, use purpose-specific subdomains, or consult the provider’s support documentation before making the SPF policy longer.

Add DKIM records exactly as your sending provider generates them

DKIM uses a selector. The selector is the portion before ._domainkey, and it lets a domain publish multiple DKIM keys at once. A message header might show a signing domain such as example.com and a selector such as s1; the matching DNS name is then s1._domainkey.example.com.

Your sending provider will normally give you either a TXT record or a CNAME record.

DKIM TXT record example

For a provider-issued TXT record, the Hostinger form usually maps like this:

The p= value is a public key and may be very long. Paste it exactly. Do not insert extra spaces, omit characters, add quotation marks unless Hostinger displays and preserves them correctly, or substitute a key from another domain.

Hostinger supports TXT records through its DNS zone editor, while Hostinger’s own email documentation also notes that custom DKIM setups use generated values that you add as TXT records. (hostinger.com)

DKIM CNAME record example

Some services use CNAME-based DKIM to make key rotation easier. In that case, the form maps like this:

A CNAME hostname cannot coexist with other DNS record types at the same exact name. If s1._domainkey already has a TXT or CNAME record, do not add another record blindly. Determine whether it belongs to a former provider, an active mail service, or a previous DKIM selector that may still be used by mail in transit.

Multiple DKIM selectors are normal when each selector has a different hostname. For example, s1._domainkey and s2._domainkey can coexist because they are different DNS names.

Add a DMARC record carefully, starting with monitoring

DMARC is also a TXT record, but its name is standardized: _dmarc for the domain being protected. For example.com, recipients query _dmarc.example.com.

A sensible starting point is a monitoring policy such as:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100

This tells receivers to take no requested enforcement action yet, while sending aggregate reports to the rua address. It gives you time to discover legitimate sources that may not be correctly aligned.

What the core DMARC tags mean

• v=DMARC1 identifies the record as DMARC.
• p=none requests monitoring only.
• p=quarantine asks receivers to treat failing messages suspiciously, often by routing them to spam.
• p=reject asks receivers to reject failing, non-aligned messages.
• rua=mailto:... sets an address for aggregate XML reports.
• pct=100 applies the stated policy to all matching messages; it can be lowered during a phased rollout.
• adkim=s and aspf=s request strict DKIM and SPF alignment, respectively. Do not add strict alignment until you understand all legitimate sending paths.

Hostinger describes DMARC as a TXT record that helps domain owners specify authentication policy and receive reports about traffic using their domain. (hostinger.com)

Do not jump straight to reject

A DMARC policy of p=reject is valuable once every legitimate sender is authenticated and aligned. It is not a harmless checkbox, though. A missed source—an invoicing platform, support tool, CRM, help desk, forwarding workflow, or employee-mail system—can see legitimate mail rejected.

A measured rollout looks like this:

1. Publish p=none with a monitored rua mailbox.
2. Review reports long enough to cover normal business cycles, automated messages, and occasional sending systems.
3. Fix unauthorized or misaligned sources, and configure authentication for legitimate ones.
4. Move to p=quarantine, potentially with a lower pct value first.
5. Move to p=reject only when reports show the remaining failures are truly unwanted or understood.

Do not send DMARC reports to an unmonitored personal inbox. Aggregate reports can be frequent and machine-readable XML. Use a mailbox or reporting service intended for them.

Set up a custom return-path without confusing it with the visible From address

The return-path is the technical address used for bounces and certain delivery notifications. It is not normally the same as the visible From: address recipients see in their inbox.

For example, a message could look like this:

From: Acme Alerts <alerts@example.com>
Return-Path: bounce@send.example.com

The visible brand and reply identity can remain at example.com, while the bounce domain uses send.example.com. When configured properly, this arrangement can support SPF alignment and clearer separation between human-facing mail and delivery infrastructure.

What Hostinger needs from you

Open the sending provider’s domain setup page and copy the exact return-path record it provides. It may be one of these patterns:

• A CNAME from bounce, send, pm_bounces, or another provider-defined label to the provider’s destination hostname.
• An MX record on the return-path subdomain, plus a TXT SPF record at that same subdomain.
• A group of records that includes a return-path CNAME and separate DKIM records.

For CNAME-based custom return-path configuration, Postmark, for example, documents adding the hostname and value shown in its DNS settings; its default hostname is commonly pm_bounces and its target is pm.mtasv.net. (postmarkapp.com)

That is a provider-specific illustration, not a value to use for every platform. If your account supplies bounce and a different target, use your provider’s target—not Postmark’s.

Some platforms set SPF through the return-path arrangement itself. Others supply a separate SPF TXT record and MX record for a sending subdomain. Follow the exact verification records generated for your domain in your email platform. For Volanea-specific record values, use the email API setup documentation associated with your account rather than copying a generic DNS example.

The most common Hostinger mistake: entering a full hostname in the Name field

The most common Hostinger-specific mistake is entering the complete domain name in a relative Name field when Hostinger is already appending the zone’s root domain.

Suppose your domain is example.com and a provider tells you to create this record:

s1._domainkey.example.com

In the Hostinger Name field, you generally enter:

s1._domainkey

If you enter the full hostname in a form that appends the zone automatically, you can accidentally create a record equivalent to:

s1._domainkey.example.com.example.com

The same issue affects return-path CNAME names. If the required hostname is bounce.example.com, entering bounce is normally the appropriate relative Name value in the example.com DNS zone.

Resend’s Hostinger setup guidance explicitly warns users to omit their domain when pasting a record name: for a required send.example.com record, it instructs entering send or a relative subdomain label instead. (resend.com)

Do not make the opposite mistake with a CNAME target

The Name field and the Target field are different. The Name identifies the hostname inside your zone; the Target is the provider’s destination hostname.

For example:

Type:   CNAME
Name:   bounce
Target: bounce.provider.example

Do not turn the provider target into a relative label unless the provider explicitly says it belongs in your own zone. A target such as bounce.provider.example is usually an external fully qualified hostname and must match the provider’s value exactly.

If Hostinger’s interface normalizes the display after saving, that alone is not a problem. What matters is the DNS result: bounce.example.com must resolve as a CNAME to the provider-supplied hostname, not to an accidentally doubled name.

Save records safely and avoid DNS conflicts

Once you have copied the provider’s values, add records one at a time and inspect the DNS zone after each save. This reduces the chance of editing a similarly named record or overwriting an active configuration.

Use this operating checklist:

1. Copy each value directly from the sending platform’s domain setup screen.
2. Match the record type first: TXT, CNAME, or MX.
3. Enter only the relative host label in Hostinger’s Name field when managing the example.com zone.
4. Paste the TXT value or target exactly, without adding explanatory text.
5. Use the provider’s requested TTL; if none is provided, Hostinger’s default is usually acceptable for a standard setup.
6. Check whether a record already exists at that exact hostname before saving.
7. Never create a second SPF policy at the same hostname.
8. Do not replace inbound-mail MX records with return-path MX records.

A CNAME conflict deserves special attention. You cannot use a CNAME at a hostname that also needs a TXT, MX, A, or other conflicting record. This is why providers commonly use dedicated labels such as pm_bounces, send, or a unique DKIM selector rather than the root domain.

Do not create a return-path CNAME at @. A root-domain CNAME would conflict with other essential records and is not an appropriate design for an email bounce subdomain.

Verify DNS publication and provider status

Saving a record in Hostinger is only the first stage. DNS resolvers around the world must receive the new data, and the email provider must detect and validate it.

Hostinger states that DNS changes can take up to 24 hours to propagate globally. (hostinger.com) In practice, a change may appear sooner, but do not assume that a few minutes of waiting proves a record is wrong.

Verify from both directions

Use two checks:

1. The sending platform’s domain-verification page. It knows the exact record set it expects and can tell you which record fails.
2. A DNS lookup or email-authentication checker. Query the exact expected hostname, such as s1._domainkey.example.com, _dmarc.example.com, or bounce.example.com.

For a simple command-line check, use tools such as:

dig TXT example.com +short
dig TXT _dmarc.example.com +short
dig TXT s1._domainkey.example.com +short
dig CNAME bounce.example.com +short

The output should match the provider’s expected value. For DKIM TXT keys, tools may display the key in split quoted strings; that is often a normal DNS presentation of a long TXT value rather than evidence that the key is broken.

After verification, send a real test message to an inbox you control and inspect its authentication results. Look for results such as:

spf=pass
dkim=pass
dmarc=pass

A provider’s domain screen can verify that records exist, but a delivered message confirms the provider is actually signing with DKIM and using the expected return-path configuration.

Troubleshooting failed verification in Hostinger

When a provider says a record cannot be found, work through the issue in this order.

The record is in the wrong DNS provider

Check the domain’s authoritative nameservers. If they point away from Hostinger, add records at the active DNS provider instead. Records visible in hPanel may not be live when external nameservers control the domain.

The hostname was duplicated

Look for a name such as _dmarc.example.com.example.com or selector._domainkey.example.com.example.com. Correct it by deleting the malformed record and adding the relative Name value.

The value was modified

Compare every character against the sending provider’s generated record. Common problems include missing semicolons, line-break damage, altered DKIM public keys, an omitted period or label in a CNAME target, or copied smart quotation marks.

There are two SPF records

Search the DNS zone for every TXT record beginning with v=spf1. Consolidate legitimate sending sources into a single policy for that exact hostname. Do not simply delete a record before confirming which mail service it authorizes.

A CNAME conflicts with another record

If you are trying to add a CNAME and Hostinger rejects it, inspect whether the same hostname already has TXT, MX, A, or another CNAME data. Use the provider-specified dedicated hostname, not a root or previously used hostname.

You are expecting DMARC enforcement too early

A p=none DMARC record is working even though it does not ask receivers to quarantine or reject anything. Its purpose is observation. Check the record’s publication and inspect the reports before changing policy.

FAQ

How long do SPF, DKIM, DMARC, and return-path records take in Hostinger?

Hostinger says DNS changes can take up to 24 hours to propagate worldwide. Your email platform may verify sooner, but allow a full day before concluding a correctly entered record has failed. (hostinger.com)

Should I put my full domain in Hostinger’s Name field?

Usually no. For a domain zone such as example.com, enter relative names like _dmarc, s1._domainkey, or bounce. Entering the full hostname can lead to a duplicated domain suffix if the interface appends the zone automatically.

Can I have more than one DKIM record?

Yes. Multiple DKIM selectors can coexist because each uses a different hostname, such as s1._domainkey and s2._domainkey. You cannot, however, have conflicting record types at the same exact hostname.

Can I have more than one SPF record?

No. Publish one SPF TXT policy per hostname. If multiple legitimate services send mail for that hostname, merge their authorized mechanisms into one SPF record.

Do I need a custom return-path record?

Only if your sending provider requests or supports one. It can improve SPF alignment and bounce-domain control, but its exact DNS format varies by provider. Use the generated CNAME, MX, and TXT values from your platform rather than a generic example.