ClubHouse Online SPF, DKIM and DMARC setup, step by step

ClubHouse Online does not have one interchangeable SPF/DKIM recipe. Its current authentication directory separates E3 Website, Campaigner Email Marketing, Frankie Email Marketing and MemberInsight. Identify the service that sends the message, use that route's records and have the responsible team confirm signing is active. Then verify the intended branded DKIM signature and DMARC result on a controlled delivered message. ClubHouse Online authentication directory.

This is a documentary guide, not a report of configuration or delivery tests in a club account.

Quick route selector

These are route-specific mechanisms and selector references, not complete SPF records to paste. The table follows the separate official Website, Campaigner, Frankie and MemberInsight instructions. Confirm the current account route and sending domain before using a row. Do not publish all four includes simply because your club uses Jonas software.

1. Confirm the exact platform and message source

Ask the application owner to identify the platform from which the message is sent, the visible From domain and the affected message type. A newsletter, website notice and survey with identical branding can have different authentication paths. Keep an inventory row for each active platform and domain.

Do not confuse ClubHouse Online with the unrelated Clubhouse social-audio application. Also separate a client-managed SMTP server from the hosted routes above. Jonas documents, for example, a tee-time confirmation workflow with J-Mail Parameters and the club's own SMTP configuration, and explicitly says it does not host that client mail server. That path must use the actual SMTP provider's authentication instructions, not automatically the Website or Campaigner include. Tee-time confirmation and SMTP boundary.

For each in-scope hosted route, record:

• Platform, club account and relevant sending address or domain.
• A redacted baseline delivered original, if available, including From, Return-Path and all DKIM signing domains/selectors.
• The administrator who manages application settings, the authoritative DNS service and the ClubHouse Online representative responsible for the setup.
• Current SPF, DKIM and DMARC records, with a rollback copy and an inventory of other authorized senders.
• Controlled recipients and an approved harmless test action for that route.

Confirm any account, edition or migration-specific restrictions with the representative. The public pages are separated by product, but do not establish a universal plan entitlement or self-service activation procedure. If your account instructions differ from the reference values below, resolve the discrepancy with the provider before editing records.

2. Publish SPF for the confirmed route

SPF authorizes an IP address for the SMTP envelope sender domain, normally recorded as smtp.mailfrom in receiver results. It does not authenticate the visible From address by itself. A provider-managed envelope domain can pass SPF without aligning with your club's From domain. The public setup pages do not establish a universal custom return-path feature, so do not create one by inventing a bounce hostname. RFC 7208 SPF identities.

Use the applicable mechanism from the route selector, with the owner confirmed for the club's setup. If the intended owner already has an SPF TXT policy, merge the mechanism into that single existing policy. Preserve the club's mailbox service and every other still-authorized sender. Do not create a second record starting v=spf1, concatenate two complete policies or add mechanisms after a terminal all.

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.

The official route pages show sample policies containing mx, a and -all, and warn that they are examples. Do not add mx or a merely to imitate the example; those mechanisms authorize additional hosts and consume lookup budget. Preserve the existing terminal policy decision rather than changing ~all to -all as an incidental step. Official Website SPF example and warning.

SPF permits at most ten evaluated DNS-dependent terms, including nested include and redirect evaluation. The budget also covers evaluated a, mx, ptr and exists terms. It is not a count of TXT records, literal includes or raw packets. ip4, ip6 and all do not consume that term budget. MX/PTR address processing and void responses have additional limits. Validate the complete policy across relevant sending paths, not just a message whose IP happens to match early. RFC 7208 section 4.6.4; SPF lookup-limit walkthrough.

Do not replace provider includes with a manually copied list of current IPs. Infrastructure can change. Confirm obsolete authorizations before removing them, and review a maintained redesign if the policy exceeds limits.

3. Configure DKIM for only the applicable platform

The owner names below are relative to the confirmed signing-domain zone. For a root domain example.com, em._domainkey becomes em._domainkey.example.com. If the authorized signing domain is a subdomain, obtain confirmation of that domain and use its actual zone placement rather than assuming the root-domain layout applies.

E3 Website: request the domain-specific records

The Website page says a ClubHouse Online representative supplies records tailored to the club's domain. Obtain the exact record type, owner and value, together with the intended signing domain and activation steps. The public page does not publish one universal Website DKIM selector or key. Do not use Campaigner's em record as a substitute. Website DKIM instructions.

Campaigner Email Marketing

For a confirmed Campaigner account, the official guide documents:

Use the domain approved for the club. A DNS editor that expects a fully qualified target may display a trailing dot; the target must not acquire the club's own domain as an accidental suffix. Campaigner EMM configuration.

Frankie Email Marketing

Frankie documents all three CNAMEs below. Publish the full set for the confirmed domain rather than choosing only the selector you happened to see on one message:

These are Frankie instructions, not a reason to replace a working Campaigner setup during an unconfirmed migration. Frankie authentication guide.

MemberInsight survey module

For the confirmed MemberInsight route, the official page documents:

Use this for the authorized survey-sending domain, not every domain associated with the club. MemberInsight authentication guide.

Avoid DNS conflicts before saving

A CNAME owner cannot coexist with ordinary TXT, A or other record data at the same name. An existing em, trp or e2ma-k1 selector may belong to another authorized use, so do not delete it blindly. Resolve ownership and, if necessary, a provider-supported alternative before proceeding. CNAME targets are hostnames, not URLs or IP addresses. RFC 2181 CNAME rules.

Check whether your DNS editor appends the zone suffix. Entering a full owner in a relative-only field can produce example.com.example.com.

For an illustrative issued owner issued-selector._domainkey.billing.example.com, a suffix-appending editor in the parent example.com zone needs issued-selector._domainkey.billing; an editor in the separately delegated billing.example.com zone needs issued-selector._domainkey. If the editor expects a fully qualified owner instead, use the complete issued name. The selector is a placeholder: keep the actual provider-issued selector and signing domain unchanged. For CNAME-based authentication, if your DNS host offers HTTP proxying or CNAME flattening, use ordinary DNS-only handling for these records and preserve the required public CNAME answer. Do not change unrelated website proxy settings. For any Website record supplied as TXT, preserve the exact public value and avoid accidental extra quotes or line breaks.

Apply these controls only to the platform’s required CNAMEs, not to a representative-issued TXT key. 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.

4. Confirm provider-side activation

The official pages describe the ClubHouse Online team implementing authentication after the relevant records are in place. They do not establish one universal activation button or automatic completion trigger. Once public DNS is correct, give the responsible representative the platform, domain and public record names and ask for confirmation that the intended signer is active for that route.

Keep three checkpoints separate: DNS published, provider setup complete, and delivered message accepted. A support confirmation or a green DNS checker alone does not prove that the next website notice, campaign or survey carries the intended signature. Do not start a broad member campaign until the controlled test succeeds.

5. Retain the effective DMARC policy

DMARC passes when either a passing SPF identifier aligns with the visible From domain, or a passing DKIM signing domain aligns with it. Strict alignment requires an exact domain match. Relaxed alignment requires a shared Organizational Domain under the applicable discovery rules, not merely a familiar brand or Reply-To address. RFC 9989 alignment.

For commissioning these branded sending routes, require the intended branded DKIM signature to pass and align, plus dmarc=pass. SPF alone can produce a DMARC pass while your new DKIM setup is not working. That is not sufficient acceptance for a DKIM deployment. RFC 9989 also requires valid DKIM for domains publishing p=reject, rather than relying solely on SPF through indirect delivery. RFC 9989 section 7.4.

Preserve the current DMARC policy and reporting settings unless the domain owner separately approves a change. Check both direct and inherited policy. If no policy exists and a monitored introduction is approved, this illustrates a single monitoring record, not a ClubHouse Online-issued value:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the example names with an approved domain and a working reporting mailbox. For example.com, enter relative host _dmarc in its zone, not @. For From news@members.example.com, the direct owner is _dmarc.members.example.com: use _dmarc.members in the parent example.com zone or _dmarc in a separately delegated members.example.com zone. Do not unintentionally override an inherited enforcing policy with a new child monitoring record.

For an external report destination, confirm authorization on the report receiver's DNS. For policy domain example.com and mailbox reports@reports.example.net, the queried owner is example.com._report._dmarc.reports.example.net; the receiver publishes an authorizing TXT response containing v=DMARC1 or an applicable wildcard. Get the exact record from the reporting service. RFC 9990 external reporting.

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.

Monitor all of the club's legitimate senders before considering stronger enforcement. A single successful campaign cannot clear website notices, surveys, office mail and client-managed SMTP. Aggregate-report access and destinations also need approval because reports reveal sending infrastructure and authentication data.

6. Run DNS acceptance checks

These read-only commands are for the reader to run. Replace all example names with the actual values; they are not a record of checks performed for this guide. ENVELOPE_DOMAIN comes from the real SPF identity, SIGNING_DOMAIN from the approved signer, and AUTH_NS must be authoritative for the record being checked.

ENVELOPE_DOMAIN='actual-envelope.example'
SIGNING_DOMAIN='approved-signing.example'
SELECTOR='actual-issued-selector'
DMARC_OWNER='_dmarc.visible-from.example'
AUTH_NS='authoritative-nameserver.example'

dig +short TXT "$ENVELOPE_DOMAIN"
dig +short CNAME "$SELECTOR._domainkey.$SIGNING_DOMAIN"
dig +short TXT "$SELECTOR._domainkey.$SIGNING_DOMAIN"
dig +short TXT "$DMARC_OWNER"
dig @"$AUTH_NS" CNAME "$SELECTOR._domainkey.$SIGNING_DOMAIN" +noall +answer

For a representative-issued TXT record, query authoritative TXT instead of expecting a CNAME. For every CNAME, compare the target with the exact route instruction and query the returned target for TXT to verify a usable public-key path. Repeat the selector checks for all three Frankie records when applicable. Do not guess missing selectors.

Check all relevant authoritative servers, then compare with an independent recursive resolver after the previous positive or negative TTL has expired. Accept one valid SPF policy at the evaluated owner, the expected DKIM records and effective DMARC policy. Investigate missing owners, doubled suffixes, CNAME conflicts, SERVFAIL and inconsistent authorities before describing the setup as propagated. A DNS key proves publication, not signing or message integrity.

7. Test each actual message route

Use controlled addresses and an authorized harmless action. A campaign test cannot stand in for a website notification or MemberInsight survey. Do not enroll real members in a survey, send an unsolicited campaign or create an actual tee-time booking simply to obtain headers. If a representative must arrange a non-production test, settle that first.

Save the received original directly from the controlled mailbox. Use its own trusted Authentication-Results or authenticated details view, not sender-supplied assertions, forwarded copies or headers pasted into the body. RFC 8601.

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.

A provider-domain SPF pass can be normal but unaligned. Label it correctly. A genuine fail, softfail, neutral, none, temperror or permerror requires investigation, even when aligned DKIM makes DMARC pass. Document the cause and resolve configuration errors rather than treating all non-aligned outcomes as equivalent.

For example, a hypothetical Campaigner message might pass SPF for a provider domain but fail its branded em DKIM signature. If another aligned method produces DMARC pass, the new Campaigner DKIM deployment still fails commissioning. The required next step is to investigate that actual signature and its DNS path, not to declare success from the overall DMARC result. This example is illustrative, not an observed ClubHouse Online message.

Troubleshooting and safe recovery

If a club-critical route breaks, pause the affected campaign or workflow and coordinate an approved fallback with its owner. Restore only the specific prior change after checking for intervening edits. Keep the previous route's DKIM records while it is still sending and while legitimate queued mail may need them; retire records with the provider after migration is complete. Avoid removing all Jonas-related authorizations together.

Retest after a platform migration, From-domain change, key update, DNS migration or SMTP change. Keep the platform map, provider instructions, before/after DNS, activation evidence and redacted accepted originals together. Authentication improves verifiable identity; it does not guarantee inbox placement or eliminate every form of impersonation.