Action Network SPF, DKIM and DMARC setup, step by step

For Action Network email, ask support for the DNS records for your domain, publish the supplied CNAMEs, and ask support to verify them. Do not add a generic SendGrid SPF record by default: Action Network's documented setup incorporates SPF into the supplied configuration. Finish by checking a delivered message, including its actual From domain. Action Network authentication instructions

This guide covers organizational email sent through Action Network's SendGrid-backed service. It does not configure an independent SendGrid account, your staff mailbox provider or every service that shares your domain. No customer account, DNS change or delivered-message test was performed for this guide.

Before requesting records

You need a domain your organization controls, access to its authoritative DNS zone and someone responsible for the Action Network sending account. A personal Gmail or Yahoo address does not give you authority to publish authentication records for that provider's domain.

Prepare a worksheet with the intended reply address, visible From address, organization or group that sends, and all domains currently used in campaigns. Save the existing zone and DMARC policy. List other legitimate senders, such as employee mail, fundraising receipts and support software, before making any SPF change.

Action Network's public procedure is support-led; it does not establish a self-service authentication feature for every account type. Ask support to confirm which sending group and domain the configuration covers rather than treating one organization's approval as approval for another.

Get and publish the Action Network records

Send the intended reply-to address to support@actionnetwork.org. Action Network obtains the domain configuration from SendGrid and returns the public DNS records. Publish that set, then notify support so it can verify installation. Continue using the agreed reply-to domain. Official setup procedure

Use this record worksheet rather than values copied from another organization's DNS:

For each CNAME, preserve the exact owner, underscores and target. Some DNS editors append the zone automatically. If your zone is example.com, entering a complete name into a relative-name field may produce name.example.com.example.com. Inspect the resulting full owner before saving.

Do not place a CNAME alongside existing TXT, A, AAAA, MX or another CNAME record at the same owner. A collision needs investigation, not deletion of the other service. Keep authentication aliases DNS-only where a DNS service offers web proxying. A web redirect is not a CNAME replacement. Leave unrelated DKIM selectors, mailbox MX records and site records intact.

Map owners across DNS delegations

These are naming examples, not provider-issued records. Suppose the signing domain is news.example.com and the issued selector is SELECTOR. Its full DKIM owner is SELECTOR._domainkey.news.example.com:

Publish in the zone served by the existing delegation's authoritative nameservers, not an inactive parent-zone copy. A DNS editor accepting full names must produce that same full owner, without repeating a zone suffix. For a visible From domain news.example.com, DMARC's full owner is _dmarc.news.example.com: relative _dmarc.news in the parent zone or _dmarc in the delegated child. A _domainkey delegation does not contain the DMARC owner. SPF belongs at the actual evaluated envelope domain, not automatically any of these DKIM or DMARC names.

Preserve NS delegations, existing selectors and shared services. Do not change parent nameservers, MX, DNSSEC or forwarding to make a tutorial fit. If authority or an owner collision is unclear, stop and involve the zone owner rather than deleting records. DNS zones and delegation

The organization should retain the record request and verification response. This makes later changes traceable without exposing account passwords, API credentials or private keys. Only public authentication data belongs in DNS.

Does Action Network need a separate SPF include?

Not in the documented standard workflow. The official instructions say the supplied configuration includes SPF and that a separate record is unnecessary. Follow the actual support-issued set if your account differs, and ask support to explain any additional TXT requirement before altering your root policy. Action Network's SPF and DKIM procedure

SPF evaluates the SMTP MAIL FROM domain (or HELO in applicable cases), commonly visible in a delivered Return-Path. It does not simply evaluate the reply-to address or the From address displayed by the mail client. An SPF change at the wrong DNS owner cannot fix an unrelated envelope identity. SPF identities

If support explicitly requires an SPF TXT update for your route, identify the exact owner first. Maintain one v=spf1 policy there; merge the approved authorization without removing other legitimate senders or weakening the existing terminal policy. Keep mechanisms before all; redirect is ignored when an all mechanism is present. SPF qualifiers do not guarantee a particular delivery outcome. Evaluate the complete policy, including nested includes and redirects, against SPF's limit of ten evaluated DNS-lookup-causing terms. This is not a count of all DNS packets or merely of includes written in the first record. SPF processing limits

Keep reply-to and DMARC identity separate

Action Network asks for the reply-to address during setup. That is operational input to its support workflow, not the identifier DMARC authenticates. Your acceptance test must inspect the actual RFC 5322 From domain, the SPF-authenticated MAIL FROM and the DKIM signing domain.

DMARC passes when at least one authenticated path also aligns with From: either passing SPF with aligned MAIL FROM, or a passing aligned DKIM signature. Strict alignment requires an exact domain match; relaxed alignment permits the same organizational domain. A provider-domain SPF pass alone may therefore be insufficient. Current DMARC specification

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

Check for both a direct policy and any applicable inherited parent policy before editing. Retain an existing p=quarantine or p=reject policy. Do not replace it with a minimum-policy example simply to make a new sender work. If no applicable policy exists, arrange a monitored introduction with the domain owner and account for all legitimate senders. Authentication setup is not a reason to weaken protection on unrelated mail.

Only when no direct or applicable inherited policy exists, the domain owner approves the destination and a monitoring plan, use this first-policy template. Publish type TXT at _dmarc.FROM_DOMAIN, mapped to the authoritative zone as above:

v=DMARC1; p=none; rua=mailto:YOUR_APPROVED_REPORT_MAILBOX

Replace YOUR_APPROVED_REPORT_MAILBOX with the mailbox address only, not another mailto: prefix. Replace FROM_DOMAIN with the actual intended From domain. Do not publish placeholders, duplicate a policy or override existing protection. Monitoring requests no quarantine or rejection; receivers retain their own delivery policies.

The current DMARC standard has removed pct; do not plan a percentage-based rollout around that obsolete tag. Aggregate reporting can help identify remaining unaligned streams. For aggregate reports, a destination in a different Organizational Domain from the domain publishing the DMARC policy requires the report-generating receiver to check DNS authorization at the destination. A destination within the same Organizational Domain is excepted; a different hostname alone is not enough to trigger this requirement. Have an external reporting operator provide and confirm the authorization for your actual policy domain. RFC 9990 section 4 DNS authorization is separate from the domain owner's approval to share reporting data. Approve the destination, access and retention before adding it; a functioning mailbox alone is not authorization. Failure reporting is separate and can expose message content or personal data; do not enable it casually. Failure-report privacy

For these issued aliases, preserve a literal CNAME answer: DNS-only is necessary where proxying is offered, but flattening can still hide the alias. Do not substitute ALIAS/ANAME or a web redirect. For Cloudflare specifically, turn the relevant per-record Flatten control off where available and ensure the applicable zone settings do not suppress these aliases. A zone-wide “flatten all” setting can override the record-level choice; review dependencies with the DNS owner before any approved zone-wide change, not a blind global disable. Cloudflare always flattens apex CNAMEs, and same-zone targets are flattened regardless of that setting. If mandatory apex or same-zone behavior prevents the required literal answer, stop and coordinate a supported record arrangement with Action Network and the DNS host. Do not invent a switch or remove an NS delegation. Cloudflare flattening controls; verification troubleshooting

Check public DNS, then close the support handoff

Replace uppercase placeholders with the exact full names supplied by support. These are read-only lookup patterns, not record values to publish:

dig +short CNAME SUPPLIED_DKIM_OWNER
dig +short TXT SUPPLIED_DKIM_OWNER
dig +short CNAME SUPPLIED_SPF_OWNER
dig +short TXT SUPPLIED_SPF_OWNER
dig +short TXT _dmarc.FROM_DOMAIN

Repeat the DKIM queries for every supplied selector. CNAME answers should match the issued targets; TXT resolution should lead to the appropriate public key or SPF data. If a resolver returns only an alias, query the returned destination separately. A published alias alone does not demonstrate that a message is signed.

For missing answers, check the actual delegated authoritative servers and ensure you edited their zone. Compare authoritative answers with recursive resolver answers before blaming propagation. Existing TTLs and negative caching affect what receivers see; a fixed waiting period cannot repair a misspelled hostname or a broken alias chain.

Once those records resolve correctly, ask Action Network to verify the installation. Do not skip that handoff just because a third-party lookup tool reports success.

Verify a message from the real campaign route

Send an authorized test through the same Action Network workflow and domain intended for campaigns, to an inbox whose original headers you can inspect. Record the campaign or test identifier, timestamp and receiving system. Avoid forwarding the test before inspection, since forwarding can change authentication behavior.

Check the receiving system's trusted Authentication-Results:

For completion of this branded DKIM setup, require a receiver-observed aligned DKIM pass as well as a DMARC pass for the intended From domain. The passing signature must be the intended Action Network signature with an issued selector, and its d= must align under the current adkim setting. A DMARC pass obtained only through SPF does not prove DKIM activation. A rewritten provider-domain From is not successful authentication of your intended brand. Investigate SPF fail, permerror or temperror even if DKIM supplies the DMARC pass: inspect the actual envelope owner and authorization, invalid policies or evaluated lookup limits, and temporary DNS failures respectively.

Use only results generated inside the actual receiving service's known processing boundary. Ask its administrator or consult its receiving-system documentation to identify the authentication component and how externally supplied Authentication-Results fields are removed or isolated from trusted results at ingress. Correlate the field with that service's original-message view or authenticated message trace. A familiar authserv-id, a topmost header, or text claiming to be from the receiver is not proof. Ignore externally supplied or otherwise untrusted fields; if the boundary cannot be established, leave acceptance unresolved and obtain the receiver's trace. Authentication-results trust and forged fields, RFC 8601 section 7.1

A receiver's authentication pass is distinct from inbox placement. Reputation, list quality and other receiver policies still matter. Test each materially different sender domain or group; one successful sample does not certify every campaign configuration.

If a change breaks an existing route, pause the rollout and have the named DNS owner restore the approved previous values from the saved zone, coordinating sender-side changes with Action Network. Do not delete shared selectors or weaken DMARC as a quick fix. For duplicate SPF policies, see the multiple SPF records diagnosis.

Troubleshooting Action Network authentication

• DNS looks correct but signing is missing: confirm that support completed verification and that the test came from the configured group and domain. Preserve the original headers for support.
• Reply-to is correct but DMARC fails: inspect From and header.d. Reply-to is not proof of alignment. Ask support which identity should be used by this sending route.
• A generic SendGrid instruction says to edit root SPF: reconcile it with your Action Network-issued set before changing anything. The delegated workflow may already handle the relevant SPF owner.
• Only some campaigns fail: compare groups, sender domains and templates. A new From domain may not share the approved configuration.
• CNAME exists but the key is unavailable: inspect the target chain, exact spelling and authoritative responses. Do not fabricate a replacement TXT key.
• Everything passes but mail is filtered: investigate recipient consent, complaints, content and sending patterns rather than repeatedly changing valid DNS.