For ActiveDEMAND's native email sending, obtain the unique email CNAMEs from Administration > Account Settings > Account Setup > View Whitelabeling, publish the approved records at the sending domain's authoritative DNS, and verify the actual messages. The documented email packet contains two DKIM aliases and a third mail alias. ActiveDEMAND says DKIM is configured automatically after the required CNAMEs are set; DNS presence alone still does not prove that the intended branded signature is being used. Account-specific issuance, authentication procedure.
This guide covers that native Engagement Center route, including a supported change to a different sending domain and the boundary around selector conflicts. It does not configure an independent SendGrid account, external SMTP transport, website migration or customer campaign launch.
Check eligibility and capture a safe baseline
Use an operator authorized to manage the intended ActiveDEMAND account and its Administration > Account Settings, plus a DNS owner authorized for the actual sending domain. The reviewed instructions do not establish a universal plan, region or named permission role; confirm access in the intended account rather than promising every seat can make these changes. If the control or records are missing, use the documented Support path rather than generating substitute keys.
Agree on the intended visible From addresses, sending domain, operational reply mailbox and affected campaigns. The website domain and sending domain can differ. Save the existing default marketing reply address, account sending-domain configuration, current whitelabel packet, DNS records, direct/inherited DMARC policy and other services' selectors before any approved change. New credentials, broader support access and actual customer sends require their own authorization. New and existing account distinction.
Obtain the correct packet for a new or existing domain
For a newly configured account, the official onboarding illustration names Default Marketing Reply Email. Use the owner-approved, usable reply address for the intended sending domain. Then open Administration > Account Settings, scroll to Account Setup, and select View Whitelabeling. A separate tab presents the generated CNAME records. Copy the three records specifically identified for email, including their full owners and exact targets. Publish them under the domain used for sending, not automatically the website domain. Official issuance and illustrations.
For an existing account changing its sending domain, the documented sequence is different: update the approved default marketing reply email in Administration > Account Settings, then ask ActiveDEMAND Support at engage@activedemand.com to change the account's email domain. Wait for Support's confirmation and current three-record packet before changing DNS. Preparing a guide does not send that request. Do not assume editing the reply field alone reassigns an existing authenticated domain. If records are absent after setting the default reply address, the same official page directs you to Support.
The provider explicitly warns that generated CNAMEs are unique. Never copy its sample customer number, target, domain or selector. Screenshots on the current official pages show different selector generations: the main setup uses ad/ad2, while the different-domain page shows s1/s2. The newer conflict runbook also distinguishes these generations. This is why the active account packet, not a memorized selector, governs the change. Authentication example, selector conflicts.
Publish the email aliases without changing website routing
The native email packet has two DKIM CNAMEs and one mail CNAME. The official examples label the mail owner email2, but use the actual account-issued owner and target. Other CNAMEs visible on the whitelabel page, such as website or link branding, are separate dependencies. Do not replace a live website or configure every displayed branding record merely to complete email authentication. Email-specific records.
The sending/routing owner must approve the exact mail-alias full owner and target and its intended use, separately from receiving a packet. Compare the approved set at authoritative and recursive DNS before treating it as active. Preserve incoming mailbox MX; this documented email setup is not an instruction to migrate mailbox service. The public procedure does not establish a universal MAIL FROM identity or bounce-fallback behavior, so test the actual envelope and coordinate any nonstandard routing with Support.
Translate the actual full owner for the authoritative zone. If an issued owner were SELECTOR._domainkey.news.example.com, the relative input would be SELECTOR._domainkey.news in example.com, SELECTOR._domainkey in a delegated news.example.com zone, or SELECTOR at an existing delegated _domainkey.news.example.com authority. These are naming examples, not assigned ActiveDEMAND selector values. Preserve NS delegation and other senders' selectors. DNS relative names.
A CNAME owner cannot also contain ordinary TXT, A, AAAA, MX or a second conflicting alias. If an issued name collides with a working service, stop and coordinate a supported allocation rather than deleting that service. These DKIM aliases are not website traffic: use DNS-only, not an HTTP proxy, where your DNS host offers proxying.
Preserve a literal CNAME answer at each issued owner. If a relevant per-record Flatten control exists, turn it off for that authentication alias. Ensure applicable whole-zone settings do not conceal the aliases, without blindly changing shared settings. Mandatory apex or same-zone flattening can still matter: if the host cannot preserve the required literal answer, stop and coordinate a supported configuration with the DNS owner and provider. Do not invent a switch or remove delegation. Cloudflare documents per-record, whole-zone and same-zone behavior; other hosts have different controls. Cloudflare CNAME flattening, configuration.
For an apex sender, SELECTOR._domainkey.example.com is relative SELECTOR._domainkey in example.com, or SELECTOR at an existing delegated _domainkey.example.com authority. The illustrative mail owner email2.news.example.com would be relative email2.news in the parent zone or email2 at a delegated news.example.com authority. These examples explain naming only; do not invent those labels if your packet differs.
Check both DKIM aliases as CNAMEs, then resolve each issued target to its public-key TXT answer. A correct alias with an absent or unusable key is not completion. Do not add TXT keys at the CNAME owners or expose private keys. The later read-only command block shows both query stages. DKIM DNS lookup.
Reconcile ActiveDEMAND SPF with the existing policy
The current official procedure shows this example at the sending domain's apex:
v=spf1 mx a include:_spf.activedemand.com ?all
Treat it as provider documentation, not a replacement policy to paste over your legitimate senders. The provider authorization is include:_spf.activedemand.com; the broad mx and a mechanisms require an actual authorization reason. Retain existing approved mechanisms and the chosen qualifier instead of automatically adding broad authorization or changing enforcement to neutral ?all. Neutral does not mean hardfail and no SPF qualifier guarantees a mailbox delivery decision. Resolve any mismatch with the current account packet before publication. Official SPF example.
Map each actual issued SPF owner explicitly: full example.com uses relative @ (or the host’s documented apex input) in its zone; full news.example.com uses news in the parent zone or @ at a delegated news.example.com authority. An apex-domain DKIM owner SELECTOR._domainkey.example.com uses SELECTOR._domainkey in the parent zone or SELECTOR at an existing delegated _domainkey.example.com authority. Use the actual issued selector and preserve NS delegation; these examples do not assign an envelope or selector to your account. Owner mapping.
Confirm activation and handle selector conflicts safely
The official setup describes automatic DKIM configuration when its CNAME records are established. Reopen the account's View Whitelabeling page and confirm the email records are verified for the intended domain, then perform the controlled message checks below. There is no separately documented universal signing-enable switch to invent. If validation is not accepted, ask Support to confirm the account-domain association rather than declaring success from a public lookup. Automatic setup, verified-state troubleshooting.
If an existing s1/s2 owner belongs to another sender, preserve it. The September 2026 official runbook describes a Support-operated regeneration that changes Email Sending Domain temporarily and recreates the managed domain with ad/ad2. That is not harmless DNS troubleshooting: it can delete/recreate a managed authentication object. Escalate the conflict with the actual records and ask Support and the sending owner to coordinate the supported replacement, dependencies and maintenance window. Do not perform a blind email2→email3→email2 toggle or promise arbitrary s3/s4 selectors. Keep queued-message and other-provider dependencies intact. Current conflict runbook.
Preserve SPF and DMARC policy
SPF evaluates the actual SMTP MAIL FROM identity, not automatically the visible From address. ActiveDEMAND's domain-authorization instruction does not prove which envelope domain a delivered message uses. Inspect that identity separately; do not promise SPF alignment or invent a custom return path. EmailAuth's custom MAIL FROM and alignment guide explains why publication, routing and actual message identity are different checks.
Keep one v=spf1 TXT policy at each evaluated owner. Merge only the approved provider authorization into an existing policy before its terminal all; retain other legitimate senders and the approved qualifier. Count the ten evaluated DNS-dependent terms across includes and redirects, not merely ten top-level includes. If a policy uses redirect=, do not blindly add all: an all mechanism makes the redirect ignored. Review the complete resulting authorization instead. Do not freeze changing provider IPs into a static SPF record as a shortcut. SPF processing, redirect.
Look up the direct and applicable inherited DMARC policy for the intended visible From domain. Preserve its enforcement, alignment settings and approved report recipients. Do not replace a working policy with a provider's p=none example, duplicate DMARC, or create a child monitoring override that weakens inherited protection.
Only if no direct or applicable inherited policy exists and the domain owner approves a monitoring and review plan, an illustrative first record is TXT with value v=DMARC1; p=none. From example.com uses full owner _dmarc.example.com, relative _dmarc in its zone. From news.example.com uses _dmarc.news.example.com: relative _dmarc.news in the parent zone, but _dmarc at a separately delegated news.example.com authority. Preserve that delegation. This value requests no reports by itself. DMARC publication.
Add rua only for a provisioned, approved and monitored recipient. Compare the Organizational Domain of the report URI's host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily visible From. If they differ, the report-generating receiver must check external-report DNS authorization; a destination within the same Organizational Domain as the policy domain is excepted. A different hostname alone is not sufficient. This check does not replace the owner's approval to share report data. RFC 9990 section 4.
SPF strict alignment (aspf=s) requires exact equality between the authenticated MAIL FROM domain and visible From domain; a child envelope and parent From can align in relaxed mode but not strict mode. Do not infer the actual envelope from a DNS hostname. DMARC can pass through either aligned SPF or aligned DKIM. Relaxed alignment compares Organizational Domains; strict adkim=s requires the signing domain to match the From domain exactly. Check the effective policy, not just a green dashboard. RFC 9989 replaces RFC 7489 and removes pct; do not design a new rollout around that obsolete tag. For domains publishing p=reject, retain the valid-DKIM requirement and consider indirect/list interoperability before changing policy. Alignment, indirect flows.
Prove publication and actual signing separately
Use read-only queries with the actual authority and account-issued names in place of these uppercase placeholders:
dig +short NS YOUR-ZONE
dig @AUTHORITATIVE-NS TXT YOUR-SPF-OWNER +noall +answer
dig @AUTHORITATIVE-NS CNAME YOUR-ISSUED-DKIM-OWNER +noall +answer
dig @1.1.1.1 CNAME YOUR-ISSUED-DKIM-OWNER +noall +answer
dig @TARGET-AUTHORITATIVE-NS TXT YOUR-RESOLVED-DKIM-TARGET +noall +answer
dig @1.1.1.1 TXT YOUR-RESOLVED-DKIM-TARGET +noall +answer
dig @1.1.1.1 TXT _dmarc.YOUR-FROM-DOMAIN +noall +answer
Repeat both stages for both issued DKIM CNAMEs: verify the literal alias at its owner, then resolve its target to the expected public-key TXT answer using that target zone’s authority and a recursive resolver. Resolve any discrepancy between authoritative and recursive answers before claiming completion. A successful DNS lookup is not a delivered-message test. Save the full owner, type, value, timestamp and provider status without publishing private credentials.
Have an authorized operator send new representative messages through the intended application or campaign path to controlled external recipients. Use synthetic records and approved harmless content, not real customer notifications. Capture the unchanged intended visible From, actual MAIL FROM/Return-Path, DKIM d= and s=, route and time.
Establish which Authentication-Results fields the actual receiving service generated inside its known processing boundary and how it removes, ignores or distinguishes externally supplied fields. Use documented receiver handling or an administrator-verified trace if unclear. Header position or a familiar authserv-id string alone is not proof. Ignore injected or otherwise untrusted results. Receiver trust boundary.
For branded-DKIM acceptance, match the intended provider's active issued d= and s= to the tested route. Require that signature to pass and align under effective adkim with the unchanged intended visible From, plus trusted receiver dmarc=pass. Another aligned signer, rewritten provider From or SPF-only DMARC pass does not complete this DKIM deployment.
Diagnose SPF separately at the actual smtp.mailfrom domain: fail or softfail calls for checking the connecting sender against approved authorization; temperror is a transient evaluation problem, often DNS; permerror calls for checking malformed or duplicate policies and the evaluated lookup budget. Aligned DKIM does not repair an SPF fault. Do not edit an unrelated apex policy to fix a provider-controlled envelope domain. SPF results.
Troubleshooting and controlled recovery
- View Whitelabeling has no email records: Confirm the intended default marketing reply domain and account, then use the official Support path. Do not construct SendGrid targets yourself.
- Two DKIM aliases remain unverified: Compare the active packet against authoritative DNS, duplicated suffixes, delegation, owner conflicts and flattening. If another tenant owns the selector, coordinate regeneration with Support, not deletion of its working record.
- The mail alias fails: Compare its entire approved owner/target pair. Stop on routing disagreement instead of changing corporate MX or unrelated website CNAMEs.
- A public DKIM lookup passes but mail does not: Match the actual message's active provider selector and signing domain to this account; inspect the final intended route and unchanged From. The main tutorial's
adlookup example is not a universal selector. - SPF fails while DKIM aligns: Diagnose the actual envelope owner's authorization and DNS result independently. Do not weaken DMARC or change an unrelated apex to hide the failure.
- Authentication passes but delivery is poor: Have the campaign owner check subscriber permission, working unsubscribe, complaints, content and suitable warm-up. Authentication is not an inbox guarantee.
Preserve the approved baseline and failed-message evidence. With the sending and DNS owners, pause only affected automation or restore the previous approved sender/transport and DNS configuration when a change regresses. A Support-managed domain recreation may require Support to restore the association; do not assume DNS rollback alone reverses it. Retain selectors required by queued mail or other services. Use synthetic records and controlled recipients to retest the failed path plus a known-good control, not real customer notifications or deliberate live routing failures.
Documentation and testing boundary
The account-issuance and mail-record illustrations were personally inspected. No customer account, DNS, support request, credentials, campaign or message was changed or sent. This is documentary guidance, not a live deployment test.