ExpertSender SPF, DKIM and DMARC setup, step by step

For ExpertSender CDP (ECDP), obtain your business unit's DNS instructions from Settings → Email → Domain authentication. Publish each account-issued Name / Type / Value at the correct authoritative DNS host, then use Verify now or Check now, depending on the displayed interface. Confirm the required rows are Verified and the email channel is Active before testing a message with the intended From address.

Do not copy an ExpertSender SPF include, selector or public key from another account. The official setup screenshot deliberately obscures tenant values. It establishes the record table and verification controls, not reusable DNS values. This guide covers CDP's native email channel, not ExpertSender Email Marketing Platform (EMP) or its separate configuration procedures. Official CDP setup

What this guide covers, and who can configure it

ExpertSender describes a business unit as a company account assigned to a single sending domain, able to manage multiple websites. ExpertSender provisions that domain when the business unit is created. The Sending domain displayed in email settings cannot be changed there; changing a sender default is not a domain migration. Email settings

Use this procedure for an already approved CDP business unit whose native email channel you are configuring. It does not cover importing an EMP private key, setting up an external SMTP relay, changing domain-family IP distributions, enabling web tracking, or migrating incoming mail.

Client Admin is required for Settings. The current Users documentation says Client users do not see Settings and cannot configure email domains or domain authentication. Both roles can create campaigns, but campaign access alone does not grant channel-configuration access. Ask an existing authorized Client Admin to handle the settings; do not broaden account access merely to follow a tutorial. CDP roles and permissions

Prepare:

• The correct active business unit, approved sending domain and From identity.
• Its complete current DNS table, not a screenshot from this article or another tenant.
• Access to the actual authoritative DNS zone through your authorized DNS operator.
• Existing SPF, DKIM, DMARC, routing and delegation records, with a recovery copy and named owners.
• An approved Reply-To mailbox and a small, consented segment containing only controlled test recipients.

The cited documents do not establish a universal plan, region, sending-IP class or SPF include for all customers. Provisioning and account-visible records determine your configuration. If the required business unit or controls are unavailable, resolve that with your administrator and ExpertSender before changing DNS.

1. Open the provisioned account's DNS instructions

The business-unit setup guide describes an activation email after ExpertSender registers and initially configures the unit. The authorized account owner uses that onboarding flow, then opens Settings → Email → Domain authentication.

That is different from a user manually created under Settings → Users: the current Users guide says such an account becomes active when saved and receives no separate activation email. Neither form of user activation proves that the email channel or DKIM is ready. Business-unit onboarding · User-account distinction

In the authentication table:

1. Confirm the business unit and the domain names against your approved sending plan.
2. Copy each row's Name, Type and complete Value. Keep its purpose and any associated link-domain dependency with it.
3. Identify the exact SPF policy owner, DKIM selector/key or alias, and any other required validation or routing records from this packet. If their purposes are unclear, have ExpertSender clarify the issued configuration rather than inferring them from row order.
4. Compare the rows with existing DNS. Identify conflicts and routing changes before publication.

The setup screenshot shows a CNAME row and two TXT rows, but its names and values are blurred. That does not prove that every account gets exactly three rows or that a particular row universally represents SPF, DKIM or DMARC. Use the complete current table for your business unit, including any additional requirements shown there.

Treat each record according to its actual type and value

Only public DKIM material belongs in DNS. Do not generate or transmit private signing keys as part of this CDP procedure. An account-specific value that is incomplete or cannot be reconciled with an existing service is a reason to stop and clarify, not a reason to invent a record. CDP DNS issuance · DKIM standard

2. Publish the approved records in authoritative DNS

The setup guide calls this your hosting service, but the operational requirement is the DNS provider authoritative for the issued owner. A website host or registrar may not hold that zone. Confirm the delegation and use the appropriate DNS administrator.

Enter the issued record type, its owner in the format your editor expects, and the complete value. Save each approved change and inspect the resulting full DNS name. Do not modify MX, nameservers, DNSSEC, website addresses, credentials or forwarding merely to imitate an example.

Map full owners to your DNS editor

This table is a structural example only. LABEL and SELECTOR stand for the actual labels issued to your business unit.

If the editor instead expects a fully qualified name, use the full issued owner. Follow the DNS host's convention for trailing dots and TXT quoting. Do not append the domain twice, drop _domainkey, change case-sensitive token data, or shorten a public key. A DNS host may split a long TXT value into quoted character strings; those strings must form one logical record, not separate policy/key records.

Preserve existing _domainkey NS delegations and work with the delegated operator. Do not delete a delegation to make publication possible in the parent zone. A CNAME cannot be forced at a delegated apex that must retain SOA/NS data; ask for a supported configuration if the issued name collides with that design.

Avoid alias conflicts and concealed CNAMEs

A CNAME owner cannot coexist with a conflicting TXT, A, AAAA, MX or another CNAME. Do not overwrite a selector or alias used by another sender. Get a supported replacement design from ExpertSender and the affected DNS owners; do not rename an account-issued owner yourself.

If a DNS host offers HTTP proxying, authentication aliases need DNS-only handling rather than a web proxy. Cloudflare describes its proxy modes here.

When the service requires a literal CNAME answer, turn a relevant per-record Flatten setting off where available, and ensure applicable zone-wide settings do not flatten those required aliases. Coordinate any shared-setting change. Cloudflare documents mandatory apex flattening and same-zone behavior that can apply regardless of the selected setting; if these prevent the required answer, stop and arrange a supported configuration rather than inventing an override or deleting shared delegations. CNAME-flattening guidance

3. Apply SPF at the actual envelope identity

SPF evaluates the SMTP MAIL FROM domain, with HELO evaluation in the relevant cases. It does not authenticate the visible From address just because both contain your brand name. The reviewed CDP instructions issue records through the account but do not publish a universal envelope-domain rule or universal SPF literal. Confirm both from the issued packet and the later received message.

For a TXT-based SPF policy you manage:

• Keep one v=spf1 policy at the evaluated owner. Other independent TXT tokens can coexist there where DNS permits, but a second SPF policy is not a merge.
• Preserve existing legitimate senders and qualifiers. Integrate a required authorization only as part of an approved policy change; do not paste an entire second policy or replace a shared policy blindly.
• Keep the evaluation within the 10 DNS-dependent-term limit, counting nested mechanisms as well as the visible top-level terms. This is not simply “10 includes.”
• An all mechanism makes redirect ineffective. Preserve deliberate design rather than adding a redirect after all.
• If the packet instead delegates a relevant owner with CNAME, do not also add a TXT at that owner. Establish the effective destination data without changing provider-managed infrastructure.

Do not change an existing -all, ~all or ?all solely to make a test green. Those qualifiers express different SPF outcomes; no outcome guarantees a particular delivery disposition. RFC 7208

A child envelope domain can align with a parent From domain under relaxed DMARC alignment when they share the appropriate Organizational Domain, but strict SPF alignment requires an exact domain match. Do not assume CDP guarantees strict alignment or silently weaken aspf. The intended DKIM signature needs its own independent check.

4. Preserve DMARC despite the p=none display

The CDP setup guide explicitly says Settings → Email → Domain authentication displays p=none even when you choose another policy value. Therefore that display is not proof that your authoritative DNS policy has changed, and it is not an instruction to downgrade a working p=quarantine or p=reject record. Official display explanation

Inspect the actual direct policy for the intended From domain and any applicable inherited policy. Preserve existing protection, adkim/aspf settings and authorized reporting destinations. Avoid a second DMARC record at the same owner or an unintended weaker child override. If verification conflicts with a legitimate existing policy arrangement, resolve the issue with ExpertSender and the domain owner instead of replacing policy with the UI example.

Only when no direct or applicable inherited policy exists, the domain owner approves a first monitoring policy and a suitable monitoring plan exists, a minimal TXT value is:

v=DMARC1; p=none

That value by itself does not request reports. Its owner depends on the actual From domain:

Add reporting only to an actual authorized destination. If a report URI's destination is in a different Organizational Domain from the domain where the policy was found, the report-generating receiver must check DNS authorization. Destinations within the same Organizational Domain are excepted; different hostnames alone do not trigger that rule. DNS authorization is separate from the owner's privacy/data-sharing approval. RFC 9990 §4

Review evidence across all legitimate senders before any later enforcement change. Do not treat a CDP verification result as a domain-wide enforcement audit. Current DMARC specification

5. Verify the records and confirm the channel is Active

Return to Settings → Email → Domain authentication after publication. The setup guide and screenshot call the control Verify now; the settings article calls it Check now. Use the DNS verification control shown in your account, not an invented separate signing toggle.

The provider allows up to 48 hours for verification. That is a documented waiting window, not a guarantee of delivery, DNS propagation everywhere or successful activation regardless of configuration.

Two layers matter:

1. Record status: inspect every required Name/Type/Value row. The successful setup screenshot shows green Verified rows.
2. Email channel status: confirm Active. Configure DNS records means DNS setup is incomplete; Configuration in progress means ExpertSender's team is still completing channel configuration.

The settings article mistakenly repeats an in-progress explanation under “Active.” Its successful setup screenshot instead shows Active together with verified records. Do not equate a pending state with readiness. If all DNS rows are correct but the channel remains in progress, have the authorized account owner ask ExpertSender to resolve the remaining configuration; do not invent an activation switch. Setup and successful-state screenshot

The settings article also describes “Wrong value” as though the Name and Value must be identical. They generally are not: a DNS owner and its record data serve different purposes. The setup screenshot instead says a record is missing or does not match the expected value. Compare the published data with the expected Value at that Name and Type, not Name text with Value text. DNS table and status reference

For read-only diagnostics, replace all uppercase placeholders with your real issued names and your approved DNS server. Run only the query types that match the actual packet:

dig @AUTHORITATIVE_NS TXT SPF_OWNER +noall +answer
dig @AUTHORITATIVE_NS TXT DKIM_TXT_OWNER +noall +answer
dig @AUTHORITATIVE_NS CNAME ISSUED_ALIAS_OWNER +noall +answer
dig @RECURSIVE_RESOLVER TXT DKIM_TXT_OWNER +noall +answer
dig @RECURSIVE_RESOLVER CNAME ISSUED_ALIAS_OWNER +noall +answer

These examples do not claim that every CDP account issues all of these records. Compare complete TXT data or exact aliases against your own packet; empty answers and errors are not success. Account verification, public DNS and message signing remain separate evidence layers.

6. Save the intended From and Reply-To settings

In Settings → Email, review the settings tab's provisioned Sending domain. Do not try to change that non-editable domain through a sender-name field. The Default domain for links is a separate setting for message, unsubscribe and system links; do not change it as a DKIM repair without assessing those dependencies.

Set and save:

• Default “From” name: a recognizable approved sender name.
• Default “From” email: the approved address using the authenticated sending identity.
• Default “Reply-to” name and Default “Reply-to” email: the approved person or monitored mailbox that should receive replies.

The defaults appear in the message editor but can be overridden for individual campaigns. Reopen the settings after saving and inspect the actual campaign's From and Reply-To before sending. A Reply-To address does not supply DMARC alignment for a different From domain. Sender defaults and campaign overrides

Leave domain-family IP distribution, dedicated/shared/premium allocation, complaint handling and other routing settings unchanged unless a separate approved change calls for them. Authentication setup is not a reason to experiment with delivery infrastructure.

7. Test the native campaign route safely

Use the native CDP path that will actually carry your messages. The first-email guide provides Campaigns → Email → Create email newsletter, with Basic settings, Content, Recipients, Delivery and Summary stages. It requires a configured email channel and consented recipients. Official first-email workflow

For an authorized controlled test:

1. In Basic settings, check the actual From name and address, and the Reply-To choice. Use non-sensitive synthetic content and avoid changing tracking or unrelated settings just to test authentication.
2. In Recipients, choose only your small approved test segment, not all customers. Preserve applicable consents and check the computed total and membership before proceeding.
3. In Delivery, select the approved delivery time/mode. Do not change IP distribution or enable ignore the local blocklist. Keep suppression and consent protections intact.
4. In Summary, resolve red errors and inspect the sender, audience and delivery details again. Send only the authorized test. A green checklist or clicking Send does not itself prove receipt or authentication.
5. Inspect the newly received message from this CDP route, not an unrelated webmail message or an assumed-equivalent preview. Repeat for materially different native automation or other paths you actually use, without enrolling customers or creating unintended triggers.

Delivered-message acceptance

Use authentication results produced inside your actual receiving service's known processing boundary, with its documented handling of externally supplied Authentication-Results. A header's position or a familiar authserv-id string alone does not make it trustworthy. Ignore attacker-inserted result fields. RFC 8601

Require all of the following for the newly configured branded DKIM route:

• The visible From is the intended approved identity, not rewritten to an unrelated provider address.
• The intended ExpertSender DKIM signature passes. Retain its signing domain d= and selector s= alongside that result.
• The passing signature aligns with From under the applicable adkim mode. Strict alignment requires exact domain equality; relaxed alignment uses the appropriate Organizational Domain relationship.
• The trusted receiver reports dmarc=pass for the intended From. A DMARC pass supplied only by SPF does not prove DKIM is functioning.
• The actual smtp.mailfrom and SPF result are recorded independently. Investigate SPF fail, temperror and permerror even when aligned DKIM provides a DMARC pass.
• The expected Reply-To is present, with an authorized reply check to the monitored destination where needed.

EmailAuth's raw DKIM results versus aligned DKIM policy results explains why an unrelated passing signature is not enough. One valid message supports the tested route, not every business unit, campaign, automation or receiver. Authentication success also does not guarantee inbox placement.

Troubleshooting after verification and safe rollback

If the email channel is Active but the intended DKIM signature is absent or unaligned, first confirm the business unit, actual campaign From override, selector and packet. Ask ExpertSender to investigate the native signing path with sanitized DNS and received-header evidence. Do not invent a private-key import or switch to EMP instructions.

If SPF passes but does not align, inspect the actual envelope domain and current aspf mode. Adding an include to the visible From domain may not affect the SPF identity at all. If DKIM passes but does not align, compare its d= with From and confirm the supported provisioned signing identity. Preserve policy while resolving the real mismatch.

If a change disrupts a route, pause only the affected campaign or automation through its owner. Restore prior approved sender settings and only those DNS changes whose dependencies are understood. Preserve keys/aliases needed for queued mail, bounces, link domains and other senders until their owners confirm safe retirement. Do not disable security checks, remove a shared delegation, change incoming-mail routing or weaken DMARC as a shortcut.

Keep a record of the packet, approved changes, DNS answers, verification state and sanitized message identities. Revalidate after a domain, key, campaign sender or route change. No account or DNS rollback was performed in preparing this guide.

Sources and documentary check

The pages do not display article dates in their inspected main bodies. Their Open Graph og:updated_time metadata supplies the update timestamps identified below; these are structured page metadata, not a visible editorial changelog or this documentary check date. The two linked setup/status screenshots were inspected, but their blurred tenant values were not reconstructed or reused.

• ExpertSender CDP Business unit setup: account provisioning, DNS issuance, Verify now, verification window and DMARC-display limitation.
• ExpertSender CDP Email, domain settings and complaints: sender defaults, non-editable sending domain, DNS table and status terminology. The two inconsistent status descriptions are qualified above using the actual setup procedure and screenshots.
• ExpertSender CDP Users: Client Admin access and the distinction between created-user activation and business-unit onboarding.
• ExpertSender CDP Create and send your first email message: actual native campaign path, audience/consent and final-send controls.

No customer login, DNS publication, channel activation, email send, deployment, delivery or inbox test was performed for this guide.