Establish which server sends the reply
Start with the Groove inbox and its configured outbound transport. Record the intended From domain, current SMTP settings and who controls DNS. A helpdesk can receive tickets successfully while its outgoing identity remains unverified. The acceptance test must therefore include a reply through the inbox being changed.
Groove's white-labeling instructions apply to its shared SMTP service, described as powered by Amazon SES. They explicitly exclude Gmail OAuth inboxes from this procedure; those need their Google-side authentication configuration. The guide also calls for migration from the earlier SPF/DKIM setup to its newer CNAME workflow. Groove white-labeling scope
Copy the current inbox’s generated configuration
In Settings > Channels > Email, edit the relevant inbox and open its SMTP configuration. Groove documents two CNAME records and one TXT record there. Publish the records shown for that inbox at the authoritative DNS service, then use Test DNS in the same tab. Do not borrow another inbox's target or infer a missing value from the Amazon SES product name. Configuration and verification
Build a small before-and-after record inventory. Include the full DNS owner, type, value, prior answer and reason for change. A DNS editor may append your domain automatically, so inspect the resulting fully qualified name. Do not add incompatible data beside a CNAME, and do not delete an older selector merely because a new one is available. First establish whether any active sender or queued mail still depends on it.
Identify the purpose of the generated TXT record before reconciling it with existing DNS. If it is a DMARC policy, preserve the domain owner's approved scope and reporting destination rather than blindly replacing it. If a policy or name conflicts, obtain a supported resolution before launch. A workflow screenshot cannot authorize weakening a shared domain's protection.
Retain the records after setup
Groove documents a daily DNS verification at midnight Pacific Time and says a detected issue disables white labeling. This makes DNS retention a continuing support dependency, not a disposable setup task. Add the record owners to the organization's DNS inventory and name an inbox administrator who can investigate after a migration or cleanup. Ongoing verification
Original acceptance plan: send a harmless new ticket from a controlled account and reply through the configured Groove inbox. Capture the trusted recipient's SPF, DKIM and DMARC results, the visible From domain, envelope sender and DKIM signing domain and selector. Confirm that a passing SPF or DKIM identity aligns with From under the applicable policy. An SMTP acceptance event alone is not a final authentication result.
Illustrative case: a website migration removes the helpdesk's CNAMEs because they appear unrelated to the website. Yesterday's successful setup screenshot does not establish today's state. Restore the approved records, repeat Groove's DNS test and retain a fresh received-message check before declaring the incident resolved.
Recover at the failing layer
Pause the affected outbound workflow if identity problems are causing customer errors. Compare public records with the current inbox configuration before changing transport. For a Gmail OAuth inbox, route the investigation to the Google mail administrator instead of applying shared-SMTP records. Preserve the last approved state and retest after any sender, DNS or transport change.
Documentation was reviewed on 8 November 2026. No Groove inbox, live DNS or reply was tested. The migration example and acceptance plan are illustrative, and no deliverability guarantee is claimed.
Close the migration gap before relying on the old screenshot
For written case GH-01, assume yesterday’s Test DNS screenshot showed both CNAMEs valid, but today’s approved zone inventory after a website migration has neither. The mailbox is still configured for Groove shared SMTP; today’s product status and message identities are unknown. The DNS owner should reconcile the migrated zone with the current inbox-generated set, restore only approved dependencies and run fresh validation with the inbox owner. The old screenshot is historical evidence, not current acceptance. Do not extrapolate that result to a separate Gmail OAuth inbox. The daily provider check is not a substitute for checking after a known change. No migration, DNS query or reply occurred for this scenario.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.