VoterVoice sender authentication controls whether supporter broadcasts can use your organization's domain. Begin with the address selected on the Compose Page and the domain owner who can publish DNS. Do not confuse an individual advocate's message to a policymaker with the organization's broadcast sending identity.
Complete the domain-authentication lifecycle
Open Profile > Settings > Email Sender Authentication. Select the domain, review the supplied DKIM selector and choose Start Authentication. Copy DNS Record Name and DNS Record Content into a TXT record at your DNS provider. After publication, run Validate that DNS is set up correctly. The documented lifecycle moves to Pending while VoterVoice deploys the record, then Verified, normally within 24 hours. Pending is not completed activation. VoterVoice authentication reference
The current reference says CNAME/return-path modification is not supported as a sender-authentication method. Use the supplied TXT workflow rather than translating another provider's setup. It also documents include:_spf.votervoice.net for applicable SPF authorization; preserve the underscore and merge it before the existing all mechanism. Whether SPF contributes to DMARC still depends on the envelope identity observed on the message.
Check the broadcast identity after activation
Until authentication is complete, broadcasts can temporarily use an @votervoice.net identity. After Verified, test the intended organization address and inspect the actual From and signature. Delivery during fallback is not proof of your custom domain's authentication. Keep a small controlled recipient group for this check, with content suitable for those recipients, rather than testing against the full supporter list.
The current guide permits changing the prefilled selector before starting authentication. Choose an unoccupied approved name and preserve the generated name and value together. A missing Compose Page warning is not independent evidence of alignment; keep explicit verification even when a restrictive policy has not triggered the warning.
Verify DNS and a real receiving result
Before changing VoterVoice supporter broadcasts, export the existing DNS values, record the approved diff and name the rollback owner. Confirm whether the DNS editor expects a relative label or a fully qualified name; doubling the domain suffix creates a record that no intended verifier will find. Query the actual owner name after saving, including any CNAME target, rather than relying on the editor's success banner.
SPF must remain one policy at the relevant domain and stay within the DNS-querying-term limits in RFC 7208. Adding an include does not itself establish alignment. Under RFC 9989, DMARC passes when at least one successful SPF or DKIM result aligns with the visible From domain under the applicable mode. Do not require both mechanisms to align as a condition imposed by the standard, and do not mistake a provider-domain pass for an aligned customer-domain pass.
Send a small authorized broadcast using the newly verified sender domain to a mailbox you control. Save the receiving system's trusted authentication results, visible From, envelope identity, DKIM d= and s= values, timestamp and provider status. A DNS lookup only shows the available key; RFC 6376 verification also evaluates the signature over the received message. Use non-sensitive content and avoid exposing full customer messages to public checkers.
Use a bounded acceptance and rollback decision
Fictional written diagnostic case only: VV-01 assumes intended From news@members.example, but a broadcast during Pending appears from notice@votervoice.net. All SPF and DKIM identities/results are unknown. Delivery does not satisfy the intended brand identity. The broadcast owner must wait for Verified, then collect a controlled sample from the exact Compose Page address and inspect alignment. No actual broadcast or repair is asserted. No account, DNS, relay or message was tested for this example.
If the test fails, separate missing DNS, wrong selector, inactive provider configuration, unexpected routing and message modification before making another change. Retest the same workflow after each approved correction. Do not weaken the whole domain's DMARC policy to hide a single sender problem. Where rollback is needed, restore the approved prior routing or sender configuration and retain key records while queued signed messages still need them. Keep the test evidence and unresolved exceptions with the domain inventory. No tenant access, DNS change or real sending was performed in preparing this guide.
Keep an accountable acceptance record
Create one row per account, domain and materially different route. Record the business owner, DNS owner, change reference, intended From, observed From, envelope domain and SPF result, each DKIM d= and s= with its result, applicable alignment mode, trusted receiver and timestamp, provider activation state, placement observation, unresolved question and next action. Mark missing values unknown rather than treating them as pass or fail. The owner accepts only the intended route and identity supported by the recorded evidence; otherwise hold that route and follow the approved recovery plan.
Separate a passing message from enforcement readiness
RFC 9989 Section 7.4 requires valid DKIM for a domain publishing p=reject and cautions about indirect-mail interoperability. A single aligned SPF result does not by itself justify a reject-policy rollout. Review all legitimate routes and policy ownership separately from this provider setup.