Set up ActiveCampaign authentication from Settings → Advanced → Sending Domain. Complete domain verification, publish the account-generated DKIM and Mailserver Domain records, retain or establish the appropriate DMARC policy, and recheck authentication. A separate root SPF include is not required for the current Mailserver Domain workflow: its CNAME lets ActiveCampaign provide SPF for your envelope-sender domain. Validate a delivered message after setup, not just the green account status. ActiveCampaign authentication overview.
Understand which mail and domains you are configuring
This guide addresses ActiveCampaign's sending-domain authentication workflow, particularly campaigns and automation email. Domain verification also applies to the platform's documented 1:1 and notification email features. That requirement does not prove that every connected-mailbox or external transport uses the same sending infrastructure. Inventory each route and verify its actual message separately. The configuration is not a Postmark setup guide, even though ActiveCampaign links to Postmark educational material. Sending-domain scope.
Make a short identity map before opening DNS:
- Visible From: the brand address the recipient sees.
- Reply-To: the address that receives replies; its domain also needs verification in ActiveCampaign.
- Mailserver Domain: the envelope/return-path domain used for bounce handling and SPF.
- DKIM domain: the signing identity in the message's
d=tag. - Custom Domain: the separate account/link-branding feature, not a substitute for email authentication.
The Mailserver Domain and a Custom Domain need different names if you use both. Configuring a white-label account URL does not configure the return path. Custom Domain versus Mailserver Domain.
Prerequisites and change preparation
Use an organizational domain you own, with access to its DNS and an inbox on that domain for verification. Obtain the appropriate ActiveCampaign account access and permission from whoever manages DNS. Verify both From and Reply-To domains, including subdomains used by your messages. The vendor recommends an established domain older than 30 days that points to a real website; review its warming guidance if starting with a new identity. Official authentication prerequisites.
Before editing, save the existing records and list other senders sharing the From domain. Include employee mail, sales tools, transactional systems and support platforms. Record the account, sending route, exact domain, DNS owner and planned test recipient. An agency managing several brands should not infer account ownership from a similar-looking DKIM target.
Decide who can approve automatic DNS access and who can pause or resume affected campaigns. Keep a copy of the pre-change record values and the new account-issued values. If an unexpected conflict appears, stop that record change and resolve its ownership instead of deleting something to make the setup screen green.
Choose automatic configuration or manual publication
In Settings → Advanced, the Sending Domain section offers Configure Domain and Set up manually. Automatic configuration connects to supported DNS providers; review the access and proposed changes before authorizing it. Manual setup is appropriate when the DNS provider is unsupported or another team controls publication.
For manual setup, enter the domain without a URL scheme, receive the verification email at an accessible address on it, and complete the confirmation. The link expires after seven days; use the account's resend option if needed. Then select Set up DNS records and copy the issued record names, types and values. Verification of ownership and authentication through DNS are separate outcomes. Current setup instructions.
Do not interpret a verified inbox as permission to skip the remaining DNS work. Likewise, publishing records for one subdomain does not establish that a different From or Reply-To domain is verified in the application.
For the administrator's worksheet, distinguish the DKIM CNAMEs, the Mailserver Domain CNAME and any DMARC recommendation. Copy each complete row. Do not construct targets from your account name, reuse an online selector example, or generate your own private key outside the provider's supported workflow.
Configure DKIM and the Mailserver Domain safely
Publish the exact account-issued DKIM CNAME owner and target pairs. They let receivers find the public keys associated with ActiveCampaign's signatures. The private signing material belongs in the provider's signing system, not your DNS zone or a change ticket. Validate the public records without attempting to invent a replacement key.
Publish the separate Mailserver Domain CNAME at its issued owner. ActiveCampaign uses it for the custom return path and provider-managed SPF. The standard setup therefore does not require creating another root SPF TXT record or modifying your existing one solely for ActiveCampaign. How ActiveCampaign handles SPF.
Keep other senders' SPF authorizations. A domain can have multiple unrelated TXT records, but must not have multiple SPF policies at the same owner. If a separate authorized change requires editing SPF, assess the whole policy and its nested DNS-querying terms against SPF's ten-term limit. Do not add an include just because it appears in an older guide. SPF specification.
Check the DNS editor's name convention. For a hypothetical full owner SELECTOR._domainkey.example.com, a relative-name field would normally take SELECTOR._domainkey; a field requiring a complete name would take the full owner. This is an illustration, not a deployable ActiveCampaign selector. Verify the resulting public name so the domain is not appended twice.
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.
A CNAME cannot coexist with ordinary other records at the same owner. It also takes a hostname as its value, not an https:// URL. Resolve conflicts with the DNS owner, and keep unrelated MX records and DKIM selectors unchanged. DNS alias requirements.
Apply these controls to the issued DKIM and Mailserver Domain aliases, not to legacy TXT keys. 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 DMARC intact and check alignment
ActiveCampaign's custom Mailserver Domain is designed to align the envelope identity with your organizational domain. Its custom DKIM setup supplies your signing identity. Without custom configuration, SPF and DKIM can pass using provider-owned domains without aligning to your visible From domain. Passing authentication and passing alignment are different tests. ActiveCampaign domain alignment.
DMARC needs at least one passing aligned mechanism: SPF or DKIM. Relaxed alignment permits the same organizational domain; strict alignment requires an exact domain match. A return path beneath your root domain can satisfy relaxed SPF alignment while failing strict SPF alignment. Aligned DKIM can still make DMARC pass. Do not assume both mechanisms align solely because the provider says the domain is authenticated. Current DMARC standard.
Look up the current applicable DMARC policy before publishing a suggested starter record. Preserve existing enforcement, reporting destinations and intentionally chosen alignment settings. Do not create a second record or downgrade an established policy to p=none just to finish onboarding.
When no policy exists, a reviewed non-enforcing rollout can start with v=DMARC1; p=none. Add an approved aggregate-report destination if monitoring is needed; the policy alone does not generate reports. Arrange external destination authorization where applicable. Check all legitimate senders before enforcement, including parent-policy effects on subdomains. RFC 9989 replaces RFC 7489 and removes pct; do not base a new staged rollout on that obsolete tag.
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 placeholder mailbox with the approved, working destination; do not publish it unchanged. p=none is monitoring, not an inbox guarantee.
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.
Recheck the account and public DNS
Adapt these read-only commands using the exact issued names. They have not been run against a customer domain for this article:
dig +short CNAME DKIM_OWNER_FQDN
dig +short TXT DKIM_TARGET_FQDN
dig +short CNAME MAILSERVER_OWNER_FQDN
dig +short TXT MAILSERVER_OWNER_FQDN
dig +short TXT _dmarc.FROM_DOMAIN
For each DKIM owner, expect the issued alias and a resolvable public key at its destination. For the Mailserver Domain, verify the alias and follow its DNS chain to the provider-managed SPF policy. A TXT query may display alias and target information depending on the tool; do not mistake formatting for a second SPF policy.
Return to Sending Domains and use Recheck Authentication or View DNS Records. The expected application state is Authenticated. The vendor notes DNS can take up to 24 hours to propagate, with additional considerations for newly purchased domains. Its Resolve Issues option starts automatic DNS configuration, so review that action rather than treating it as a read-only refresh. Account verification and recovery.
Validate a real message, including its From address
Send an authorized representative campaign or automation to a mailbox you control. Inspect the trusted receiving service’s Authentication-Results in its raw source. Do not accept an arbitrary same-named header inserted upstream as proof of authentication; identify results generated within your mailbox provider’s trust boundary. Authentication-Results trust model, RFC 8601. Retain the visible From domain, Return-Path, SPF smtp.mailfrom, DKIM d= and s=, DMARC result and test date. Repeat for additional routes instead of extrapolating from one successful campaign.
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.
The DKIM selector lookup is SELECTOR._domainkey.SIGNING_DOMAIN, using the signature's actual s= and d= values. This connects your DNS evidence to the key the message used. DKIM verification.
An acceptable sample uses the intended brand in From and passes DMARC through an aligned passing mechanism. Investigate missing custom DKIM or an unexpected return path even if another mechanism makes DMARC pass. Do not use a display-name match or disappearance of a “via” label as the only success criterion.
For the ActiveCampaign branded-DKIM setup, require trusted dkim=pass for the intended custom signature, with its actual d= aligned to the intended visible From under the active adkim mode, plus trusted receiver dmarc=pass. A pass supplied only by SPF does not prove this DKIM setup works. Independently diagnose SPF fail, softfail, temperror and permerror, even when DKIM supplies DMARC: examine the actual envelope domain, connecting IP, full policy and route. DMARC alignment, SPF results.
Also check for From rewriting. ActiveCampaign documents a gradual rollout for accounts under 5,000 contacts that substitutes a generic From address when a domain is unauthenticated. A message authenticated under that substitute identity does not prove your original brand's configuration is complete. Inspect the delivered From, not only the editor. From-rewrite caveat.
Troubleshooting and frequently asked questions
Why does Configure Domain say the domain was not found?
The official setup guide identifies unsupported DNS providers as a cause. Use manual setup when appropriate, and distinguish that limitation from a genuinely missing or newly registered domain.
Why is the domain verified but not authenticated?
Ownership verification succeeded, but DNS authentication is incomplete. Compare each generated row with public DNS, then recheck. Confirm the authoritative zone and look for a doubled hostname suffix or a conflicting CNAME owner.
What if my account still uses legacy TXT DKIM?
ActiveCampaign says TXT DKIM configured before February 23, 2023 still works, but recommends migrating to its CNAME method. Retrieve the current generated DNS records from the relevant domain’s Advanced Settings authentication controls. Plan the migration, verify the new records and test a delivered message before retiring a functioning legacy key. Do not delete it merely because a newer screenshot uses CNAMEs. Official legacy-DKIM troubleshooting.
Do I still need an ActiveCampaign SPF include?
Not for the current Mailserver Domain setup. Check the actual envelope identity before considering any root-domain SPF edit; an include does not change that identity.
Why does SPF pass but DMARC fail?
The passing SPF domain may be unrelated to From, or strict alignment may reject a subdomain relationship. Inspect DKIM too: DMARC fails when neither passing mechanism aligns.
Should I change DMARC to none to fix a campaign?
Do not weaken an established policy as the default repair. Diagnose the route, From identity, DKIM and Mailserver Domain first. Other senders and spoofing protections share the same policy.
Can authentication fix every spam-folder problem?
No. It establishes domain authentication, not consent, favorable reputation or guaranteed placement. Investigate complaints, list quality and sending patterns separately after the identity checks pass.
No customer-account setup, DNS change or delivered-message test was performed for this guide.