For VoterVoice broadcasts, authenticate your organization's domain with the DKIM TXT record generated in the administrator settings, add include:_spf.votervoice.net to the appropriate existing SPF policy, and preserve your DMARC protection. Finish by checking a delivered broadcast for your intended From domain and a passing, aligned branded DKIM signature. A DNS record alone does not prove that signing is active.
On this page
- Identify the broadcast domain
- Generate and activate VoterVoice DKIM
- Add SPF without breaking other senders
- Preserve DMARC and enable useful reporting
- Check public DNS
- Accept the setup only after a delivered-message check
- Troubleshoot VoterVoice authentication
- Frequently asked questions
Identify the broadcast domain
This guide covers email broadcasts sent by VoterVoice to an organization's supporters. It does not establish authentication for employee mailboxes or for every other application used by the organization. Begin with the exact address selected on the broadcast Compose page. For updates@advocacy.example.com, the sending domain to investigate is advocacy.example.com, not automatically example.com.
An individual advocate’s message to a policymaker is a different sending identity and is not authenticated by this supporter-broadcast procedure. Keep that route out of this acceptance claim.
Have a VoterVoice administrator and the person managing authoritative DNS available. Make a small change worksheet containing the organization/account, intended From address, domain, DNS zone, current SPF policy, DKIM record names, DMARC policy and person approving the change. Keep a copy of the existing records so unrelated mail streams can be preserved.
Do not change incoming-mail MX records, transfer nameservers or remove your workplace email service to complete this task. A domain can support several applications, with separate DKIM selectors. Where two products request the same selector, resolve that conflict before replacing either record.
Generate and activate VoterVoice DKIM
Open Profile → Settings → Email Sender Authentication, select the domain, review the prefilled DKIM Selector, then choose Start Authentication. Publish a TXT record using the displayed DNS Record Name and DNS Record Content. Return to Validate that DNS is set up correctly. Successful validation leads to Pending while VoterVoice deploys signing; the documentation gives up to 24 hours for Verified. Follow this current self-service process rather than older instructions to generate and send a private key. VoterVoice's current authentication instructions
Treat the displayed fields as a matched pair. The selector identifies a particular public key; it is not the key itself. Do not substitute a key from another domain, organization or screenshot. Publish only the supplied public DNS content, never private-key material. DNS must ultimately answer at the name formed from the signature's selector and signing domain: selector._domainkey.signing-domain. DKIM DNS binding
For example, if the generated name were civic2026._domainkey.advocacy.example.com, the DNS fields would map as follows. This is a fictional name, not a VoterVoice default:
| DNS zone being edited | Relative host/name, if the panel appends that zone | Final public owner |
|---|---|---|
example.com |
civic2026._domainkey.advocacy |
civic2026._domainkey.advocacy.example.com |
advocacy.example.com |
civic2026._domainkey |
civic2026._domainkey.advocacy.example.com |
If the panel expects a full hostname, use the full generated name instead. Check its convention before saving; an automatically appended suffix can accidentally produce example.com.example.com. Preserve the exact content of the key. A DNS host may display one long TXT record as several quoted character strings. Those strings form one record; do not create several independent public-key records to fit the form.
At an existing delegated _domainkey.advocacy.example.com authority, the illustrative full owner civic2026._domainkey.advocacy.example.com maps to relative civic2026. Use the actual generated selector and preserve NS delegation and other selectors. Relative owners.
If the requested owner already has a CNAME or an unrelated public key, stop and coordinate a different selector or a planned replacement. Keep older selectors until the administrator has confirmed that no active sender or in-flight mail needs them. This avoids turning a new authentication setup into a key-rotation outage.
Add SPF without breaking other senders
VoterVoice's published mechanism is:
include:_spf.votervoice.net
The underscore is significant. Merge this mechanism into the domain's existing SPF TXT policy before its terminating all mechanism; do not create another SPF record. The vendor gives up to 24 hours for the change to take effect. VoterVoice SPF guidance
For a domain that genuinely already authorizes Google Workspace with the following policy, this is an illustrative merge, not a replacement for every organization's DNS:
Before: v=spf1 include:_spf.google.com -all
After: v=spf1 include:_spf.google.com include:_spf.votervoice.net -all
Keep other legitimate mechanisms and the existing final qualifier. A policy using redirect= needs separate review by the administrator who manages its delegated policy. Do not paste a second v=spf1 declaration or another final all into the middle of it. For duplicate-record cleanup, use the separate guide to merging SPF records safely.
If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.
SPF authenticates the SMTP MAIL FROM domain, usually visible in the delivered Return-Path, not the display name, Reply-To or visible From address. A policy at example.com does not automatically cover advocacy.example.com. At each actual envelope domain, there must be at most one SPF policy, and evaluation must stay within the limit of ten DNS-querying terms, including nested mechanisms. Count the evaluated chain, not just the visible includes. SPF identity, record and lookup rules
If the broadcast uses a VoterVoice-owned envelope domain, changing your root SPF does not change that identity or make it align with your visible From address. VoterVoice currently says CNAME/Return-Path modification is unsupported. Do not invent a custom bounce CNAME; use branded DKIM for alignment and verify the actual envelope domain in the delivered message. VoterVoice authentication capabilities
Preserve DMARC and enable useful reporting
DMARC compares the visible From domain with an authenticated SPF or DKIM domain. Either method can provide a DMARC pass if it both passes authentication and aligns. Relaxed alignment permits the same organizational domain; strict aspf=s or adkim=s requires an exact domain match for that method. For example, d=example.com with From advocacy.example.com can meet relaxed DKIM alignment but not strict alignment. Current DMARC specification
Inspect the current policy at _dmarc under the exact From domain and any applicable inherited policy. Preserve existing enforcement, reporting destinations and alignment settings. Do not replace p=quarantine or p=reject with p=none to remove a sender warning. Correct authentication instead.
RFC 9989 section 7.4 requires valid DKIM for domains publishing p=reject and cautions about indirect delivery and mailing lists. Review all legitimate routes before a separately approved enforcement decision; a single direct broadcast is not domain-wide readiness. Interoperability requirements.
Only where there is no applicable policy and the domain owner approves a monitored rollout, a starting TXT value can be:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Replace the sample report mailbox with an address you control and actually monitor. For a policy explicitly scoped to advocacy.example.com, the full owner is _dmarc.advocacy.example.com: enter _dmarc.advocacy in an auto-appending example.com zone, or _dmarc in a separately managed advocacy.example.com zone. Do not add a child p=none record that unintentionally weakens parent protection.
For an owner-approved first policy at the apex, full owner _dmarc.example.com maps to relative _dmarc in the example.com zone. First confirm no direct or applicable inherited policy exists and obtain approval of the monitoring and review plan; preserve all established policies.
Aggregate reports help separate passing but unaligned SPF from genuine SPF errors, and show which DKIM domains receivers validated. If reports go to another organization, arrange the recipient's required external-report authorization and approve that data destination. Reports are delayed and incomplete across receivers, so combine them with message headers rather than expecting one report for every broadcast. Aggregate-reporting standard and EmailAuth's report-reading guide
Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.
Check public DNS
These are read-only examples for your administrator. Replace every fictional name with the exact domain or selector from your setup; no commands below were run against a customer domain for this article.
dig +short NS example.com
dig +short TXT advocacy.example.com
dig +short TXT civic2026._domainkey.advocacy.example.com
dig +short TXT _dmarc.advocacy.example.com
dig +short TXT _dmarc.example.com
Check the authoritative zone and an independent resolver if results disagree. In a delegated subdomain, query that subdomain's authoritative servers rather than assuming the parent host manages its records. A blank answer is not automatically a propagation delay: check the owner name, record type, delegation and query status. SERVFAIL calls for DNS troubleshooting, including DNSSEC where relevant; waiting alone will not repair a broken zone.
The DKIM TXT result must match the generated public content. The SPF result must have one relevant v=spf1 policy at the owner being examined, with the new mechanism present and existing approved senders intact. Check the full lookup chain with an SPF evaluator. Repeat the SPF query for the actual smtp.mailfrom domain seen in a delivered broadcast; that identity may differ from the domain above. DMARC should resolve to the approved policy, not an accidental second record or policy reset.
Accept the setup only after a delivered-message check
After provider activation, send an authorized broadcast to an external test mailbox using the production From address and normal sending route. Inspect the raw original message, not a forwarded copy. In Gmail, Show original exposes the authentication summary and headers. Save the message identifier, send time, receiver and route so another administrator can repeat the check.
Use the receiving service's trusted Authentication-Results, not a header copied into the message by an untrusted sender. Record these fields: Authentication-Results trust guidance
Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.
| Observation | Acceptance criterion |
|---|---|
Visible From and header.from |
The intended organizational domain is present, not an unnoticed provider fallback. |
DKIM result, signature d= and s= |
The intended branded signature passes, uses the configured selector, and aligns under the actual adkim mode. A passing provider-only signature is insufficient. |
SPF result and smtp.mailfrom |
The real envelope identity is recorded. Distinguish spf=pass with no alignment from fail, softfail, neutral, none, temperror or permerror; investigate unexpected non-pass results. |
| DMARC result | dmarc=pass applies to the intended From domain, with at least one identified aligned pass. |
| Provider state | The selected domain has completed provider-side activation, rather than merely passing a DNS lookup. |
A DMARC pass through DKIM can coexist with unaligned SPF. It does not excuse an actual SPF configuration error on direct mail. Likewise, a DMARC pass through SPF does not prove that the newly configured branded DKIM key works. Require the intended signature before signing off this DKIM setup. Authentication also does not guarantee inbox placement, subscriber engagement or delivery to every destination.
Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.
Troubleshoot VoterVoice authentication
The From address changes to @votervoice.net. The current guide describes a temporary provider-domain fallback when more authentication is required. Compare the configured domain with the actual Compose address and complete the domain's activation rather than weakening DMARC. VoterVoice fallback behavior
Validation fails although the DNS panel says saved. Query the final public owner. Look for an extra domain suffix, the wrong DNS host, a copied selector without _domainkey, missing key characters or a conflicting CNAME. Compare the published content with the current generated value, not an earlier screenshot.
The domain stays Pending. Separate DNS publication from deployment on the sender. Once the documented activation window has passed, give support the domain, selector, validation time and public DNS results. Do not repeatedly regenerate keys while the sender may be deploying the previous one.
SPF passes but DMARC fails. Compare smtp.mailfrom with header.from, then inspect the branded DKIM signature. An authorized vendor envelope domain does not authenticate use of an unrelated visible From domain. Use the DKIM alignment walkthrough if the signing domain differs.
SPF returns permerror. Inspect duplicate SPF policies, malformed mechanisms and nested lookup limits. Do not replace maintained includes with a one-time list of IPs or remove legitimate senders merely to make a checker green.
A forwarded copy fails when direct delivery passes. Capture both paths. Forwarding can change the connecting server used for SPF; message modifications can break DKIM. Diagnose the affected hop rather than changing correct original-sender DNS based on the forwarded message alone.
If recovery is necessary, have the broadcast owner approve pausing the affected stream or restoring its prior supported sender configuration. Restore only the approved DNS differences, preserve other senders and retain keys needed by queued messages. Repeat the same controlled broadcast after repair; never weaken the domain-wide policy to conceal the fault.