On this page: Before opening DNS settings · Retrieve the sending profile’s instructions · Configure the SPF alias and preserve existing SPF · Publish both issued DKIM aliases without changing their meaning · Preserve DMARC and check alignment · Validate public DNS and obtain activation confirmation · Accept a delivered ActiveTrail campaign · Troubleshooting ActiveTrail authentication · Frequently asked questions · Review scope and maintenance
To authenticate ActiveTrail email, open the selected domain’s DNS instructions in your account and publish its issued records. The current CNAME workflow has three aliases: one for SPF and two for DKIM, with the DKIM aliases providing mutual backup. Then check a delivered campaign for aligned DKIM and DMARC. Do not reuse a DKIM public key from a third-party tutorial or assume a root-domain SPF change establishes alignment.
This guide covers ActiveTrail campaign delivery from a domain you control. It is not an ActiveCampaign guide: the similarly named products have different authentication workflows. A campaign, an automation and any separate application integration must be checked on their actual sending paths before one successful test is applied to all of them.
Before opening DNS settings
Identify the ActiveTrail account, sending profile, visible From address and authoritative DNS administrator. Keep an export of existing DNS values and record which other services send for the same domain. Access to a website editor does not necessarily give access to authoritative DNS.
You need authority to use the sender domain and change the relevant DNS records. You cannot publish authentication records for a public mailbox domain you do not own. The reviewed ActiveTrail instructions do not establish a particular plan entitlement or guarantee every account has identical menus. If the documented setting is absent, obtain current profile-specific instructions from ActiveTrail support instead of borrowing another account’s settings.
Create a change worksheet containing the complete DNS owner, type, value, existing value, proposed change, profile and approval owner. Keep credentials out of it. Authentication should not replace your inbound MX records, disturb website records or change another platform’s DKIM selector.
Retrieve the sending profile’s instructions
ActiveTrail’s current Academy guide points to Account → Settings → SPF, Domain Keys → the account DNS-record link. Check that the intended domain is selected, then copy its records for the DNS administrator. The CNAME guide specifies one SPF alias and two DKIM aliases; after all three are added, it describes the return path changing from ActiveTrail’s domain to the sending profile. The documentation does not establish the exact envelope hostname or strict alignment for every account. Account DNS workflow, current three-CNAME setup
Keep the generated instructions with the change request. If the account now presents a different screen, use the current record set for the intended sender and ask support to resolve the difference. Older tutorials describe a different protocol-choice menu. Use the current account record set, not those historical steps or fixed TXT keys.
Before proceeding, answer these questions from the issued instructions:
- Which sender domain and sending profile does this set authenticate?
- Which DNS owners receive SPF, DKIM and any verification records?
- Is each record a TXT value or a CNAME target?
- Does ActiveTrail require a separate activation or support confirmation after publication?
- Which envelope domain should appear in production mail, and is a custom return path available for this profile?
The public guide does not settle every profile’s selector, alias target or exact envelope-domain behavior. Those values must come from the account or support; this article deliberately supplies no universal ActiveTrail key or selector.
Configure the SPF alias and preserve existing SPF
SPF evaluates the envelope MAIL FROM domain, commonly reflected in the delivered Return-Path. It does not authenticate the visible From address directly. Adding a service to example.com cannot change a message whose envelope sender remains under an unrelated provider domain. Read the issued SPF instructions alongside the actual message identities. SPF identity and record rules, RFC 7208
For the documented three-CNAME route, publish the SPF-related alias exactly as issued. Do not create an additional TXT record at that CNAME owner or add a root SPF include simply because an older tutorial uses one. The alias delegates the named lookup; it is not a TXT include to merge at the root. Verify the resulting envelope identity on delivery. ActiveTrail CNAME roles
Only if current account-specific instructions explicitly require a separate SPF TXT authorization at an owner that already has SPF, merge that authorization into the existing policy after resolving the route with support. Do not create a second TXT record beginning v=spf1 at that owner. Preserve other legitimate senders and the established ending policy unless a separately approved domain-wide review changes them. Unrelated TXT verification records can remain.
Count the DNS-querying terms evaluated across the complete SPF tree, including nested includes and redirects. RFC 7208 permits at most ten such terms during evaluation. This is not simply a count of the includes you can see on the first line. If a new authorization exceeds the limit, inventory retired senders and simplify safely; do not replace dynamic vendor ranges with a one-time IP snapshot.
An SPF lookup can establish what DNS publishes. A real SPF pass additionally depends on the sending IP and envelope identity used for that message. Treat account approval, DNS validity and message authentication as three different results.
Publish both issued DKIM aliases without changing their meaning
Publish both DKIM CNAMEs from the current account set, not just whichever selector a sample message happens to use. ActiveTrail documents them as mutual backups. Copy each complete owner and target exactly; do not infer a selector from an old article or replace the alias with a tutorial’s public-key string. A delivered signature identifies its selector as s= and signing domain as d=; the resulting lookup must reach the provider’s public key. ActiveTrail DKIM aliases, DKIM key discovery, RFC 6376
For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.
If support confirms an account-specific legacy TXT route instead, preserve the entire issued public key; do not assume that legacy route replaces the current CNAME setup. DNS software may display a long TXT record as several quoted strings within one record; that is different from publishing conflicting separate records. Never publish a private key, password or API token.
For the documented CNAME route, use the exact hostname targets rather than public-key strings. Keep these aliases DNS-only where the DNS host offers HTTP proxying; a web proxy or CNAME flattening must not hide the required alias. Cloudflare proxy behavior, CNAME flattening and verification A CNAME owner cannot also hold unrelated record data. Resolve a collision with the DNS administrator and ActiveTrail instead of deleting an existing service’s record. Check whether the DNS editor automatically appends the zone: entering the full name in a relative-name field can create a duplicated suffix.
For ActiveTrail’s three issued aliases, the required end state is the literal CNAME answer. Where the actual authoritative DNS host offers these controls, use DNS-only aliases, not HTTP proxying or redirects, and keep a literal CNAME answer to each required target. Turn the relevant per-record Flatten option off when available, and ensure applicable zone-wide settings do not conceal the issued aliases. For Cloudflare specifically, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are Cloudflare behaviors, not assumed controls in another provider’s panel. If mandatory behavior or shared settings prevent the required CNAME answer, stop and coordinate a supported configuration without breaking dependent records. Do not blindly change the whole zone or remove an NS delegation; publish at the delegated authority when appropriate. Cloudflare CNAME verification, flattening controls.
Keep an old active selector during an approved rotation until the provider’s retirement guidance and in-flight messages have been considered. Changing the DNS public key alone does not make a service sign with the corresponding private key.
Preserve DMARC and check alignment
DMARC passes when at least one authenticated identity aligns with the visible From domain: SPF passes and aligns, or DKIM passes and aligns. Relaxed alignment permits an organizational-domain match; strict alignment requires an exact domain match. Both mechanisms may pass without either aligning. Current DMARC standard, RFC 9989
Read the domain’s existing DMARC policy, including any applicable inherited policy for a subdomain. Do not replace p=quarantine or p=reject with a tutorial’s p=none record merely to make onboarding easier. Do not create a second DMARC record at the same owner. For a genuinely new policy, a monitored p=none phase may be appropriate after inventorying legitimate senders, but it is not enforcement or an inbox guarantee. The obsolete pct tag is not a current percentage-rollout mechanism.
For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names. An illustrative first-policy value is v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. Replace the sample mailbox with the approved, working destination and never publish the placeholder unchanged.
Use an approved aggregate-report destination and arrange review of reports before considering stronger enforcement. External reporting destinations may require authorization DNS. Failure reports have additional privacy implications and should not be enabled casually. Aggregate reporting, RFC 9990, failure reporting, RFC 9991
Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.
Validate public DNS and obtain activation confirmation
Replace every uppercase placeholder below with the complete owner from the account. These commands only query DNS; they are not records to publish.
dig CNAME ISSUED-SPF-ALIAS
dig CNAME ISSUED-DKIM-ALIAS-ONE
dig CNAME ISSUED-DKIM-ALIAS-TWO
dig TXT ACTUAL-MAIL-FROM-DOMAIN
dig TXT SELECTOR._domainkey.SIGNING-DOMAIN
dig TXT _dmarc.VISIBLE-FROM-DOMAIN
Compare all three issued aliases, and follow their targets when inspecting the corresponding SPF and DKIM data. The TXT queries inspect authentication data; they are not instructions to add TXT records at alias owners. Compare authoritative answers with the account instructions and with a recursive resolver. A blank short answer or a timeout is not enough to conclude a record is absent; inspect the response status and delegation. Cache lifetime and the previous TTL affect when changes become visible.
Acceptance at this stage means the intended owners resolve to the issued values, SPF has only one policy at its owner, and no existing record was accidentally overwritten. Then check the current account’s authentication status; if it remains unclear or the return path has not changed as documented, obtain confirmation from ActiveTrail support. The current short guides do not specify a universal verification button, status label or fixed activation delay. Follow any verification offered in the account, and do not treat publication alone as successful activation.
Accept a delivered ActiveTrail campaign
After authorized setup, send a small representative campaign to controlled recipient mailboxes. Use the real From address and selected profile, not only an editor preview. Repeat for automation or integration routes whose sender selection differs.
Inspect the receiving system’s trusted Authentication-Results, not an arbitrary header inserted earlier in transit. Record the date, route, visible From domain, smtp.mailfrom, SPF result, DKIM d= and s=, DKIM result and DMARC result. Trusted authentication results, RFC 8601
Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.
A successful acceptance record should show:
- The intended branded From identity, with no unexplained rewrite.
- A passing branded DKIM signature that aligns with the visible From domain under the actual adkim setting and uses its issued selector.
- The actual SPF identity and result, with no unexplained failure or permanent error.
- A trusted
dmarc=pass, with the aligned passing mechanism identified under the domain’s actual alignment settings.
If SPF passes for a provider-owned domain but branded DKIM passes and aligns, DMARC can pass through DKIM. Do not add unrelated root SPF includes to “fix” that nonalignment. Investigate an actual SPF fail, permerror or temperror even when aligned DKIM supplies the DMARC pass. Inspect the actual envelope domain, its DNS resolution and the provider route; a real SPF error is different from an authenticated but nonaligned identity. Conversely, an unaligned DKIM pass is not evidence that branded DKIM works. Investigate it even if another path currently supplies the DMARC pass.
For example, a fictional campaign from news@example.com with passing DKIM d=example.com can align even when its SPF identity is unrelated. This is a diagnostic example, not an observation of ActiveTrail’s infrastructure. A successful message proves that sample and route, not all future delivery or inbox placement.
Troubleshooting ActiveTrail authentication
The documented setting is missing
Confirm you are in ActiveTrail, in the intended account and profile, and have the necessary permissions. Ask support for the current authentication instructions. Do not apply ActiveCampaign records or a competitor’s copied public key.
DNS looks right but the account is not ready
Compare fully qualified owners, authoritative nameservers, TXT versus CNAME type, complete values and cache timing. Ask whether the profile needs additional activation. Give support record owners and observed DNS answers, not credentials.
DKIM is absent or fails on delivery
Compare the message’s s= and d= with the published owner. A different selector suggests a different profile, an uncompleted activation or rotation. A matching record with signature failure may require examination of message modification after signing. Retest a direct delivery before blaming a forwarder or gateway.
SPF passes but DMARC fails
Check the envelope domain’s relationship to the visible From domain, then the DKIM signing domain. Do not weaken DMARC to conceal an identity mismatch. Confirm which aligned route the account actually supports.
Authentication passes but messages reach spam
Authentication does not establish consent, engagement, content quality or reputation. Preserve the technical evidence and investigate campaign quality separately instead of repeatedly editing correct DNS.
Review scope and maintenance
No customer account was accessed, DNS published, campaign sent or delivery tested for this guide. Verify exact values and current account permissions, and complete the DNS and delivered-message checks above. Recheck after changing profiles, From domains, DNS providers or DKIM keys. Authentication does not guarantee inbox placement.