Provider documentation checked on 8 November 2026. Account-specific values, current product scope and provider activation remain deployment prerequisites.
Choose the Apptivo route before changing DNS
Apptivo's SES migration article, last modified March 13, 2024, says it migrated outgoing email to Amazon SES. For a domain you control, it directs customers to obtain DKIM CNAME records and updated SPF information from Apptivo Support. Its older November 2020 manual instead describes Business Settings > Email Deliverability and a Generate SPF and DKIM record button. These are different documented workflows, not interchangeable instructions. Confirm which applies to your account and outbound feature before publishing records. This guide covers the documented SES support-assisted route; it does not claim every Apptivo integration uses that route.
The business owner should identify which CRM or campaign workflow is failing and which From addresses it uses. The Apptivo administrator identifies the account and obtains the current record set. The DNS administrator verifies zone ownership and applies the authorized changes. Keep mailbox-sync problems separate: a working DNS setup does not establish that a Google, Microsoft or IMAP mailbox connection is healthy.
Configure a domain you control
References: RFC 7208 §3.2.
- Contact Apptivo Support at the address documented in its migration article, support@apptivo.com. Specify the account, sending domain and affected outgoing workflow. Ask for the current account-specific Amazon SES DKIM CNAMEs and SPF change instructions.
- The migration article describes six CNAME records and an IN TXT record containing updated SPF IP information. Treat that as the documented migration set, not permission to manufacture six names or reuse another tenant's values. If your support-provided count differs, reconcile that difference before editing DNS.
- Copy each supplied owner name and target into the correct authoritative zone. Check whether your DNS interface appends the domain automatically. Retain the original support response and a before-and-after record export.
- Merge the authorized SPF change into the existing policy at the instructed domain rather than publishing a competing v=spf1 record. Confirm that its scope matches the actual sending route. No universal Apptivo SPF include or IP address is supplied in this guide.
- Ask Support to confirm domain verification and whether any activation step remains. Then send a new message through the affected Apptivo workflow and complete the identity worksheet below.
Handle free addresses and sync separately
For free email accounts such as Gmail or Yahoo, the migration article directs the account to request a verification link from Support and click it to verify the address. That does not give the user DNS control over gmail.com or yahoo.com, and it is not proof of aligned custom-domain DKIM. Inspect the resulting message rather than asserting DMARC success from address verification alone.
If sync still fails after configuration, the article describes Preferences > General > Email > G Suite/Office365/IMAP, editing the configured account, then Disable sync and Enable Sync. Use that only for the documented sync issue, with the mailbox owner's authorization and awareness of interruption. Do not use reauthentication as a substitute for fixing a wrong DNS owner name. Escalate contradictory legacy and SES instructions to Support with the workflow and record evidence instead of combining both sets blindly.
Provider procedure and scope: Apptivo SES migration and domain verification, Apptivo legacy DKIM and SPF records.
Verify the message, not only the DNS
References: RFC 9989 §4.4, RFC 6376 §6.
Use a controlled recipient you administer and send through the exact production workflow. Preserve the raw message and trusted receiving system's Authentication-Results, together with the workflow, sending domain, timestamp and account identifier. A green DNS result proves record visibility, not that the service signed this message or that the receiver accepted an aligned identity. No live account, DNS lookup or received message has been tested for this guide; the following is a collection worksheet, not a claimed successful result.
- Visible RFC5322.From domain: Is this the intended customer-facing identity?
- Envelope/Return-Path and receiver SPF result: Which domain did the receiver actually evaluate, and did it pass?
- Every DKIM signature's d= and s=: Which signing domain and selector were used, and which signature passed?
- Receiver DMARC result and evaluated policy: Does a passing SPF or DKIM identity align with the From domain?
- Workflow, timestamp and raw message: Can another administrator reproduce and review the exact route?
SPF authenticates the envelope identity, not simply the visible From address. DKIM verifies a signature associated with its d= domain; it does not encrypt the message. DMARC needs at least one passing, aligned authentication path. Under strict alignment, the relevant domains must match exactly; relaxed alignment follows the organizational-domain rules in RFC 9989. Do not infer alignment from a provider-domain SPF pass or from an unrelated passing DKIM signature. Use the receiver's trusted results rather than arbitrary Authentication-Results headers carried inside the message.
Release, troubleshoot and recover
References: RFC 7208 §4.6.4.
Before making changes, record the current DNS values, TTLs, sender settings and a named rollback owner. Check authoritative DNS first, then a recursive resolver after relevant cached data expires. A missing record can mean an incorrect owner name, a duplicated domain suffix, the wrong authoritative zone or a stale cache. Never create a second SPF policy at the same owner name. When editing an existing policy, preserve legitimate senders and evaluate the complete nested lookup budget against RFC 7208’s ten-term limit for evaluated include, a, mx, ptr, exists and redirect terms, including nested processing. This is not a simple count of visible includes or raw DNS packets.
If DKIM passes but DMARC fails, compare the passing d= domain with the actual From domain and the published alignment mode. If DKIM is absent, investigate provider activation and route selection before repeatedly replacing the key. If authentication passes but delivery remains poor, inspect rejection responses, suppression state, reputation and recipient filtering separately. Authentication is not an inbox-placement guarantee, and a DMARC policy expresses requested handling rather than a promise of every receiver's decision.
Do not tighten the whole domain's DMARC policy based on this one integration. Inventory and verify other legitimate senders first. Release only after the DNS owner and service owner review a fresh message for every intended route. If the change fails, pause the affected flow or return to a previously tested supported route; restore only the records changed in this operation. Keep old selectors during a planned rotation until the old route has stopped signing and queued mail has been considered. Remove retired provider permissions only after confirming that no other active application depends on them.