[ Sending-service guides ]
Authenticate email sent through Action Network: configuration and verification
Use Action Network’s support-generated domain records and verify the actual From identity after installation.
By the EmailAuth research team · 3 min read
[ Key points ]
- Obtain the organization-specific records through Action Network support.
- Reply-To intake does not change DMARC’s use of the visible From domain.
- Keep provider installation checks separate from message evidence.
[ Takeaway ]
Keep provider installation checks separate from message evidence.
[ By role ]
What this means for you
Choose your role for practical next steps.
IT / Mail Admin
Verify the actual route
Retain the support-issued record set and a real campaign-path header comparison.
Next steps
- Retain the support-issued record set and a real campaign-path header comparison.
- Preserve the exact generated record set and the authoritative DNS before-and-after comparison.
- Capture From, SPF identity, DKIM d=/s= and trusted receiver results from the real route.
CISO / SecOps
Govern the remaining exposure
Keep domain-wide DMARC approval separate from a group-level authentication request.
Next steps
- Keep domain-wide DMARC approval separate from a group-level authentication request.
- Require a recorded decision for any unresolved authentication or vendor-capability exception.
- Review obsolete DNS authorizations and delegations when this service is retired.
Founder / Non-technical
Own the sending outcome
Assign a single owner to coordinate the organizing group, DNS administrator and provider verification.
Next steps
- Assign a single owner to coordinate the organizing group, DNS administrator and provider verification.
- Assign the business workflow and sending-domain owner before approving the change.
- Keep the affected campaign paused until its acceptance evidence is available.
[ FAQs ]
Frequently asked questions
Do I need my own SendGrid account?
The documented Action Network workflow obtains the records through Action Network support. Do not create a parallel setup without a separate need.
Why does support ask for Reply-To?
That is its documented intake workflow. Still inspect the actual visible From domain for DMARC alignment.
Should I add a separate SPF record?
The cited workflow says its supplied CNAME setup covers SPF without a separate SPF record. Follow the issued values for your domain.
Can I copy another group’s CNAMEs?
No. Use the records supplied for your authorized domain and group.
Should I overwrite our existing DMARC policy?
No. Have the domain owner reconcile any proposed record with the current policy and reporting destinations.
Does support verification replace a test email?
No. It confirms installation; a received message shows which identities the actual mailing used.
Does a private key appear in the header?
No. A DKIM signature appears in the header. The secret private signing key is not transmitted.
What if the campaign uses another From domain?
Configure and verify that owned domain or select the authenticated sender. Reply-To alone does not fix alignment.
[ Sources ]
Sources
- Action Network: Installing DKIM, SPF and DMARC records
Sections DKIM and SPF, steps 1–6 · DMARC, steps 1–6 · FAQs: How does DKIM work? (inaccurate key explanation not adopted)
- RFC 9989: DMARC
Sections §4.4.1 DKIM-authenticated identifiers · §4.4.2 SPF-authenticated identifiers · §4.10 DNS tree walk and duplicate policy records · §5.3.5 Determine DMARC pass or fail
- RFC 7208: SPF
Sections §3.2 Multiple DNS records · §4.5 Selecting records · §4.6.4 DNS lookup limits
- RFC 6376: DKIM
Sections §3.3 Signing and verification algorithms · §3.6.2 DNS binding · §6 Verifier actions
[ Glossary ]
Glossary
- Visible From
- The author address displayed in the message From header, whose domain is used for DMARC alignment.
- Envelope identity
- The SMTP sending identity evaluated by SPF, distinct from the visible From and Reply-To.
- DKIM selector
- The s= identifier used with the signing d= domain to locate the verification key.
- Alignment
- The required domain relationship between an authenticated SPF or DKIM identity and the visible From domain.
Enterprise provenance
Why top financial institutions and governments retired their email security dashboards.
Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.
EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.
SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption