Scope Elkdata guidance to Veebimajutus mail service
Elkdata OÜ's Veebimajutus site publishes an Estonian email-authentication guide describing SPF, DKIM and DMARC for its mail service. Its support pages identify Elkdata OÜ as the operator. This article translates the relevant workflow into English and keeps the service boundary explicit: the documented DKIM behavior applies to mail sent through Veebimajutus webmail or mail.veebimajutus.ee SMTP, not automatically to every application that uses the same domain.
The guide distinguishes domains using the provider's nameservers from domains whose DNS is hosted elsewhere. That distinction determines which records the provider says are automatically active and where the customer must arrange publication. Start by recording the actual authoritative DNS service and outbound mail route. Domain registration, website hosting and mail submission can belong to different providers, so an invoice from Elkdata alone does not establish all three.
The retained public articles do not expose an unambiguous revision date for the technical text. They were reviewed on November 9, 2026. Current account applicability, actual DNS contents and message behavior remain unverified. This manuscript does not sign into self-service, alter nameservers or send mail. An automatic default described by documentation is not proof of an individual domain's present state.
Review SPF defaults and the external-DNS branch
The authentication guide says SPF is enabled by default for domains using Veebimajutus nameservers. It shows a recommended policy containing a, mx and include:mail.spf.elkdata.ee, with a soft-fail ending. The separate SPF article explains that a customer using the mail service with another DNS provider must arrange the TXT record there. Preserve this branch distinction rather than editing a zone that is no longer authoritative.
The documented self-service path is Iseteenindus, Domeen, Nimeserver (DNS), DNS kirjed: self-service, domain, nameserver settings and DNS records. Use this as a navigation reference only for the applicable provider-managed zone. If another service hosts the zone, the correct change belongs with that service's authorized administrator. Do not move nameservers merely to make a record editor appear relevant.
Before adding the provider include, review all legitimate senders. The published example is not a complete inventory for every organization. Employee mail, website notifications and marketing platforms may need distinct authorizations or signing arrangements. Preserve those that remain approved and document any retirement separately. The a and mx terms and final qualifier in the sample also require review rather than automatic adoption in an unrelated policy.
Preserve one coherent SPF policy and its meaning
RFC 7208, sections 3.1 and 3.2 require TXT publication and prohibit multiple records that would cause more than one SPF policy to be selected. If a policy already exists, merge the approved authorization instead of publishing another full sample alongside it. A saved TXT entry at the wrong owner cannot authorize the intended identity, even when its syntax looks plausible.
Section 4.6.4 limits evaluated DNS-dependent terms, including nested work. The example's a, mx and include terms each need to be considered in the complete evaluation context. Counting only literal addresses, visible includes or DNS packets does not establish compliance. Preserve the distinction between evaluation-limit errors and a valid result that does not authorize a particular sending IP.
The source's discussion of rejecting unauthorized messages should not be read as a universal delivery guarantee. SPF results and receiver policy are different. Its own caveat says SPF does not provide complete protection against domain misuse and that interpretation depends on the receiving system. Do not describe softfail or fail as an automatic promise of a specific SMTP response. Veebimajutus SPF article
Apply the nameserver-dependent DKIM workflow
The authentication guide says DKIM is automatically active when the domain uses Veebimajutus nameservers. For externally managed nameservers, it directs the customer to request the DKIM DNS record from support. Do not invent a selector, key value or universal customer-managed activation control for that second branch. Obtain the actual applicable record and bind it to the intended domain and service route. Veebimajutus authentication guide
The source describes signing for messages sent through its webmail or SMTP service. A separate marketing provider or application that bypasses that route needs its own authentication assessment. Publishing Veebimajutus records does not cause another company's servers to sign messages with the same identity. Keep the actual submission route visible in the acceptance worksheet and in any support request.
A support handoff should contain the domain, current DNS-hosting arrangement and requested public record, not passwords or the provider's private signing key. This manuscript has not contacted support. When an authorized operator receives instructions, review existing data at the requested owner before publication and retain the complete public value without accidental formatting changes. Current provider confirmation remains a gate, particularly after a DNS-hosting migration.
Do not translate digital signing into message encryption
The Estonian guide uses wording about a cryptographic signature. In this English workflow, DKIM means signing and verification of selected message content, not encryption of the message body for confidentiality. RFC 6376, section 1 describes DKIM's role, and section 3.5 defines the signing-domain and selector fields. A recipient's ability to verify a signature does not establish that the message was unreadable in transit or at rest.
A later authorized message assessment should record d= and s= from the actual signature and the trusted receiver's result. Compare those fields with the intended domain and published key location. An automatic DNS default does not establish that a particular application's message traversed the provider's signing route. Likewise, one passing sample does not prove every separate sender or forwarding path.
Review DMARC defaults without overwriting policy
The provider documents a default DMARC value of v=DMARC1; p=none. It explains that this does not request blocking or quarantine for messages that fail the relevant checks. Treat that as a documented default, not an instruction to downgrade an organization's existing policy or evidence that the current domain still has the default. Review all legitimate senders and reporting arrangements before a domain-wide change. Veebimajutus authentication guide
RFC 9989, section 4.4 adds alignment between the visible author domain and a passing authenticated identity. Passing aligned SPF or passing aligned DKIM can satisfy the authentication condition. A signature from an unrelated domain is not sufficient simply because it verifies. Authentication also does not establish that a payment request, attachment or instruction inside the message is safe.
Forwarding deserves a separate row in the review. The SPF article notes that forwarding changes the connecting server while the original sender identity may remain, which can affect SPF. Do not remove forwarding or weaken policy automatically. Identify the actual route and trusted results before deciding whether the problem is authorization, alignment, message modification or recipient policy. No forwarding experiment was performed here.
Fictional diagnosis and blank acceptance worksheet
A fictional design studio, Birch Harbour, moves DNS hosting while retaining Veebimajutus mail service. Its team assumes that the old provider-managed DKIM default will automatically appear in the new zone. The proposed review identifies the external-DNS branch and requests the applicable public record through an authorized owner. It then keeps actual signing and alignment evidence open until verified safely. This is a fictional migration scenario, not an observed outage or completed support exchange.
- Domain, mail service and authoritative nameserver operator: ______
- Webmail, provider SMTP or separate application route: ______
- Existing SPF policy and approved include change: ______
- Automatic-DKIM applicability or support-issued external-DNS record: ______
- Migration dependencies and public-record publication evidence: ______
- Actual signature, envelope identity and trusted receiver results: ______
- DMARC policy owner, forwarding exceptions and release decision: ______
The exact original implementation evidence, human review, current applicability, production routes, visual accessibility and owner release remain open. No domain, DNS record, credential, routing setting or message was changed or created.