Seznam Email Profi has two different DKIM situations: domains whose DNS is managed within Email Profi, and domains connected while their DNS stays elsewhere. Identify your situation before changing anything. This guide is for an existing Email Profi custom-domain mailbox, not an instruction to migrate a domain, change mail providers or authenticate an unrelated newsletter platform.
Start with the right sending route
Record the actual mailbox address, visible From domain, current outgoing service and DNS administrator. A domain registration receipt does not by itself identify where DNS is authoritative. Confirm the current nameservers and any separately delegated child zone with the domain administrator. Export existing SPF, DKIM and DMARC records and preserve the prior values in a change record.
Keep the mailbox's existing inbound routing, nameservers, DNSSEC and other services unchanged. If email is actually sent by an external CRM or newsletter service, authenticate that service separately. Adding a Seznam authorization does not make another provider sign with your domain.
For DNS managed inside Email Profi, an administrator opens the relevant domain's detail and the Změna DNS tab, meaning “Change DNS.” For externally managed DNS, use that DNS provider's authorized administrator instead. Seznam's DNS reference also explains its restrictions on changing native nameservers and MX records; this outbound-authentication task does not require overriding them. Seznam DNS administration.
Configure Seznam SPF without deleting other senders
For a domain sending only through Email Profi, Seznam publishes this baseline:
v=spf1 include:spf.seznam.cz ~all
It is a TXT record at the sending domain, shown as @ in Seznam's example, with TTL 1800 seconds. If other legitimate services send using the same SPF identity, merge their verified requirements into the existing policy rather than replacing it with this single-service example. Seznam SPF instructions.
SPF evaluates the SMTP envelope sender domain, ordinarily reported as smtp.mailfrom; it does not automatically evaluate the visible From domain. Determine the actual envelope identity from a controlled delivered message before assuming an apex TXT edit repairs a particular stream. Subdomains need the policy applicable at their own evaluated name; SPF is not inherited from the parent. Publish only one v=spf1 policy at that name. SPF specification, RFC 7208.
Preserve existing legitimate authorizations and qualifiers unless the owner approves a deliberate change. Insert a necessary include before the final all mechanism. An all mechanism terminates matching; a redirect modifier is ignored when all is present. Do not append a second complete policy or copy arbitrary example IP addresses. The ~all result is softfail, distinct from neutral or fail; none of these qualifiers guarantees a particular delivery decision. RFC 7208, mechanisms and results.
Budget the ten DNS-dependent terms evaluated across the SPF policy and nested processing, not merely ten visible includes. Check for permanent errors separately from temporary DNS failures. A long TXT value may use multiple character strings within one TXT resource record; that is different from publishing multiple SPF records. Do not treat the provider help page's stated 250-character ceiling as a universal SPF protocol limit. Ask the DNS host about its editor's actual constraints while following the protocol's record construction rules. RFC 7208 sections 3.3 and 4.6.4.
Select the correct DKIM branch
Seznam documents automatic own-domain signing when DNS is managed within Email Profi. Externally connected domains initially use emailprofi.seznam.cz signing; Seznam provides three CNAMEs to enable own-domain DKIM for that branch. Its free @seznam.cz, @email.cz and @post.cz mailboxes are a different case. Seznam DKIM instructions.
For an externally connected Email Profi domain, use all three published records below. Replace example.com with the actual configured domain; the right-hand destinations are Seznam's documented constants, not generated tenant values. TTL is 1800 seconds.
szn1._domainkey.example.com. 1800 IN CNAME szn1._domainkey.seznam.cz.
szn2._domainkey.example.com. 1800 IN CNAME szn2._domainkey.seznam.cz.
szn3._domainkey.example.com. 1800 IN CNAME szn3._domainkey.seznam.cz.
The provider's procedure specifies DNS publication, not a separate signing toggle or promised activation interval. Do not invent either. Confirm the result externally; if the own-domain signature is still absent after correct public DNS answers, ask Seznam to inspect that domain's signing state. Official DKIM procedure.
Put each record at the right DNS owner
A DNS editor may want a relative name or a full name. For the example.com zone, the first relative owner is szn1._domainkey; its full name is szn1._domainkey.example.com. If the configured sender is mail.example.com but the editor manages example.com, use the appropriate szn1._domainkey.mail owner. If mail.example.com has its own delegated zone, the relative owner there becomes szn1._domainkey. If _domainkey.example.com itself is delegated and that is the zone being edited, the relative owners are simply szn1, szn2 and szn3, giving the same full selector names. Apply the same reasoning to the other selectors and inspect the resulting full names before saving.
The CNAME value is a hostname, not an HTTPS URL, IP address or TXT public key. Seznam's own DNS editor requires a terminating dot for CNAME destinations; other editors have their own absolute-name conventions. Follow the actual host's convention and verify the public result. Seznam DNS record formats.
Check for existing records at each owner. A CNAME must not conflict with TXT, A, AAAA, MX or another CNAME there. Preserve any _domainkey delegation and other services' selectors. If the namespace is delegated elsewhere, coordinate with its actual authority rather than deleting that delegation. DNS alias rules, RFC 2181 section 10.1.
For DNS hosts with HTTP proxying, publish these authentication aliases as DNS-only. The required public result is the literal CNAME pointing to the specified destination. Where applicable, turn off a per-record Flatten control and ensure zone-level flattening does not conceal the alias. Cloudflare documents that flatten-all cannot be overridden per record and that apex and same-zone behavior have additional rules. If a mandatory behavior prevents the required answer, coordinate a supported configuration instead of changing shared settings blindly. Do not disable global flattening or change nameservers merely to match a tutorial. Cloudflare CNAME-flattening controls.
Verify DNS, then test outside Seznam
After the approved edit, compare authoritative answers and a public resolver. These are example read-only commands, not results:
dig TXT example.com
dig CNAME szn1._domainkey.example.com
dig CNAME szn2._domainkey.example.com
dig CNAME szn3._domainkey.example.com
Replace the domain first. Check all three destinations, not only the first successful response. For missing answers, inspect the authoritative zone, duplicated domain suffixes, record conflicts, delegation and cached responses. Record when the authoritative answer became correct before repeatedly changing DNS. A published key or alias is not proof that the sending system used it.
Send a new message from the actual configured mailbox to an external account you control, outside Seznam's infrastructure. Seznam says messages between its own mailboxes do not carry DKIM signatures, so an internal-only test cannot validate this setup. Seznam's internal-message exception.
Open the received raw headers. Establish which Authentication-Results fields were generated inside the receiving service's trusted processing boundary, using its documented handling of externally supplied fields or its administrator's guidance. A familiar authserv-id string or a header's position alone is not proof; ignore attacker-supplied results. RFC 8601 security requirements.
Record the visible From, envelope domain, SPF result, DKIM signing domain (d=), selector (s=), DKIM result and DMARC result. Acceptance for this own-domain DKIM task requires a passing intended signature aligned with the intended branded From under the effective alignment policy, plus the trusted receiver's dmarc=pass. SPF-only DMARC success does not establish that DKIM works. A rewritten provider From or unrelated passing signature is not success for the requested branded identity. DMARC identifier alignment, RFC 9989.
DKIM alignment compares the signature’s d= domain with visible From under adkim; SPF alignment compares the authenticated SMTP MAIL FROM domain with visible From under aspf. Strict alignment requires an exact domain match; relaxed alignment permits the relevant Organizational Domain relationship. A child envelope domain such as bounce.example.com can align with example.com in relaxed mode but not strict mode. Do not assume this service uses that illustrative envelope identity; inspect the actual message. Inspect SPF independently even if DKIM supplies the DMARC pass: fail, softfail, neutral, none, temperror and permerror are different diagnostic outcomes. Never add a receiving server or forwarder to SPF automatically. For more on separating cryptographic success from policy alignment, read EmailAuth's raw DKIM versus aligned DKIM guide.
Keep DMARC under the domain owner's control
Read the current TXT record at _dmarc for the visible From domain and check applicable parent policy when no direct record exists. Preserve enforcement, alignment settings and authorized report destinations. Do not weaken a direct or inherited policy to make a test pass. DMARC policy discovery and processing, RFC 9989.
Only if no applicable policy exists and the owner approves initial monitoring, a template is:
v=DMARC1; p=none; rua=mailto:APPROVED-REPORT-ADDRESS
Replace the whole report address with an authorized, working recipient before publishing one TXT policy at _dmarc.YOUR-FROM-DOMAIN. In a parent-zone editor use the correct relative subdomain owner; in a separately delegated zone use its own _dmarc. Monitoring requests neither quarantine nor rejection. Do not add a second policy alongside an existing one.
Compare the Organizational Domain of the report destination with that of the domain where the policy was found. Different Organizational Domains require the report-generating receiver to check DNS authorization; destinations within the same Organizational Domain are excepted. A different hostname alone is not sufficient to classify the destination as external. This protocol authorization is separate from the owner's approval to share report data. RFC 9990 section 4.
Troubleshooting and handover
SPF fails: inspect the actual envelope identity and final sending IP, then compare the existing policy with the authorized inventory. Check duplicate records and nested-term limits for permerror; investigate DNS reliability for temperror. Do not overwrite a mixed-provider policy with a single-provider example.
Only a provider-domain signature appears: compare all three public CNAME answers and the actual From domain with the intended setup. If they are correct but a new external message still lacks the required aligned signature, preserve the evidence and escalate to Seznam. Do not repeatedly replace working DNS or assume an undocumented activation button exists.
DKIM passes but DMARC fails: compare the authenticated identity with From under the effective policy. DKIM fails after forwarding or modification: compare direct and modified routes independently; changing SPF cannot repair a broken body hash. DNS looks right but the message is unsigned: check that the test went through the intended sender and outside Seznam before diagnosing activation.
Keep original/final records, approvals, lookup timestamps and controlled test evidence in the handover. If an edit causes a regression, have the responsible administrator restore only the affected approved prior records after checking concurrent changes; do not delete shared selectors or downgrade DMARC. Review again after changes to sender, domain or DNS authority.