Elkdata SPF, DKIM and DMARC setup, step by step

On this page: Identify your nameservers and actual sending route · Review the documented SPF policy before publishing · Publish SPF in the authoritative DNS editor · Follow the correct DKIM branch · Review the DMARC default without downgrading protection · Verify DNS and newly delivered messages · Troubleshoot the provider-specific failure modes · Frequently asked questions · Documentation review and testing boundary

Quick answer: Veebimajutus, operated by Elkdata OÜ, documents include:mail.spf.elkdata.ee for its mail service. SPF is supplied by default when its nameservers are used. DKIM is automatically active with Veebimajutus nameservers for mail sent through its webmail or mail.veebimajutus.ee SMTP server. If DNS is hosted elsewhere, request the applicable DKIM DNS record from support and publish it at that authoritative DNS host. Verify the actual message identities before claiming DMARC alignment. Official email-authentication guide

This guide covers Veebimajutus mail, not every application or marketing platform that uses the same From domain. It translates the provider's relevant Estonian control labels and separates its automatic setup from the external-DNS handoff.

Identify your nameservers and actual sending route

DNS hosting determines where the records must exist. Domain registration or website hosting with Elkdata does not establish that its nameservers remain authoritative. Confirm delegation, the domain in your mail account and the application's actual outgoing server before editing.

The official guide limits its stated DKIM signing to Veebimajutus webmail and mail.veebimajutus.ee SMTP. A web application that bypasses those services is not covered merely because its domain is hosted there. Documented signing routes

Before starting, retain a copy of the current SPF, DKIM, DMARC and relevant DNS records, their owners and TTLs. Identify a person responsible for restoring the affected values if needed. Leave MX, web-address records, unrelated verification tokens and existing senders alone. Changing nameservers is not necessary just to follow the external-DNS branch; the provider warns that records left only at the old DNS host cease to control the domain after delegation changes. Veebimajutus DNS management

Review the documented SPF policy before publishing

Veebimajutus's current authentication guide gives this example:

v=spf1 a mx include:mail.spf.elkdata.ee ~all

The exact mechanism is include:mail.spf.elkdata.ee, including its colon. Do not replace it with prose such as “including”, omit the colon or copy sentence-ending punctuation after ~all. The example is the provider's policy, not proof that it includes every sender your organization uses. Official SPF value

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

Review a and mx deliberately. A website's address or inbound mail host is not automatically an intended outbound sender. Preserve an existing valid policy and its chosen qualifier rather than replacing it wholesale with the example. For a new policy, include only the approved sources and choose the final treatment with the domain owner. SPF softfail or fail is a protocol result, not a guaranteed delivery or rejection outcome. RFC 7208 mechanisms and results

Choose the correct SPF owner

SPF normally evaluates the SMTP envelope MAIL FROM domain, not the visible From header. Inspect smtp.mailfrom in a trusted receiver result to learn which owner was checked. For a null reverse-path, SPF uses the HELO identity. Publishing at example.com does not automatically give bounce.example.com its own policy. RFC 7208 identity rules

The provider's public pages do not establish a universal customer-controlled custom Return-Path procedure. Do not invent one or assume an SPF include changes the envelope domain. If the observed identity differs from your expectation, confirm the route with support and assess DKIM alignment separately. The custom MAIL FROM guide explains this boundary.

Preserve one policy and the processing budget

Query the required owner before editing. If an SPF policy already exists, merge the approved Veebimajutus authorization into that one policy, before its terminal all, while retaining other legitimate senders. A policy using redirect= needs a considered edit; adding a terminal all can bypass the redirect. Do not publish a second v=spf1 record alongside the first. RFC 7208 record selection

The limit is ten evaluated DNS-dependent terms, including nested work, across include, a, mx, ptr, exists and redirect. The a, mx and include in the provider's sample must be considered with all nested dependencies and other senders. This is not just a count of visible includes or DNS packets. Excessive evaluation causes permerror. ip4, ip6 and all do not consume that term budget. RFC 7208 processing limits

Unrelated TXT records may remain. Multiple quoted strings inside one TXT record are joined without added spaces; they are not inherently multiple SPF policies. See merging duplicate SPF policies if a previous setup left more than one selectable policy.

Publish SPF in the authoritative DNS editor

When Veebimajutus hosts DNS

The provider says SPF is enabled by default on its nameservers. Verify the actual current value first rather than adding another copy. Its documented TXT editor sequence is:

1. Open Iseteenindus (self-service) and select the domain's management page.
2. Choose Domeen → Nimeserver (DNS).
3. In DNS kirjed (DNS records), click Muuda (edit).
4. Update the existing SPF TXT entry. Use + Lisa uus kirje (add a new record) only if a required record is genuinely absent.
5. Set Tüüp to TXT and place the complete reviewed policy in Väärtus. For the zone apex, the provider's TXT example leaves Nimi blank. Confirm the resulting public owner rather than assuming another DNS host uses the same convention.
6. Confirm with Jätka (continue) and Kinnita (confirm), then verify public DNS.

These controls come from the official TXT publishing guide. The SPF guide establishes the default and external-nameserver distinction.

When another service hosts DNS

Make the reviewed TXT change at that authoritative service, not in an inactive Veebimajutus zone. Follow the external host's rules for blank/apex names and automatic suffixes. For an envelope owner bounce.example.com in an example.com zone, the relative entry is commonly bounce; if bounce.example.com is a separately delegated zone, its apex convention applies instead. Record the complete expected owner independently of what the form displays.

Do not change the domain's nameservers or inbound MX to make an email-authentication edit. Use the external DNS administrator when you do not control the correct zone.

Follow the correct DKIM branch

Veebimajutus nameservers: verify automatic DKIM

The official authentication page describes DKIM as automatically active with Veebimajutus nameservers. Start by verifying that those nameservers are authoritative and that the message actually travels through its webmail or mail.veebimajutus.ee SMTP route. Do not create an arbitrary default._domainkey entry or generate a private key that the provider's signer has not been configured to use. Automatic DKIM scope

Obtain the actual selector from a delivered message or support. Its signature contains d= for the signing domain and s= for the selector. Query the resulting selector._domainkey.signing-domain name. A public key's existence does not show that this particular message used it. DKIM lookup rules, finding a DKIM selector

External nameservers: get the domain's record from support

Veebimajutus directs customers with externally managed nameservers to request the DKIM DNS record from support. Its support pages list abi@veebimajutus.ee. The public guide does not supply a universal selector, public key, CNAME target or customer activation switch for this branch. External-DNS DKIM instruction

Use this specific handoff checklist through your authorized account owner:

• Identify the mail domain and confirm that Veebimajutus remains the mail provider.
• Name the external authoritative DNS service and any recent DNS migration.
• Specify webmail, mail.veebimajutus.ee SMTP and any application routes you need covered.
• Request each exact DNS owner, type, complete public value and selector, including any rotation records.
• Ask which d= signing domain should appear and whether support must activate or recheck signing after publication.
• Ask how to retain the previous signing configuration during transition and how support will confirm completion.

Do not send mailbox passwords, private keys or confidential message contents. A request for the public DNS record does not require those secrets.

When the instructions arrive, compare the requested owners with existing DNS. Publish the exact TXT public key or CNAME type specified by support; do not convert between types or reuse another domain's key. Preserve all current selectors used by other senders. At a CNAME owner, ordinary TXT, A, MX or other conflicting data cannot coexist. Resolve collisions with support rather than deleting the existing service. CNAME coexistence rule

Only if support actually issues a CNAME, apply these checks; do not convert an issued TXT key to an alias. Where the actual authoritative DNS host offers these controls, use DNS-only aliases, not HTTP proxying or redirects, and keep a literal CNAME answer to each required target. Turn the relevant per-record Flatten option off when available, and ensure applicable zone-wide settings do not conceal the issued aliases. For Cloudflare specifically, 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 Cloudflare behaviors, not assumed controls in another provider’s panel. If mandatory behavior or shared settings prevent the required CNAME answer, stop and coordinate a supported configuration without breaking dependent records. Do not blindly change the whole zone or remove an NS delegation; publish at the delegated authority when appropriate. Cloudflare CNAME verification, flattening controls.

For a fictional signing domain mail.example.com and support-issued selector mail1, the complete owner would be mail1._domainkey.mail.example.com. It maps to mail1._domainkey.mail in the parent zone, or mail1._domainkey in a separately delegated mail.example.com zone. Neither the fictional selector nor a support record for another domain is a value to copy.

If _domainkey.mail.example.com itself is already delegated, the same illustrative full owner belongs at relative name mail1 in that delegated zone, not in an inactive parent copy. Preserve that namespace’s NS delegation and other active selectors, and publish only the exact provider-issued type and value at its authoritative operator. The selector shown remains an example, not an issued account value. Relative DNS names, DKIM key lookup.

After public DNS is correct, complete any support-directed activation or verification. Require a newly delivered message to show the intended passing, aligned signature. DKIM signs selected message data; it does not encrypt the email body for confidentiality. DKIM purpose and signature fields

Review the DMARC default without downgrading protection

Veebimajutus documents a default DMARC value of v=DMARC1; p=none;. That describes a default, not your domain's observed current policy and not permission to overwrite a stronger one. By itself it does not request aggregate reports. Provider DMARC default

First inspect the applicable direct and parent policy. For From example.com, the direct owner is _dmarc.example.com: enter _dmarc in the example.com zone when the DNS editor appends the zone suffix. For From mail.example.com, it is _dmarc.mail.example.com, entered as _dmarc.mail in the parent zone or _dmarc in a separately delegated mail.example.com zone. Publish where that owner is authoritative. An absent child record can still be governed by a parent policy; adding child p=none can weaken inherited enforcement. DMARC policy discovery

Only for an approved new monitoring deployment with no existing direct or inherited policy, this minimal illustrative TXT value can be considered:

v=DMARC1; p=none

For approved aggregate reporting, append ; rua=mailto: followed by the actual approved destination address, leaving no placeholder or another customer's address in DNS. Preserve established policy, reporting and alignment settings instead when they already exist. External report recipients require DNS authorization under RFC 9990 section 4. Review DMARC aggregate reports across the whole sender inventory before changing enforcement.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

DMARC passes with at least one passing, aligned SPF or DKIM identifier. Compare From with smtp.mailfrom for SPF and d= for DKIM. Relaxed alignment permits a shared organizational domain; strict aspf=s or adkim=s requires an exact match for that mechanism. A provider-owned domain can pass authentication without aligning with your From domain. Do not infer alignment from an automatic-DKIM label. Current DMARC alignment rules

Verify DNS and newly delivered messages

Replace all variables with actual values. Get the selector and signing domain from support or the message; do not query a guessed universal selector. These are checks for you to run, not customer DNS results collected for this article.

ZONE='example.com'
AUTH_NS='replace-with-authoritative-nameserver'
SPF_OWNER='example.com'
DKIM_OWNER='replace-with-actual-selector._domainkey.example.com'
DMARC_OWNER='_dmarc.example.com'

dig NS "$ZONE"
dig @"$AUTH_NS" "$SPF_OWNER" TXT +norecurse
dig @"$AUTH_NS" "$DKIM_OWNER" TXT +norecurse
dig @"$AUTH_NS" "$DKIM_OWNER" CNAME +norecurse
dig @"$AUTH_NS" "$DMARC_OWNER" TXT +norecurse
dig "$SPF_OWNER" TXT
dig "$DKIM_OWNER" TXT
dig "$DMARC_OWNER" TXT

Repeat against every authoritative server for the relevant zone and compare recursive answers. Save the query owner, type, server, timestamp, status, TTL and full answer. Expect exactly one selectable SPF policy with the reviewed authorizations. The DKIM record must match the support-issued or actual signer configuration. A CNAME may need recursive resolution to reach its target's public TXT key; a direct TXT key need not have a CNAME answer.

Distinguish an absent record from a timeout or SERVFAIL. The provider notes that DNS changes may take up to 24–48 hours to appear everywhere, but correct authoritative answers, cache expiry and negative caching matter more than waiting a fixed period without checking. Provider DNS verification guidance

Next, send a non-sensitive test through each intended route to a mailbox you control. Test webmail and the configured SMTP application separately where both are used. Inspect the receiving system's raw headers and trusted Authentication-Results. Do not treat untrusted sender-inserted results as evidence. Authentication-results trust

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

For DKIM commissioning, require the intended signature to pass and align, even if SPF alone already supplies DMARC. Distinguish SPF fail, softfail and none from an SPF pass that is merely unaligned. Investigate unexpected SPF authorization, missing-policy and evaluation errors instead of hiding them behind a passing DKIM result.

Accept this branded-DKIM setup only when the intended provider signature has trusted dkim=pass, its actual d= aligns with the intended visible From under the effective adkim mode, and the trusted receiver reports dmarc=pass for that From. SPF-only DMARC success does not complete the DKIM deployment. Independently diagnose SPF fail or softfail (authorization mismatch), temperror (transient evaluation failure, often DNS) and permerror (uninterpretable policy, duplicates or lookup limits) at the observed smtp.mailfrom, even when aligned DKIM supplies DMARC. A passing but unaligned provider envelope is a different outcome from an SPF error. DMARC alignment, SPF results.

If mail is not delivered, preserve the sender's event or SMTP response as a separate delivery investigation. No received sample means the header test is incomplete. A passing authentication test also does not guarantee inbox placement or validate the safety of the message's content.

Troubleshoot the provider-specific failure modes

The provider's SPF article discusses forwarding problems. That warning is not a reason to disable forwarding or add arbitrary forwarder networks to your policy. Diagnose the actual messages before changing service behavior. Veebimajutus forwarding caveat

For recovery, pause further edits and compare the current records with the saved baseline. Restore only the approved affected state, preserving legitimate changes made since the snapshot. Coordinate key or signer rollback with support: an old public key may not verify messages signed with a newly activated key. Recheck authoritative DNS, recursive DNS and a new message after the repair. Do not remove old selectors until their use and retention requirements are resolved.

Documentation review and testing boundary

No account was accessed, support contacted, nameserver changed, DNS record published, customer domain tested or message sent. Public documentation supports the branches described here; account-specific records and actual sending results must be verified by the authorized operator.