KlickTipp SPF, DKIM and DMARC setup, step by step

For KlickTipp Standard, Premium and Deluxe, publish the three CNAME records shown for your domain in the account, then use Refresh in the domain details to check them. You do not need an additional SPF TXT record for this shared-plan setup. Keep an existing DMARC policy; if none applies, establish one with the domain owner. Finally, inspect a received message to confirm that your intended From address is unchanged and your branded DKIM signature passes and aligns. KlickTipp's current sending-address guide

Enterprise customers using their own white-label mail server follow a separate server-specific branch. Do not apply a generic SPF include or copy another account's CNAME values into either route.

This is a documentary guide: no customer account, DNS change, account activation or live delivery test was performed while preparing it.

Choose the correct KlickTipp sending route

The route depends on the actual sending address and server configuration, not just the account's plan name. KlickTipp's current FAQ explicitly distinguishes white-label-domain addresses from other Enterprise sending addresses. Plan and address-domain distinctions

Use a domain your organization controls. KlickTipp does not accept freemail addresses such as Gmail or Outlook addresses as sending addresses in this workflow. Arrange a monitored mailbox or reply path appropriate for your campaign; creating DNS authentication does not create a mailbox.

You also need an authorized account user who can access the relevant domain settings and an administrator who can change authoritative DNS. The public guide does not specify a minimum permission role, so do not assume every account user can edit the settings. If the controls are absent, have the account owner resolve access and route applicability before asking the DNS administrator to make changes.

Add the sending address and domain in the current interface

Create the address using your own domain

In KlickTipp, open the settings gear > Email Delivery > Settings > Sender & System Addresses, then choose Add Email Address. Use the intended campaign address on your own domain. Record that address so you can compare it with the actual received From later.

Open the centralized domain settings

Go to the settings gear > Email Sending > Domains and DNS Records and choose Add Domain. The current English article also calls this location Email Settings > Domains and DNS Entries. In German the area is E-Mail-Versand > Domains und DNS-Einträge. Look for the domain overview rather than assuming an older account-menu screenshot matches your interface.

KlickTipp now allows full domains and subdomains to be added. Register the domain appropriate to the intended sending identity. If your From is newsletter@news.example.com, do not silently substitute the parent example.com and assume the same account records apply.

Open the domain's details to view the exact DNS records. Where the domain serves multiple purposes, use the purpose filter to distinguish sending/DKIM configuration from landing-page records. A landing-page hostname is not proof that your campaign sender is authenticated. Current domain-management workflow

Copy the values generated for this domain

For the shared-plan route, the FAQ identifies three CNAME records covering the required SPF/DKIM setup. The current public page does not establish universal selectors, owner names or targets. Copy the records displayed for your domain, including all required entries; do not reuse values from a video, another customer or a different email provider.

KlickTipp provides a formatted DNS-information email and a separate dialog for a hosting provider to see the required records without logging into the account. Use an approved administrator and share only what is needed for this change; a DNS handoff is not a reason to share the account password. Review any supplied DMARC recommendation separately from the CNAME records.

Publish all required CNAMEs safely

Start with a DNS export or a documented snapshot. Locate the authoritative DNS host, which may differ from the company where the domain was purchased. Preserve other senders' SPF, DKIM, MX and DMARC records.

For each account-issued CNAME:

1. Locate the correct zone. If the domain is delegated to separate nameservers, publish at that delegated zone's authoritative host. Do not remove the delegation.
2. Translate the owner correctly. If an issued full owner were issued-selector._domainkey.news.example.com, its relative name would be issued-selector._domainkey.news in the example.com zone, or issued-selector._domainkey in a delegated news.example.com zone. This illustrates name handling only; issued-selector is not a KlickTipp selector to publish.
3. Copy the exact target. Avoid doubled domain suffixes, missing underscores or transcription errors. Check whether the editor treats the target as a complete hostname.
4. Inspect existing data at the owner. A literal CNAME cannot coexist with ordinary A, AAAA, MX or TXT records at that same name. If an issued owner conflicts, stop that record change and ask KlickTipp for a supported solution. Do not delete another service's active selector or invent a new one locally.
5. Preserve literal CNAME answers. Do not replace the required aliases with copied public keys, static provider IP addresses, ALIAS/ANAME records or a guessed SPF TXT.

A zone apex also contains SOA and NS records, so it cannot simply become a literal CNAME. This applies to the apex of a delegated subdomain as well as the parent domain. If the supplied structure appears to require that, resolve the exact owner and supported arrangement with KlickTipp and the DNS administrator rather than flattening it by default. DNS alias rules

DNS-only and flattening controls

On Cloudflare, set these authentication aliases to DNS only. Also inspect both the per-record Flatten control and the zone-wide CNAME flattening for all CNAME records setting. DNS only can still be flattened, which can hide the literal CNAME required for verification.

Cloudflare documents that a zone-wide flatten-all setting cannot be overridden per record. If it is enabled, have the zone owner assess other services before changing it; a shared zone may have unrelated dependencies. Keep DNSSEC, existing nameservers and delegation intact. If the required aliases cannot be served safely, work with KlickTipp and the DNS host on a supported solution. Do not broadly change security settings to make one domain status green. Cloudflare flattening behavior and controls

Refresh the domain status in KlickTipp

After the records are publicly available, return to the domain details and select Refresh. The current workflow updates the individual DNS-entry statuses and shows the last refresh time. KlickTipp limits how often checks can run, and the button is disabled while a check is in progress. Wait for the current check to finish instead of repeatedly clicking or recreating the domain. DNS checking and refresh

If an entry is not recognized, compare its full owner, type and target with the account-issued values, then check authoritative DNS and resolver caching. Use the next permitted Refresh after resolving the discrepancy. The reviewed current guide does not document a separate universal activation switch beyond this domain-validation process.

Select the correctly configured sending address for the campaign or workflow you intend to use. A verified domain overview does not prove that an existing automation has switched from a different sender. Keep the account status, DNS evidence and actual message evidence together.

Why the current shared setup needs no extra SPF TXT

KlickTipp's explicit current FAQ says Standard, Premium and Deluxe do not need a separately added SPF entry, because the three CNAME records cover it. Do not create another v=spf1 record or add a root-domain include merely to satisfy a generic checker. Shared-plan SPF statement

An older, still-accessible KlickTipp SPF-definition article, describes include:spf.strold.io and an older account workflow. Its undifferentiated instructions do not establish a requirement for the current three-CNAME shared-plan route. Do not combine the two procedures or add the older article's a and mx mechanisms without a documented need.

If your existing account specifically shows a different configuration, ask KlickTipp to identify the sending route and exact SPF owner before changing it. Do not remove an existing include blindly either: it may still support a different legitimate path. The safe decision comes from the active configuration and actual envelope, not the age of a page alone.

Check the envelope, not just the visible From

SPF evaluates the SMTP MAIL FROM domain, usually exposed by the receiving system as smtp.mailfrom and reflected in Return-Path. It does not authenticate the visible From by itself. A null reverse-path uses the HELO identity. The reviewed shared-plan documentation does not establish a fixed envelope-domain string or a universal custom-return-path control. Inspect a real received message rather than inferring the envelope from a CNAME target or tracking link. SPF identities

A provider envelope may pass SPF without aligning with your brand. Under relaxed DMARC alignment, the authenticated domain and visible From must share the same Organizational Domain. Strict alignment requires an exact match. For example, bounce.example.com can align with example.com in relaxed mode but not in strict mode. These are illustrative domains, not a promise about KlickTipp's shared envelope. DMARC alignment

Retain the SPF lookup limit and fault ownership

At the actual evaluated owner, SPF must not exceed 10 DNS-querying terms across the evaluation, including nested includes and redirects. include, a, mx, ptr, exists and redirect count toward that limit; it is not a simple limit of 10 visible includes. Exceeding it returns permerror. Publishing multiple SPF policies at the same owner can also produce permerror. SPF DNS limits

The DNS administrator owns your aliases and any customer-managed policy. KlickTipp owns its provider-managed targets and sending configuration. For a failure, preserve the envelope domain, sending IP, receiver result and complete DNS chain so the correct party can diagnose it. fail, temperror and permerror remain faults to investigate even when aligned DKIM makes DMARC pass.

Keep DMARC policy separate from domain activation

Before adding a DMARC record, establish what already applies to the intended From domain. Query _dmarc.example.com for a From at example.com. For a From at news.example.com, inspect _dmarc.news.example.com and applicable parent policy inheritance. An empty exact-name response is not enough to conclude that the subdomain has no policy. Current DMARC policy discovery can involve a DNS tree walk. DMARC policy discovery

Preserve existing p, alignment settings, reporting destinations and subdomain-policy decisions. Do not create a second record, replace an enforcing policy with p=none, or add a weaker local policy to bypass inherited protection. The provider's instruction to configure DMARC does not mean an existing valid policy must be replaced.

If no direct or inherited policy applies

Have the domain owner approve the intended scope and the DNS administrator publish one first policy. A minimal observation policy for a From domain of example.com is:

_dmarc.example.com. IN TXT "v=DMARC1; p=none"

The relative name is _dmarc in the example.com zone. A policy specifically approved for news.example.com instead belongs at _dmarc.news.example.com, entered as _dmarc.news in the parent zone or _dmarc in a delegated news.example.com zone. Do not create this subdomain policy if it would override an existing inherited decision without the policy owner's approval.

This example requests neither enforcement nor reports. Add rua only when an approved collection mailbox or report service is ready. Reports can disclose domains, sending IPs, volumes and authentication results, so review the destination, access and retention. When the report destination is outside the policy domain's Organizational Domain, the report consumer must publish external authorization, commonly TXT at <policy-domain>._report._dmarc.<destination-host> with v=DMARC1, or its supported wildcard equivalent. Follow the consumer's issued setup; do not use an arbitrary example mailbox. External report authorization

A later move to quarantine or reject should follow evidence across all legitimate senders using the policy, not just a successful KlickTipp message. Never lower an existing policy merely to follow this first-policy example.

Enterprise white-label servers: use the separate setup

For an Enterprise own-server route, KlickTipp's FAQ says an SPF entry is needed for a subdomain and may already have been installed during server setup. Its Enterprise offering includes SPF, DKIM and DMARC configuration, a white-label return-path and a tracking subdomain. Those features do not establish universal DNS values for every Enterprise account. Enterprise service scope

The Enterprise setup article describes My account > Settings > Domains, adding the domain, and Configure Mail Server to open the setup form. It offers self-configuration for administrators who know the requirements, or provider-assisted setup. Use the actual form and support-issued values for your server; menu wording may differ from the current shared-domain overview. Enterprise domain and mail-server setup

Before changing an Enterprise record, confirm:

• Which domain the white-label server is configured to send for.
• Which existing SPF owner and DKIM selectors were installed for that server.
• Whether this campaign's From address matches that configured domain.
• Who completes provisioning and how to verify the server is active.
• The actual envelope, intended signature and DMARC result on a received message.

Addresses on the configured white-label domain already have DKIM according to KlickTipp's FAQ. Addresses outside it follow shared sending rules. Do not install the shared recipe over a working server or assume that buying Enterprise alone changes every message route.

Verify DNS and the intended identity on a received message

Check public records independently of the account badge

Use dig or a DNS lookup tool. Replace the uppercase placeholders below with the full record owners and target shown in your account; they are not records to publish.

dig CNAME EXACT_CNAME_OWNER_FROM_KLICKTIPP +noall +answer
dig TXT EXACT_DKIM_OWNER_FROM_KLICKTIPP +noall +answer
dig TXT DKIM_TARGET_FROM_KLICKTIPP +noall +answer
dig TXT ACTUAL_MAIL_FROM_DOMAIN +noall +answer
dig TXT _dmarc.example.com +noall +answer

Repeat the CNAME query for all three shared-plan entries. The public CNAME answers should match the issued targets. The DKIM chain should lead to usable public-key material. Inspect SPF at the envelope domain observed in a real message, following its DNS chain, rather than assuming every CNAME has the same purpose. Change the final DMARC query to your actual From domain and check inheritance as needed.

If answers differ, compare the authoritative nameserver with your recursive resolver and record the TTL and lookup time. NXDOMAIN, empty answers, SERVFAIL and timeouts require different investigation. Caching can delay a correct change; it cannot fix a typo, a CNAME collision or a missing record in a delegated zone.

Use trusted receiving evidence

An authorized operator should send a controlled message from the actual campaign or automation to a trusted mailbox after DNS validation. Preserve the original message, not just a screenshot of the inbox badge.

Read authentication results generated by receiving infrastructure you control or trust. A sender can prepend a forged Authentication-Results header; a matching authserv-id string alone is insufficient. If your receiver cannot distinguish or remove untrusted fields, use an independent trusted mailbox or receiving trace. Authentication-results trust boundary

Use this acceptance checklist:

If strict DKIM alignment is required, d= must equal the visible From domain. A passing signature on a related subdomain only supplies relaxed alignment. A provider-domain signature that does not align cannot substitute for the branded signature this setup is meant to establish.

With several signatures, pair each d= with its own s= and trusted verification result. EmailAuth's guide to finding the DKIM selector from the actual message walks through that evidence chain. A green DNS status or a generic DMARC pass alone is not the acceptance test.

Watch for KlickTipp's From-rewriting fallback

KlickTipp documents two behaviors that make identity checks especially important:

• Previously created addresses without activated DKIM may continue over shared IPs with a Without DKIM Signature and limited-deliverability warning.
• If DKIM was active but its DNS becomes incorrect, KlickTipp can adjust the sending address to maintain DKIM functionality. The resulting address can be provider-controlled even though the familiar original address appears in the display name.

Therefore, a DMARC pass for a rewritten provider From does not validate your intended branded sender. Read the actual mailbox address inside the From header, not just the display name. Restore the issued DNS configuration, Refresh, and retest until the intended address is unchanged and its branded signature passes and aligns. Documented fallback behavior

Troubleshooting by symptom