Active24 SPF, DKIM and DMARC setup, step by step

For Active24 Czech email on the current Webadmin platform, the documented SPF policy is v=spf1 a mx include:_spf.websupport.cz ?all. DKIM is enabled by default at domain level and uses a provider-issued TXT record at mail._domainkey. Check the domain’s signing setting, publish the complete record issued for that domain if it is missing, then verify an externally received message. Do not copy a screenshot’s public key or replace an existing multi-sender SPF policy. Active24 authentication instructions.

This guide covers an existing custom-domain mailbox on Active24’s new Webadmin/Websupport platform, with authoritative DNS currently managed by Active24. It is not a migration guide. It does not cover the old Active24 platform, a domain that only historically used Active24 DNS, independent SMTP services, forwarding-only aliases, PHP mail, VPS or self-managed mail servers.

No customer account, DNS change or live message test was performed.

Confirm the platform and the mail route first

Active24’s migration documentation says the new settings apply only after the account’s migration is complete, with completion notified by email. A familiar Active24 logo does not identify the underlying platform. Confirm that the domain is in the current Webadmin and use the mailbox’s current outgoing-server details there. The authentication article describes smtp.websupport.cz; use the settings actually assigned to your mailbox rather than carrying over an old SMTP hostname. Migration changes.

The same migration article says domain aliases cannot send on the new platform. Do not use an alias as the test From address, delete it, or create a replacement mailbox merely to complete this guide. Have the mailbox owner resolve an unsupported sending identity separately.

Before editing, obtain authorized access to both the domain’s email settings and its DNS records. The reviewed instructions do not establish a named administrator role or a universal plan entitlement. If the controls below are unavailable, confirm the account, product and permissions with Active24 rather than substituting another provider’s interface.

Record:

• The actual mailbox, approved visible From address, current SMTP or webmail route, and who owns it.
• The authoritative nameservers and the domain or delegated zone serving each required record.
• Existing SPF, DKIM selectors, _domainkey delegations, and direct or inherited DMARC policy.
• Other legitimate senders, shared records, queued mail, and who may authorize recovery.

If another part of the organization uses Exchange Online, handle it separately with the Microsoft 365 SPF and DKIM guide. Registering a domain at Active24 does not make Active24 the sender for every application using it.

Understand the SPF record before changing it

Active24 publishes this template for the current Czech platform:

v=spf1 a mx include:_spf.websupport.cz ?all

It is a provider template, not permission to replace your current policy. Its mechanisms have distinct effects:

• a authorizes the address records of the SPF domain. A website or other host at that name may therefore gain sending authorization.
• mx authorizes the addresses of that domain’s MX hosts. Check whether those inbound hosts are also intended outbound senders.
• include:_spf.websupport.cz evaluates Active24’s documented current provider policy.
• ?all returns neutral for a source not matched earlier. It is neither softfail nor fail and does not guarantee any receiver’s delivery decision.

Compare the actual A/AAAA addresses and MX hosts with the approved sending inventory. Do not add broad a or mx authorizations simply because they occur in a template. Do not change the A, MX or nameserver records to make the template fit. Resolve the required sender authorization with the domain owner and Active24 where the inventory differs. Active24 SPF instructions; SPF mechanisms, RFC 7208.

SPF checks the SMTP MAIL FROM domain, commonly visible in the received Return-Path, not automatically the visible From address. For a null reverse-path, HELO handling is relevant. Inspect the receiver’s smtp.mailfrom identity before deciding which owner needs a policy. The reviewed Active24 pages do not promise one universal envelope domain for every route. SPF identity selection.

At that owner, keep one TXT record beginning v=spf1. Merge necessary authorizations into the existing policy after reviewing all senders; do not add a second complete policy. Preserve its deliberate qualifier. Adding all to a policy using redirect= makes the redirect ineffective, so that requires a deliberate redesign, not a suffix edit. SPF does not inherit an apex policy automatically at a child domain.

Evaluate the full lookup tree. SPF permits at most ten evaluated DNS-query-causing terms, including nested include and redirect processing; this is not a limit of ten visible includes. a and mx also consume the term budget, with additional lookup constraints. Duplicates, bad syntax or excess evaluated terms can produce permerror. SPF processing limits; redirect behavior.

Why the official screenshot has a different SPF value

Active24’s current Czech prose specifies include:_spf.websupport.cz, but its example screenshot shows include:_spf.m1.websupport.sk and a separate old spf2.0 entry. Use the current documented platform and actual account requirements, not the screenshot’s sample SPF. Do not add that legacy entry. If the account’s issued requirements disagree with the current Czech instructions, pause that change and ask Active24 to reconcile them. Also, do not adopt the article’s suggestion that an unmatched source necessarily fails a policy ending in ?all.

Check domain signing and obtain the exact DKIM record

Active24 describes DKIM as enabled by default. Do not switch it off and on to “refresh” a working configuration.

1. Sign in to Webadmin.
2. Open Služby and select the intended domain.
3. Open Emaily → Bezpečnost domény (Domain security).
4. Inspect Autorizace odesílaných emailů DKIM. The enabled option indicates outgoing email authorization/signing, not inbound SPF filtering.
5. If enabling is an approved, necessary change, select the enabled setting and choose Uložit změny (Save changes), as shown in Active24’s interface image. Leave the neighboring RBL and incoming-SPF controls unchanged.

The provider limits this DKIM feature to domains whose nameservers are currently or historically with it. This guide deliberately uses only the current-Active24-DNS case. Do not move nameservers to satisfy that condition. Domain signing control and applicability.

Next, inspect the domain’s DNS → TXT records. Active24 says it automatically adds DKIM within 24 hours after successful registration or transfer. If the correct key is already published, preserve it. An old transfer date does not explain a missing or incorrect record indefinitely.

If the DKIM record is missing:

1. Under the domain, open DNS → Rychlé nastavení (Quick settings).
2. Open the Websupport Mail record preview.
3. Locate the issued record whose full name begins mail._domainkey..
4. Copy its complete owner and complete TXT value, including v=DKIM1, key-type tags and the entire p= public key, into the ordinary TXT editor described below.
5. If the record is absent from the preview too, ask Active24 Support for the domain’s correct record. Do not generate a replacement key yourself or copy another account’s key.

Do not apply the whole Websupport Mail quick-setting set just to recover DKIM. The official interface says that preset updates TXT and MX records. Although the help article offers Continue as an automatic option, changing inbound routing is a separate decision. The documented manual-copy alternative lets you publish only the exact DKIM TXT. Keep the private signing key with the provider. Issued record and Quick settings procedure.

Publish only the approved TXT changes

For Active24’s current editor, open Webadmin → domain → DNS → DNS nastavení → TXT. Use Pro adresu for the record owner, Hodnota for its value, and the intended TTL. Save the approved change. Compare the resulting full owner with the provider output before and after saving. Active24 TXT editor.

The following names are mapping examples, not additional domains to create:

• If the signing domain is example.com, the DKIM full owner is mail._domainkey.example.com. In a relative-name editor for the example.com zone, enter mail._domainkey; in a full-name field, use the complete owner once.
• If Active24 has actually configured news.example.com as the signing domain, its full owner is mail._domainkey.news.example.com. In the parent example.com zone, the relative owner is mail._domainkey.news; in a separately delegated news.example.com zone, it is mail._domainkey.
• If _domainkey.example.com is separately delegated, the selector’s relative owner in that authoritative zone is mail. For a delegation of _domainkey.news.example.com, it is also mail in that zone. Do not delete the delegation or put an ineffective copy in the parent zone. Coordinate publication with the authority serving that namespace and with Active24 if automatic publication cannot reach it.
• An SPF policy for example.com belongs at that full name, usually the zone apex in a relative editor. An SPF policy for an actually used envelope domain news.example.com belongs at news in the parent zone, or at the child zone’s apex. Use the editor’s displayed apex convention rather than assuming that typing @ always works.

Preserve other selectors and unrelated TXT records. Different services can use different selectors, but two independent public keys at the same DKIM owner create a conflict. Stop if that owner already contains a CNAME or another service’s data; do not delete it to make room. This native route uses TXT, not DKIM CNAME targets, so HTTP proxy and CNAME-flattening controls are not setup steps here. DKIM selector lookup.

Verify DNS and then the received message

Use read-only queries, substituting the actual configured domain and authoritative server for these fictional examples:

dig NS example.com
dig @ns1.example.net TXT example.com
dig @ns1.example.net TXT mail._domainkey.example.com
dig TXT example.com
dig TXT mail._domainkey.example.com
dig TXT _dmarc.example.com

Query the authority for each owner, including a delegated namespace where applicable. Expect one applicable SPF policy and the exact provider-issued DKIM TXT. Multiple quoted character strings in one TXT resource record are joined for interpretation; do not mistake them for several independent policies or remove characters from a long key. Compare authoritative answers with a public recursive resolver after the prior TTL has expired. These commands show what to inspect, not results already obtained.

DNS publication and the enabled domain setting are separate from proof that a message was signed. Send a new message through each actually used in-scope Active24 mailbox route, using harmless synthetic content and controlled, valid external test mailboxes. Do not send tests to customers or use a live campaign audience. An internal-only message is insufficient for this external-path check.

Open the original message at the recipient. Use Authentication-Results produced inside that receiving service’s known processing boundary, with its documented handling of externally supplied Authentication-Results. If that boundary is unclear, ask the receiving administrator. Header position or a familiar authserv-id string alone is not proof. Ignore attacker-inserted or otherwise untrusted result fields. Authentication-Results security requirements.

Record the actual visible From, connecting source IP, smtp.mailfrom, SPF result, DKIM d= and s=, and the receiver’s DKIM and DMARC results. Match the intended Active24 signature to its issued selector and signing domain. Query the public key at <selector>._domainkey.<signing-domain> using those actual values if the signature differs from your expectations.

For this branded DKIM setup, completion requires the intended signature to pass DKIM and align with the unchanged approved branded From, plus a trusted dmarc=pass for that From domain. A provider-rewritten From, an unrelated passing signature or DMARC passing only through SPF does not prove the intended DKIM setup works.

Relaxed DKIM alignment permits the signing and From domains to share an Organizational Domain; strict adkim=s requires identical domains. SPF alignment separately compares the authenticated envelope domain with From under aspf. The provider instructions do not establish a universal Return-Path or strict-alignment guarantee. If the observed identities do not meet the effective policy, resolve the route with Active24 instead of weakening DMARC. Current DMARC alignment rules.

Preserve DMARC and approve reporting separately

Before adding any DMARC record, inspect the exact visible From domain’s policy and applicable inherited policy. Preserve an existing policy, including p=none, its alignment settings, subdomain treatment and authorized reports. Do not add a new child monitoring override over an inherited policy simply because a setup example shows p=none.

Only when no applicable direct or inherited policy exists, and the domain owner approves an initial policy with an assigned monitoring and review plan, a minimal first TXT value is:

v=DMARC1; p=none

For From domain example.com, publish at full owner _dmarc.example.com, relative _dmarc in its zone. For From domain news.example.com, use full owner _dmarc.news.example.com, relative _dmarc.news in the parent zone or _dmarc in a separately delegated child zone. Publish one policy, not a duplicate. This minimal record requests neither enforcement nor aggregate reports; add a rua destination only after approving and configuring the real report service or mailbox. DMARC policy discovery and records.

Compare the report destination’s Organizational Domain with the Organizational Domain where the policy was found, which may be a parent of From. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone is not the test. Have the chosen report receiver establish the required authorization. External-report authorization, RFC 9990 section 4.

Protocol authorization does not replace the owner’s permission to share sending-activity data. Approve recipients, access, retention and processing before adding them. Do not copy Active24’s example report mailbox or enable failure reporting casually.

Changing domain-wide enforcement is a separate decision covering all legitimate routes and indirect mail. RFC 9989 says domains publishing p=reject must not rely solely on SPF and must apply valid DKIM signatures; it also warns about forwarding and mailing-list interoperability. Review those paths and aggregate evidence before enforcement. Do not downgrade an existing policy to run this test. Interoperability considerations.

Troubleshoot the failing layer

The DKIM setting is missing: verify the migrated/current platform, domain selection, product and authorized access. This guide does not establish support for never-hosted external DNS or the historical-DNS-only case. Do not change nameservers as a troubleshooting shortcut.

Signing is enabled but the key is missing: inspect TXT and the Websupport Mail preview. Publish only the issued record. If no record is supplied, stop and ask Active24; neither a generic key generator nor a copied screenshot completes the signing setup.

The key exists but DKIM is absent or fails: check the actual outgoing transport, approved From, d= and s=, full owner, public-key completeness, delegation and cached answers. Compare a direct mailbox route with any gateway-modified route; a signature can fail if signed content changes. Do not replace keys until you know which layer failed.

SPF returns fail or softfail: inspect the actual envelope owner, connecting IP and authorized route, then reconcile legitimate sources. Neutral can be the expected unmatched result of ?all; it is not a pass. None calls for checking the actual evaluated owner and whether a policy exists there. Permerror calls for duplicate-policy, syntax and nested lookup-budget checks. Temperror calls for DNS availability and resolution checks followed by a retest, not immediate rewriting of a correct policy. Investigate SPF independently even if aligned DKIM already supplies DMARC pass.

SPF and DKIM pass but DMARC fails: compare their authenticated identities with the unchanged From and the effective alignment policy. More SPF includes cannot repair an unrelated signing domain or provider-owned envelope identity.

The wrong service stopped receiving mail: review whether an MX-changing preset was applied. Do not run another blanket preset. Escalate to the mail and DNS owners with the precise before-and-after records and approved routing plan.

Recover narrowly and retain working keys

Before rollout, agree with the mailbox and DNS owners who may pause affected sending and who may restore the exact approved previous configuration. Save the original records and domain setting. Recovery must preserve concurrent DNS changes, unrelated selectors, shared dependencies and public keys still needed by queued messages.

Active24’s TXT help says its History restoration returns all DNS settings to an earlier state. Do not use that as an unreviewed single-record undo. Restore only the agreed affected records and account setting, or coordinate a broader recovery explicitly. Retest after restoration and after future platform, domain, DNS, SMTP-route or signing-key changes. TXT history and restoration behavior.

Keep the issued record, change timestamps, authoritative and recursive answers, domain-setting evidence, controlled test results and unresolved exceptions. A historical screenshot does not prove that today’s route still signs correctly.

Sources and verification limits

The principal sources are Active24’s authentication procedureand updated February 7, 2025; its platform-migration article; and its TXT editor guide. The actual domain-setting and Quick settings images were inspected, including the broader MX effect and the screenshot/prose SPF discrepancy.

These are documentary instructions. Account eligibility, actual records, delivered headers, DNS changes and message tests remain checks for the authorized operator. No production configuration, sending, website publication or inbox-placement result is claimed here.