Provider documentation checked on 8 November 2026. Account-generated values, entitlements and current support remain deployment prerequisites.
Act-On's published technical requirements distinguish the visible From address from the envelope domain used for bounces and SPF. Configuring only the visible address misses part of the sending route. Treat the account, the envelope subdomain and every From domain as separate items in your setup worksheet.
Establish the account-specific DNS change
Act-On's first-party technical PDF describes an envelope subdomain with an SPF TXT record and an MX record. It lists include:_spf.act-on.net in the SPF policy and est-mta.b2b-mail.net as the MX target at priority 10. For DKIM, it describes a CNAME whose host incorporates the Act-On account ID followed by aoauth._domainkey, targeting dkim.act-on.com. For child accounts it directs use of the parent account ID. The DKIM entry belongs under each From domain, not simply under the envelope domain. Act-On technical requirements
These are documentary instructions, not a verified record set for your account. Obtain or confirm the current account's setup with Act-On before publication, especially if its current onboarding screen differs from the PDF. No universal account number, selector or private key is supplied here. Keep the envelope subdomain separate from the domain handling employees' incoming mail.
Publish only the approved scope
References: RFC 7208 §3.2, RFC 7208 §4.6.4.
Original operator procedure: capture the existing authoritative TXT, MX and relevant DKIM records, identify the requested changes, and have the DNS owner approve the diff. Merge an authorized SPF mechanism into the existing policy at the correct owner name rather than creating a second SPF record. Check the ten-term SPF limit across evaluated include, a, mx, ptr, exists and redirect terms, including nested processing; it is not a count of all DNS packets. Never interpret an SPF include as a DKIM key or use a domain-wide MX replacement to solve a marketing subdomain request.
Confirm DNS visibility and the account's activation state before scheduling a real campaign. The public PDF points to additional technical setup steps; the account-specific completion flow was not exercised here. If those steps are not available, obtain a current provider confirmation rather than declaring setup complete from a CNAME lookup alone.
Prove the relationship with the visible From
References: RFC 9989 §4.4, RFC 9989 §5.3.5.
Send a controlled test through the intended campaign route. Retain the trusted receiving system's SPF result and evaluated identity, each DKIM result with d= and s=, the visible From and DMARC outcome. SPF passing for an Act-On-owned envelope domain does not by itself align with your corporate From domain. A passing DKIM signature for your From domain can provide the aligned path.
Illustrative diagnostic: From is offers.example.com; the envelope is a provider-owned domain; DKIM passes with d=offers.example.com. The aligned DKIM path can satisfy DMARC even though SPF is not aligned. If the only passing signature instead belongs to an unrelated provider domain, the same raw pass labels do not establish DMARC success. This is a hypothetical identity comparison, not an Act-On observation.
Keep changes and recovery bounded
References: RFC 6376 §3.3.
Pause the affected campaign when the intended aligned path cannot be demonstrated. Preserve the old records while investigating account ID, selected From address and service activation. Restore only a known working configuration under the change owner's approval. Do not broaden SPF to every sender or weaken the whole domain's DMARC policy as a shortcut. Authentication does not guarantee inbox placement, and DKIM signs selected message content rather than encrypting mail for confidentiality. The PDF’s diagram suggesting that the receiver obtains a private key is incorrect: only the public verification key is published; never transmit the signing private key.