Provider documentation checked on 8 November 2026. Account-generated values and current product support remain deployment prerequisites.
Action Network's email authentication workflow is support-mediated. Its first-party guide says Action Network uses SendGrid for delivery and obtains domain-specific DNS records for the partner. Do not substitute a generic SendGrid example for the records issued to your organization.
Request the correct domain setup
References: RFC 9989 §4.4.
Identify the domain you control, the group sending the messages and the reply-to address you intend to use. Action Network instructs partners to contact its support with that reply-to address, publish the returned CNAME records, then notify support so it can verify the installation. The guide says this setup covers SPF without a separate SPF record for that workflow. It also offers DMARC records alongside the domain authentication records. Action Network installation guide
The guide's reply-to-based intake is not a change to how DMARC works. DMARC alignment concerns the visible From domain, not Reply-To. Before the request, record both addresses. Ask support to resolve any difference between the submitted domain and the identity that will actually appear in outgoing mail.
Review the returned DNS changes
References: RFC 9989 §4.10.
Original change-control recommendation: give the DNS owner a row for each supplied owner name, type and target, plus its intended purpose and any existing record at that name. CNAME delegation values must be copied exactly. If the DNS editor appends the zone name, use its required relative-host format so the domain is not duplicated. Do not add an unrelated apex SPF include merely because another service's instructions mention it.
Treat a supplied DMARC policy as a proposal for the domain owner to review. Preserve an existing valid policy and reporting configuration unless a deliberate change is approved. Do not create two DMARC records at the same policy name or replace an enforced policy with a monitoring policy just to complete onboarding. Sender authentication setup and domain-wide policy decisions have different scopes.
Verify after support confirms installation
References: RFC 6376 §6, RFC 9989 §4.4.
Use a controlled Action Network mailing, not a message sent directly from your regular mailbox. Save the original received headers and capture visible From, envelope/SPF identity, passing DKIM d= and selector, and the trusted receiver's DMARC result. Check every organizational sending domain in use. Support's verification closes the provider setup step; message evidence closes the end-to-end check.
Illustrative case: the request used reply-to@organizing.example, but a campaign uses a From address on coalition.example. Installing organizing.example's records does not establish aligned authentication for coalition.example. Resolve the sender selection or configure the other owned domain through the supported process.
Keep support and policy evidence separate
References: RFC 6376 §3.3.
If records are visible but the intended domain is not signing, return the exact domain, record names and a redacted test to support through your approved process. Do not disclose unrelated recipients or message content. Pause affected mail rather than guessing additional selectors. Keep records needed by other groups until their use is understood.
This article does not repeat the source's simplified cryptographic or list-size explanations: DKIM does not place a private key in the message, and mailbox-provider requirements must be assessed from each receiver's current rules. The documented Action Network setup is supported; no tenant execution, delivery guarantee or universally applicable bulk-sender threshold is claimed.