Source review dated 8 November 2026. This is documentary guidance; account, DNS and received-message acceptance tests below have not been executed.
Confirm the AdvocateHub sending identity
Influitive’s AdvocateHub can send using a selected company identity or its provider-domain fallback. Decide which identity the program should present before changing DNS. Record the Hub, company sending domain, responsible program owner and authoritative DNS administrator. A branded website domain is not evidence that the same domain is configured for mail. Use a dedicated test recipient and a harmless invitation rather than adding real advocates merely to exercise setup.
In Settings > Email > General, AdvocateHub requires the selected sender address to belong to an Administrator, including a group address used as the sender. Choose the default Email Sender and save it with Update email sender. The provider-domain fallback is available through the “Encountering deliverability problems?” option. AdvocateHub email configuration
Treat the administrator requirement as an access decision as well as a branding choice. Identify who receives mail sent to the address and who controls the associated account. Do not create a widely shared administrative identity solely to make a friendly From address appear. Ask the program owner to choose an appropriate existing identity or approve the required access setup through the organization’s normal process.
Use the current signing record and activate it
Influitive’s authentication guide specifies include:email.influitive.com for SPF and documents an IP alternative. It identifies hub2048 as the selector for new 2048-bit DKIM setups, replacing the older scph0416 configuration for new verifications. Publish the current full TXT key from the provider’s guide, then contact Influitive Support: the documented process requires a backend setting to be enabled. DNS publication alone does not complete activation. Influitive SPF and DKIM setup
Before publication, expand the intended selector owner to its full domain name and compare it with existing records. Remove incidental display spacing from owner names, but do not edit the cryptographic key or copy a shortened excerpt. Preserve unrelated selectors and avoid deleting the old selector until the active signer and any queued messages have been considered. Record the source, retrieval date and approved change in the operational ticket.
Merge the approved SPF mechanism into the single policy at the relevant owner. Count nested DNS lookups against the protocol limit. Do not adopt a fixed IP merely because it produces a shorter record: confirm that the provider still supports it for the route and assign someone to maintain it. A DNS policy that becomes stale can fail without any visible change to the Hub settings.
Test the configured invitation route
After support confirms activation, ensure the intended company sender is selected and the provider-domain fallback is not selected for the branded test. Use the Hub’s invitation workflow to send to the controlled account, then inspect both the member’s email status and the received message. The setup guide describes the Invite List test and the profile’s Email tab. A Delivered status is useful operational evidence, but it is not a complete DMARC result.
Original acceptance worksheet: record the Hub identity, selected sender, timestamp, recipient, visible From domain, SMTP envelope domain, every DKIM d= and s= pair and the receiving service’s trusted authentication results. Check whether at least one passing SPF or DKIM identity aligns with the visible From domain under its actual DMARC settings. Do not assume that adding a root SPF include creates a custom Return-Path; this guide does not establish that capability.
Illustrative failure: the new public key is visible, but the invitation still uses the provider-domain sender. Check the fallback setting, selected administrator and support activation before changing DMARC. A second failure pattern is an invitation sent with the company From address but no corresponding aligned signature. That warrants checking the active signing selector with support, not indiscriminately deleting every key.
Preserve program access during recovery
If the company identity is not ready, coordinate with the program owner before using the documented provider-domain fallback. Retest the resulting identity and communicate any visible sender change to the people responsible for the program. Do not lower domain-wide enforcement to rescue a single Hub. Keep authentication separate from permission to send marketing invitations and from footer or consent requirements; working DNS does not establish either.
Documentation was reviewed on 8 November 2026. No Influitive account, DNS change, support activation or received invitation was tested. The worksheet and failure scenarios are proposed operational checks.