Domeneshop SPF, DKIM and DMARC setup, step by step

For a native Domeneshop mailbox still managed in the legacy Client Area, SPF uses include:_spf.domeneshop.no. Domeneshop documents automatic SPF and DKIM setup when it also hosts that domain’s DNS. With external DNS, open the legacy domain’s Epost page and copy the missing-record instructions shown below the mailboxes, including the exact generated DKIM CNAME. Then verify public DNS and a fresh message’s intended aligned DKIM signature and DMARC result. Do not apply these records to new-platform or migrated email services. Legacy SPF procedure · Automatic setup · External-DNS record instructions

This guide is based on public provider documentation. No customer-account configuration, DNS changes or live sending tests were performed.

In this guide

• First confirm that this is the legacy email service
• Identify the sender and authoritative DNS
• Configure legacy SPF without losing other senders
• Check automatic DKIM or publish the issued CNAME
• Preserve the effective DMARC policy
• Verify DNS and a delivered mailbox message
• Troubleshoot the legacy setup
• Frequently asked questions

First confirm that this is the legacy email service

Domeneshop has separate legacy and new customer platforms. Its login FAQ says earlier services remain on the legacy platform until migration is complete, and an existing customer can also have a new-platform account. Account age alone therefore cannot identify the service you are configuring. Official platform and login explanation

Before changing DNS:

1. Use the legacy Client Area login option and inspect the actual domain and email service.
2. Confirm that the service is still managed through Mine domener (My domains) → the domain → Epost (Email), or Administrere epost (Manage email).
3. Check the current service-specific client settings. The documented legacy outgoing server is smtp.domeneshop.no.
4. If the service has migrated, or its mailbox controls are under Email Hosting → View details → Manage Mailboxes, stop using this guide. If its location is unclear, ask Domeneshop to identify the platform before editing authentication records.

The legacy mail-client instructions specify smtp.domeneshop.no, with port 587 and STARTTLS or port 465 and TLS. The new-platform settings instead document mail1.no1.essentialhosting.net; its mailbox-management workflow is also different. An old mail-client setting is only a cross-check, not proof that the service has not migrated.

For new-platform mail, obtain that service’s current SPF authorization, DKIM issuance and activation instructions from its account controls or Domeneshop support. Do not assume the legacy include or selector covers a new server because both services use the same brand. This guide does not establish new-platform authentication values.

Which legacy sending routes are covered?

This procedure covers ordinary personal and office mailbox email using Domeneshop’s native legacy service. The provider says smtp.domeneshop.no is not intended for cloud services, webservers, newsletters, marketing, bulk or automated server/device mail. The same restriction applies to its legacy webmail service. Do not route a CRM, contact form or bulk campaign through this SMTP server to fit these instructions. Use an appropriate supported sending service and authenticate it separately. Permitted legacy SMTP use

Microsoft 365 resale, external mail providers, DNS-only customers and self-managed servers are outside this setup. A domain registered at Domeneshop does not necessarily send mail through Domeneshop. Website PHP mail also needs its own route and envelope-identity evidence; mailbox authentication does not prove that scripts align.

Identify the sender and authoritative DNS

You need authorized access to the legacy domain/email controls and permission to manage its authoritative DNS, or cooperation from the DNS administrator. Save the existing records before making changes. Inventory the visible From domain, legitimate sending services, current SPF policy, DKIM selectors, and direct or inherited DMARC policy and report destinations.

Identify the name servers actually answering for the domain. For a sending subdomain, check whether its zone or _domainkey namespace is separately delegated. Edit the authoritative zone, not an inactive registrar panel. Changing name servers or MX records is not required merely to add SPF and DKIM to an existing working mailbox service.

Keep these identities separate:

• Visible From domain: the address domain readers see and DMARC evaluates.
• SPF envelope domain: the SMTP MAIL FROM identity, normally reported as smtp.mailfrom by the receiver.
• DKIM signing domain and selector: the signature’s d= and s= values, which determine the public-key lookup.

The legacy setup pages do not promise one universal envelope template for every route. Verify the identity actually used. Adding an SPF include at the visible domain cannot change a different envelope sender. SPF identity · DMARC alignment

Configure legacy SPF without losing other senders

Understand the documented value and qualifier difference

Domeneshop’s dedicated legacy SPF page gives this default for a domain sending only through its native service:

v=spf1 include:_spf.domeneshop.no ~all

However, its legacy external-DNS/MX FAQ gives an otherwise identical example ending in -all. Both authorize the same Domeneshop include, but the unmatched-source result differs. Preserve the qualifier deliberately chosen for your existing policy; do not silently weaken -all to ~all, or tighten ~all to -all, merely to match one tutorial. Dedicated SPF default · External-DNS/MX example

For a genuinely new, Domeneshop-only legacy policy, the dedicated SPF guide’s default above is the documented starting example. Confirm that it covers the actual sender inventory before publishing. ~all produces SPF softfail for unmatched sources, while -all produces fail. Neither is a universal promise of delivery or rejection; the receiving system decides how to use the result. SPF result handling

For an illustrative envelope domain example.com, the TXT owner is example.com. Editors that append the zone commonly use @ or an empty field for that apex, as the provider’s warning screenshot illustrates. If the evaluated envelope domain is a subdomain, use that exact owner instead.

When Domeneshop hosts the legacy domain’s DNS

Domeneshop says it automatically configures SPF and DKIM for domains with both its native email and DNS. Inspect the current public policy before adding anything. Automatic configuration

If the SPF policy needs adjustment, the documented legacy wizard is:

1. Open Mine domener and select the domain.
2. Select Epost.
3. Choose Vis avanserte innstillinger (Show advanced settings).
4. Scroll to Redigere SPF (Edit SPF).
5. Review the selected providers, retaining every service still authorized to send for this SPF owner.
6. Save the intended policy and verify its public TXT value.

For manual editing, use the domain’s DNS-pekere (DNS records) → Vis avanserte innstillinger and edit the relevant TXT record. Do not follow an add-new workflow when an SPF policy already exists. SPF wizard · Advanced DNS editing

When another provider hosts DNS

In the legacy email page, inspect the warnings below the mailbox list. The SPF warning supplies the required record information. Publish or merge it at the external authoritative DNS host; the legacy warning itself does not update that provider’s zone.

There must be one SPF policy per evaluated owner, not one per sender. If an existing record begins v=spf1, amend that single policy to retain its legitimate dependencies. Do not concatenate complete policies or add a second SPF TXT record. Other unrelated TXT records should remain. SPF record uniqueness

For a shared-sender policy, insert the required authorization before its terminal all mechanism and preserve its intended behavior. If it uses a redirect, has unfamiliar mechanisms, or serves other applications, have its owner review the entire policy rather than applying a blind merge. Obtain each external sender’s current requirements from that sender, not from a screenshot or placeholder example.

If the existing SPF policy uses redirect=, reconcile its authorizations and terminal behavior with the DNS owner before changing it. Any all mechanism makes redirect ignored regardless of their order. Do not append all automatically: preserve the redirected senders and approved policy semantics through a reviewed redesign. SPF qualifiers describe authentication results, not guaranteed receiver delivery or rejection decisions. SPF all and redirect processing.

Validate the expanded policy against SPF’s limit of 10 DNS-lookup-causing terms, including nested include and redirect evaluation. Counting only top-level includes is insufficient. Investigate excessive void lookups and DNS errors too. Do not freeze the provider’s current IP addresses into a replacement policy that will become stale. SPF processing limits

Check automatic DKIM or publish the issued CNAME

Native email and Domeneshop DNS

For the in-scope legacy service with Domeneshop DNS, the provider documents automatic DKIM setup. There is no need to generate a private key in another tool or invent a manual enable-signing step. Confirm the current DNS and delivered signature instead. A missing signature or unresolved key needs investigation even when the account has no warning. Automatic setup

Native email with external DNS

Use the provider’s documented record-retrieval path:

1. Sign in to Min konto (My account) on the legacy platform.
2. Open Mine domener and select the affected domain.
3. Choose Epost or Administrere epost.
4. Scroll below the email addresses and users to the missing-record warnings.
5. Read the DKIM warning and copy its Vertsnavn (hostname), Type, and Data (target) as a matched set.
6. Publish that record at the authoritative DNS provider, then check the public answer and a new message.

The official screenshot shows a CNAME example using selector ds2023. That selector and the screenshot’s customer-domain target are illustrative, not universal current values. Use the exact record issued for your domain. If the warning is absent and you need to confirm an existing setup, inspect the actual signature and DNS records or ask support; do not manufacture a selector. Warning and copy procedure · Domain-specific DKIM records

Publish the CNAME at the right owner

Preserve the issued record type and full target. A CNAME target is a hostname, not a URL or a v=DKIM1 public-key string. Do not replace the CNAME with a copied TXT key: the provider may maintain the target’s verification data.

These examples explain owner mapping only. ISSUED_SELECTOR is a placeholder, not a value to publish:

• For full owner ISSUED_SELECTOR._domainkey.example.com in a DNS editor that appends the example.com zone, the relative host is ISSUED_SELECTOR._domainkey.
• If _domainkey.example.com is separately delegated and you are editing that child zone, the relative host is ISSUED_SELECTOR.
• For a generated owner under signing domain mail.example.com, a separately managed mail.example.com zone uses ISSUED_SELECTOR._domainkey; the parent example.com zone would use ISSUED_SELECTOR._domainkey.mail if it were authoritative for that name.

Editors accepting full names can use the complete issued owner according to their naming convention. Check the final expanded name to avoid a duplicated suffix. Do not put a selector record at @ merely because the From address uses the root domain.

A CNAME cannot share its owner with a conflicting TXT, A or other ordinary record. Identify existing dependencies before replacing data. Preserve other selectors and any existing _domainkey delegation; changing that delegation can affect every sender under it. CNAME rules

If the DNS host offers proxying or CNAME flattening

For the issued legacy external-DNS DKIM CNAME, use the following DNS-host controls. Where literal CNAME answers are required, use DNS-only aliases returning the exact issued targets, without HTTP proxying or flattening hiding them. Turn the relevant per-record Flatten control off when available and ensure applicable zone-wide settings preserve those aliases. Cloudflare documents that 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 conditional DNS-host behaviors, not assumed controls in every panel. If mandatory apex/same-zone behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sending service. Do not blindly change the whole zone or remove an existing NS delegation. Cloudflare CNAME verification, flattening controls and limits.

Do not disable proxying for the whole website or change a zone-wide setting without reviewing other records that rely on it. If a shared setting cannot be adjusted narrowly, coordinate a supported solution with the DNS administrator and provider. Leave unrelated DNSSEC, MX and website records unchanged. Query the issued owner to confirm the actual CNAME is returned and the target resolves to DKIM verification data.

Preserve the effective DMARC policy

The legacy DMARC guide says Domeneshop supplies a basic p=quarantine policy for its email customers. Inspect the actual authoritative record before assuming one is absent. Do not overwrite an existing policy with a screenshot’s value or with a new p=none starter. The legacy DMARC-policy control changes policy; it is not a required DKIM activation step. Legacy DMARC configuration

Check _dmarc under the visible From domain and establish any applicable parent or organizational-domain policy. Preserve enforcement, alignment modes, reporting destinations and subdomain treatment. A missing direct subdomain record does not prove there is no inherited policy. Repair duplicates or malformed records with their owner rather than adding another policy. DMARC policy discovery

Only if no direct or inherited policy applies, and the owner chooses a first non-enforcing policy, this minimal example applies to example.com:

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

Use _dmarc in an editor that appends the example.com zone. For From domain mail.example.com, the full owner is _dmarc.mail.example.com: use _dmarc.mail in the parent zone or _dmarc in a separately delegated mail.example.com zone. Verify the final owner.

This record requests no reports. Add rua only for a real, approved reporting destination and a monitoring plan. Review report access, retention and privacy because aggregate reports expose sending and authentication metadata. Do not send reports to a tutorial address or casually enable failure reports.

Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, which is 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 the policy domain is excepted; a different hostname alone does not make it external. Follow the report receiver's exact authorization instructions when needed. This protocol check is separate from the domain owner's approval to share report data with that recipient. RFC 9990 section 4.

DMARC needs an aligned SPF or DKIM pass. Relaxed alignment, the default when the relevant alignment tag is omitted, permits the appropriate organizational-domain match; strict alignment requires an exact domain match. Retain existing aspf and adkim choices. Review every legitimate sender before changing enforcement, not just one successful legacy mailbox message. Alignment requirements

Verify DNS and a delivered mailbox message

Check the public records first

Replace the example domain and uppercase placeholders with your actual authoritative server, issued DKIM owner and CNAME target. These are reader instructions, not results of tests performed for this guide.

dig NS example.com +short
dig @AUTHORITATIVE_NS example.com TXT +noall +answer
dig @AUTHORITATIVE_NS ISSUED_DKIM_OWNER CNAME +noall +answer
dig @AUTHORITATIVE_NS _dmarc.example.com TXT +noall +answer
dig @1.1.1.1 example.com TXT +noall +answer
dig @1.1.1.1 ISSUED_DKIM_OWNER CNAME +noall +answer
dig @1.1.1.1 ISSUED_CNAME_TARGET TXT +noall +answer
dig @1.1.1.1 _dmarc.example.com TXT +noall +answer

Use the appropriate authoritative server for each owner if subdomains are delegated. For automatically managed DKIM, inspect the record type actually in use rather than converting it to match an example. Compare authoritative and recursive answers after relevant TTLs expire. Expect one valid SPF policy at the envelope domain, the exact issued CNAME and retrievable key for external-DNS DKIM, and the intended effective DMARC policy.

An account warning disappearing is useful configuration evidence, not proof that a message was signed. Likewise, a public key cannot prove that the sender used the corresponding private key.

Verify the exact permitted mailbox route

Send a fresh ordinary mailbox message through the legacy service to an independent mailbox you control. Confirm the email client uses the service’s current authenticated SMTP settings, not an external account. Open the received original’s headers or a receiver-side trace.

Trust only authentication results added by receiving infrastructure you control or trust. Attackers can prepend Authentication-Results, including a plausible authserv-id. If the receiver cannot distinguish or remove untrusted fields, use an independent trusted mailbox or trace instead of treating a matching label as proof. Authentication-Results trust boundary

Record and compare:

1. Visible From: the domain whose mail you intend to authenticate.
2. SPF: the result, actual smtp.mailfrom domain and sending IP. Expect spf=pass on a direct properly authorized route; evaluate alignment separately.
3. DKIM: the intended Domeneshop signature’s d= domain and s= selector, correlated with its trusted dkim=pass. Its signing domain must align with the visible From under the effective policy.
4. DMARC: a trusted dmarc=pass for that From domain.

Keep each signature’s domain, selector and result together when several signatures appear. EmailAuth’s DKIM selector guide explains how to derive the correct key lookup from the received signature rather than guessing a selector from the provider name.

Completion requires the intended aligned DKIM pass and DMARC pass. A DMARC pass supplied only by SPF does not establish working DKIM, and an unrelated provider-domain signature is not proof of branded signing. Investigate independent SPF faults even if DKIM lets DMARC pass: fail may indicate an unauthorized route, temperror a temporary evaluation issue, and permerror an invalid, duplicate or over-budget policy. SPF that passes but does not align is a separate condition, not a reason to ignore actual failures.

Troubleshoot the legacy setup

The menus or SMTP server do not match

Recheck the actual service’s platform and migration status. Do not force the legacy record set onto Email Hosting → View details → Manage Mailboxes or the new platform’s mail server. Ask Domeneshop for current authentication instructions for that service.

SPF broke after adding another sender

Check for a second v=spf1 record, a lost existing include, a mechanism inserted after all, a changed qualifier, or excessive nested lookups. Repair the single policy while preserving legitimate senders. Test both the Domeneshop mailbox and the other authorized route afterward.

External DKIM still shows a warning

Compare the current warning’s exact owner, type and target with the authoritative answer. Look for a doubled suffix, inactive DNS panel, conflicting record, proxying, flattening or cached old data. Do not keep replacing the selector with ds2023 just because it appears in the screenshot.

There is no warning, but the message is unsigned or DKIM fails

Check the actual outgoing server and workflow first. Then compare the received d= and s= values with public DNS. Missing keys, an incorrect target, stale selectors or changes to signed content require different remedies. A no-warning state is not a substitute for trusted delivered-message evidence.

Mailbox mail works, but a form or campaign fails

The legacy SMTP service excludes automated server, cloud, bulk and marketing use. Do not work around the restriction by putting mailbox credentials into that application. Use an appropriate supported sender and configure its authentication separately, preserving the mailbox’s records.

Authentication passes, but mail still goes to spam

Review the recipient’s rejection or filtering evidence, reputation, content and sending behavior. Authentication does not guarantee acceptance or inbox placement. Forwarding is also a separate path: a mailbox’s direct-send result does not establish what survives after forwarding.

For support, keep the domain’s platform, current record instructions, authoritative answers, sending route, timestamp and trusted result lines together. Redact message content and personal addresses when sharing evidence; never send passwords or private keys.