What is the DKIM record for current Webshop?

Publish webshop._domainkey.YOUR-SHOP-DOMAIN as a CNAME to dkim.shopfactory.io . The documented TTL is 3600 seconds.

Do I need to turn on a DKIM switch in the shop?

The current documentation says DanDomain handles signing for native shop mail. It does not provide a separate customer signing toggle. Verify the DNS and actual delivered signature rather than inventing an extra activation step.

Can I use the same records for Mailhotel or Classic Webshop?

No. Those are separate sending products with different documentation. A mailbox bundled with a shop is not the shop’s native order-email route.

Can another company host the DNS?

Yes. The current instructions direct you to the DNS manager serving the domain and explicitly recognize another DNS provider. Keep the existing authority and publish the correct owners there.

Does a template preview prove SPF or DKIM works?

No. A preview shows content, not the final SMTP route or receiver verification. Use an authorized native message delivered to a controlled external mailbox.

Should I change DMARC to none if order emails fail?

Do not downgrade an existing or inherited policy as a troubleshooting shortcut. Establish the failed authentication layer and correct the intended sender configuration.

DanDomain SPF, DKIM & DMARC Setup: Step-by-Step Guide

For native email from the current DanDomain Webshop, authorize include:spf.shopfactory.io in the sending domain’s single SPF policy and publish webshop._domainkey as a CNAME to dkim.shopfactory.io. DanDomain says its shop system handles outgoing DKIM signing. No separate customer signing toggle is documented in this procedure. DanDomain Webshop SPF setup and DKIM setup.

These records cover the current shop system’s order confirmations, order-status messages, invoices and similar native mail. They do not authenticate a bundled staff mailbox merely because it belongs to the same shop account. Keep existing SPF senders and DMARC protection intact, then verify a real message from the intended shop route.

Identify the current Webshop sending route

DanDomain’s current authentication overview explicitly describes mail generated by the webshop. It says the associated mail server signs outgoing messages and exposes the corresponding public verification data through the shop domain. Current Webshop mail flow.

Before touching DNS, record:

The current shop product and domain.
The exact intended visible From address used by native shop messages.
The authoritative DNS host, which may be DanDomain or another provider.
Other legitimate senders sharing the domain.
The administrator responsible for the shop and the person authorized to change DNS.
A safe, controlled way to receive a real native message for verification.

Use this guide for an existing current DanDomain Webshop, not for creating a new shop or migrating its domain. The reviewed procedure does not establish a special subscription tier or named administrative role for these DNS records. Confirm account-specific access rather than inventing a plan requirement.

Do not mix these DanDomain products

Classic Webshop has a separate authentication article and a different selector and target. Its records are not the current Webshop records. The Classic article itself directs current-Webshop users to the newer documentation. Classic Webshop scope distinction.

Mailhotel/Webhotel mailboxes use a separate mailbox sending route and separate DKIM instructions. The mailbox DNS article does not establish the same signing-activation workflow as the current shop system. Do not apply the shop’s automatic-signing statement to those mailboxes. DanDomain mailbox DKIM documentation.

Hosted Exchange and Office 365 are also separate. Configuring an email account in Outlook does not establish that a shop confirmation went through that account. Likewise, a third-party newsletter service requires its own authentication.

If staff mail uses Microsoft 365, retain that service’s authorization and tenant-issued DKIM records. The Microsoft 365 authentication guide covers that independent route.

Save the DNS state and map all senders

Export or otherwise preserve current records before editing. Include SPF, active DKIM selectors, DMARC, TTLs and any NS delegation under _domainkey. Identify the current authoritative nameservers rather than assuming that registration at DanDomain means DanDomain hosts the active zone.

List staff mailboxes, native shop mail, newsletters, invoicing services, website forms and other applications using the domain. For each route, identify the intended From and the actual envelope domain when evidence is available.

Do not change MX, website A/AAAA records, parent nameservers, DNSSEC, credentials or forwarding destinations to match an authentication example. Those changes affect routing or security outside this task. An inbound MX gateway is not automatically an authorized outbound sender.

For an existing _domainkey delegation, determine which DNS authority actually serves the selector name. Adding a record to the parent zone may have no effect below a delegation. Preserve the delegation and coordinate with its owner rather than deleting it.

Add the shop authorization to one SPF policy

DanDomain documents the following shop-only new-policy example:

v=spf1 include:spf.shopfactory.io -all

The type is TXT, the owner is the configured sending domain, and the documented TTL is 3600 seconds. The provider maintains the service authorization behind spf.shopfactory.io. Current shop SPF record.

Use the complete example only when there is no existing SPF policy at that owner and the shop is its only authorized sender. If a policy already exists, preserve legitimate senders and merge the required shop authorization into the approved policy. Do not add a second v=spf1 record.

DanDomain’s page illustrates a mixed policy with Microsoft 365 and a newsletter service. Those additional includes are examples, not instructions to authorize products you do not use. Its broader DanDomain, ScanNet and Wannafind examples also cover wider service sets; they are not automatic replacements for the scoped shop include.

Review the whole policy, not just the new include

Preserve the existing qualifier unless a deliberate policy change is approved. The shop’s new-policy example uses -all, which returns SPF fail for an unmatched source. It does not guarantee rejection by every receiver.

Inspect existing a and mx mechanisms for the addresses they authorize, including IPv6 where applicable. Do not remove a legitimate sender to simplify the policy, or authorize every inbound host without checking whether it actually sends.

A policy containing redirect= needs careful reconciliation: an all mechanism causes SPF to ignore redirect. Appending the sample’s -all can therefore disable the existing delegated policy. SPF redirect semantics.

The lookup budget is ten evaluated DNS-querying mechanisms and modifiers, with nested processing counted. Putting services behind another include does not bypass the limit. Long TXT data can use multiple character strings within one resource record; 255 characters is not a universal total-record limit. These details matter because the provider’s explanatory text oversimplifies both points. SPF lookup limits and SPF TXT strings.

Confirm which domain SPF actually evaluates

SPF normally authenticates SMTP MAIL FROM, commonly represented by Return-Path after delivery, rather than the visible From. HELO can be evaluated in applicable cases. The reviewed shop procedure does not document a universal MAIL FROM shape, custom bounce-domain control or strict-alignment guarantee. SPF identity definitions.

Follow the provider’s sending-domain DNS procedure, then observe the actual receiver-reported SPF identity. If the message uses a provider-owned envelope domain, do not invent a new DNS record on that provider’s behalf or claim that editing your apex policy changes its result.

Publish the current Webshop DKIM CNAME

The current shop record is:

Type: CNAME
Full owner: webshop._domainkey.YOUR-SHOP-DOMAIN
Target: dkim.shopfactory.io
Documented TTL: 3600 seconds

Replace YOUR-SHOP-DOMAIN with the actual configured domain. The CNAME is a published product value, not a tenant-generated token. Do not replace it with a TXT public key or generate your own private key for the hosted shop. Current DanDomain Webshop DKIM instructions.

DanDomain explicitly says it handles signing for mail sent through this shop system. Publishing the CNAME makes the provider’s verification data reachable under the domain; it does not prove that a particular message used the intended signature. No separate customer signing switch or Support-finalization step is specified by the reviewed current-Webshop procedure.

Map the owner to the right DNS zone

For a fictional shop sender domain example.com, the full owner is:

webshop._domainkey.example.com

In a DNS editor that appends example.com, enter the relative owner webshop._domainkey. The SPF owner is the apex, commonly @. An editor requiring a full name may need a trailing dot to avoid appending the zone again.

For a fictional sending domain shop.example.com:

Full DKIM owner: webshop._domainkey.shop.example.com.
Relative owner in the parent example.com zone: webshop._domainkey.shop.
Relative owner in a separately delegated shop.example.com zone: webshop._domainkey.
SPF owner: shop in the parent zone, or the apex of the delegated child zone.

These examples explain DNS name construction. They do not imply that an unconfigured shop can send as any subdomain.

If DanDomain hosts the authoritative DNS, use the relevant domain’s DNS-administration. Its current DNS instructions describe tilføj ny DNS record, opret record and Udgiv ændringer for publishing changes. Review the full saved owner before publication. If another provider hosts DNS, make the records there instead. DanDomain’s current DNS publishing instructions.

Preserve other owners and expose the required CNAME

Check whether the exact selector owner already exists. Do not add a CNAME alongside TXT, A, AAAA, MX or conflicting CNAME data at the same owner. Establish which service owns an existing record before replacing anything. Other DKIM selectors can coexist at different names. CNAME constraints.

Use DNS-only handling, not an HTTP proxy. If CNAME flattening would hide the required selector CNAME, choose the applicable exception or setting for that record. Inspect per-record, whole-zone, apex-only and same-zone behavior: a setting’s name alone does not establish what it changes. Do not globally disable flattening or change unrelated website records.

Keep an existing _domainkey NS delegation and publish through its actual authority. A DKIM CNAME is not a reason to move the domain’s nameservers.

Keep DMARC protection while onboarding the shop

Inspect the TXT record at _dmarc of the exact intended visible From domain. If there is no direct record, determine whether a parent policy applies. Preserve existing enforcement, alignment modes and approved report destinations. DMARC policy discovery.

The provider’s current DMARC article includes monitoring examples and says its interface may default to p=reject. Neither a sample nor a default is permission to replace the domain’s approved policy. Do not downgrade to p=none simply because a shop message fails. Correct the sender configuration while protecting other domain mail. DanDomain DMARC instructions.

Only where no direct or applicable inherited policy exists, and the owner approves an initial monitored deployment, a minimal value is:

v=DMARC1; p=none

Use type TXT, with these owner mappings:

From domain example.com: full owner _dmarc.example.com; relative owner _dmarc in that zone.
From domain shop.example.com: full owner _dmarc.shop.example.com; relative owner _dmarc.shop in the parent zone, or _dmarc in a delegated shop.example.com zone.

Publish one policy at the chosen owner. This minimal example requests no reports and no quarantine or rejection. It is not an override for inherited enforcement.

If aggregate reporting is wanted, add an approved functioning rua=mailto: destination and decide who reviews the reports, who can access them and how long they are retained. Reports describe sending activity; treat that as a data-sharing decision.

When the reporting destination is in a different Organizational Domain from the policy domain, the report-generating receiver must check the destination’s DNS authorization. A destination within the same Organizational Domain is excepted. This protocol check does not replace the owner’s privacy approval. RFC 9990 section 4.

Do not add failure reporting from a sample without a specific need and privacy review. Do not assume that every different hostname requires external-report authorization.

Verify public records before testing the shop

These read-only examples use fictional example.com. Substitute the actual configured sender domain:

dig TXT example.com
dig CNAME webshop._domainkey.example.com
dig TXT webshop._domainkey.example.com
dig TXT _dmarc.example.com

Confirm one applicable SPF policy at the intended owner and the exact CNAME target dkim.shopfactory.io. Follow the CNAME chain when diagnosing public-key availability. Compare authoritative answers with recursive responses and account for the previous TTL.

Check the final policy after publishing through the DNS editor. A pending change in a control panel is not the same as an authoritative public answer. Repeatedly adding records while caches expire can create duplicate policies and make the problem worse.

A public lookup proves only what DNS served at that time. It does not establish the signing domain, envelope identity or authentication outcome of a shop message.

Test native order mail without creating a commercial order

Use an authorized test mechanism available in your shop that sends an actual native order/status message only to a controlled recipient. If no safe mechanism is available, leave message verification pending and ask the shop administrator how to produce a non-commercial test. Do not place a real order, charge a customer or send a customer notification merely to test authentication.

DanDomain’s Indstillinger → E-mailindhold instructions concern template text. A preview checks presentation, not SMTP authentication. Likewise, a copy received by the shop owner is useful only if it follows the route you intend to validate. DanDomain email-template instructions.

Save the raw externally received message and inspect:

The intended and delivered visible From.
The actual MAIL FROM/Return-Path and receiver-reported SPF identity.
Every DKIM signature’s signing domain d=, selector s= and result.
The DMARC result and applicable strict or relaxed alignment modes.
The exact message type and any intermediary processing.

Use Authentication-Results produced inside the receiving service’s known processing boundary, with its documented treatment of externally supplied Authentication-Results. Ignore untrusted fields inserted before that boundary. Header position or a familiar authserv-id string is not sufficient proof; ask the receiving administrator when provenance is unclear. Authentication-Results trust boundary.

For completion, the intended shop signature must pass with s=webshop and a d= domain aligned to the unchanged intended visible From, and the trusted receiver must report dmarc=pass. A provider-rewritten From or a different service’s passing signature does not establish that the intended shop identity works.

DMARC can pass through either aligned SPF or aligned DKIM. A generic DMARC pass carried only by SPF is insufficient evidence for this DKIM setup. Relaxed alignment uses the same Organizational Domain; strict alignment requires an exact domain match. Check actual identities rather than treating every subdomain as a strict match. DMARC alignment.

Even when DKIM carries DMARC, investigate SPF fail, temperror or permerror independently. Authentication success on one path must not hide an unrelated DNS or sender-policy fault.

Troubleshoot by product and failure layer

The selector is wrong: confirm that the account is current Webshop, not Classic or a mailbox service. The current native shop selector is webshop; another product’s record does not validate this route.

The CNAME is absent: check the full owner, duplicated suffixes, the active DNS authority, pending publication, existing delegation and conditional proxy/flattening behavior.

SPF permerror: look for multiple SPF policies, syntax errors and the evaluated nested lookup budget. Do not add the shop-only example as a second record.

SPF temperror: investigate temporary DNS failures before rewriting the policy. SPF fail: compare the evaluated envelope domain and final sending IP with the actual authorizations.

The intended shop signature is missing: verify that the message was native shop mail, not a mailbox message, newsletter-platform send or preview. Preserve the received evidence and ask DanDomain to investigate the actual route; do not invent an activation toggle.

DKIM fails despite correct DNS: compare d= and s=, complete key lookup and any modifications to signed content. A gateway adding a footer can matter even when the published record is correct.

DKIM passes but DMARC fails: establish which signature passed and whether its domain aligns. Do not weaken the whole domain’s DMARC policy to conceal a route-specific problem.

All authentication passes but delivery is poor: keep the recipient’s SMTP response and examine reputation, content, permission and recipient filtering. SPF, DKIM and DMARC do not guarantee inbox placement or block every malicious message.

Preserve a narrow recovery path

Retain the original DNS export, approved diff, public results, test-message identifier and redacted headers. Document any unresolved message types instead of calling the entire shop verified after one unrelated success.

If a change fails, pause the affected sending activity or use an already approved route where operationally possible. Restore only records changed for this integration after checking whether other legitimate senders depend on them. Keep keys needed by delayed messages and do not remove a shared SPF include casually.

Recheck after a domain change, shop-platform migration, sender-identity change or gateway modification. A previously passing order message does not prove that a new newsletter or invoicing integration uses the same path.

Documentation and testing limits

Current DanDomain Webshop authentication, SPF, DKIM, DMARC and email-template instructions were read in full, with separate mailbox, Classic and Hosted Exchange materials checked for scope exclusions. The core current-Webshop pages do not expose reliable publication dates in the reviewed material. No shop account, DNS change, commercial order or test delivery was performed.

DanDomain SPF, DKIM and DMARC setup, step by step