Email authentication for ActiveCampaign: SPF, DKIM and DMARC

22 May 2026 · 12 min read

ActiveCampaign sits in an awkward middle ground for email authentication, and that is exactly why it trips people up. It is not a pure transactional API like Postmark, and it is not a hands-off newsletter tool where you never touch DNS. It is a marketing automation platform that, by default, sends your campaigns and automations from its own shared infrastructure under its own domain, and then gives you an optional "domain authentication" feature that, once enabled, completely changes which authentication checks line up with your domain. Get the order wrong and you will publish a DMARC policy that quietly junks your automations.

This guide is specific to ActiveCampaign. It covers the exact SPF include you publish, how ActiveCampaign's CNAME-based DKIM works, why the return-path (bounce domain) is the hinge that decides whether SPF aligns, and the concrete, staged path to p=reject without losing a single automated email. If you only read one provider authentication guide, read the one for the platform you actually send from, because the alignment behaviour differs between providers and a generic DMARC checklist will mislead you here.

The three identities, and why DMARC only cares about two of them

Every message ActiveCampaign sends carries three separate notions of "who sent this":

• The From header: the address your contacts see in their inbox, for example news@yourdomain.com. This is the identity DMARC protects.
• The DKIM signature: a cryptographic signature whose d= tag names the domain that signed the message.
• The return-path (also called the envelope-from, bounce address, or MAIL FROM): where bounces are routed. This is the domain SPF actually checks.

DMARC does not pass simply because SPF or DKIM pass. It passes when at least one of them passes and aligns, meaning the authenticated domain matches the organisational domain in the From header. This single idea is the whole game with ActiveCampaign, so it is worth stating bluntly before we touch any DNS.

By default, before you enable domain authentication, ActiveCampaign sends on your behalf but signs and bounces under its own domain, not yours. The From header may say you@yourdomain.com, but the DKIM d= and the return-path both point at ActiveCampaign infrastructure. In that default state:

• SPF passes for ActiveCampaign's bounce domain, but that domain is not yours, so SPF does not align.
• DKIM passes for ActiveCampaign's signing domain, but again that domain is not yours, so DKIM does not align.

Result: neither identity aligns with yourdomain.com, so DMARC fails for everything ActiveCampaign sends. If your domain is at p=none you will not notice, because p=none takes no action. But the moment you move to p=quarantine or p=reject, your campaigns and automations start landing in spam or being rejected. This is the classic ActiveCampaign failure, and it is entirely preventable.

The fix is to enable domain authentication, which makes ActiveCampaign sign with your domain and (with the bounce step) bounce under your subdomain, so both SPF and DKIM can align. You can confirm exactly what is aligning for your live mail with the DMARC report analyzer, which breaks aggregate reports down by source so you can see ActiveCampaign's traffic and whether it currently passes on DKIM, SPF, or neither.

Step 1: enable domain authentication inside ActiveCampaign

Do the DNS work only after ActiveCampaign has generated your account-specific records, because the selectors and CNAME targets are tied to your account.

1. In ActiveCampaign, go to Settings, then Advanced (older accounts: Settings, Domains).
2. Find the domain authentication section and add your sending domain, for example yourdomain.com.
3. ActiveCampaign generates the DNS records you must publish: a DKIM record (CNAME), an SPF/return-path record (CNAME for the bounce subdomain), and it tells you what to do about your root SPF TXT record.

Always copy the literal values from your own ActiveCampaign screen. The examples below are representative of the shape ActiveCampaign uses, not your exact values. Targets typically resolve into ActiveCampaign's sending platform, historically emsmtp.com / *.mailfeed.io infrastructure, but copy what the dashboard shows you.

Step 2: publish DKIM (the load-bearing record)

ActiveCampaign uses CNAME-based DKIM. Instead of pasting a public key into a TXT record, you publish a CNAME that delegates the lookup to ActiveCampaign, which means ActiveCampaign can rotate the underlying key without you ever touching DNS again. This is the more robust option and you should not try to convert it to a manual TXT key.

The DKIM record has the familiar selector._domainkey shape. ActiveCampaign typically uses a selector such as dkim (you will sometimes see it presented as the host dkim._domainkey). A representative record looks like this:

Type:  CNAME
Host:  dkim._domainkey.yourdomain.com
Value: dkim.yourdomain.com.<account-id>.dkim.emsmtp.com

Some ActiveCampaign accounts present DKIM as a plain CNAME at a host like <selector>._domainkey.yourdomain.com pointing at a per-account *.dkim.emsmtp.com target. Whatever the exact target string, the principle is the same: a CNAME at the _domainkey host, delegating to ActiveCampaign.

Three things that catch people out on this record:

• Host field doubling. Some DNS panels want the bare label dkim._domainkey and append your domain automatically. Others want the fully qualified dkim._domainkey.yourdomain.com. If you enter the full host on a panel that also appends the domain, you create a broken record like dkim._domainkey.yourdomain.com.yourdomain.com. When verification fails, check for this doubling first.
• Cloudflare proxying and flattening. If your DNS is on Cloudflare, keep the DKIM CNAME DNS-only (grey cloud), not proxied (orange cloud). A proxied DKIM CNAME will not resolve to ActiveCampaign's key and DKIM will silently break. Leave it as a plain, unproxied CNAME.
• Do not also paste a TXT at the same selector. One record per selector. A leftover TXT public key fighting with the CNAME produces unpredictable validation results.

Once the CNAME resolves, return to ActiveCampaign and click verify. A correct record shows as authenticated. You can independently confirm the signature is live and well-formed with the DKIM checker, entering your domain and the selector (for example dkim). For background on why the selector matters and how receivers locate the key, see the glossary.

DKIM is the record you most need to get right, because on a marketing platform like ActiveCampaign aligned DKIM is the most reliable way DMARC passes, and it survives mailing-list forwarding in ways that SPF does not.

Step 3: SPF, the return-path, and why both matter here

This is where ActiveCampaign differs from a pure shared-pool newsletter tool, and where a generic guide steers you wrong. ActiveCampaign gives you two separate SPF-related actions, and you need to understand each.

3a. The root SPF include

ActiveCampaign's published sending include resolves into its emsmtp.com sending infrastructure. You add it to your single root SPF TXT record:

Type:  TXT
Host:  @
Value: v=spf1 include:emsmtp.com ~all

If ActiveCampaign's dashboard shows a different include host for your account, use the one it shows; the platform has used more than one sending domain over the years. The important rule is that a domain must have exactly one v=spf1 TXT record. If you already send through, say, Google Workspace and ActiveCampaign, you merge them into one record:

Type:  TXT
Host:  @
Value: v=spf1 include:_spf.google.com include:emsmtp.com ~all

Never publish two separate v=spf1 records. Receivers treat that as a permanent error and SPF stops working for the whole domain. SPF also allows a maximum of 10 DNS lookups during evaluation, and include:emsmtp.com consumes at least one. If your record is creeping toward that ceiling because you have stacked every tool you ever trialled, validate it with the SPF checker and read how to fix SPF PermError from too many DNS lookups. Flattening is one mitigation, explained in how SPF flattening works.

3b. The return-path / bounce subdomain (this is what makes SPF align)

Here is the crucial part. Adding include:emsmtp.com to your root SPF record does not, on its own, make SPF align for ActiveCampaign. Alignment depends on the return-path, and by default the return-path is ActiveCampaign's bounce domain, not yours.

ActiveCampaign's domain authentication fixes this by having you publish a CNAME for a bounce subdomain under your own domain, so the envelope-from becomes something like bounce.yourdomain.com or email.yourdomain.com instead of an ActiveCampaign host. A representative record looks like this:

Type:  CNAME
Host:  email.yourdomain.com
Value: <account-id>.bnc.emsmtp.com

(Some accounts label this the "custom mail server domain" or "return-path" record. The exact host and target come from your dashboard.)

Once that subdomain is live and ActiveCampaign sets the envelope-from to email.yourdomain.com, SPF is evaluated against your subdomain, which CNAMEs into ActiveCampaign's SPF-authorised infrastructure. Now SPF passes and aligns, because email.yourdomain.com shares the organisational domain yourdomain.com with your From header (under relaxed alignment, which is the DMARC default).

So the honest summary for ActiveCampaign is:

• DKIM CNAME gives you aligned DKIM.
• Bounce-subdomain CNAME plus the SPF include gives you aligned SPF.
• You want both, but you only strictly need one of them aligned for DMARC to pass. Publish all three records and you have belt and braces.

This is a meaningfully stronger position than shared-pool platforms where SPF alignment is simply unavailable. On ActiveCampaign, properly authenticated, you can have both authentication results aligned, which is the most resilient setup.

Step 4: From-address consistency and subdomains

DMARC uses the organisational domain for relaxed alignment, so a DKIM signature on yourdomain.com aligns with a From of news@yourdomain.com, and a bounce on email.yourdomain.com aligns with it too. A clean pattern many senders adopt is to dedicate a subdomain to ActiveCampaign marketing, for example news.yourdomain.com, so the reputation of your bulk automations is isolated from your corporate mail on the parent domain.

If you go down that route:

• Authenticate the subdomain in ActiveCampaign and publish the DKIM and bounce CNAMEs under that subdomain.
• Send your campaigns from you@news.yourdomain.com.
• Be aware of subdomain policy. If your DMARC record sets an explicit sp= (subdomain policy), that governs news.yourdomain.com. If you do not set sp=, the subdomain inherits the main p=. This matters because you can enforce the parent at p=reject while keeping a subdomain at a looser policy during testing, and vice versa. See should you publish a subdomain DMARC record for the trade-offs.

Whichever you choose, send from a consistent, authenticated From domain. Switching the From domain after you have authenticated only one domain is a common way to break alignment without realising.

Step 5: the DMARC record and the staged path to enforcement

DMARC ties it together. It tells receivers what to do when a message fails both aligned SPF and aligned DKIM, and where to send you reports. You publish it once at _dmarc.yourdomain.com, no matter how many providers you use. The order of operations is the entire point: authenticate ActiveCampaign first, watch the reports, then tighten. Do not start at p=reject.

Stage 1: monitor

Publish a monitor-only record with reporting turned on:

Type:  TXT
Host:  _dmarc.yourdomain.com
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r

p=none changes nothing about delivery; it just asks receivers to send aggregate reports to your rua address. adkim=r and aspf=r request relaxed alignment, which is exactly what lets a news.yourdomain.com DKIM signature and an email.yourdomain.com bounce align with the yourdomain.com From header. Build a correct record with the DMARC generator and validate an existing one with the DMARC checker.

Stage 2: read the reports

Let it run for one to two weeks of normal sending, including any automations that fire on a schedule rather than daily. Aggregate reports arrive as XML, which is unreadable by eye, so feed them to the DMARC report analyzer. You are looking for one thing: is ActiveCampaign traffic passing DMARC via aligned DKIM, aligned SPF, or both? After you have completed domain authentication, it should show your ActiveCampaign volume passing with DKIM aligned and, if you published the bounce subdomain, SPF aligned too.

While you are there, confirm every other legitimate source is aligned: your mailbox provider (Google Workspace, Microsoft 365), any helpdesk, any billing or invoicing tool. DMARC enforcement is domain-wide; it will hit those sources too, not just ActiveCampaign. New to reading these, the walkthrough in reading your first DMARC report is the place to start. If your reports come back empty, that is its own problem, usually a typo in rua or a brand-new record, and a quiet p=none gives false security explains why you should not sit in monitor mode forever.

Stage 3: quarantine, partially

Once ActiveCampaign and your other sources are consistently aligned, step up cautiously using the percentage tag:

Type:  TXT
Host:  _dmarc.yourdomain.com
Value: v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r

pct=25 applies quarantine to a quarter of failing mail, limiting the blast radius while you keep watching reports. If nothing legitimate is being quarantined, raise to pct=50, then pct=100. The point of sampling is to catch a forgotten sender before it affects all of your mail rather than a slice of it.

Stage 4: reject

When p=quarantine; pct=100 has run clean for a week or two, move to full enforcement:

Type:  TXT
Host:  _dmarc.yourdomain.com
Value: v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r

At p=reject, anything failing aligned authentication is rejected outright, which is exactly what stops criminals spoofing your domain. Because you reached this point by confirming ActiveCampaign's aligned DKIM and SPF first, your campaigns and automations keep flowing untouched.

For a fuller, provider-independent walk-through of this rollout, see how to reach p=reject without breaking email. For the mailbox-provider rules driving all of this, why Gmail, Yahoo and Microsoft now require DMARC covers the bulk-sender thresholds and the broader requirements.

Common ActiveCampaign authentication mistakes

• Skipping domain authentication entirely. Sending "from" your domain while ActiveCampaign signs and bounces under its own domain means neither identity aligns and DMARC fails for everything. This is invisible at p=none and catastrophic at p=reject. Always enable domain authentication.
• Publishing the SPF include but not the bounce subdomain. include:emsmtp.com alone does not align SPF, because the return-path is still ActiveCampaign's by default. Publish the bounce CNAME so the envelope-from becomes your subdomain.
• Proxying the DKIM or bounce CNAME on Cloudflare. Keep both DNS-only (grey cloud). A proxied record will not resolve to ActiveCampaign's targets.
• Doubling the host suffix. dkim._domainkey.yourdomain.com.yourdomain.com from entering a full host on a panel that auto-appends the domain.
• Two SPF records. One v=spf1 line only; merge providers into it. Stacking includes can also blow the 10-lookup limit.
• Converting CNAME DKIM to a manual TXT key. You lose ActiveCampaign's automatic key rotation and gain a maintenance burden for no benefit.
• Changing the From domain after authenticating only one. If you authenticate yourdomain.com and then start sending from news.yourdomain.com without authenticating it, alignment breaks.
• Jumping straight to p=reject. Always monitor, then quarantine with pct, then reject.
• Forgetting your other senders. If your CRM, invoicing tool, or support desk is not aligned, enforcement junks them too. The fix when a specific service is not aligned at reject is covered in what to do when a service is not aligned at p=reject.

Verify the whole chain

Before and after you reach enforcement, confirm each layer resolves:

• DKIM checker: query selector dkim and confirm a valid key resolves through the CNAME to ActiveCampaign.
• SPF checker: confirm a single valid record, under 10 lookups, with include:emsmtp.com present.
• DMARC checker: confirm the policy, reporting address and alignment tags are what you intend.
• DMARC report analyzer: confirm ActiveCampaign traffic is passing on aligned DKIM and SPF before you tighten the policy.

If you also publish MTA-STS or BIMI, note that BIMI requires p=quarantine or p=reject first, so reaching enforcement through ActiveCampaign is a prerequisite for a verified logo in the inbox. Whether you actually need it is discussed in do you need BIMI.

The practical takeaway

For ActiveCampaign, the rule is short: enable domain authentication first, publish all three records (DKIM CNAME, bounce-subdomain CNAME, and the include:emsmtp.com SPF include), then move DMARC from p=none to p=quarantine to p=reject while watching aggregate reports. The hinge is the return-path: the bounce subdomain is what turns a passing-but-unaligned SPF result into a passing-and-aligned one, and aligned DKIM is your most resilient path through forwarding. Done in that order, you reach full enforcement with your campaigns and automations untouched.

If you would rather not babysit selectors, bounce subdomains, percentages and XML reports yourself, our done-for-you DMARC service takes your domain from p=none to p=reject with continuous monitoring and change alerts, and our free monitoring will email you the moment an ActiveCampaign DKIM record stops resolving or your alignment slips. Start by running your domain through the DMARC report analyzer to see exactly how your ActiveCampaign mail is authenticating today.