Artfiles SPF, DKIM and DMARC setup, step by step

For an existing Artfiles mailbox domain using Artfiles nameservers, enable DKIM in DCP under E-Mail → Domains → your domain → E-Mail-Sicherheit → bearbeiten. Select DKIM and click Übernehmen. Artfiles documents automatic signing activation and DNS publication. Its native SPF authorization is include:spf.dcpserver.de, added to the domain’s single approved SPF policy, not as a second record. Artfiles DKIM instructions; SPF instructions.

This guide covers native Artfiles mailbox sending with Artfiles-authoritative DNS. It is not a setup procedure for a self-managed server, a third-party newsletter service, a different SMTP gateway or external DNS. Artfiles documents external-DNS aliases too, but those deployments need their own coordinated signing and DNS procedure. Do not move nameservers merely to follow this guide.

No customer account, DNS change or delivered-message test was performed.

Confirm the mailbox route and preserve existing settings

You need authorized access to the correct DCP account and domain, permission to change its email security and DNS, and a controlled external mailbox for a later test. Artfiles’ October 27, 2026 article says DKIM is available in all tariffs; it does not establish a universal administrator-role name. If the documented controls are missing, confirm account access and product scope with Artfiles instead of assuming an upgrade is required.

Identify the actual outgoing route. Receiving mail at Artfiles does not prove that a CRM, website or desktop client sends through Artfiles. Inventory every legitimate sending service and record the intended visible From address before editing authentication.

Confirm the authoritative DNS from the actual delegation. A domain registered at Artfiles can use another DNS operator, and a child zone or _domainkey namespace can be separately delegated. This automatic-publication procedure applies only where Artfiles controls the relevant authoritative namespace. If a delegation or conflicting record prevents that, stop and coordinate with its owner; do not remove the delegation.

Save the current SPF policy, relevant DKIM records and selectors, direct and inherited DMARC policies, authorized reporting destinations and TTLs. Preserve other legitimate senders and shared dependencies. Do not change MX, nameservers, DNSSEC, mailbox credentials or inbound routing to make an authentication example fit.

Set the single correct SPF policy in DCP

SPF normally checks the SMTP MAIL FROM domain, often reflected in Return-Path, or HELO for the applicable null reverse-path case. It does not automatically check the visible From address. Confirm which envelope identity the native route actually uses when you inspect a delivered message.

Artfiles gives this default for domains that send only through its native mail servers:

v=spf1 include:spf.dcpserver.de -all

This is an official provider policy, not a universal replacement for an existing multi-sender policy. If other authorized services use the same evaluated domain, reconcile their authorizations in one TXT record beginning v=spf1. Preserve the owner’s approved qualifiers and dependencies. Unrelated verification TXT records may coexist. Do not add a second SPF record, concatenate two complete policies or copy the sample IP range from Artfiles’ longer example.

1. Open Domains → DNS-Zonen → the intended domain in DCP.
2. Find TXT-Record and inspect the existing entries first.
3. If SPF already exists, edit that record to the reviewed single policy. Do not use the add control to create a duplicate.
4. If there is no policy at the evaluated owner, the SPF dropdown beside TXT-Eintrag hinzufügen can insert Artfiles’ default. Review the generated value against your sender inventory before saving. Manual entry is also documented.
5. Click Übernehmen at the bottom to save the approved change.

Artfiles’ zone-editor notation uses @ for the zone apex. For mail.example.com inside the example.com zone, the relative owner is mail; if mail.example.com is itself a separately delegated zone, its apex is @ in that zone. Check the resulting full owner rather than letting the interface append a domain twice. Keep the owner and quoted TXT data in the appropriate fields or DCP syntax; @ is not part of the SPF value.

Before saving, check the limit of ten evaluated DNS-dependent terms across nested SPF processing, not ten visible includes. Terms such as include, a, mx, ptr, exists and redirect can consume that budget. An all mechanism makes redirect ineffective, so appending -all to a delegated policy can change its meaning. Qualifiers produce SPF results, not deterministic inbox placement or rejection. RFC7208.

Artfiles advises allowing up to 24 hours for visibility. Actual caches follow TTLs and prior answers; this is not a guaranteed completion time or a reason to ignore an incorrect authoritative answer.

Enable native DKIM without replacing other senders’ keys

1. In DCP, open E-Mail → Domains and choose the existing mailbox domain.
2. Find E-Mail-Sicherheit and click bearbeiten.
3. In Erweiterte Sicherheitsfunktionen, select the DKIM checkbox.
4. Click Übernehmen.

Artfiles says this activates DKIM for the domain and adds its DNS records when Artfiles nameservers are used. The official screenshots show the DKIM checkbox and save button. If DKIM is already active and working, verify it rather than toggling it off and on.

For this native service, Artfiles publishes the keys itself and documents four provider-hosted CNAME aliases. The names below are relative to the sending domain, not values copied from another customer:

dcp-rsa-001._domainkey CNAME dcp-rsa-001._domainkey.dkim.dcpserver.de.
dcp-rsa-002._domainkey CNAME dcp-rsa-002._domainkey.dkim.dcpserver.de.
dcp-ed25519-001._domainkey CNAME dcp-ed25519-001._domainkey.dkim.dcpserver.de.
dcp-ed25519-002._domainkey CNAME dcp-ed25519-002._domainkey.dkim.dcpserver.de.

Use these to review the automatically published records, not to create duplicates after successful activation. Retain all four documented aliases and any unrelated selectors. For example.com, the first full owner is dcp-rsa-001._domainkey.example.com. In a parent zone publishing for a child sending domain, include that child label; in a separately delegated child zone, use the selector relative to that zone. A delegated _domainkey namespace requires coordination with its actual authority.

A CNAME owner cannot also contain a conflicting TXT, A, AAAA, MX or second CNAME record. If an existing owner conflicts, stop and determine what depends on it rather than deleting it blindly. Do not substitute an HTTP-proxied address or a flattened A/AAAA answer for the required alias. If the DNS service suppresses literal CNAME answers through per-record, whole-zone, apex or same-zone flattening, obtain an applicable supported configuration that preserves these aliases; do not globally disable unrelated DNS features. If no supported setting can preserve the answer, coordinate with Artfiles and the DNS operator before proceeding.

The private signing key stays with Artfiles. Do not request, publish or share it. Do not replace these aliases with a copied public TXT key: Artfiles explains that alias targets follow provider key changes, whereas a manually copied key needs separate updates. Its example default._domainkey TXT is for another provider’s DKIM record, not this native workflow. Current Artfiles explanation and record table.

Use the matching mailbox domain for SMTP authentication

Artfiles specifically requires the SMTP login mailbox domain and sender-address domain to match for this native signing path. An agency logging in with its own mailbox while using a customer’s visible From can produce an agency-domain signature instead of the intended customer-domain signature.

Use the approved existing mailbox and route for the intended brand. Do not solve a mismatch by rewriting From to the provider or agency domain, sharing credentials, or silently moving the application to a different account. Obtain the owner’s approved sending configuration if a route change is needed.

This is an Artfiles routing condition, not the protocol definition of alignment. DKIM authenticates the signature’s d= domain. DMARC compares that authenticated domain with the visible From domain. Under relaxed alignment they share the same Organizational Domain; strict adkim=s requires an exact domain match. SPF alignment separately compares the authenticated MAIL FROM domain with From, with exact matching under aspf=s. A child envelope domain is not automatically strictly aligned. Current DMARC specification, RFC9989.

Preserve DMARC while checking the new route

Check for both a direct policy and an applicable inherited policy before adding or changing DMARC. Keep an established enforcement policy and its authorized reporting destinations. Do not add a child p=none record that weakens inherited protection, create duplicate DMARC records or copy the old pct example from the support wiki. Current DMARC specifications no longer use pct for rollout.

Only if there is no applicable policy, the owner approves monitoring, and someone will review the results, a first-policy example is:

v=DMARC1; p=none

Publish it as a TXT at _dmarc relative to the sending-domain zone: _dmarc.example.com for example.com. For a child domain in a parent zone, include the child label; for a separately delegated child zone, use _dmarc there. This example requests no DMARC-specific enforcement and contains no report destination. It does not guarantee delivery or produce reports by itself.

If aggregate reports are wanted, arrange an approved destination and monitoring process before adding rua. A report destination in a different Organizational Domain requires the report-generating receiver to check DNS authorization; destinations within the same Organizational Domain are excepted. Protocol authorization does not replace the owner’s privacy and data-sharing decision. Never copy somebody else’s report mailbox. RFC9990 section 4.

Verify DNS and a real delivered message separately

Check authoritative DNS and then recursive resolution. These commands contain documentation placeholders; replace example.com with the intended domain. They are not fabricated test results:

dig TXT example.com
dig CNAME dcp-rsa-001._domainkey.example.com
dig CNAME dcp-rsa-002._domainkey.example.com
dig CNAME dcp-ed25519-001._domainkey.example.com
dig CNAME dcp-ed25519-002._domainkey.example.com
dig TXT _dmarc.example.com

Confirm one SPF policy at the actual evaluated owner, all four exact CNAME destinations, and the intended effective DMARC policy. For DKIM, also resolve the provider target to its complete public-key TXT. A DNS answer alone does not prove that outgoing mail is signed with the corresponding private key. If the sending domain has no direct DMARC answer, investigate applicable inheritance rather than assuming DMARC is absent.

Then send a harmless test from each intended native mailbox or application path to a controlled valid external recipient. Inspect the original delivered message in the receiving service. Use Authentication-Results generated inside that service’s known processing boundary, with its documented treatment of externally supplied result headers. Header position or a familiar authserv-id string alone does not establish trust. If that boundary cannot be established, use the receiving administrator’s authenticated message trace or another supported verification method; ignore attacker-supplied results. RFC8601.

Accept the new branded DKIM route only when:

• The intended Artfiles DKIM signature passes and its actual d= domain aligns with the unchanged intended visible From under the current policy. Check its s= selector against the published DNS owner.
• The trusted receiver reports dmarc=pass for that From domain. DMARC passing through SPF alone is not proof that the new DKIM route works.
• SPF is separately inspected at the real MAIL FROM identity. Diagnose fail, temporary DNS temperror and persistent configuration permerror separately, even if DKIM makes DMARC pass.
• Every relevant native sending path is tested, not just an unrelated webmail message.

For interpreting this distinction, see raw DKIM results versus aligned DKIM policy results. Passing authentication does not guarantee delivery, inbox placement or sender reputation.

Troubleshooting and safe recovery

DKIM active in DCP, but no public alias: Recheck authoritative DNS and any delegation. The automatic path depends on Artfiles DNS. Check all four owners and their exact targets. Do not keep adding identical records in a non-authoritative editor.

DKIM passes for the wrong domain: Compare SMTP login domain, actual signature d= and visible From. An agency mailbox is not the same sending identity as its customer. Check the approved account route before changing DNS.

SPF permerror: Look for multiple SPF policies, malformed syntax or an exceeded nested lookup budget. Do not remove other senders at random to fit a limit.

SPF fail or temperror: For fail, compare the actual sender and MAIL FROM with the approved policy. For temperror, investigate temporary resolution failures rather than replacing the policy. Forwarding changes the connecting server and can break SPF; a surviving aligned DKIM signature may help DMARC, but altered signed content can also break DKIM.

DKIM fails after a key change: Check that the aliases still resolve to the provider’s current public keys, without conflicting records or flattened answers. Avoid stale, manually copied key material.

A change disrupts legitimate sending: Pause the affected route, preserve the failed message and DNS evidence, and restore only the documented owner-approved previous state. Do not disable DKIM, weaken DMARC or delete shared selectors as a blanket repair. Recheck the actual route after recovery. Keep public-key aliases current and review authentication when a sending account, domain, application or DNS authority changes.

Sources and documentation date

Protocol interpretation follows the current standards where older explanatory examples differ.

• Artfiles: native DKIM activation and DNS records
• Artfiles: SPF record and DCP editor
• Artfiles: SPF, DKIM and DMARC explained, October 27, 2026
• RFC7208: SPF, RFC6376: DKIM, RFC8601: Authentication-Results
• RFC9989: DMARC, RFC9990: aggregate reporting

This is a documentation-based guide, not evidence of a customer deployment or a promise of authentication outcomes.