Kreativmedia SPF, DKIM and DMARC setup, step by step

For KreativMedia Webhosting, the documented SPF authorization is include:_spf.kreativmedia.ch. Reseller Hosting uses include:_spf.ch-dns.net instead. For mail hosted in Plesk, enable DKIM-Spamschutz verwenden in the selected domain's email settings and confirm with OK. KreativMedia says this publishes the public key automatically and signs authenticated outgoing mail. Its automatic procedure requires the active DNS zone to be on the KreativMedia hosting service. Verify both public DNS and a newly delivered message before treating the setup as working. KreativMedia SPF instructions, DKIM instructions.

This guide is a documentary review, not a test of a customer account, DNS zone or delivered message.

On this page

• Confirm your product and sending route
• Prepare and publish SPF
• Enable DKIM in Plesk
• Publish DMARC at the correct owner
• Run DNS and delivered-message checks
• Troubleshoot without disrupting other services
• Frequently asked questions

Confirm your product and sending route

This procedure covers the documented Plesk-hosted mail route, with separate SPF mechanisms for Webhosting and Reseller Hosting. Do not apply it automatically to Office Mail/kmSuite, Business Mail, SMTP-Relay, a third-party mail platform or a self-managed server. KreativMedia sells multiple mail products; a domain registration or website subscription does not identify which service sends a particular message. KreativMedia product and support navigation.

Before editing, identify:

• The purchased hosting product and the domain selected in Plesk.
• Who operates the outbound mail service, and whether the application submits using authenticated mail.
• Who publishes the authoritative DNS zone. A local copy in Plesk is not necessarily the zone receivers query.
• The intended visible From address, current envelope sender and current DKIM signing domain, if known.
• Other legitimate senders using the same domain, including marketing, billing and website forms.
• The person authorized to change DNS, plus a record-level backup and recovery plan.

Treat mailbox clients and website scripts as separate routes until evidence shows otherwise. A working website and a working Plesk mailbox do not prove that a contact form submits through the mailbox server. For WordPress, first identify the actual SMTP or API sending service.

KreativMedia explicitly requires its active hosting DNS zone for the documented automatic DKIM procedure. If your authoritative DNS is external, ask its support team for the supported method for your account before assuming automatic publication will reach the internet. Do not switch nameservers as a shortcut: that can affect websites, incoming mail and unrelated services. KreativMedia's DNS prerequisite.

Prepare and publish SPF

Choose the mechanism for the actual product

The provider's complete baseline examples are:

Webhosting:
v=spf1 include:_spf.kreativmedia.ch +mx +a -all

Reseller Hosting:
v=spf1 include:_spf.ch-dns.net +mx +a -all

These are documented examples, not replacements for your existing policy. The a and mx mechanisms authorize addresses associated with those DNS records; retain them only when that authorization matches your intended senders. The explicit + means pass and is the default qualifier. Do not copy the provider's illustrative IP address or another organization's include into production. Official SPF examples.

Merge rather than add a second policy

SPF checks the SMTP MAIL FROM domain, normally reflected in a delivered message's Return-Path. It does not directly check the visible From address. For an empty envelope sender, SPF uses the HELO identity. Publish the policy at the identity actually being evaluated, and do not assume an apex SPF record is inherited by a sending subdomain. RFC 7208.

Read the existing authoritative TXT records. If one SPF policy exists, edit that policy to incorporate the necessary authorization while preserving active senders. Keep one v=spf1 record per owner, not one per vendor. Unrelated TXT records can stay. Multiple quoted character strings within a single TXT resource record are not multiple SPF policies.

Review the whole evaluation path. SPF permits at most ten evaluated DNS-querying terms across include, a, mx, ptr, exists and redirect, including nested evaluation. ip4, ip6 and all do not consume that term budget. There are additional per-mechanism limits and a recommended limit of two void lookups. Ten visible includes is not a safe shortcut for this calculation. Exceeding the limit produces permerror; an aligned DKIM pass does not repair that SPF error. RFC 7208, DNS lookup limits.

If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.

Do not change an established -all to ~all, or the reverse, merely because a sample uses it. The final qualifier should remain an intentional decision after the sender inventory is checked.

Save the change in the authoritative zone

When Plesk hosts the active zone:

1. Sign in to Plesk and open DNS Einstellungen for the domain.
2. Select the existing SPF TXT record to edit it. Use Eintrag hinzufügen only when there is no SPF record at the intended owner.
3. Choose TXT where needed and enter the reviewed value.
4. Confirm with OK, then click Aktualisieren in the yellow confirmation box. KreativMedia says DNS changes require this additional update confirmation.
5. Reopen the record and verify the complete owner and value through DNS, not only the editor.

For an apex record in the example.com zone, the final owner must be example.com. Use the editor's apex convention, often blank or @, rather than guessing. Avoid accidentally publishing example.com.example.com. KreativMedia DNS editing procedure.

Enable DKIM in Plesk

For the documented hosted-mail route:

1. Sign in to Plesk.
2. Open Websites & Domains.
3. Select the sending domain and open its email settings.
4. Enable DKIM-Spamschutz verwenden and confirm with OK.
5. Inspect the resulting public-key record in the domain's DNS zone and retain its exact owner, record type and complete public value.

KreativMedia says the checkbox activates signing and creates the DNS public-key entry automatically. Its stated coverage is authenticated outgoing messages. A script using another server or an unauthenticated local route is not proved covered by that checkbox. Official DKIM activation.

Do not invent a universal selector or reuse a public key from an example. The real selector and signing domain determine the lookup name:

SELECTOR._domainkey.SIGNING-DOMAIN

This is a placeholder shape, not a record to publish. A real signature carries the selector in s= and the signing domain in d=. Only public-key data belongs in DNS; private keys remain in the signing system. If account-specific instructions provide a CNAME, its value must be a hostname, not k=rsa; p=... text. Do not add a TXT record alongside a CNAME at the same owner. DKIM key discovery, RFC 6376.

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.

Only if the mail service supplies an account-specific CNAME for a supported route, apply these alias checks; they do not change the documented native public-key publication method. For authentication records that actually use CNAME, retain a literal CNAME answer to the issued target and use DNS-only rather than HTTP proxying. Turn the relevant per-record Flatten setting off where available, and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are DNS-host behaviors, not assumed controls in the sending application. If mandatory behavior or shared settings cannot preserve the required CNAME answer, stop and coordinate a supported layout without breaking other services or removing shared NS delegations. Do not blindly disable features across the whole zone. Cloudflare verification guidance, flattening controls and limits.

For an external mail service, KreativMedia's guide says to obtain the public key from that mail service and add it to DNS. Plesk publishing another service's public record does not enable that other service to sign; complete its own activation procedure. For external DNS with KreativMedia-hosted mail, retain the documented prerequisite and obtain the supported account-specific publication steps rather than assuming generic Plesk instructions override it.

Publish DMARC at the correct owner

DMARC passes when SPF passes and aligns, or DKIM passes and aligns, with the visible From domain. It does not require both. Relaxed alignment permits the same organizational domain; strict alignment requires an exact domain match. The aspf and adkim tags control the two modes, with relaxed as the default. Current DMARC standard, RFC 9989.

For example, a verified signature using d=example.com aligns with From: team@example.com under either mode. A verified signature using d=mail.example.com can align with that From domain under relaxed alignment, but not strict. A provider-owned signing domain unrelated to example.com does not become aligned merely because DKIM passes.

KreativMedia says newly created domains receive p=none. Inspect the live policy before doing anything: existing domains may already have an intentional enforcement policy. p=none does not disable DMARC; it requests no DMARC-specific enforcement. Do not move straight to quarantine simply because DKIM was enabled, and do not downgrade an existing policy to follow a starter example. Provider defaults, RFC 9989 deployment guidance.

If there is no existing applicable policy and a monitored rollout is appropriate, the following is an illustrative starting record. Replace the report mailbox with one you control and have authorized for these reports:

Final DNS owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

In a DNS editor for the example.com zone, the relative Host is _dmarc, not @. For a separate policy on news.example.com in that same zone, use _dmarc.news, resulting in _dmarc.news.example.com. If editing a separately delegated news.example.com zone, use _dmarc. Check inherited policy before adding an explicit child policy. Keep one DMARC record at each policy owner and include a valid p tag; do not copy a reporting-only string missing policy.

Aggregate reports expose sending-source information. Use an approved mailbox or reporting service with appropriate access controls; an external reporting destination may need DNS authorization from that destination's operator. Do not insert an arbitrary third-party reporting address. Message-specific failure reporting is outside this starter setup. RFC 9989 supersedes RFC 7489 and removes pct; do not rely on percentage-based enforcement promises. Aggregate reporting and external authorization, RFC 9990, RFC 9989.

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.

Run DNS and delivered-message checks

Check publication

The commands below are reader-run examples. Replace every uppercase placeholder with the actual value. AUTH_NS is an authoritative nameserver for the queried owner; delegated subdomains can have different authoritative servers.

dig NS example.com
dig @AUTH_NS TXT MAIL_FROM_DOMAIN
dig @AUTH_NS TXT SELECTOR._domainkey.SIGNING_DOMAIN
dig @AUTH_NS TXT _dmarc.example.com
dig TXT MAIL_FROM_DOMAIN
dig TXT SELECTOR._domainkey.SIGNING_DOMAIN
dig TXT _dmarc.example.com

Expect the reviewed single SPF policy at the actual envelope domain, the generated public DKIM value at the exact selector owner, and the intended single DMARC policy. If a supported setup uses a DKIM CNAME, inspect that CNAME and confirm its target resolves to the expected public key. Do not substitute a TXT value for a CNAME target.

Inspect response status as well as answers: NXDOMAIN, no TXT data, SERVFAIL and a timeout are different conditions. A DNS error is not proof that a record is absent. KreativMedia allows several hours, up to 24, for propagation; compare authoritative answers with cached public-resolver answers and their TTLs rather than relying solely on elapsed time. DNS editing and propagation guidance.

Check the actual message

Send a harmless message, through an authorized test process, from the configured mailbox to a controlled external recipient. Repeat for each website form, scheduled job and distinct relay. Inspect the original message in the receiving system, using the Authentication-Results added by the receiver you trust, not a sender-supplied header. RFC 8601 trust boundary.

Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.

Record the workflow, UTC time, visible From domain, receiver-reported smtp.mailfrom, SPF result, every DKIM d= and s= pair, DKIM result, and DMARC result with its header.from domain. Retain sensitive message details privately.

Accept the intended custom-DKIM configuration only when the receiver reports DKIM pass for the intended branded signing domain and that domain aligns with From. A DMARC pass supplied solely by SPF does not demonstrate that DKIM setup succeeded. Separately require SPF to behave correctly for its actual envelope identity, and explain any unaligned provider-controlled envelope rather than editing the wrong domain. Confirm the expected DMARC pass and then review aggregate reports over representative business activity, not just one sample.

Troubleshoot without disrupting other services

If a change causes trouble, retain before-and-after records and isolate the affected route. Restore only the specific changed record or setting after confirming it is the cause. Preserve unrelated changes, working senders, existing enforcement policy and public keys needed by messages still in transit. Do not disable domain-wide DMARC to mask a Plesk signing issue.