Hostpoint SPF, DKIM and DMARC setup, step by step

For email sent through Hostpoint’s own Cloud Office or web hosting mailboxes, use Hostpoint’s current SPF policy and activate DKIM under Domains → your domain → Enhanced protection. The standard SPF value is v=spf1 redirect=spf.mail.hostpoint.ch, with no all mechanism. If another company hosts your authoritative DNS, activate DKIM in Hostpoint first, then publish all three account-generated TXT records there. Finish by checking public DNS and a newly delivered message’s intended domain signature and DMARC result. Hostpoint SPF instructions · Hostpoint DKIM activation

This guide is based on public documentation, not access to a customer account. No DNS changes or live sending tests were performed.

In this guide

• Confirm the sending service and DNS owner
• Configure SPF without disabling the redirect
• Activate Hostpoint DKIM
• Keep DMARC policy and reporting safe
• Verify DNS and a real delivered message
• Troubleshoot Hostpoint authentication
• Frequently asked questions

Confirm the sending service and DNS owner

This procedure covers Hostpoint-operated mailbox sending for a domain associated with a web hosting or Cloud Office group. You need access to that domain in the Hostpoint Control Panel with your Hostpoint ID, plus permission to manage its authoritative DNS or coordinate with the person who can. Hostpoint documents automatic DKIM activation for newly assigned domains from May 2024 onward; older assignments may need manual activation. Check the current domain state rather than assuming the date of your mailbox proves DKIM is on. Activation prerequisites and automatic setup

Separate these other routes before editing anything:

• Hostpoint only registers the domain or hosts DNS: obtain SPF and DKIM instructions from the service that actually sends your mail. A Hostpoint registration does not make its mail servers your sender.
• Google Workspace, Microsoft 365 or another external SMTP service sends the message: authenticate that service independently. Retain its valid records if you also use Hostpoint mailboxes.
• A website sends through PHP or Sendmail: do not treat a successful mailbox test as proof that the website aligns. Hostpoint documents a default envelope sender of [username]@webuser.mail.hostpoint.ch, which can differ from your visible From domain. Its website-mail procedure addresses that separate route. Website sending and envelope sender
• Forwarded mail: a forwarding hop can change SPF evaluation. Test direct mailbox mail first, then examine forwarding separately.

Before making changes, save the existing DNS records and record the visible From domain, every legitimate sending service, the current SPF policy, active DKIM selectors, and any direct or inherited DMARC policy. Do not change name servers, MX records or DNSSEC just to add authentication records.

Match each record to its authoritative zone

The registrar and DNS host may be different companies. Identify the active name servers and check whether the sending subdomain has a separate delegation. Edit the zone that actually answers for the record, not an unused DNS panel.

For a mailbox using person@example.com, SPF normally belongs at example.com. A generated DKIM owner has the shape SELECTOR._domainkey.example.com, where SELECTOR must come from your account. These are illustrative names, not account values.

If a DNS editor automatically appends example.com, use the relative name SELECTOR._domainkey; if it expects a fully qualified name, use the whole supplied owner. At the zone apex, editors commonly use @ or a blank field. Follow your DNS host’s convention and check the final expanded name. For a separately delegated zone such as mail.example.com, a record for that zone’s apex uses its own @ or blank field, not mail again. Avoid publishing example.com.example.com by accident.

For an issued signing domain such as news.example.com, a full owner SELECTOR._domainkey.news.example.com is SELECTOR._domainkey.news relative to the parent example.com zone, or SELECTOR._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, the relative owner there is SELECTOR. Replace the selector placeholder with the issued value, preserve the account’s exact type and public value, and publish at the actual authority without removing the NS delegation. This example explains name placement, not automatic product eligibility for a new domain. DKIM owner construction, relative DNS names.

Configure SPF without disabling the redirect

Hostpoint is the only sender for this SPF identity

Hostpoint’s documented SPF TXT value is:

v=spf1 redirect=spf.mail.hostpoint.ch

For an illustrative mailbox domain example.com, publish it as one TXT record at example.com, only after confirming it is the intended SPF identity and no existing legitimate senders will be removed. SPF checks the SMTP envelope sender, normally shown as smtp.mailfrom in the receiver’s result, rather than the address readers see in the From line. If a route uses a different envelope domain, examine that domain’s policy instead of adding records blindly at the visible From domain. SPF identity and record placement, RFC 7208

Do not append ~all, -all or ?all to Hostpoint’s redirect policy. The all mechanism always matches, so a record containing it never reaches the redirect. Merely moving redirect= before all does not fix that. Hostpoint explicitly requires no all in its combined redirect form. Hostpoint combined-policy conditions · RFC 7208, all

When Hostpoint hosts the authoritative DNS

For a domain that needs the standard Hostpoint-only policy:

1. Sign in to the Hostpoint Control Panel with your Hostpoint ID.
2. Open Domains and choose Edit DNS zone for the domain.
3. Inspect existing TXT records first. If there is already a record beginning v=spf1, review and edit that policy instead of adding a second one.
4. For a genuinely missing Hostpoint-only policy, choose Add Hostpoint SPF record.
5. Review the proposed change, then choose Execute now.
6. Query the public record after the change. Hostpoint says its update takes about 5 to 10 minutes; previously cached records can remain until their TTL expires.

Hostpoint also says new registrations or transfers through its Control Panel receive an SPF record automatically. Inspect that record before adding anything. Official SPF workflow

If another provider hosts authoritative DNS, create or edit the TXT record there. A change in an inactive Hostpoint zone will not update the public answer.

Hostpoint and other services share the same SPF owner

Keep one SPF record per owner name. Do not concatenate two complete v=spf1 strings or replace a working multi-sender policy with the Hostpoint-only value. Other unrelated TXT records at that owner should remain intact. Single-record requirement

Hostpoint documents a combined policy in which other authorized mechanisms are evaluated before its redirect. Its Microsoft 365 example is:

v=spf1 include:spf.protection.outlook.com redirect=spf.mail.hostpoint.ch

This is appropriate only when those are the services you intend to authorize and their current policies fit your deployment. It is not a migration instruction or a universal replacement. Hostpoint’s required form has one redirect, at the end, and no all. If your existing policy ends in -all or redirects somewhere else, ask the DNS owner to redesign the whole policy with all sender dependencies preserved. Do not remove the terminator or an existing redirect without understanding the resulting authorization and failure behavior.

Check the fully expanded policy against SPF’s limit of 10 DNS-lookup-causing terms, including nested include and redirect evaluation. Counting only the mechanisms visible in your top-level string is insufficient. DNS errors and excessive void lookups can also break evaluation. Do not replace Hostpoint’s maintained policy with a snapshot of today’s IP addresses. SPF processing limits

Activate Hostpoint DKIM

Use the current domain-level controls

1. Sign in to the Hostpoint Control Panel.
2. Select Domains in the top menu and open the domain.
3. Open Enhanced protection.
4. Check whether DKIM is already enabled. If not, activate it for this domain.
5. Repeat only for other domains whose Hostpoint mailbox sending you also intend to configure.

You do not need to create an extra Cloud Office group merely to follow this DKIM procedure. Hostpoint’s current activation page uses the domain-level path above. Current DKIM activation instructions

Hostpoint DNS versus external DNS

When Hostpoint manages the authoritative zone, check the generated DNS records and enabled status there. When the domain uses external name servers, Hostpoint’s documented order is activate DKIM first, then copy the generated entries to the external DNS provider. The account screen shows Your DKIM records with the owner in the Domain column and its corresponding Value.

Hostpoint creates three DKIM TXT records by default, associated with RSA-1024, RSA-2048 and Ed25519 keys. Publish all records currently supplied for your domain, preserving each owner/value pairing. Do not copy a selector or public key from a screenshot or another customer. Hostpoint’s selectors contain account-generated information, including a date, key type and random component. Record structure and keys

For each generated entry:

• Select TXT, not CNAME.
• Use the exact owner, adjusted only for your DNS editor’s suffix handling.
• Copy the entire supplied TXT value, including the public-key data. Do not publish private keys or credentials.
• Preserve other services’ selectors. If the same owner already has conflicting data, establish which service owns it before replacing anything.
• Let the DNS editor handle long TXT strings according to its documented format. Several quoted strings within one TXT resource record can be normal; several different key records at the same selector are not a safe substitute.

These are TXT records, so there is no reason to change CNAME flattening or website proxy settings. If a record conflict appears, fix the specific owner with the DNS administrator rather than changing a shared zone’s general configuration.

For external DNS, future changes in Hostpoint’s DKIM screen must also be copied to the authoritative zone. Coordinate key changes so that active selectors and mail already in transit are not stranded. The three published records do not mean your acceptance test must find three passing signatures on every message. Inspect the signatures actually emitted and require a passing, aligned Hostpoint signature for your intended domain.

Keep DMARC policy and reporting safe

DMARC compares the visible From domain with a passing SPF envelope domain or a passing DKIM signing domain. Relaxed alignment permits an organizational-domain match; strict alignment requires an exact match. Check the effective aspf and adkim settings. Hostpoint’s SPF policy alone does not prove that either identity aligns on a particular message. DMARC alignment

Hostpoint documents automatic DMARC activation for domains assigned to a web hosting or Cloud Office group from August 2024, so do not assume this is a new policy. Its Enhanced protection screen also has a separate DMARC control; leave it unchanged while configuring DKIM unless you have reviewed the intended policy change. Hostpoint DMARC activation

First inspect the TXT record at _dmarc under the actual From domain. Also establish any applicable parent or organizational-domain policy before treating a subdomain as unprotected. Preserve existing enforcement, alignment settings, reporting destinations and subdomain policy. Do not overwrite p=quarantine or p=reject with p=none to make a setup test easier. If a policy exists but is malformed or duplicated, repair it with its owner rather than adding another record. DMARC policy discovery

Only if no direct or inherited policy applies, and the domain owner has chosen a first non-enforcing policy, the minimal starting record for the illustrative domain example.com is:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none

In an example.com zone that appends its suffix, the host field is _dmarc. For a From domain of mail.example.com, the full owner is _dmarc.mail.example.com: use _dmarc.mail in the parent zone or _dmarc in a separately delegated mail.example.com zone. Confirm the final expanded owner before saving.

This minimal record does not request reports. Add a rua destination only after selecting and approving a real reporting mailbox or service. When the reporting destination is outside the policy domain’s organizational domain, arrange the required destination-side DNS authorization; publishing an address in your policy alone is insufficient. Review report access, retention and privacy because reports can expose sending infrastructure and authentication metadata. Do not enable failure reports or send aggregate reports to a tutorial’s example address. Aggregate reporting and external destinations

Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.

Move to enforcement only after reviewing all legitimate routes and representative report evidence. One successful mailbox message does not establish that forms, invoices, marketing and forwarding all work.

Verify DNS and a real delivered message

Check public records

The following commands are illustrative. Replace the domain, authoritative server and selector with your own discovered values. Do not publish SELECTOR as a literal name.

dig NS example.com +short
dig @AUTHORITATIVE_NS example.com TXT +noall +answer
dig @AUTHORITATIVE_NS SELECTOR._domainkey.example.com TXT +noall +answer
dig @1.1.1.1 example.com TXT +noall +answer
dig @1.1.1.1 SELECTOR._domainkey.example.com TXT +noall +answer
dig @1.1.1.1 _dmarc.example.com TXT +noall +answer

For delegated subdomains, identify their actual authoritative zone rather than assuming the apex’s name servers answer for them. Repeat the DKIM lookup for all three generated owners. Check that:

• There is one SPF policy at the intended envelope domain, with the expected sender coverage and a functioning redirect.
• Each generated DKIM owner resolves to its correct complete TXT value.
• The expected DMARC policy is visible, with inheritance checked separately when needed.
• Authoritative answers and at least one public recursive resolver agree after caches expire.

A DNS record proves publication, not signing, alignment or delivery. Do not regenerate keys repeatedly while waiting for cache expiry.

Test the exact mailbox route

Send a fresh message from the intended Hostpoint mailbox through its actual outbound service to an independent mailbox you control. Hostpoint’s mail client settings specify asmtp.mail.hostpoint.ch, SMTP authentication enabled, and the full mailbox address as username. Use an encrypted connection, such as port 587 with STARTTLS or port 465 with TLS, and confirm the client has not selected an external SMTP account. Open the received original’s raw headers.

Trust only authentication results added by receiving infrastructure you control or trust. Attackers can prepend Authentication-Results fields. A matching authserv-id label by itself is not proof of provenance. If the receiver cannot distinguish or remove untrusted instances, use an independent trusted mailbox or receiver-side trace instead. Authentication-Results trust boundary

Before relying on those results, establish the actual receiving service’s known processing boundary using its documented diagnostics or the receiving administrator. Confirm its documented handling of externally supplied Authentication-Results: those fields must be removed, ignored or clearly distinguished from results generated inside that boundary. Ignore attacker-supplied and otherwise untrusted fields; a familiar service name or header position does not establish provenance. If that boundary cannot be established, use the trusted receiver-side trace or independently controlled receiving service described above. Receiver operational boundary.

Record these observations together:

1. Visible From: the domain users see.
2. SPF: result, smtp.mailfrom domain and sending IP. For a direct, correctly authorized route, expect spf=pass; then check its alignment separately.
3. Hostpoint DKIM: the signature’s d= signing domain and s= selector, correlated with that signature’s trusted dkim=pass result. The signing domain must align with the intended From domain.
4. DMARC: trusted dmarc=pass for the visible From domain under the effective policy.

If multiple signatures appear, map each result to its own domain and selector. A passing unrelated provider signature does not establish that your branded DKIM works. EmailAuth’s guide to finding the DKIM selector explains how to construct the correct lookup from the same signature’s d= and s= values.

Completion requires both the intended aligned DKIM pass and DMARC pass, not simply a green DNS lookup or a DMARC pass supplied only by SPF. Investigate independent SPF failures even when DKIM lets DMARC pass: fail can indicate an unauthorized route, temperror a temporary DNS problem, and permerror an invalid or over-budget policy. SPF that passes but does not align is a different condition from those failures.

Troubleshoot Hostpoint authentication

SPF fails after adding the standard record

Check for a second v=spf1 TXT record, an accidentally appended all, a truncated policy, a bad owner name, or a change in a non-authoritative zone. For a multi-sender setup, check nested lookup limits and whether each intended sender remains authorized. Do not add a new SPF record as a repair for an existing one.

DKIM is enabled but a receiver cannot find the key

Compare the received signature’s exact d= and s= with the public owner and the current Hostpoint screen. With external DNS, an enabled toggle does not publish the key for you. Look for a duplicated domain suffix, omitted entry, incomplete public key, stale selector or cached negative answer. Keep the original key evidence while diagnosing the mismatch.

A mailbox passes, but the website fails DMARC

Check the website’s envelope sender and signatures independently. The default webuser.mail.hostpoint.ch envelope is not aligned with an unrelated customer domain. Follow Hostpoint’s separate website-mail instructions for that application; do not assume mailbox DKIM activation makes every PHP or Sendmail message aligned. Do not weaken the whole domain’s DMARC policy to accommodate an unverified script.

Forwarded mail behaves differently

Hostpoint documents SRS rewriting for mail it forwards. SRS can address SPF authorization on the forwarding leg, but it does not guarantee alignment with the original From domain or preserve every DKIM signature. Inspect the forwarded message itself and check whether signed content changed. Do not authorize arbitrary forwarders in your domain’s SPF policy. Hostpoint forwarding and SRS

Authentication passes, but delivery is poor

SPF, DKIM and DMARC are not guarantees of inbox placement. Inspect the actual rejection response or spam result, sending reputation, content, volume and recipient expectations. Keep authentication failures separate from other filtering decisions.

If escalation is needed, give Hostpoint or your DNS administrator the affected domain, sending route, timestamp, current generated owner names, authoritative answers and trusted result lines. Redact message content and personal addresses where possible. Never send mailbox passwords or private keys.