Skip to main content

Stop Hostinger Emails Going to Spam: Configuring SPF, DKIM & DMARC

 The most critical vulnerability in modern web infrastructure isn't always a compromised database; often, it is the inability to communicate reliably with users. If you are hosting custom domain emails on Hostinger, you may have noticed a disturbing trend: transactional emails, invoices, and password resets landing directly in the recipient's Spam folder.

This is not bad luck. It is a failure of authentication.

Email providers like Google and Microsoft enforce strict reputation checks. If your domain cannot cryptographically prove it authorized a message, the email is treated as a spoofing attempt. To solve this on Hostinger, you must manually align three specific DNS protocols: SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting, and Conformance).

The Root Cause: Why SMTP is Inherently Insecure

To understand why your emails are blocked, you must understand the protocol they travel on. SMTP (Simple Mail Transfer Protocol), designed in 1982, has no built-in mechanism to verify the sender's identity.

In a standard SMTP transaction, a sender can claim to be admin@your-domain.com regardless of the actual originating server. This is how phishing attacks operate.

To combat this, receiving Mail Transfer Agents (MTAs) like Gmail perform a series of DNS lookups upon receiving a message:

  1. IP Verification: Is the IP address sending this email authorized by the domain owner? (SPF)
  2. Integrity Check: Has the message body or headers been tampered with in transit? (DKIM)
  3. Policy Enforcement: If checks 1 or 2 fail, what should the receiver do with the email? (DMARC)

Hostinger's default "One-Click" setup often configures basic MX records but may leave SPF in a "soft fail" state or omit DKIM entirely. Without these, your domain reputation allows for spoofing, leading Gmail to classify your actual emails as spam.

Step 1: Configuring SPF (Sender Policy Framework)

SPF prevents IP spoofing. It is a TXT record in your DNS zone that lists every IP address or service provider authorized to send email on your behalf.

The Auditing Process

Before applying changes, verify your current SPF record using the dig command in your terminal.

# Replace example.com with your actual domain
dig example.com TXT +short

You are looking for a string starting with v=spf1.

The Hostinger Configuration

If you are sending emails exclusively through Hostinger's webmail or SMTP servers, your record must include Hostinger's mail server include.

Correct SPF Record:

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

The Hybrid Configuration (Hostinger + Transactional Services)

A common pitfall is creating multiple SPF records. This is a protocol violation. If you have multiple SPF records, the lookup fails immediately.

If you send email via Hostinger and a third-party service (e.g., SendGrid, Mailchimp, or Google Workspace), you must merge them into a single record.

Example: Hostinger + Google Workspace:

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

Technical Breakdown:

  • v=spf1: Identifies the TXT record as SPF version 1.
  • include:: Authorizes the IPs listed in the referenced domain's SPF record.
  • ~all: SoftFail. This tells receivers, "If the IP isn't listed, accept it but mark it as suspicious." This is safer for testing than -all (HardFail).

Step 2: Implementing DKIM (DomainKeys Identified Mail)

While SPF verifies the server, DKIM verifies the message. It attaches a digital signature to the email header using public-key cryptography.

Hostinger manages the private key on their mail servers. You must publish the corresponding public key in your DNS records so receivers can verify the signature.

Retrieving the Selector

  1. Log in to hPanel.
  2. Navigate to Emails > Select your domain > DNS settings (or "DKIM").
  3. Identify the Selector. For Hostinger, this is typically default or s1.

Creating the Record

You will add a TXT record. The "Host" (or Name) follows the format selector._domainkey.

Host/Name:

default._domainkey

TXT Value (Example):

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv...

Note: The p= value is a long, base64 encoded string provided by Hostinger. Ensure you copy the entire string without whitespace breaks.

Step 3: Enforcing Policy with DMARC

SPF and DKIM are authentication mechanisms, but DMARC is the instruction manual for the receiver. It tells Gmail or Outlook what to do if an email claims to be from you but fails SPF or DKIM checks.

Without DMARC, a failed check might still result in the email being delivered. DMARC aligns the "Header From" domain with the "Envelope From" domain.

The DMARC Record

Create a new TXT record in your Hostinger DNS Zone.

Host/Name:

_dmarc

TXT Value (Recommended Initial Policy):

v=DMARC1; p=none; rua=mailto:admin@yourdomain.com; ruf=mailto:admin@yourdomain.com; sp=none; fo=1;

Configuration Deep Dive

  • v=DMARC1: Protocol version tag.
  • p=none: Monitoring Mode. This is crucial for the first 2-4 weeks. It tells receivers "Don't block anything yet, just tell me what's happening."
  • rua=: Reporting URI for Aggregate data. Gmail will send you daily XML reports summarizing which IPs are sending email as your domain.
  • fo=1: Generate a failure report if either SPF or DKIM fails (not necessarily both).

Progression Strategy: Once you review your reports and confirm only valid IPs are sending email, update the policy tag to protect your domain:

  1. Quarantine: p=quarantine (Send failed auth to Spam folder).
  2. Reject: p=reject (Bounce failed auth entirely).

Verification and Testing

After updating DNS records in Hostinger, propagation can take anywhere from 1 hour to 24 hours. Do not rely on sending an email to your personal Gmail to test this. You need header analysis.

Using dig for Final Verification

Verify your DMARC record exists:

dig _dmarc.yourdomain.com TXT +short

Analyzing Headers

Send a test email to a Gmail account. Open the email, click the three dots, and select "Show original".

You are looking for the "Authentication-Results" header. A successful configuration looks like this:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@yourdomain.com header.s=default header.b=...;
       spf=pass (google.com: domain of user@yourdomain.com designates 1.2.3.4 as permitted sender) smtp.mailfrom=user@yourdomain.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

If you see spf=softfail, dkim=fail, or dmarc=fail, the configuration is incorrect, or propagation is incomplete.

Common Pitfalls and Edge Cases

1. The CNAME Flattening Issue

Some DNS providers (like Cloudflare) offer CNAME flattening, but standard DNS requires SPF to be a TXT record. Ensure you are not trying to add SPF as a CNAME record pointing to Hostinger. It must be a TXT record containing the IP data.

2. Exceeding the 10-Lookup Limit

SPF records have a hard limit of 10 DNS lookups.

  • Bad: include:service1.com include:service2.com include:service3.com ...
  • If you include too many services, your SPF breaks, and all email is treated as spam.
  • Fix: Use an SPF flattening tool if you use extensive marketing services alongside Hostinger.

3. Subdomain Delegation

If you send email from support.yourdomain.com but your DMARC record is only on yourdomain.com, the sp (Subdomain Policy) tag controls the behavior.

  • If sp is missing, it defaults to the p policy.
  • If you want strict rejection on the main domain but lenient monitoring on subdomains, set p=reject; sp=none;.

Conclusion

Delivering email to the inbox is no longer about luck; it is about cryptographic proof. By configuring SPF to authorize Hostinger's IPs, DKIM to sign your messages, and DMARC to enforce policies, you establish domain authority.

This setup does not just prevent your emails from hitting the spam folder; it protects your brand identity from being used in phishing campaigns against your own clients. Monitor your DMARC reports, wait for propagation, and move to p=reject once your traffic is validated.

Labels: