For an approved user email domain in Showpad, choose CNAME automatic security, publish the instance-specific permission TXT and all three issued CNAME records, preserve the applicable DMARC policy, and verify the domain. Separately enable and save the approved organization-wide sending mode. A green DNS check is not proof that a real message uses the intended aligned signature. Showpad's current sending-domain instructions
This guide covers native Email Shares and Shared Space invitations, using the automatic CNAME configuration for an existing user's approved default domain. It does not configure a connected mailbox, migrate inbound mail or reproduce Showpad's separate manual SPF/DKIM/MX workflow. The automatic route uses DNS aliases to provider-managed authentication records; CNAME is not a third authentication protocol alongside SPF and DKIM.
On this page: Check access, product scope and sender permission · Distinguish default domains, global domains and fallback · Retrieve the account-specific automatic packet · Publish without disturbing other mail or DNS · Do not mix manual SPF or MX instructions into this route · Preserve the effective DMARC policy · Verify DNS, then confirm the sending mode · Test the intended native message safely · Troubleshooting by symptom · Frequently asked questions
Check access, product scope and sender permission
Showpad's current documentation lists Administrator permission and eOS Expert, Advanced or Professional plans. It also lists the legacy Showpad Coach Essential and Content Essential plans, or higher. Confirm the actual entitlement before changing configuration; a missing control is not a reason to purchase an upgrade or grant broader permissions without approval.
In the Admin App, open the gear icon, then Settings → Sending Domains. The Default Domains list is populated from existing users' email domains. A domain appearing there does not prove ownership, permission to send or completed authentication.
Approve the exact domain, users, native route and visible From identities with the domain owner. Record the authoritative DNS host, the existing sending mode and all other Showpad organizations already authorized to use the domain. Showpad warns that configuration and verification can propagate across organizations authorized by the same DNS. Do not add another organization's permission token or silently broaden the approved audience.
Distinguish default domains, global domains and fallback
| Configuration | Meaning for this guide |
|---|---|
| Verified default user domain | The intended route: eligible users send from their own approved company addresses |
| Custom Global Sending Domain | A separate substitution route; messages can use the configured global domain while Reply-To remains the actual user's address |
| Showpad domain mode | Sends through the provider's default identity rather than the requested company From |
| User without a configured domain | Can fall back to share@showpad.com or an existing custom global domain |
Do not create a Custom Global Sending Domain merely because another tutorial starts there. That changes the sender model and is outside this default-domain procedure. A successful reply to the user does not establish that the visible From is the user's domain; Reply-To and From perform different roles.
Inspect the current global mode before work. If custom/default-domain sending is already active, making another domain eligible may change its users' visible sender without a later organization-wide switch. Coordinate that activation timing and obtain the affected sender approvals before verification. Sending modes and fallback behavior
Retrieve the account-specific automatic packet
- In Default Domains, locate the approved user domain.
- Select Configuration beside that domain.
- Choose CNAME as the Configuration Type, not the manual SPF/DKIM option.
- Copy the complete account-issued owners, types and targets. Keep the instance-specific permission TXT as well as the three CNAME rows.
- Review and save the selected configuration, retaining the exact resulting packet for DNS publication.
The official CNAME demonstration shows one permission TXT, a non-_domainkey CNAME and two _domainkey CNAMEs, plus a DMARC example. Use the actual account's values, not the demonstration's domain, tenant identifier, selectors or targets. If the current account presents a materially different packet, resolve the supported layout before proceeding rather than forcing it to match a screenshot.
The permission TXT is mandatory and unique to the Showpad instance. It authorizes that instance to verify the domain. It is not an SPF policy, a DKIM public key or optional decoration. Removing it from the worksheet because the title says “CNAME setup” can prevent verification.
The two _domainkey aliases support provider-managed DKIM. The separate alias participates in the automatic authentication layout; confirm its exact envelope/routing purpose in the supplied configuration if unclear. Do not omit it, replace it with an invented apex SPF include or rename it to a convenient unused label.
Showpad describes automatic key rotation and support for keys up to 2048 bits. Its custom Selector control changes generated CNAME pairs. A selector change is therefore a coordinated rotation, not cosmetic editing. Preserve existing dependencies and keys until the new issued configuration is verified and any delayed messages using the previous selector have been accounted for. Never publish a private signing key.
Publish without disturbing other mail or DNS
Save the current DNS values and TTLs before making the approved changes. Keep working MX, website records, other senders' selectors, SPF authorizations and relevant NS delegations. Do not import a downloaded zone file wholesale: inspect its proposed rows and publish only the authorized changes.
Determine which DNS server is authoritative for each owner. The registrar's editor may not serve the zone. An editor that appends the zone name needs relative labels, not blindly copied fully qualified names.
For example, an issued owner SELECTOR._domainkey.news.example.com maps to SELECTOR._domainkey.news in the example.com zone, or SELECTOR._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, use SELECTOR there. These are naming examples, not Showpad-issued selectors or approval to add a new domain.
A CNAME owner cannot coexist with conflicting records at that same name. Do not delete an existing service's key or routing record to make room. Request a supported configuration, including a coordinated alternate selector where appropriate. Compare any envelope/routing alias with the approved routing plan and obtain separate approval for changes affecting those destinations; domain authentication is not permission to redirect unrelated traffic.
Authentication CNAMEs must remain literal DNS aliases to the issued targets. Use DNS-only rather than HTTP proxying. Where supported, disable flattening for the relevant alias only. Cloudflare's flatten-all setting cannot be overridden per record; apex and same-zone aliases also have special behavior. If shared settings prevent the required CNAME answer, coordinate a supported layout rather than disabling a feature across the whole zone. Flattening controls and limits
Do not mix manual SPF or MX instructions into this route
The automatic CNAME configuration links to authentication records Showpad manages. Do not copy the manual-mode SPF TXT or MX example into it. No incoming-mail migration or apex SPF replacement is part of this procedure.
SPF evaluates the actual SMTP MAIL FROM domain. Read the trusted receiver's smtp.mailfrom to identify the evaluated owner; it is not necessarily the visible From domain. Assess that route's SPF result even when DKIM supplies DMARC success.
If an administrator separately needs to adjust an existing SPF TXT policy, review that as its own supported change: one SPF policy per actual owner, retained legitimate authorizations and approved terminal behavior, and a valid evaluation within the ten lookup-causing-term limit. Never append a second full policy, use +all or assume every include costs one total lookup. Any all mechanism suppresses redirect, so a redirect-based policy needs a deliberate merge. These protocol rules are not an instruction to add TXT beside an issued CNAME. SPF rules and result meanings
Preserve the effective DMARC policy
Inspect the intended From domain's direct and inherited policy before publication. A missing child record does not prove that the domain is unprotected. Preserve enforcement, alignment modes and reporting recipients unless the owner approves a specific change. Do not add a second DMARC record or overwrite an established policy with the demonstration's p=none. DMARC policy and alignment
Showpad requires a DMARC policy for its sending-domain setup. If the validator does not recognize valid inherited protection, coordinate a supported resolution rather than installing a weaker child policy. With no applicable policy, a first monitoring-only rollout can be planned separately with the domain owner. Map its _dmarc owner to the actual authoritative zone and approve its report destinations.
Aggregate-report rua addresses receive authentication reports, not forwarded quarantined messages. For external authorization, compare the Organizational Domain of the reporting URI destination host with the Organizational Domain of the domain where the policy was found, including inherited policy. Different Organizational Domains require external authorization; the same-Organizational-Domain exception uses that policy-found domain. DNS authorization does not replace approval to share report data. Aggregate reporting requirements
Do not relax strict alignment because a troubleshooting list recommends relaxed mode, or strengthen enforcement solely because the DNS status is green. Establish a route that satisfies the approved policy and assess other legitimate senders before proposing policy changes.
Verify DNS, then confirm the sending mode
After publication, query the authoritative server and a recursive resolver for each exact owner. Compare the permission TXT and all three CNAME answers with the saved packet; follow the DKIM targets to their public keys. Check for doubled domain suffixes, wrong zones, conflicting data and suppressed aliases.
Return to the intended domain and select Verify Now. Resolve red indicators using their error detail. Showpad documents a green verification status for a verified configuration; DNS-editor Save and configuration Save alone are not equivalent to that status. Its stated propagation window is an estimate, not a universal maximum or a guarantee that a wrong record will eventually work.
Separately inspect the top-level Settings section on the Sending Domains page. For an approved transition, choose Use a custom or verified default domain for sending, configured underneath, then Save. This is an organization-wide sender-mode decision, not merely another DNS check. Confirm approvals and effects on other verified domains, unconfigured users and any existing global fallback before changing it. If the mode is already enabled, do not toggle it unnecessarily.
The documentation does not establish an additional private “start signing” switch beyond this configuration and sending-mode workflow. If a verified, enabled route remains unsigned, have Showpad Support investigate the exact organization and domain rather than inventing another control.
Test the intended native message safely
Use an approved isolated native Email Share or Shared Space invitation to a controlled recipient, containing only non-confidential test material and permissions explicitly approved for that recipient. Do not share a customer's file, broaden content access or invite external people merely to test authentication. A mailbox integration or preview is not a substitute for the intended native route. No standalone authentication test-send control is established by the reviewed instructions.
If no safe authorized native message is available, leave message acceptance pending. DNS and account verification can be documented without pretending that sending was tested.
Use receiving-system diagnostics, or have its administrator establish which Authentication-Results originated inside the trusted receiving boundary and how externally supplied fields are removed or distinguished. Header position and a familiar authserv-id alone do not prove authenticity. Retain sanitized identities, results and timestamps, not confidential shared content. Receiver trust requirements
| Check | Acceptance requirement |
|---|---|
| Sender and route | Actual native Showpad message with the approved user's From, not unnoticed provider/global-domain fallback |
| Intended DKIM | The expected Showpad signature passes using the actual active selector |
| Alignment | That same passing signature's d= aligns with the approved From under effective adkim |
| DMARC | Trusted receiver reports pass for the actual From |
| SPF | Actual MAIL FROM result assessed independently; errors investigated even if DKIM supplies DMARC pass |
| Other affected users | Approved default and fallback behavior retained; no unintended organization-wide sender changes |
Relaxed DKIM alignment compares Organizational Domains; strict alignment requires exact equality between signing domain and From domain. SPF alignment compares MAIL FROM with From under the separate aspf mode. A child envelope domain does not automatically meet strict alignment with its parent From.
A DMARC pass through SPF alone cannot validate this DKIM deployment. Nor can a passing unrelated signature or a rewritten provider From. See raw DKIM results versus aligned policy results.
Troubleshooting by symptom
Verification fails despite published CNAMEs
Check the mandatory instance TXT first, then the complete issued packet, exact zone, suffix handling and literal CNAME responses. A token from another organization is not interchangeable. Preserve the current approved configuration while resolving collisions rather than removing another sender's records.
Verification is green but mail uses share@showpad.com
Inspect the top-level sending mode and whether this particular user's domain is configured. Confirm that you examined a fresh native message. An existing global fallback can change From while keeping the user's Reply-To; neither fallback proves the requested default domain is authenticated.
DKIM passes but the branded acceptance check fails
Inspect which signature passed and whether its d= aligns with the actual From under the effective policy. Confirm the active selector after any rotation. Keep strict alignment when required and request a supported exact-domain route rather than downgrading the policy.
SPF reports an error while DMARC passes
For fail or softfail, examine authorization for the actual envelope route. For temperror, investigate transient DNS/evaluation availability. For permerror, check syntax, duplicate SPF policies and lookup limits at the evaluated owner. An unaligned but passing provider envelope is different from an SPF error. Do not hide either outcome behind a generic green badge.
Another organization or user changed unexpectedly
Check the pre-change authorization inventory, global mode and shared-domain behavior. Coordinate a bounded rollback with affected owners after checking intervening changes. Do not remove all instance tokens or restore an entire old DNS zone indiscriminately.