In the current CommUnity administrator interface, open Admin Panel > Site Building Tools > Site Messages > Sender Authentication, enter the sending domain and click Get Started once. Publish the CNAME records issued for that domain, return to Verify, then select the verified domain under Administrator Email, enter the intended username and choose Change Administrator Email. DNS publication, successful verification and selecting the sender are separate steps. Official CommUnity procedure
This guide covers that specific CommUnity Site Messages workflow documented in the MemberClicks help center. It is not a universal guide for MC Professional, Smart Newsletter or every Personify product. If your environment lacks these controls, confirm the exact product and supported workflow before making DNS changes.
On this page: Scope and preparation · Request one record set · Publish the issued CNAMEs · What to do about SPF · Keep DMARC intact · Verify and select the sender · Test an actual Site Messages email · Troubleshoot · Frequently asked questions · Sources and review limits
Scope and preparation
The official article, says CommUnity requires sender authentication from February 21, 2024. It specifically calls out administrators who previously changed their email address in Site Messages. That is evidence for the documented current interface, not proof of the configuration of every community, edition or historical installation.
Identify the Site Messages workflow and the organization-approved administrator From address. Confirm the domain is controlled by your organization and that you have the appropriate administrator access. The source identifies administrator controls but does not establish that every user role can use them. If access is missing, ask the account owner to resolve it; do not expand permissions merely to follow a tutorial.
Also identify the authoritative DNS operator. DNS may be managed separately from your registrar or website host. Record the existing sender setting, domain-authentication entries and their state, the relevant DNS records and TTLs, current DKIM selectors and delegations, and the applicable direct or inherited DMARC policy. Keep a baseline so a later repair can be limited to the intended change.
Do not alter staff-mail routing or your usual Microsoft 365/Google Workspace authorization. Site Messages is one sending route, not your entire organization's email service. Existing authentication for another application does not establish that CommUnity is using it.
Request one record set
Open Admin Panel > Site Building Tools > Site Messages > Sender Authentication. Check whether the intended domain already has a configuration before starting another. If it does, inspect that existing entry and coordinate with its owner instead of generating competing records.
For a new, approved setup:
- Enter the domain you intend to use for the sender.
- Click Get Started once during the session.
- Retain the displayed CNAME packet with its domain and creation context.
- Give the complete type, full Host and complete Value for every row to the authorized DNS operator.
The provider explicitly warns that each additional click adds another record set, a behavior intended for changing custom domains. Repeated clicking is not a refresh or a safe way to repair validation. If you accidentally generate multiple sets, identify which configuration should remain active with the administrator or support before deleting anything.
The official screenshot illustrates three CNAME rows, status indicators, a last-validation time, a Verify button and copy controls. Its hosts and targets are blurred. The screenshot is therefore evidence of the interface and record type, not a usable DNS template. Copy your account’s current complete values rather than guessing selectors, counts for every future configuration or a generic provider target.
The article does not identify the purpose of each blurred row or publish a universal SPF include. Do not label one as a particular return-path or tracking record based only on its position. If the issued packet is unclear or conflicts with an existing owner, obtain a record-by-record explanation from support before publishing.
Publish the issued CNAMEs
Use the authoritative DNS service for each owner. Keep the generated types and full targets intact. Do not replace a CNAME with a TXT record because another DKIM tutorial uses TXT: different providers publish their public-key information differently.
Translate full owners correctly
A DNS panel may want a complete hostname or only the portion relative to its zone. Use the full issued owner as the reference and verify the name actually saved.
For illustration only, an issued owner of selector._domainkey.example.com normally becomes selector._domainkey in an example.com zone that appends its suffix. If _domainkey.example.com is a separately delegated zone, the relative name at that authority is instead selector.
For a hypothetical selector._domainkey.news.example.com, the relative name is selector._domainkey.news in the parent example.com zone, selector._domainkey in a delegated news.example.com zone, or selector in a delegated _domainkey.news.example.com zone. These examples explain DNS naming; they are not claims that CommUnity issues these particular owners or supports every sender-domain arrangement.
Preserve existing NS delegations. Publishing at the parent when another authority owns the child will not repair validation. Do not remove a delegation or move nameservers to simplify a name field.
Resolve conflicts without breaking other services
A CNAME cannot coexist at the same owner with conflicting TXT, A, AAAA, MX data or another CNAME. Check the current record and its owner before making any replacement. A shared selector may still be used by another application or queued mail. Coordinate a supported record change with the affected service owners rather than deleting their keys.
Do not add an apex CNAME or change MX as an improvised authentication fix. If the issued name would conflict with a zone apex or another required record, stop for a supported design. Do not change account credentials, DNSSEC or transport security to make the form accept it.
Make literal CNAME answers visible
Publish these aliases as DNS-only records, not behind an HTTP proxy. Check both per-record and whole-zone CNAME-flattening behavior. An alias silently flattened into address answers may not be visible to the provider’s verification process.
On Cloudflare, turn the relevant record’s Flatten option off where available and ensure the zone-wide flatten-all setting does not suppress these required aliases. A whole-zone setting cannot always be overridden per record; coordinate any broader change because other services may depend on it. Cloudflare documents mandatory apex flattening and same-zone target behavior that ignores the flattening setting. If those constraints prevent the required CNAME answer, obtain a supported arrangement instead of inventing a switch or removing shared delegations. Cloudflare controls and exceptions
The required outcome is the correct published alias at the actual authoritative owner. Merely inspecting a dashboard setting does not establish that outcome. The service’s private signing keys never belong in your DNS; do not generate or publish a private key to supplement this CNAME workflow.
What to do about SPF
The current CommUnity instructions provide a generated CNAME workflow, not a universal apex SPF recipe. Do not add include:sendgrid.net, derive an include from the MemberClicks website, copy another customer’s records or authorize an observed sending IP without current instructions for your actual route.
SPF checks the SMTP MAIL FROM domain, or the relevant HELO identity when the reverse path is empty. The visible From address is a different identity. Identify the real evaluated domain from trusted receiver evidence before deciding which policy needs attention. A green sender-verification screen does not prove branded SPF alignment. SPF identity rules
If a separately justified change to a TXT SPF policy is needed, maintain one v=spf1 policy at that owner. Preserve legitimate authorizations and existing qualifiers; merge an approved mechanism rather than creating a second SPF record. Evaluation permits at most ten DNS-dependent terms, including nested mechanisms and redirects, not ten visible includes. An all mechanism causes redirect to be ignored. Do not promise a particular delivery outcome from a qualifier. SPF limits
A passing SPF identity must also align with the visible From to supply a DMARC pass. Relaxed alignment permits the applicable Organizational Domain relationship; strict alignment requires an exact domain match. A child return-path and a root From do not satisfy strict SPF alignment merely because your organization owns both. This guide does not claim a universal CommUnity envelope domain or a custom return-path control.
Keep DMARC intact
Preserve the existing policy at the From domain and any applicable inherited policy, along with approved report destinations and alignment settings. A missing child-domain record does not prove the domain has no protection. Do not add an overriding child p=none policy simply to avoid a setup failure.
Only when no applicable policy exists, the domain owner has approved monitoring and there is a suitable monitoring plan, this is an illustrative first record for example.com:
Full owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:reports@example.com
Replace the domain and mailbox with your authorized, functioning reporting destination. In a zone that appends example.com, the relative owner is _dmarc. Do not create a second policy at that owner, weaken existing quarantine/reject protection or use obsolete pct rollout advice. Monitoring does not itself block spoofing. Current DMARC standard
For aggregate reports, a destination in a different Organizational Domain from the domain where the policy was found requires the report-generating receiver to check DNS authorization. A destination within the same Organizational Domain is excepted, even when the hostname differs. DNS authorization is separate from the domain owner’s permission to share report data with that destination. RFC 9990, section 4
DMARC can pass through either aligned SPF or aligned DKIM. That does not make an SPF-only pass sufficient evidence that newly configured DKIM is working.
Verify and select the sender
After publication, check the issued aliases at the authority and through recursive DNS, allowing for the actual TTLs. These are read-only examples, not actual CommUnity values or observed results:
dig +short CNAME issued-owner.example.com
dig +short CNAME selector._domainkey.example.com
dig +short TXT issued-dkim-target.example.net
dig +short TXT _dmarc.example.com
Replace every illustrative owner or target with the approved packet. Expect each CNAME to match its issued target; where a record is confirmed as a DKIM alias, follow it to the complete public key. Do not assume every generated row is a DKIM key or accept empty output as successful propagation.
Return to Sender Authentication and choose Verify. Resolve the errors reported for that domain. The source does not publish a guaranteed activation interval, so do not promise a fixed wait. Incorrect types, owners, targets, delegation or flattened answers will not fix themselves with time.
After verification succeeds, select the authenticated domain from the @ dropdown under Administrator Email, enter the approved username/local part and click Change Administrator Email. This final sender-selection step matters: publishing records without selecting the intended sender leaves the workflow incomplete. Confirm the resulting full address is the one approved for Site Messages, not a substitute chosen only to obtain a pass.
Test an actual Site Messages email
Use an approved representative message and a controlled recipient, sent through the actual CommUnity Site Messages workflow. Do not broadcast to members merely to validate setup, and do not substitute a test sent from your staff mailbox.
Obtain the receiver’s full original message and its documented header or trace interpretation. Rely on Authentication-Results produced inside that receiving service’s known processing boundary, not externally supplied fields. A plausible authserv-id or familiar header position alone is not evidence of trust. Ask the receiving administrator to identify trusted results if you cannot establish that boundary. Authentication-Results security guidance
Record the unchanged approved visible From, the SPF result and evaluated identity, the intended provider’s DKIM signing domain (d=) and selector (s=), and the receiver’s DMARC result. For this DKIM setup, require the intended signature to pass and align with the approved From, plus trusted receiver dmarc=pass. Strict DKIM alignment requires exact domain equality; relaxed alignment uses the applicable Organizational Domain relationship.
An unrelated passing signature does not establish your intended signing path. Neither does a provider-rewritten From address, an SPF-only DMARC pass or a success badge in the administrator panel. The EmailAuth guide to raw DKIM results versus aligned DKIM policy results explains that distinction.
Diagnose SPF fail or softfail, temporary DNS failure (temperror) and invalid-policy/lookup-limit problems (permerror) separately, even when aligned DKIM permits DMARC to pass. Authentication is also separate from inbox placement, recipient consent and filtering. Keep the test result limited to the actual route and message examined.
Troubleshoot
More records appeared after another Get Started click. Stop generating sets. Preserve the current record inventory, determine which domain/configuration should be active and coordinate cleanup. Do not delete older records until their active or queued-message dependencies are understood.
Verify fails for one or more CNAMEs. Compare each full owner, type and target with the account packet. Check duplicated zone suffixes, the real authority, a conflicting owner, proxy mode and relevant flattening controls. Do not repair a CNAME failure by adding an unrelated apex SPF include.
The domain verified but the old address is still used. Recheck the Administrator Email domain dropdown, username and Change Administrator Email step, then test the actual workflow again. A sender-display name is not the From domain.
The domain is unavailable in the dropdown. Confirm verification succeeded for the intended entry in the correct administrator context. Preserve the error details and ask support; do not invent a missing-role entitlement or generate repeated records.
DKIM verifies but DMARC fails. Compare the signature’s actual signing domain with the unchanged From under the applicable adkim. Also inspect SPF independently. Do not weaken DMARC to conceal a misaligned sender.
Another service breaks after publication. Compare the baseline, identify the exact changed owner and its dependencies, and agree a narrow rollback. Do not restore the entire zone or remove every selector. Retest both services after the authorized repair.
Sources and review limits
The full official CommUnity procedure and its linked record-table screenshot were reviewed. The screenshot confirms CNAME rows and validation controls; its blurred values were not inferred. The current workflow is documented in the MemberClicks help center, but this article does not assert that every legacy installation uses it. This is documentary guidance, not a report of customer account operation, live DNS, received-message validation, visual CMS testing, indexation or publication.