mailXpert SPF, DKIM and DMARC setup, step by step

mailXpert authenticates its native newsletter route through the records shown in your account, not a universal SPF include pasted into your root domain. Add the domain under Verwaltung → Konfiguration → Absender-Domains, open its eye-icon detail view, publish the issued records at your authoritative DNS host, and run DNS-Abfrage starten. Then select the approved From address in each relevant contact list and validate an actual mailXpert message.

The documented five-record set contains a verification TXT record, a bounce CNAME, two DKIM CNAMEs and a DMARC TXT record. The bounce CNAME leads to mailXpert-managed SPF. Account values, existing DNS dependencies and your current DMARC policy govern what you publish. A green DNS status is not proof that a delivered message used aligned DKIM. Official domain setup

Scope and prerequisites

This guide covers mailXpert's native sending-domain configuration and contact-list sender settings. It does not configure a mailbox, external SMTP service, another newsletter product or a website's application mail. Authenticating mailXpert does not authorize all other systems using your domain.

Have the following ready:

• An approved sending domain and From address, plus a monitored Reply-To mailbox.
• Access to the relevant mailXpert configuration and contact-list settings. mailXpert permissions are assigned through user groups and menu/submenu rights; do not assume every user can change them. If an option is missing, ask your account administrator to establish the appropriate existing access rather than granting broad rights. User permissions
• A DNS administrator for the zone that actually answers for the issued names. Your registrar, website host and authoritative DNS host can be different companies.
• A saved copy of current relevant DNS records, list sender settings, applicable DMARC policy and legitimate sending dependencies.
• Controlled recipients for a later native-route test. No customer campaign should be used as a test audience.

The cited setup instructions do not establish a particular paid-plan or regional entitlement. Confirm access in your account. Per-language sender settings specifically require the subscribed Mehrsprachigkeit option. mailXpert cannot publish your DNS records for you; that work belongs to your authorized DNS administrator or hosting provider.

1. Obtain the five records from your account

1. Open Verwaltung → Konfiguration → Absender-Domains.
2. Add every domain you intend to use after the @ in a From address. For example, newsletter@news.example.com uses news.example.com, not automatically example.com.
3. Find the domain and select the eye icon under Aktionen.
4. Record the exact DNS-Name, DNS Typ, DNS TTL and DNS Wert from each row. The detail view also offers Download als PDF, which can help your DNS administrator work from the same account-issued instructions.
5. Compare the packet with existing records before making changes. The public screenshot uses a demonstration domain and is not a source of tenant values.

The current setup page and its detail screenshot establish this five-record workflow. They do not require you to generate a key pair or paste a private key anywhere. mailXpert's CNAME targets provide the public authentication data. If your account shows a different packet, resolve that difference with mailXpert before substituting records from this guide. Setup and issued-record view

2. Publish at the correct DNS owners

Make approved changes in the authoritative zone, not simply whichever control panel hosts your website. Preserve unrelated records, inbound-mail MX, nameserver delegations and DNSSEC. This workflow is not an instruction to migrate DNS or change mailbox routing.

The following table demonstrates name entry only. SELECTOR and BOUNCE are placeholders for the exact labels issued by mailXpert. example.com is a reserved example, not your domain.

If the editor expects a full name, enter the full issued owner instead. A trailing dot can mark an absolute DNS name in tools that support that convention; use your DNS host's documented input format. Inspect the saved result to catch an accidentally duplicated suffix. Preserve _domainkey underscores and both selectors.

For an existing delegated _domainkey namespace, work with its authoritative operator. Do not delete the NS delegation to make the parent's zone editor accept records. If an issued owner falls at a delegated zone apex, its required SOA/NS data can conflict with a CNAME; stop for a supported design rather than forcing the alias there.

Resolve CNAME conflicts without breaking another sender

A CNAME owner must not also contain a competing TXT, A, AAAA, MX or different CNAME. If another service already owns an issued selector, do not overwrite it or invent a replacement selector.

mailXpert's red-status FAQ specifically says its illustrated mx1 selector cannot be customized and suggests another sending domain or subdomain when it is occupied. Treat that as a conflict-resolution boundary, not permission to move a live sender without approval. Arrange a suitable domain, obtain its own account packet and update the affected list settings deliberately. Official conflict guidance

Keep the required CNAME answers visible

Where your DNS host offers an HTTP proxy, publish these authentication aliases as DNS only, not proxied web traffic. For Cloudflare, use its proxy-status guidance.

Where literal CNAME answers are required, turn a relevant per-record Flatten control off when available, and ensure applicable whole-zone settings do not flatten these issued aliases. Coordinate shared-setting changes with the DNS owner so other applications keep working. Cloudflare always flattens apex aliases and documents same-zone behavior that can apply regardless of the selected setting. If such mandatory behavior prevents the required CNAME response, stop and coordinate a supported configuration; do not remove delegations or invent a bypass. Cloudflare CNAME-flattening settings

3. Understand why no extra apex SPF record is needed

mailXpert's SPF documentation says its SMTP HELO/EHLO and MAIL FROM domain are normally a bounce subdomain such as bnc.your-sending-domain. The issued CNAME points that name to a mailXpert-controlled domain containing the effective SPF policy. mailXpert updates that policy as its infrastructure changes. Why mailXpert does not require a separate SPF record

Therefore:

• Publish the actual issued bounce CNAME, not a guessed include: at your root domain.
• Do not add an SPF TXT beside that CNAME. It would conflict at the same DNS owner.
• Do not erase your existing apex SPF policy. It may authorize your normal mailbox service or other legitimate senders.
• Inspect the actual smtp.mailfrom identity on a received mailXpert message. “Normally” is not proof of every account's envelope identity.

SPF evaluates SMTP identities, not the visible From address. For any SPF owner you independently manage, maintain one v=spf1 policy, preserve legitimate authorizations and qualifiers, and account for the limit of 10 evaluated DNS-dependent terms, including nested mechanisms. An all mechanism causes redirect to be ignored. None of those rules calls for editing mailXpert's managed policy or blindly changing ~all, -all or ?all. SPF results do not guarantee a receiver's delivery decision. RFC 7208

A bounce identity such as bnc.news.example.com can align with From news.example.com under relaxed DMARC alignment when they share the appropriate Organizational Domain. It does not exactly match under strict SPF alignment. Do not loosen aspf simply to make a test pass; check the intended DKIM path and actual policy first.

4. Preserve DMARC while completing the domain setup

mailXpert's five-record view includes DMARC and labels p=none as a minimum example, with other values possible. It does not require downgrading a working p=quarantine or p=reject policy.

Have the domain owner inspect both the direct policy and any applicable inherited policy before adding a record. Keep existing protection, alignment modes and authorized reporting destinations. Do not create a second DMARC policy at the same owner, or create a weaker child policy merely because the screenshot shows one. If the product's checker does not accept a legitimate inherited arrangement, resolve that with mailXpert and the policy owner before creating an override.

Only if no direct or applicable inherited policy exists, the owner approves a first monitoring policy and there is an appropriate monitoring plan, this is a minimal TXT value:

v=DMARC1; p=none

That value alone does not collect aggregate reports. Use the full owner corresponding to the intended From domain:

Add rua only for an actual authorized reporting destination. If the report destination is in a different Organizational Domain from the domain where the policy was found, the report-generating receiver must check DNS authorization. A destination within that same Organizational Domain is excepted; a different hostname alone does not make it external. That protocol authorization is separate from the owner's privacy and data-sharing approval. RFC 9990 §4

Review monitoring evidence across all legitimate senders before any enforcement change. mailXpert setup does not authorize weakening an existing policy or imposing a new enforcement policy on other services. Current DMARC standard, RFC 9989

5. Recheck DNS in mailXpert

Return to the domain's eye-icon detail page and select DNS-Abfrage starten. Check each row's status and Abfrageresultat against the required name, type and value. A saved DNS-editor entry is not enough: it must be available from the correct authority and subsequently visible through recursive DNS.

These are read-only diagnostic examples. Replace all uppercase placeholders with your actual account-issued names and a resolver or authoritative nameserver approved for your investigation. They do not publish records or display fabricated successful results.

dig @AUTHORITATIVE_NS TXT VERIFICATION_OWNER +noall +answer
dig @AUTHORITATIVE_NS CNAME BOUNCE_OWNER +noall +answer
dig @AUTHORITATIVE_NS CNAME FIRST_DKIM_OWNER +noall +answer
dig @AUTHORITATIVE_NS CNAME SECOND_DKIM_OWNER +noall +answer
dig @RECURSIVE_RESOLVER TXT BOUNCE_OWNER +noall +answer
dig @RECURSIVE_RESOLVER TXT FIRST_DKIM_OWNER +noall +answer
dig @RECURSIVE_RESOLVER TXT SECOND_DKIM_OWNER +noall +answer

Compare literal CNAME answers with the issued targets. A recursive TXT lookup can follow an alias to the effective SPF or public DKIM data. Do not confuse the verification token with v=spf1 or a public DKIM key. Investigate empty answers, wrong targets, truncated data and resolver errors rather than treating any response as a pass.

The setup screenshot recommends a 24-hour TTL but explicitly permits other values; the older red-status FAQ suggests four to eight hours. Neither is an end-to-end activation guarantee. Use the account's current guidance and your DNS operator's cache/change plan, including the old TTL when correcting an existing record.

If the authoritative data and independent recursive answers are correct but mailXpert remains red, retain the exact affected names, expected/observed values and timestamps for Support. No separate universal “enable DKIM” switch is established by these sources: the documented flow is account-issued records and DNS checking, followed by sender selection and message evidence.

6. Set the sender for every relevant contact list

Domain authentication does not automatically choose the right From address for every list.

1. Open Kontakte. The standard contact list initially loads.
2. Select the contact-list name at the far left of the subnavigation to open its dropdown.
3. Choose Verwaltung von Kontaktlisten.
4. Hover over the intended list's row and select the pencil icon.
5. Set Standard Absender Name and Standard Absender E-Mail Adresse to the approved identity using the authenticated domain.
6. Set Standard Antwort Name and Standard Antwort E-Mail Adresse to the approved, monitored reply destination.
7. If multilingual sending is subscribed, review each language's values. Select Speichern, then reopen the intended list to confirm what was saved.

The screenshot also shows a dynamic-sender option. Do not enable it as part of DNS setup. If an existing workflow uses variable senders, inventory and authenticate every resulting From domain and test representative paths rather than assuming one default covers them all.

Repeat the review for newly created lists and languages. A Reply-To address directs replies; it does not replace the From identity used by DMARC. Official list-specific sender instructions

7. Accept the setup only after a native-route message check

After the account accepts DNS and the correct list sender is saved, use a small controlled recipient list or approved test segment to send a non-sensitive message through the actual mailXpert route you intend to use. Inspect the audience and any schedule or automation before sending. Do not start a broad mailing, enroll real customers or test from your ordinary mailbox instead.

For a preview or test-send facility, first establish that it uses the same envelope and signing configuration as the intended campaign. If it does not, use a controlled native campaign path. The documented trial exception, which permits up to 10 sendings through e-mail-newsletter.ch, does not demonstrate your own domain's authentication.

In the receiving service, open the raw message or its trusted authentication diagnostics. Establish which Authentication-Results fields were produced inside that service's known receiving boundary, using its documented treatment of externally supplied result headers. Header position or a familiar authserv-id string alone is not proof; ignore attacker-supplied results. RFC 8601

Record and require:

• The intended visible From is unchanged, not silently rewritten to a provider domain.
• The intended mailXpert DKIM signature reports dkim=pass. Keep its d= signing domain and s= selector together.
• That signature aligns with From under the applicable adkim mode: exact domain equality for strict mode, the proper Organizational Domain relationship for relaxed mode.
• The trusted receiver reports dmarc=pass for the intended From domain. SPF-only DMARC success is not evidence that the newly configured DKIM route works.
• The actual SPF identity/result is recorded separately. Investigate fail, temperror and permerror even if aligned DKIM provides the DMARC pass.
• Replies reach the intended monitored mailbox in an authorized reply test. Bounce handling is assessed from legitimate observed events or a provider-approved procedure, not deliberate mail to invented addresses.

For multiple signatures or a confusing green result, see EmailAuth's raw DKIM results versus aligned DKIM policy results. One passed message is evidence for that path, not all lists, languages, automations or recipients, and authentication does not guarantee inbox placement.

Troubleshooting and safe rollback

The older FAQ's instruction to “always add a new TXT record” is appropriate only for an independent token where coexistence is valid. It is not permission for duplicate SPF or DMARC policies, or TXT beside a CNAME.

If a change causes trouble, pause only the affected mailing or automation through its authorized owner. Restore the prior approved list sender and only the DNS changes whose ownership and effects are understood. Keep records needed by queued mail, verification, bounces and other senders until dependencies are checked. Do not delete both DKIM selectors, change MX, remove shared delegations or weaken DMARC as a quick rollback. Recheck DNS, the product state and a fresh controlled message after repair.

Sources and documentary check

• mailXpert [sending-domain setup](https://mailxpert.zendesk.
• mailXpert [managed SPF explanation](https://mailxpert.zendesk.
• mailXpert [contact-list sender settings](https://mailxpert.zendesk.
• mailXpert [red-status troubleshooting](https://mailxpert.zendesk. Protocol-specific safeguards above qualify its general TXT advice.
• mailXpert [user-group permissions](https://mailxpert.zendesk. Older publication dates alone do not invalidate still-served instructions; the actual account packet remains controlling.