Vanilla SPF, DKIM and DMARC setup, step by step

For hosted Higher Logic Vanilla community email, confirm the public sender in Dashboard > Settings > Communications > Email Settings, then ask Vanilla Support to arrange sender authentication with Vanilla Ops. Publish the site-specific DNS records they supply and obtain their final activation confirmation. For SPF, use only the Support-confirmed mechanism, include:vanilla.email or include:sendgrid.net, at the confirmed envelope domain. Finish by checking an actual notification for branded, aligned DKIM and dmarc=pass. Vanilla Email Deliverability, Vanilla SPF setup.

Confirm the community and its public sender

This procedure covers the hosted Vanilla community service and its notification mail. It does not configure an open-source self-hosted Vanilla installation, Higher Logic Informz/Thrive Marketing Professional, or Real Magnet/Thrive Marketing Enterprise. Shared ownership does not make their authentication records interchangeable.

Before launch or a sender change, review Outgoing Emails on the Email Settings page. Check both From Name and From Email Address. Vanilla says the default address comes from the community account and can appear on user messages, including subscribed notifications. Replace an unintended personal administrator address with an approved community identity before members see it. Decide whether replies should reach a monitored mailbox. Outgoing sender settings.

Do not confuse the community website hostname with its email identities. A site at community.example.com can use a different approved From domain. Document the intended From, the actual SMTP MAIL FROM/Return-Path domain and the requested DKIM signing domain separately. A display name or Reply-To address does not determine DMARC alignment.

Prepare the support handoff and DNS access

Arrange a community administrator, DNS administrator and domain-policy owner. Identify the production community, affected sender addresses and materially different notification workflows. Save the existing sender settings, DNS records and DMARC policy before changes. Choose a quiet window, a rollback owner and a controlled recipient who has subscribed to the notification being tested.

Send Vanilla Support the minimum information needed through your organization's approved support channel:

• The community identifier and intended public From address/name.
• The domain or subdomain you own and its authoritative DNS provider.
• Whether that same DNS name already serves the website as a CNAME.
• The requested sender-authentication setup and any existing DKIM selector conflict.
• A request to confirm the envelope domain, active sending service, applicable SPF mechanism, complete record set and final activation step.

No private DKIM key, mailbox password or unrestricted DNS account access belongs in this handoff. Public records can be supplied as a type/owner/value worksheet. Support's involvement is part of the documented procedure, not evidence that a configuration has already been activated.

Obtain, publish and activate the site-specific records

1. Review and set the approved outgoing sender in Settings > Communications > Email Settings.
2. Contact Vanilla Support and ask them to confirm the outgoing settings and coordinate sender authentication with Vanilla Ops.
3. Obtain the exact DNS records for this community and domain. Retain each type, complete owner name and value, plus its purpose and the support reference.
4. Have the DNS administrator publish those records in the authoritative zone without changing unrelated mail or website records.
5. Ask Support to confirm that the published records are correct.
6. Obtain Support/Ops confirmation that sender authentication is active, then perform the received-notification acceptance check below.

Vanilla identifies SendGrid as its community-mail delivery service, but the supported customer workflow runs through Vanilla Support. Do not create your own SendGrid account, copy another customer's SendGrid values or assume you can operate Vanilla's backend. The public Vanilla procedure does not publish a universal selector, key, record count or tenant target. Use the current set supplied for your site. Official sender-authentication procedure.

If the handoff contains DKIM CNAMEs, publish their exact hostname targets. If it specifies a DKIM TXT record, publish the supplied public key without line-break corruption or added labels. Never publish private signing material. Ask Support to resolve an ambiguous type, missing value or occupied selector before proceeding. The standard DKIM lookup combines the actual selector and signing domain as SELECTOR._domainkey.SIGNING_DOMAIN. DKIM specification.

Configure SPF for the actual envelope domain

Vanilla's current SPF instructions explicitly require Support to confirm the return-path domain and sending service. Choose the mechanism they approve:

Do not add both by default. If Support supplies a site-specific sender-authentication CNAME set instead, follow that set and clarify how SPF is managed at the envelope owner. Do not add an SPF TXT record beside a CNAME at the same name. Vanilla's own instructions say site-specific records take priority. Current SPF procedure.

At an owner where an SPF TXT edit is required, modify the single existing v=spf1 record. Preserve all other legitimate senders and the existing terminal policy qualifier. Insert the approved mechanism before all; do not paste a second complete policy into the same value or create a second SPF TXT record. Multiple unrelated TXT records are permitted, but multiple SPF policies at one owner cause an error.

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.

Check the complete evaluated policy, including nested includes. SPF's maximum is ten DNS-querying terms using include, a, mx, ptr, exists or redirect, not ten top-level services. Additional MX and void-lookup limits apply. ip4, ip6 and all do not use that term budget. Resolve excess authorization with the domain owner; do not substitute a static snapshot of provider IPs for its maintained include. RFC 7208, SPF lookup-limit walkthrough.

SPF authenticates the SMTP envelope domain, not the visible From by itself. A root SPF edit has no effect on a different provider-owned envelope policy, and a subdomain does not inherit its parent's SPF record. If SPF passes but its identity is unrelated to From, aligned DKIM remains the intended route to DMARC success unless Support supplies a supported aligned envelope configuration.

Avoid website conflicts and misplaced DNS records

Vanilla warns against adding SPF at the same custom hostname already occupied by the community website's CNAME. This is a same-owner DNS conflict, not a blanket ban on custom-domain email. Preserve the working website record and have Support identify compatible mail owners. Moving the website or changing inbound MX is not an authentication shortcut. Vanilla's conflict warning, DNS alias rules.

For an illustrative Support-issued DKIM owner SELECTOR._domainkey.notify.example.com, use this mapping:

These are placeholders, not Vanilla selectors. For a supplied envelope owner BOUNCE.notify.example.com, the relative name is BOUNCE.notify in the parent zone or BOUNCE in the delegated child. An SPF TXT at notify.example.com itself is notify in the parent zone or the child zone's apex marker, often @. Confirm the DNS host's convention and query the full public name afterward.

At an existing delegated _domainkey.notify.example.com authority, the illustrative SELECTOR._domainkey.notify.example.com maps to relative SELECTOR. Substitute only the actual issued selector, record type and value, and preserve NS delegation and all other active selectors. Relative DNS owners.

Authentication CNAMEs must remain visible as DNS aliases. Use DNS-only records rather than HTTP proxying, and avoid flattening that hides the CNAME answer required by verification. Preserve the destination hostname, including its provider-required spelling; do not add a URL scheme. If a name is already in use, coordinate a supported alternative rather than deleting another sender's key.

If Cloudflare hosts the relevant authentication records, check DNS only, the record-level Flatten option is off, and the zone-wide CNAME flattening for all CNAME records setting is off. A DNS-only record can still be flattened. Coordinate any zone-wide change with owners of other affected services rather than changing a shared setting blindly. If NS records delegate the sending subdomain or _domainkey to another DNS service, publish the record at that authoritative service and preserve the delegation; do not remove NS records just to make a parent-zone entry visible. Cloudflare CNAME verification troubleshooting.

Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.

Keep the domain's DMARC policy intact

Under current RFC 9989, DMARC passes when either SPF or DKIM passes and its authenticated domain aligns with the visible From domain. Relaxed mode permits an organizational-domain match. Strict adkim=s or aspf=s requires exact equality for that mechanism.

For an illustrative From domain notify.example.com, DKIM d=notify.example.com satisfies either mode, while d=example.com satisfies only relaxed alignment. A signature for an unrelated provider domain does not align. A passing SPF result likewise needs its envelope domain compared with From. See strict and relaxed alignment if subdomain policy needs a separate review.

Inspect _dmarc at the actual From domain and determine the effective policy, including parent-domain discovery where applicable. Keep established enforcement, report recipients and alignment settings. Do not overwrite a working policy with a setup example or publish duplicate DMARC records.

Only if no policy applies and the domain owner approves a monitoring rollout, a starter TXT value can be v=DMARC1; p=none; rua=mailto:APPROVED_REPORT_ADDRESS at _dmarc.FROM_DOMAIN. Replace placeholders with an approved destination and confirm report handling. External reporting destinations require the appropriate DNS authorization from the report recipient. Reports contain operational information; choose an authorized recipient and do not add failure-reporting addresses casually. Aggregate-report requirements.

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. For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names. Confirm there is no direct or applicable inherited policy and obtain domain-owner approval of the monitoring and review plan before using the example.

p=none is not a delivery guarantee. RFC 9989 replaces RFC 7489 and removes pct; do not rely on percentage enforcement for a new rollout. Its section 7.4 requires valid DKIM for p=reject domains and cautions about forwarded and other indirect mail. Community authentication acceptance and domain-wide enforcement readiness are separate decisions.

Check public DNS and get final activation confirmation

Use exact Support-issued values in these read-only commands. Uppercase items are placeholders, and no customer-domain queries were run for this guide:

dig +short NS AUTHORITATIVE_ZONE
dig @AUTHORITATIVE_NAMESERVER DKIM_OWNER_FQDN CNAME +noall +answer
dig DKIM_OWNER_FQDN CNAME +noall +answer
dig DKIM_TARGET_FQDN TXT +noall +answer
dig ENVELOPE_DOMAIN TXT +noall +answer
dig _dmarc.FROM_DOMAIN TXT +noall +answer

For a TXT-based DKIM instruction, query DKIM_OWNER_FQDN TXT instead of expecting a CNAME. For aliases, follow the chain to the public key. Repeat for every record Support supplied. Confirm that the authoritative response and recursive response converge after caching expires. An editor's save banner is not public DNS evidence; NXDOMAIN, empty answers and SERVFAIL require diagnosis.

Ask Support to confirm both the record match and completed sender-authentication activation. Keep that confirmation separate from your DNS timestamps. If provider verification and public answers disagree, send the issued owner/target, observed answers and query times through the approved support channel. Avoid repeated record regeneration while a change is still propagating.

Verify an actual subscribed community notification

After authorized activation, trigger a harmless notification for a controlled account that has subscribed to that notification type. Check the real workflow, not only a template preview. Vanilla's template documentation provides preview and test-email features, but custom templates also depend on Automation Rules for live sending. A design preview does not prove routing, subscriptions or authentication. Template and automation boundaries.

Open the received message's raw source. Use Authentication-Results generated by the receiving mailbox service within its trusted boundary. Confirm the authentication-service identity and delivery trace using that receiver's documentation; do not trust every identically named header or infer trust from position alone. RFC 8601.

Establish provenance through receiver-controlled evidence: the mailbox service's documented handling of authentication results, its trusted administrative logs, or confirmation from its mail administrator. A familiar authserv-id, a copied Received line or header position alone can be forged and is insufficient. Ignore results supplied from outside that established trust boundary unless the receiving administrator has explicitly configured a trusted relationship for them. If provenance is unclear, obtain the receiver's own verdict before accepting the test. RFC 8601 section 7.1.

Retain a compact acceptance record with the community, workflow, intended and received From, envelope identity and SPF result, every DKIM d=/s= pair and result, applicable alignment mode, DMARC result, receiver and timestamp. Store message evidence securely and share only the minimum necessary with Support.

Accept the branded community setup only when the actual From is correct, a branded DKIM signature passes and aligns, the trusted receiver reports dmarc=pass, public records match and Support confirms activation. Explain or repair an unexpected SPF error even if DKIM supplies the DMARC pass. This acceptance rule checks the intended DKIM setup; DMARC itself still needs only one aligned passing mechanism.

Match the intended active Vanilla-issued signature’s d= and s= with the Support-issued configuration. Require that signature itself to pass and align under effective adkim with the unchanged intended visible From, plus the trusted receiver’s dmarc=pass. A different aligned signature, SPF-only pass or rewritten provider From does not complete this branded setup. DKIM identifiers, alignment.

Confirm reply behavior and recipient expectations separately. Repeat for materially different community domains and notification paths. The disappearance of a “via” label, successful website loading or one inbox delivery is insufficient proof.

Diagnose failures and recover safely

Do not authorize both SPF includes, publish +all or weaken the organization's DMARC policy to conceal a defect. If the new sender is not ready, coordinate restoration of the approved previous sender configuration or pause the affected notification workflow where operationally safe. Do not disable critical community messages without the business owner's decision.

Keep old keys while queued signed messages may still require them, and let Support confirm when a retired route can be removed. Restore only the approved DNS changes, not an entire old zone that would erase unrelated updates. Re-run the same notification acceptance after any repair.