Zone.ee SPF, DKIM and DMARC setup, step by step

For Zone-hosted mailbox email using Zone-managed DNS, open My Zone → Webhosting → E-mail → DKIM / SPF / DMARC. Activate DKIM to publish the provider-generated TXT key at zone._domainkey.yourdomain and enable outgoing signing. Review SPF separately: Zone's documented default is v=spf1 a mx include:_spf.zone.eu -all. Preserve existing senders and DMARC policy, then verify an aligned Zone DKIM pass and DMARC pass on a newly delivered message. Zone activation guide · Zone DKIM

This guide covers hosted mailboxes managed under My Zone Webhosting, sent through webmail.ee or smtp.zone.eu, with Zone authoritative DNS. It does not cover self-managed CloudServer/VPS mailservers, PHP or website-generated mail, external SMTP providers, or a manual DKIM-key retrieval workflow for external DNS.

On this page: Before activation · SPF · DKIM · Record names · DMARC · Validation · Troubleshooting · FAQ

Before activation

You need an active hosted mailbox service, access to that service's email settings in My Zone, and authority to manage its DNS records. Zone's current Starter, Business and Pro comparison lists DKIM signature (webmail & SMTP) on all three plans. Do not carry an older webserver-specific plan restriction into the mailbox workflow. Current plan comparison

Check these prerequisites before using any Activate button:

• The domain's live authoritative nameservers are Zone's. Registering the domain at Zone is not enough if DNS has moved elsewhere.
• Users send via webmail.ee or the Zone outgoing server smtp.zone.eu, as the current activation guide requires. Check each mail client's actual outgoing-server setting; the address in From does not establish the route.
• You have a copy of the current DNS zone, especially SPF, DKIM, direct DMARC and any applicable parent DMARC policy.
• You know every other service that sends using the domain. A CRM, invoicing service or newsletter platform may require separate authentication, even when users read their replies in Zone.

The provider's screenshot shows separate DKIM and SPF Activate controls. DMARC activation is gated until SPF or DKIM has been activated. Do not treat the page as a single safe “enable everything” operation, particularly if the domain already has policies.

Zone's documented automatic workflow publishes to its DNS service. If your DNS is external, obtain a current product-specific retrieval/publication procedure from Zone before proceeding. A general ability to add TXT records does not establish how to retrieve the correct signing key or enable that domain's signing. Do not change nameservers solely to make this guide apply.

SPF

Understand what Zone's default authorizes

The official default is:

Owner: example.com
Type: TXT
Value: v=spf1 a mx include:_spf.zone.eu -all

This example is for a domain using the documented Zone authorization, not a safe replacement for every existing SPF policy. Zone SPF record

Each mechanism has consequences:

The default is broader than “only my mailbox SMTP server.” Zone describes its include as covering outgoing SMTP, webmail, mailing lists and webservers. The a and mx terms also authorize whatever the domain's current records resolve to. If your website points to a separate host, CDN or another service, inspect those addresses before deliberately authorizing them to send. Incoming MX servers are not automatically intended outbound senders either.

Do not blindly remove a or mx from an existing policy: they may support a legitimate route. Have the domain administrator reconcile the actual sender inventory with the desired authorization. The key is to understand and approve their effect, not to copy or delete mechanisms by habit.

Activate or edit without overwriting other senders

1. Open My Zone → Webhosting and select the relevant service.
2. Open E-mail → DKIM / SPF / DMARC.
3. Inspect the existing SPF status and public TXT value before activating it.
4. If no SPF policy exists at the intended owner and Zone's default expresses your approved sender inventory, activate SPF and verify the resulting record.
5. If a policy already exists, preserve its legitimate authorizations and merge the Zone include where required. Zone also documents manual management under server management DNS server → TXT.

Do not create an additional v=spf1 TXT record. Two SPF policies at one owner produce a permanent error rather than combining permissions. Keep unrelated TXT verification records and other mail records. Add any justified mechanism before the final all, keep a single version tag, and retain the current failure qualifier unless an intentional change has been approved. An existing redirect= design needs explicit reconciliation because an all mechanism overrides that redirect.

Zone's list of examples for other senders is not a checklist to authorize wholesale. Obtain current requirements from each sender and determine whether its envelope domain actually uses the SPF policy you are editing.

Publish at the envelope domain and respect the lookup limit

Zone's SPF guide correctly distinguishes the envelope sender from the visible From address. SPF normally evaluates the SMTP MAIL FROM domain, shown as smtp.mailfrom in receiver results. Check a real message to identify that domain. There is no universal mailbox Return-Path formula established by the setup documentation.

If MAIL FROM uses mail.example.com, the SPF record at example.com does not automatically apply there. A passing SPF result for a provider-owned envelope domain may also be unaligned with your visible From domain. Adding more includes to an unrelated apex will not change the envelope identity.

Evaluate the full policy against the maximum of ten DNS-query-causing SPF terms, including nested includes, a, mx, exists and redirect. Zone's default already includes a, mx and an include; do not assume it consumes only one lookup or has a permanently fixed total. Use the current expanded policy and do not replace Zone's maintained include with a static IP snapshot. SPF lookup rules · EmailAuth SPF reference

DKIM

Activate provider-managed signing

In My Zone → Webhosting → E-mail → DKIM / SPF / DMARC, use Activate in the DKIM section if it is not already active. Zone states this creates a TXT record containing the public key and configures outgoing SMTP signing. The selector is zone, so for the domain example.com the owner is:

Owner: zone._domainkey.example.com
Type: TXT
Value: complete public DKIM record generated by Zone

The value line describes what to obtain, not literal DNS content to paste. No reusable public key is provided here. Zone generates the key for the configured service/domain, and its private key remains on the server and is not displayed. Do not generate an unrelated key pair or attempt to upload a private key. Zone's DKIM procedure

Zone's combined activation guide gives an approximate setup time of 15 minutes. Treat that as a provider estimate, not proof that every cache has expired or that a message passed. Confirm the enabled state, public key and delivered signature separately. If DKIM is already active, avoid toggling it merely to troubleshoot a message that used another SMTP route.

Activation applies to messages sent through the relevant Zone service. It does not sign a separate newsletter provider's mail. That provider needs its own signing setup and distinct selector. A public record at zone._domainkey cannot cause an unrelated SMTP system to use Zone's private key.

Resolve a selector collision deliberately

If zone._domainkey already exists with an unexpected value, determine which sender uses it before activating or replacing anything. Preserve a working key and ask the service administrator to resolve the collision. Multiple providers can use different selectors; multiple unrelated TXT key records at the same selector are not a useful way to combine senders.

If the public key has a long value, multiple quoted character strings can belong to one TXT record and concatenate into that value. Do not split the key into multiple independent TXT records. Preserve its complete tagged form, including p= and all other supplied tags, rather than copying only the base64 key material. DKIM key-record format

Record names

Automatic publication should produce the exact owner for the configured domain. These mappings help verify the result and avoid mistakes during an authorized repair:

In a separate authoritative mail.example.com zone, the last two relative names become zone._domainkey and _dmarc. These examples explain DNS naming; they do not provision a new sending subdomain in Zone.

Check for an NS delegation below the main zone. If _domainkey.example.com is delegated, its child zone is authoritative for the selector, where the relative name would be zone. A TXT record inserted only into the parent may not be visible. Do not delete the delegation to force the automatic workflow; it may serve multiple senders. Have the DNS owner coordinate the affected signing records with Zone.

This documented Zone workflow uses a TXT key, not a CNAME. Do not convert it to a CNAME or change proxy/flattening settings intended for website records. TXT publication does not require weakening DNSSEC, changing MX routing or disabling unrelated zone protections.

DMARC

Preserve the current DMARC policy before considering Zone's DMARC activation control. Keep existing alignment modes, subdomain rules and report recipients. A subdomain may inherit policy even when it has no direct _dmarc record, so check applicable parent policy before creating a new one.

If no direct or inherited policy applies, and you are intentionally beginning without enforcement, a minimal first policy is:

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

Use the name mapping above, publish one policy TXT record at that owner, and verify the actual result if you use a provider assistant. Do not overwrite an existing quarantine or reject policy with this example. p=none requests no enforcement based on DMARC; it does not turn a failed message into a pass and it does not disable a recipient's other filters. DMARC specification

The minimal example does not request reports. Add rua only for an authorized destination after agreeing who can access the data, how it is retained and how it is protected. Aggregate reports disclose sending infrastructure and authentication activity. If the report destination's organizational domain differs from the policy domain's, the reporting service must publish the required external-destination authorization. Obtain its exact onboarding details rather than inserting an example mailbox. Do not enable message-level failure reports by default. Report destination authorization

Move to a stronger policy only after validating legitimate senders and reviewing representative activity. One successful mailbox test is not enough to establish that every sender using the domain is ready.

Validation

First check DNS

Replace example.com with the configured domain. Use the actual authoritative server and at least one ordinary recursive resolver, through dig or a DNS lookup service:

dig +short NS example.com
dig +short TXT example.com
dig +short TXT zone._domainkey.example.com
dig +short TXT _dmarc.example.com

Verify:

• The actual envelope domain returns one complete SPF policy with the intended authorization.
• zone._domainkey returns the complete generated public key, without conflicting key records or a doubled domain suffix.
• The domain has the intended direct or inherited DMARC policy, not an accidental second record or a weakened replacement.
• Authoritative and recursive answers agree after caching has caught up. Check the prior TTL and negative caching when a record was previously absent.

Then check the real mailbox route

Send a fresh message from webmail.ee, then test each production mail client using Zone's outgoing server. Keep the intended visible From address unchanged for the test. At a trusted receiving mailbox, inspect the raw headers and authentication results:

DMARC can pass through either aligned SPF or aligned DKIM, but an SPF-only DMARC pass does not complete this DKIM setup. Likewise, a passing unaligned DKIM signature from a relay does not prove that Zone is signing for your domain.

SPF can pass yet fail alignment if the envelope domain does not align with From. That differs from spf=fail, temperror or permerror. Investigate those actual faults even when DKIM supplies DMARC pass: check the evaluated domain, sending IP, policy syntax, duplicates, lookup budget and DNS availability.

Use only Authentication-Results genuinely produced by receiving infrastructure you control or trust. An attacker can prepend a fake field, including the expected authserv-id. If your receiver cannot separate or remove untrusted fields, use an independent trusted mailbox or administrator trace instead. Trust boundary requirements

Troubleshooting

DKIM is active but the message has no Zone signature

Check the outgoing route before editing DNS. Test from webmail.ee; compare it with the failing client's SMTP settings. A client using another provider, or a webserver script using a different path, is outside what mailbox activation proves. If the supported route still lacks the signature, retain a sanitized header sample and ask Zone to investigate the selected service/domain.

SPF passes for an unexpected server

Review the actual A/AAAA records and the addresses behind MX. Zone's default contains a and mx, so a website or incoming-mail change can alter which servers are authorized without changing the SPF text. Reconcile those dependencies before narrowing the policy.

DKIM lookup fails after activation

Check the authority and full owner first. Ensure you selected the correct service and did not put the record in an unused external zone or beneath an unresolved delegation. Allow the documented setup period and relevant cache lifetimes, but do not rely on waiting to fix the wrong owner.

SPF fails after adding another mail service

Check whether the new service uses your domain as MAIL FROM, whether you created duplicate SPF policies, and whether the combined lookup budget is exceeded. Obtain that service's current instructions. Zone's DKIM activation does not authenticate its signature.

The DMARC control is unavailable

The provider screenshot requires SPF or DKIM activation first. Check the supported service's status and existing DNS rather than deleting a current policy. The UI gate is distinct from message validation: DMARC itself needs at least one passing aligned path.

Authentication passes but mail still lands in spam

Investigate recipient filtering, reputation, consent and content separately. Authentication is necessary evidence, not an inbox-placement guarantee. Do not weaken the domain policy or repeatedly regenerate keys without a matching fault.