Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Confirm the Hostinger email product
Treat Hostinger Email, called Hostinger Mail in the current manual setup article, as the scope of this guide. Confirm the service shown beside the domain before editing DNS. Do not transplant these records to Titan Email, Google Workspace or Hostinger Reach merely because those products appear in the same account. Record the mailbox domain, DNS owner, existing authentication and each application that uses the address. A website hosted at Hostinger can still send through a different email service.
The manual workflow directs administrators to Emails > Mailboxes beside the domain > Domain settings. Publish records at the actual DNS provider and return to check status. The documented SPF authorization is include:_spf.mail.hostinger.com. The default signing configuration uses three CNAME owners: hostingermail-a._domainkey, hostingermail-b._domainkey and hostingermail-c._domainkey, each pointing to the matching hostingermail-a, -b or -c.dkim.mail.hostinger.com target. Use the current account display as the final source of values. Manual domain setup
Prepare records without losing other senders
Make a change worksheet before publication. Record each full owner name, record type, destination, existing data and intended purpose. Expand relative names using the domain once, not twice. Where a CNAME owner already contains a TXT record, determine the existing signer and migration plan before replacing it. Preserve unrelated selectors used by other services.
Reconcile the Hostinger authorization into one SPF policy at the appropriate owner. The provider’s complete example is not automatically suitable for a domain with other senders or a different established enforcement decision. Evaluate nested DNS lookups rather than counting only visible includes. Preserve the current DMARC policy and approved report recipients; the sample reporting address is not a provisioned mailbox. Sending reputation and mailbox routing remain separate concerns, so avoid changing MX solely to fix an outbound signature.
Choose custom DKIM deliberately
Hostinger also documents Emails > Mailboxes > Custom DKIM > Generate, followed by a generated TXT record and verification. It says removing custom DKIM returns messages to the default signing record. The page contains a broad instruction to delete existing DKIM records if Generate is unavailable, but also says custom and default records can coexist. Do not interpret this as permission to remove every signer in the zone. Ask support which Hostinger record is blocking the operation and preserve other services. Custom DKIM workflow
Treat this choice as a managed signing change. Document why the default configuration is insufficient, what selector the account intends to use and how the previous valid configuration will be restored. Publishing a key does not by itself prove that outgoing messages are signed with it. Avoid switching between default and custom options while troubleshooting an unrelated SMTP login or delivery problem.
Test the active configuration
Original acceptance plan: send synthetic messages from Hostinger webmail and from the mail client normally used by staff. If an application submits through this mailbox, test its actual route separately. Capture the receiving system’s trusted SPF, DKIM and DMARC results, visible From domain, envelope sender, DKIM d= and s= values, and the time of the test. Match the active selector to the correct DNS owner instead of checking a familiar selector name by habit.
Illustrative failure: default CNAMEs are present but a message carries a custom selector. Investigate whether custom DKIM is active and whether that selector’s TXT key is publicly available. Adding a duplicate SPF policy cannot repair that mismatch. If the DKIM signature passes but uses an unrelated domain, check alignment before declaring the sender ready for DMARC enforcement.
Close with a recovery path
Wait for relevant DNS caches to refresh, but first establish that authoritative answers are correct. Keep a before-and-after record and change only one layer at a time. When reverting custom signing, verify the restored default route with another received message; do not assume fallback is proven by removing a setting. Repeat the route tests after a nameserver move or email-product change.
Documentation was reviewed on 8 November 2026. No Hostinger tenant, public customer zone or delivered message was tested. The test plan and failure scenario are proposed checks, not observed outcomes.
Hostinger signing-mode acceptance worksheet
This is a proposed evidence sheet, not a completed test. Leave unobserved results pending.
- Account, exact mail product, mailbox and application owner: ____.
- Authoritative DNS provider and preserved before-change answers: ____.
- Active signer mode, signing domain, selector and issued public record: ____.
- SPF envelope domain, single merged policy and evaluated-term assessment: ____.
- Public owner/type/value, query timestamp and resolver: ____.
- Received message, actual From, envelope, DKIM results and trusted DMARC result: ____.
- Separate website/client cases, rollback trigger and approving owner: ____.
Publication remains subject to live evidence, visual inspection and human SME/owner approval. No worksheet row is prefilled with a pass.