Act-On SPF, DKIM and DMARC setup, step by step

Authenticate every Act-On From domain, configure the separate envelope domain, publish the account-specific DKIM record and obtain Act-On Support activation. The current From-domain workflow uses include:_spf.act-on.net; DKIM normally uses an account-ID CNAME pointing to dkim.act-on.com. DNS publication alone does not complete activation. Act-On Email From Setup

This guide covers email transported by Act-On, including personalized From identities. It does not configure the underlying corporate mailbox provider or treat a CRM connection as an alternative authentication route. No account configuration, DNS edit or test send was performed.

Plan identities and permissions

Create a worksheet with the Act-On account, parent account if applicable, each visible From domain, the envelope domain, DNS administrator and support ticket owner. Include personalized sales-owner addresses, not just the default newsletter sender. A domain appearing in a personalization field can change which identity needs testing.

An Act-On administrator needs access to manage senders; the mailbox owner must be able to receive its verification email. DNS access belongs to the DNS administrator. Keep these approvals distinct: clicking a mailbox-verification link does not publish DKIM, and publishing DKIM does not verify mailbox ownership. Manage From Addresses and Email Senders

Before changing an established account, recover its original support change sheet. Determine whether the envelope already works and whether DKIM uses CNAME or a Support-issued TXT exception. Do not rebuild working routing as a side effect of adding a new sender.

Configure the envelope domain

Act-On's envelope setup uses a dedicated email-only subdomain. On that subdomain, its documented new setup is:

Before publication, compare the exact envelope owner, MX target and numeric priority with the domain owner’s approved bounce-routing plan. A provider instruction is not authorization to redirect an existing mailbox or bounce service.

Do not apply the MX change to the company's root domain. The envelope is separate from the address readers see. Submit the Envelope Domain setup form after publication and wait for Support's completion notice. Envelope From Domain Setup

For an existing envelope domain, compare these requirements with the account's configuration rather than overwriting it. An unexpected MX or SPF value deserves investigation with Support. Moving bounce routing can affect processing of undeliverable messages even if ordinary corporate inboxes remain unaffected.

Configure every From domain

For each visible From domain, add the documented SPF authorization to its existing single policy. If no policy exists and Act-On is the only authorized sender, the provider's new-policy example is v=spf1 include:_spf.act-on.net -all. Do not paste that as a second SPF record.

The normal DKIM CNAME owner is {{AOAccountID}}aoauth._domainkey; replace the placeholder with the real account ID from the Start page or Account Details. The target is dkim.act-on.com. For child accounts, use the parent account ID. Preserve working DMARC rather than replacing it with the documentation's monitoring example. Email From Setup

Confirm the fully qualified owner before saving. For a From domain of example.com, the owner ends in ._domainkey.example.com. It is not an entry under the envelope domain unless that is also the relevant signing domain.

For a signing domain of news.example.com, these are DNS-name mappings, not permission to use that domain or to create a new delegation. Replace ACCOUNTIDaoauth with the exact account selector and preserve the issued type and complete target/key.

Keep existing NS and DNSSEC delegations. A parent-zone record below a delegation is not a substitute for publication at the real authority. DKIM owner construction, relative DNS names.

Legitimate TXT alternative

If the DNS host will not accept an underscore in the CNAME owner, request a TXT record from Act-On Support. Publish the exact host and complete key they issue. Do not put dkim.act-on.com into a TXT field, reuse a public-key screenshot, or create both TXT and CNAME at the same owner. Act-On's DNS guidance explicitly documents this fallback. Editing DNS to implement DKIM

Record which mode you selected so future maintenance does not mistake a legitimate TXT deployment for a missing CNAME. A key-format change must stay coordinated with the signing service.

Activate and select the sender

Submit the Email From setup support request after the required records are published for every From domain; obtain confirmation that Act-On has completed its side. The provider describes propagation of up to 24 hours, but elapsed time is not an acceptance test. Email From Setup

Once domain setup is complete, an admin can open Settings > Other Settings > From Addresses, choose + Add sender, enter the sender and complete the verification email. Select the verified identity in Email Composer > Settings > Sender, or Address > Sender for legacy emails. Test the actual selected sender rather than assuming a newly added one became the default. Sender management

Keep support activation, mailbox verification and delivered-message acceptance as separate worksheet columns. Close the change only when all three have evidence.

Preserve DNS and DMARC safely

Export the affected records before making an approved change. Record the authoritative DNS host, exact owner name, record type, existing value, proposed value and rollback owner. A registrar is not necessarily the DNS host. Check whether the DNS interface appends the zone name; a doubled suffix creates a record at the wrong name. Keep unrelated verification TXT records and corporate mail routing intact.

SPF checks the envelope MAIL FROM identity (or the HELO identity in applicable cases, such as a null reverse-path), not just the visible From address. Maintain one SPF policy per owner name. Preserve existing legitimate authorizations and the existing terminal policy unless a separate change is approved. SPF permits at most ten evaluated DNS-lookup-causing terms, including nested includes and redirects; merely counting visible includes is insufficient. SPF standard, RFC 7208

Any all mechanism makes redirect= ignored, regardless of order; mechanisms after all are never evaluated. Preserve a legitimate redirect-based policy instead of adding an all that silently disables it. SPF all and redirect processing.

For authentication CNAMEs hosted at Cloudflare, use DNS only, not the HTTP proxy, and leave record-level flattening off. Check that zone-wide flattening is not hiding these aliases. Receivers and verification tools must see the assigned CNAME, not a substituted address response. Review the impact before changing any zone-wide setting. Cloudflare CNAME verification guidance

Cloudflare flattens apex CNAMEs by default and flattens same-zone targets regardless of the flattening setting. Its zone-wide flatten-all option cannot be overridden per record. Where the sender requires a literal CNAME answer, leave the applicable record-level Flatten control off and ensure zone settings do not conceal it. If mandatory apex/same-zone behavior or shared settings prevent that answer, stop and coordinate a supported design; do not delete a delegation or disable shared controls blindly. Cloudflare exact flattening behavior.

Do not place other record data at a CNAME owner. If an existing selector is occupied, resolve its ownership with the provider before replacing it. Never publish a private key or generate a replacement key independently for a managed signing service. A TXT public key and a CNAME pointing to a key service are different record types, not interchangeable text fields. DNS aliases, RFC 1034 · DKIM, RFC 6376

Keep an existing DMARC policy. DMARC passes when either SPF passes and aligns with From, or a valid DKIM signature aligns with From. Relaxed alignment permits the same organizational domain; strict alignment requires an exact domain match. Subdomains can inherit policy, so inspect the effective policy before adding another record. A new monitoring policy is a separate, owner-approved rollout decision, not a reason to replace quarantine or reject. Current DMARC removes pct; do not promise percentage-based enforcement. Current DMARC standard, RFC 9989

Only when no direct or applicable inherited policy exists, the owner approves it and someone will review the reports, a first monitoring TXT value may be:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the mailbox address after mailto: with the approved monitored address, not a second mailto: URI. From example.com uses full owner _dmarc.example.com, relative _dmarc in example.com. From news.example.com uses full owner _dmarc.news.example.com, relative _dmarc.news in its authoritative parent zone or _dmarc in a separately delegated news.example.com zone. Do not create a child monitoring override of inherited protection. Current DMARC publication and discovery.

Compare the Organizational Domain of the domain where the DMARC policy was found with the Organizational Domain of the report URI host. If they differ, the report-generating mail receiver must check DNS authorization published by the report-destination operator. A destination within the same Organizational Domain is excepted; a different hostname alone is not external. This protocol check does not replace the owner’s approval to share reports. RFC 9990 section 4.

For a new monitoring deployment, choose an authorized aggregate-report destination and satisfy external reporting authorization where required. Reports need an accountable reviewer, not just a mailbox. Do not add forensic reporting by default: failure reports can expose message or personal information. Aggregate reporting, RFC 9990 · Failure reporting, RFC 9991

Verify DNS and a delivered message separately

Use the real values from the approved change sheet in place of these example names. These are read-only checks, not commands to publish records:

dig +short TXT envelope.example.com
dig +short CNAME actual-selector._domainkey.example.com
dig +short TXT actual-selector._domainkey.example.com
dig +short TXT _dmarc.example.com

Query the authoritative DNS server as well as a recursive resolver if answers disagree. A CNAME must resolve to the assigned target and ultimately a usable public key; a TXT deployment must expose the complete issued key. An empty answer can mean the wrong owner name, missing data or stale negative caching. Check the name before waiting longer.

After activation, send an authorized representative message to a mailbox you control and inspect its original headers. Trust only Authentication-Results added by that receiving system, not a header supplied by the sender or an arbitrary intermediary. Record visible From, envelope identity (smtp.mailfrom), DKIM signing domain (header.d), DKIM selector (s=), and the receiver's DMARC result. A DNS lookup cannot show whether a sender actually used a key. Authentication-Results trust boundary, RFC 8601

Use results generated inside the receiving service’s known processing boundary, with its documented handling that removes or clearly distinguishes externally supplied Authentication-Results. If unclear, ask its mail administrator or use receiver-controlled diagnostics. A familiar authserv-id string or header position alone is not proof; ignore attacker-supplied fields. RFC 8601 section 7.1.

For illustrative From sender@example.com, a passing intended signature with d=news.example.com is relaxed-aligned when both share Organizational Domain example.com, but not strict-aligned. A passing d=example.com signature aligns under either mode. These are identity examples, not measured results.

Acceptance requires the expected route and sender, valid provider DNS, completed provider activation, and a trusted receiver showing the expected branded DKIM identity with dkim=pass, alignment to the visible From domain, and dmarc=pass. This operational acceptance gate is deliberately stronger than DMARC's protocol minimum: an aligned SPF pass alone must not hide a broken DKIM deployment. Investigate unexpected SPF or DKIM failures even when the other mechanism carries DMARC. Keep the message ID, send time, relevant headers and change reference with the test result. Forwarded mail can behave differently, so start with direct delivery and test forwarding separately.

Do not accept a provider-rewritten From address as successful authentication of the intended brand. Diagnose SPF fail against the actual sending IP, envelope policy and route; permerror against duplicate policies, syntax and evaluated lookup limits; and temperror against transient DNS failures. Keep these investigations open even when aligned DKIM supplies DMARC pass. SPF result meanings.

Passing authentication is not a promise of inbox placement. Consent, complaints, reputation, content and recipient filtering remain separate operational concerns. Do not tighten policy solely because one test message passed.

For a message with several signatures, the EmailAuth raw-versus-aligned DKIM guide explains why an unrelated signer’s pass is not the branded path you are trying to validate.

Troubleshoot Act-On by symptom

For escalation, supply the account and parent relationship, affected domain, selector, record type, support ticket, a redacted original-header sample and exact failure time. Do not send private keys or unrelated recipient data.

Review boundary

This guide is based on documentation, not hands-on account, DNS or delivery testing. Complete account-specific validation, public DNS checks, support activation and trusted-receiver tests before relying on your setup. Authentication does not guarantee delivery.