For ChamberMaster/MemberZone database email using the premier authentication option, add include:spf.memberzone.com to the domain's single SPF policy, publish both DKIM CNAMEs, and ask ChamberMaster Support to finalize premier setup after DNS is available. The current CNAMEs are cm._domainkey → dkim1.chambermaster.com and cm2._domainkey → dkim2.chambermaster.com. DNS publication alone does not complete activation. Current ChamberMaster/MemberZone setup instructions.
The provider's current procedure also requires SPF to end in -all. Review that requirement against existing senders and any SPF redirect before changing policy. Keep an existing DMARC policy rather than replacing it with the provider's monitoring example.
This guide covers the ChamberMaster/MemberZone native database and its documented premier-level setup for a domain you control. It does not cover the separate GrowthZone database, ordinary staff-mailbox configuration, another marketing platform or an assumed branded signing capability under the default economy option.
Confirm the product and domain you can authenticate
ChamberMaster/MemberZone and GrowthZone have separate DNS procedures. The current ChamberMaster article explicitly excludes GrowthZone; the GrowthZone article explicitly excludes ChamberMaster/MemberZone. Do not copy GrowthZone's gz selectors, tracking records or return-path names into a ChamberMaster setup. Separate GrowthZone procedure.
Before starting, confirm:
- The message is generated through the ChamberMaster/MemberZone database, not merely sent by a staff member who also uses the software.
- The intended visible From address uses a domain your organization controls.
- You have an authorized DNS administrator and a person who can coordinate the premier configuration with ChamberMaster Support.
- You can inspect a new delivery at a controlled external mailbox after activation.
- All existing domain senders and their current authentication records have been inventoried.
Customers cannot publish authentication records for public mailbox domains such as gmail.com or yahoo.com. Owning an address there does not provide control of that provider's DNS. Choose an approved organizational domain for this workflow. Provider explanation of domain control.
The public procedure does not specify a price, named administrator role or self-service premier toggle. Confirm any account-specific eligibility or commercial terms with Support rather than assuming “premier” maps to a particular subscription package.
Use the current DKIM instructions, not the old FAQ
It documents both economy-level DKIM and a premier option requiring DNS configuration followed by Support finalization.
An older integration FAQ still says ChamberMaster is not compatible with DKIM and suggests waiting before configuring it. That statement conflicts with the explicit current procedure and the provider's February 2024 announcement of DKIM signing. Use the current setup instructions for this task, not the stale no-DKIM answer. Current DNS requirements and February 2024 announcement.
Economy signing does not, by itself, establish that your own domain appears in a passing aligned signature. The reviewed instructions do not specify its signing-domain identity. Treat premier activation and the actual branded-message test as separate requirements, rather than accepting any DKIM signature as success.
Save the current DNS and map all senders
Identify the authoritative DNS host from the domain's current delegated nameservers. The registrar, website host, staff-mailbox provider and database sender may be different organizations. Use the active DNS editor; do not move nameservers to follow a familiar screenshot.
Save the existing SPF policy, DKIM selectors, DMARC policy, TTLs and any _domainkey NS delegation. Preserve incoming MX, website records, unrelated verification TXT records and other senders' keys. Do not perform the website migration steps in a general ChamberMaster DNS article as a side effect of an email-authentication task.
List staff mailboxes, database notifications, newsletters, website forms and other applications using the same domain. If Microsoft 365 handles staff mail, its authorization and tenant-issued DKIM setup remain separate; the Microsoft 365 authentication guide covers that route. Authenticating ChamberMaster must not remove the working mailbox service.
Configure one SPF policy with a deliberate -all decision
The authorization mechanism for the current ChamberMaster/MemberZone setup is:
include:spf.memberzone.com
The current premier setup table shows this new-policy example at the domain apex:
v=spf1 mx include:spf.memberzone.com -all
The separate official SPF guide shows a new-policy example without mx:
v=spf1 include:spf.memberzone.com -all
These are alternative documented examples, not two records to publish together. The shared required service authorization is include:spf.memberzone.com. The mx mechanism additionally authorizes addresses of the domain's MX hosts; it is not decorative syntax. Premier DNS table and official SPF guide.
For a new policy, determine whether the MX infrastructure actually sends mail and should be authorized. An inbound filtering gateway is not automatically an outbound sender. For an existing policy, preserve legitimate mechanisms, including any a or mx terms, while reviewing what they authorize. a can authorize the domain's address records, and mx can authorize its mail-exchanger addresses, including IPv6 as applicable. Do not add or remove those authorizations merely to make a sample match.
Merge rather than replace
At the documented mail-domain apex, use TXT and the DNS editor's apex notation, often @ or blank. If a v=spf1 policy already exists at that owner, merge the required include into that one policy before its terminal all, preserving all approved services. Leave unrelated TXT records alone. Never create a second SPF policy or join two complete v=spf1 strings.
The premier instructions explicitly require an ending of -all, not ~all. If the existing policy uses another qualifier, the DNS owner must review the consequences for every legitimate sender before changing it. Do not label the premier configuration complete while ignoring that provider requirement, but do not automatically strengthen a shared domain policy without reconciling its routes. Resolve a conflict with the DNS owner and ChamberMaster Support first.
A policy using redirect= needs special attention. Appending -all disables the redirect's effect and can discard authorization supplied by the redirected policy. Do not treat that case as a simple suffix replacement. Have the DNS owner deliberately construct a valid combined policy that preserves the intended senders and reconcile the resulting configuration with Support. SPF redirect and all processing.
Check the actual SPF identity and lookup budget
SPF normally authenticates SMTP MAIL FROM, not the visible From address. A policy at example.com is not automatically inherited by bounce.example.com and cannot alter a provider-owned envelope domain. For a null reverse path, SPF can use HELO instead.
The current ChamberMaster setup specifies apex SPF but does not document an exact custom MAIL FROM format or a customer-configurable return-path record. Inspect the trusted receiving system's actual smtp.mailfrom on a new message. Do not import GrowthZone or SendGrid bounce-domain records to fill that gap.
Keep the complete SPF evaluation within ten DNS-lookup-causing terms, including evaluated nested includes and mechanisms such as a, mx, exists, ptr and redirect. This is not merely ten literal includes in the visible record. Duplicate policies, invalid syntax or excessive lookups can produce permerror. Do not delete a still-needed service because one lookup failed, or manually freeze a provider's changing infrastructure into copied IP addresses without a supported maintenance plan. SPF processing limits.
-all returns fail for an unmatched sender. It does not command every receiver to reject the message, guarantee inbox placement or prove that the visible From is authenticated.
Publish both current ChamberMaster DKIM CNAMEs
For new setups, the current provider-published pairs are:
Type: CNAME
Relative owner: cm._domainkey
Target: dkim1.chambermaster.com
Type: CNAME
Relative owner: cm2._domainkey
Target: dkim2.chambermaster.com
These are published product values, not invented tenant-specific examples. Confirm them against the current procedure and any instructions supplied for your account, then publish both in the intended sending domain's authoritative DNS. Do not reuse a conflicting selector or assume a legacy custom arrangement should be replaced without checking it. Official CNAME table.
For a domain of example.com, the complete owners are cm._domainkey.example.com and cm2._domainkey.example.com. In an editor that appends example.com, enter only cm._domainkey and cm2._domainkey. In an editor requiring full names, enter the complete owners. Verify the saved names so the domain suffix is not duplicated.
If Support configures a sending subdomain and the issued owner is cm._domainkey.news.example.com, use cm._domainkey.news in the parent example.com zone, or cm._domainkey in a separately delegated news.example.com zone. This is name translation, not a claim that every account automatically supports every subdomain arrangement.
If _domainkey.example.com is NS-delegated, the selectors must be served by that delegated authority. Their relative labels there would be cm and cm2. Preserve the delegation and coordinate with its administrator. Do not delete it or publish ineffective parent-zone data to force the setup.
Keep aliases literal and avoid record conflicts
A CNAME owner cannot also hold TXT, A, AAAA, MX or other conflicting data. If a selector is occupied, identify the existing dependency and obtain a supported resolution before editing it. Keep unrelated senders' selectors intact.
Enter the destinations as DNS hostnames, not URLs. Where the DNS service offers HTTP proxying, use DNS-only. If CNAME flattening is enabled, verify whether it actually hides the required selector aliases. Check the relevant per-record or zone-wide setting, including any same-zone behavior. An apex-only feature is not automatically relevant to these non-apex names.
Change only a setting that prevents the required CNAME chain from being served, after reviewing its effects. Do not globally disable flattening or change website records unnecessarily. If the host cannot expose the required aliases, resolve its supported configuration before claiming success. CNAME constraints and DKIM lookup model.
Preserve DMARC instead of copying the provider template
The setup table shows a monitoring template with p=none; sp=none. It must not overwrite an existing direct or applicable inherited policy. In particular, replacing an enforced policy or explicitly setting sp=none can weaken protection for subdomains.
Inspect the intended visible From domain's effective policy, alignment settings and authorized reporting destinations. Retain them. If a provider check or Support request appears to require weaker DMARC settings, resolve compatibility with the responsible administrators rather than silently downgrading protection.
Only if no direct or applicable inherited policy exists, and the owner approves a monitored rollout, a first record may use this illustrative form:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Replace the mailbox with an approved working reporting destination. Publish TXT at _dmarc.example.com, using relative Host _dmarc in an example.com zone. For _dmarc.news.example.com, use _dmarc.news in the parent zone or _dmarc in the delegated child zone. Do not publish a DMARC policy at the apex or add a duplicate. DMARC policy discovery and alignment.
When the aggregate-report destination has a different Organizational Domain from the domain where the policy was found, the report-generating receiver must check destination DNS authorization for that reporting relationship. The external-authorization check is not required when both share the same Organizational Domain. Obtain the reporting service's exact destination and authorization instructions. External reporting authorization.
That protocol check does not replace the owner's privacy and data-sharing decision. Aggregate reports reveal sending infrastructure and authentication activity; approve the recipient, access and retention. Failure reports can disclose additional message details and should not be enabled casually. Failure-reporting considerations.
Have Support finalize premier activation
After the required DNS records are publicly available, contact ChamberMaster Support to update the database to the premier option and finalize setup. This is an explicit step in the current procedure, not an optional escalation after failure.
Provide the intended sending domain and the relevant DNS configuration evidence without sending passwords, private keys or unnecessary message content. Ask Support to confirm completion for the correct ChamberMaster/MemberZone database and domain. If existing SPF or DMARC protection required reconciliation, include the agreed configuration rather than claiming an incompatible setup is finished.
Do not stop at a green DNS lookup or assume a self-service signing toggle exists. Wait for confirmation of the provider-side change, then run the actual message check. Support finalization requirement.
Verify DNS and the intended branded signature
These commands are examples, not executed results. Replace the domain and authoritative server with actual values, and query every authoritative server:
dig +short NS example.com
dig @ns1.dns-host.example TXT example.com +noall +answer
dig @ns1.dns-host.example CNAME cm._domainkey.example.com +noall +answer
dig @ns1.dns-host.example CNAME cm2._domainkey.example.com +noall +answer
dig @1.1.1.1 TXT dkim1.chambermaster.com +noall +answer
dig @1.1.1.1 TXT dkim2.chambermaster.com +noall +answer
dig @1.1.1.1 TXT _dmarc.example.com +noall +answer
Follow any delegation or additional aliases to the actual verification data. Confirm both CNAME destinations, the complete SPF policy at the evaluated owner and the intended DMARC policy. Compare authoritative answers with recursive answers and account for previous TTLs. A wrong owner, conflict or SERVFAIL needs investigation, not an automatic waiting period.
After Support confirms activation, send a newly authorized native-database message to a controlled external mailbox. Inspect Authentication-Results generated within that receiving system's trusted processing boundary. Header position or an authserv-id string alone does not prove authenticity; attacker-inserted results are not acceptable evidence. Authentication-Results trust requirements.
Accept the branded DKIM setup only when:
- The visible From remains the intended organizational address, not a substituted provider address.
- The intended ChamberMaster signature has the expected signing domain
d=and actual selectors=. - The trusted receiver reports that signature as
dkim=pass, and it aligns with visible From under the applicable policy. - The trusted receiver reports
dmarc=pass, with the aligned passing path identified.
Relaxed alignment permits an organizational-domain match; strict alignment requires exact equality. Evaluate DKIM's signing domain and SPF's MAIL FROM separately. A child envelope domain may align in relaxed mode but fail strict alignment. No strict-alignment guarantee follows from the published DNS table.
A generic DMARC pass supplied by SPF does not prove the intended DKIM change worked. An economy or provider-domain signature is not a substitute for the intended branded signature. Inspect SPF independently: direct-route fail or softfail needs a sending-IP and envelope-policy comparison; permerror needs syntax, duplicates and lookup-budget checks; temperror needs DNS investigation. An aligned DKIM pass should not hide a broken SPF policy.
Troubleshooting and rollback
Both CNAMEs resolve, but branded DKIM is missing. Confirm Support completed premier activation for the right database and domain, then verify the message used that native sending route. Repeated DNS edits cannot replace a missing provider-side step.
SPF fails after changing the ending to -all. Check whether a redirect was disabled, an approved sender was omitted or an existing mechanism was placed after all. Reconstruct the intended policy with the DNS owner; do not use +all or delete legitimate services blindly.
The provider's checker objects to your DMARC policy. Preserve working enforcement and reporting. Ask Support to reconcile the current policy with the premier configuration rather than copying the weaker template.
One DKIM selector appears unused. Retain both records required for the current setup. One message using only one selector does not establish that the other can be removed.
An old tutorial says DKIM is unsupported. Use the explicit current setup article and Support confirmation. Do not turn off another sender's DKIM because of the stale FAQ.
For reversal, restore only the faulty record after checking for concurrent edits. Coordinate any signing or selector rollback with Support so queued messages retain their verification keys. Retest ChamberMaster and unaffected senders; do not reset the entire zone or lower DMARC as the default recovery action.
Documentation and testing limits
No customer account was accessed, Support contacted, DNS changed or message sent. Actual premier activation, published records, delivered-message results, CMS rendering, publication, indexing and inbox placement remain untested.