For Higher Logic Vanilla, treat sender authentication as a coordinated community, support and DNS change. This is not a guide for an independently installed open-source forum or a different Higher Logic email product. First identify the community and its approved public sender identity; a notification address should not expose an administrator's private address accidentally.
Coordinate the supported setup
Review Dashboard > Settings > Communications > Email Settings and the outgoing sender name and address. Ask Vanilla Support to confirm those settings and supply the DNS records through its operations team. Your DNS owner implements the supplied records, then Support confirms activation. The public guide identifies SendGrid as the sending service. It also says Support should confirm the return-path domain and whether include:vanilla.email or include:sendgrid.net applies. Do not authorize both by assumption. Vanilla sender-authentication reference
Keep a copy of the support-provided owner names, types and values with the approved change. Do not reuse another community's selectors. Where a proposed owner name already has a CNAME, resolve the name conflict before attempting to add TXT data there. Choosing a separate mail identity can be safer than changing records used by the community website.
Test community-specific consequences
Exercise a notification that members have actually subscribed to, using a controlled test account and recipient. Confirm the visible sender, reply behavior and authentication separately. Successful website loading does not test email, and a template preview does not prove the notification's real sending path. Avoid sending a broad announcement merely to obtain one header sample. If one notification class differs, investigate its route rather than treating a single passing sample as proof of every community message.
The public guide’s warning about a custom-domain CNAME concerns the same DNS owner name: it is not a prohibition on every custom From domain. Preserve the website record and have Support identify the appropriate mail names. Record who confirmed activation and when, not just when DNS was saved.
Verify DNS and a real receiving result
Before changing community notification sender settings, 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 subscribed community notification sent through the live community workflow 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: VA-01 assumes community.example is a website CNAME and an operator proposes putting an SPF TXT at that same owner name. The intended notification From is community@example.org, but envelope and DKIM identities/results remain unknown. The community owner must obtain the exact mail owner names from Support and resolve the website-name collision without changing unrelated website routing. A template preview cannot close activation or alignment. 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.