Oderland SPF, DKIM and DMARC setup, step by step

For an existing Oderland-hosted mailbox, open the domain’s Email Deliverability settings in cPanel and copy its public DKIM TXT name and complete value to the authoritative DNS provider. Then check public DNS, the domain’s status and a real message sent through the approved Oderland mailbox route. Do not export the private key or assume that editing a non-authoritative cPanel zone publishes anything on the internet. Oderland’s official authentication instructions.

This guide covers native Oderland hosted-mailbox sending with an existing domain, an approved SPF configuration and the public DKIM record already available in the account. Its main procedure is publication at an external authoritative DNS service. It does not cover Postal, a self-hosted mail server, website-generated mail, third-party campaign platforms or transferring a signing key to another server.

If Oderland already manages your DNS and you send only through its servers, Oderland says DKIM normally needs no additional action. Verify that existing route rather than creating a duplicate record. If the account does not display a public DKIM record, or does not sign its native mail, have Oderland establish the supported setup before continuing; this guide does not invent a key-generation or enable-signing control.

Confirm the sending route and DNS authority

Start with one approved mailbox and its intended From domain. Record the mailbox service, current public DKIM record, existing SPF policy, applicable DMARC policy and responsible administrators. A domain registered at Oderland can still use another DNS provider; conversely, a website hosted elsewhere does not establish which server sends its mail.

Find the authoritative zone for the exact DKIM owner. A separately delegated child domain or _domainkey namespace can be managed somewhere other than the parent domain. Preserve existing delegations and identify any other sender that depends on the same selector. Do not remove working records to make the DNS screen look like a screenshot.

Before publication, confirm that the intended route is an existing authorized Oderland mailbox path, not a newsletter service or an application relaying through a different provider. An outgoing message composed in one application can be transmitted by another system. A passing test from an unrelated route does not validate the hosted-mail configuration.

Agree on the change window and save the relevant current records. No nameserver migration, MX replacement, DNSSEC change, paid upgrade or new mailbox is needed merely to publish the existing public DKIM key. If the proposed record conflicts with another active service, stop and resolve the dependency with the service owners.

SPF is a prerequisite, not a universal record to copy

Oderland’s official guide says externally managed DNS for its hosted mail needs authorization for the actual hosting server’s IP address and its _vsp.oderland.com sender list. It explicitly notes that other mail services can require additional authorizations. The server address is account-specific: do not substitute a guessed IP, your computer’s public IP or the address of a website behind a proxy.

This procedure assumes the DNS owner has already established the correct approved SPF policy for the actual mailbox route. If that prerequisite is missing, obtain the account’s current server and SPF instructions from Oderland and have the DNS owner validate them first. Do not copy the provider’s XXX placeholder into DNS, and do not treat an include alone as proof that every required sender is covered.

SPF evaluates the SMTP MAIL FROM identity, commonly reflected in the delivered Return-Path, rather than automatically evaluating the visible From address. An empty MAIL FROM can involve the HELO identity. Identify the actual evaluated domain before deciding which DNS owner needs authorization. A child envelope domain does not inherit the parent’s SPF merely because both belong to the same organization.

At each evaluated owner, keep exactly one TXT policy beginning v=spf1. Preserve other legitimate senders, unrelated TXT records and the owner’s approved qualifiers. Evaluate the complete policy within SPF’s limit of ten DNS-dependent terms, including nested evaluation, not ten visible includes. An all mechanism means an otherwise present redirect is ignored. SPF specification.

Do not copy Oderland’s simplified description of ~all as meaning the domain owner does not care. It is an SPF softfail qualifier, not a universal spam-folder instruction. Likewise, -all does not guarantee a particular receiver action. Changing the qualifier is not a substitute for fixing a missing sender, a malformed policy or a lookup-limit error.

Open the domain’s public DKIM details

Use the existing authorized Oderland cPanel account. The Swedish labels in the official guide are included here so you can match the actual interface:

1. Open Levererbarhet för e-post, meaning Email Deliverability, in the email category.
2. Find the exact domain or subdomain used by the intended mailbox.
3. Select Hantera, meaning Manage, for that domain.
4. Read the DNS-authority warning, if present. Oderland explains that a warning about not using its nameservers means you must publish the required records at your external DNS provider.
5. In the DKIM section, locate the public TXT record’s Namn (Name) and Värde (Value). Use their Kopiera (Copy) controls to obtain the complete account-specific record.

The official article and its illustrations show both the public record and a separate private-key control. Do not use Visa den privata nyckeln, meaning Show the private key, for this task. Only the public TXT information belongs in DNS. Never put a private key in a DNS record, support ticket, screenshot or shared implementation document.

The screenshot’s domain, selector and truncated visible key are examples, not your configuration. Do not assume that a selector called default belongs to your account simply because the illustration uses it. Copy the actual Name and full public Value for the chosen domain.

Oderland’s guide also discusses copying a private key to another server. That is outside this hosted-mailbox procedure. An unrelated sending service should be configured through its own approved authentication workflow, not given this mailbox service’s key as a shortcut.

Publish the public TXT record in the authoritative zone

Compare the copied Name with the DNS zone you actually manage. For example, if an account issued the full owner ACCOUNT-SELECTOR._domainkey.mail.example.com, a panel for example.com might expect ACCOUNT-SELECTOR._domainkey.mail; a separately delegated mail.example.com zone might expect ACCOUNT-SELECTOR._domainkey. If _domainkey.mail.example.com is itself a separately delegated zone, the relative owner in that zone is just ACCOUNT-SELECTOR; preserve the existing NS delegation and coordinate with its owner. These are placeholders illustrating name handling, not values to publish.

Some DNS panels accept full names and others automatically append the zone. Check the final full owner so you do not create a duplicated suffix or put the record at the apex. A trailing dot may indicate an absolute DNS name; follow the authoritative host’s documented input convention rather than adding or stripping labels blindly.

Publish the account’s complete public DKIM value as the specified TXT record. Preserve its tags and every key character. If the owner already has a different key, an alias or a delegated namespace, investigate before changing it. A TXT record cannot be added beside a CNAME at the same owner. Do not delete another signer’s record or overwrite a shared selector to clear a warning. DKIM key model.

Full and split views describe the same public value

Oderland shows Full and Delad, meaning Split, display choices for the public TXT value. Use the form your DNS provider accepts. Splitting a long logical TXT value into character strings within one record is not the same as creating several independent DKIM records. The returned strings must concatenate to the complete account-issued value without lost or inserted characters.

Do not truncate the public key to fit a field. If the DNS service cannot store the required record, ask its operator how to enter the complete value. Do not reduce key strength, regenerate the signer or move nameservers merely to bypass an input problem.

A local cPanel entry is not sufficient when an external DNS service is authoritative. Publish there and verify the answer from that authority. This procedure does not require bulk Repair, private-key export or a separate signing-activation button that the Oderland instructions do not document.

Check DNS and the native domain status separately

Use a read-only lookup tool to compare the published owner and complete value with the current account record. The examples below contain placeholders; replace both the selector owner and authoritative server with the correct values before use:

dig TXT ACCOUNT-SELECTOR._domainkey.mail.example.com
dig @authoritative-dns.example.net TXT ACCOUNT-SELECTOR._domainkey.mail.example.com

Check the authoritative answer first, then an independent recursive resolver. Save the result and time. If they differ, compare caching and TTL behavior before editing again. No answer, an old public key, a conflicting alias or a duplicated domain suffix needs investigation. A resolver’s quoted-string formatting alone does not mean the record is wrong; compare the reconstructed logical value.

Return to the relevant domain in Email Deliverability and check its current status. Oderland’s illustration shows Valid in the domain list and VALID in the DKIM section. Do not infer from those example indicators that your own account has passed, and do not treat a local status as evidence that every external resolver sees the right value.

Oderland describes signing as part of its native mail service. This guide does not add an invented Enable DKIM step. If the intended key is published but the native mailbox path does not sign correctly, keep acceptance pending and ask Oderland to resolve the account-side state rather than exporting keys or changing unrelated settings.

Verify the actual hosted-mailbox signature

After publication and status checks, send an approved, harmless message from the intended Oderland mailbox path to an external recipient you control. Avoid customer recipients, distribution lists and confidential content. Do not use a newsletter service or website script as a substitute test for the native mailbox route.

Inspect the full received message at the destination. Use authentication results generated inside the actual receiving service’s known processing boundary, with its documented handling of externally supplied Authentication-Results. A familiar authserv-id string or a header’s position is not enough to establish trust. Ignore attacker-inserted or otherwise untrusted results. Receiver-result trust.

For this setup, record and require:

• The intended approved visible From address, without rewriting to an unrelated provider identity.
• A passing intended Oderland-hosted domain signature, including its d= signing domain and s= selector.
• Alignment of that passing signature with the From domain under the effective DMARC adkim mode.
• A trusted receiver dmarc=pass result for that From domain.
• The actual envelope domain and SPF result, with any failure or DNS error investigated separately.

Relaxed DKIM alignment compares Organizational Domains; strict alignment requires an exact domain match. DMARC can pass through aligned SPF or aligned DKIM, but an SPF-only DMARC pass does not prove this DKIM setup works. A passing signature for another service also does not validate the intended signer. See raw DKIM results versus aligned DKIM policy results and the current DMARC specification.

If an approved gateway modifies signed content, compare the actual paths with the service owners. Do not disable filtering or other security controls merely to obtain a passing result. A valid signature is evidence about this message and route, not a guarantee of inbox placement or message safety.

Preserve the existing DMARC plan

Check both a direct policy at _dmarc of the From domain and any applicable inherited policy. Preserve enforcement, child-domain treatment, alignment settings and authorized report recipients. Do not create a second policy or weaken an inherited policy while publishing DKIM.

This narrow procedure assumes the domain owner already has an approved DMARC plan. If there is no applicable policy, complete that separate deployment before treating the mailbox route as fully accepted. The DKIM publication task is not permission to add a new reporting service, publish a weaker monitoring override or change enforcement.

If reporting is separately changed, a destination in a different Organizational Domain from the domain where the policy was found, including an inherited policy, requires the report-generating receiver to check DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted. Authorization in DNS does not replace the owner’s approval to share reporting data. Aggregate-report authorization.

Troubleshooting