Groove SPF, DKIM and DMARC setup, step by step

To authenticate support replies sent through Groove Classic’s shared SMTP servers, open the inbox’s SMTP configuration, publish its current DNS records, and run Test DNS. Then check a delivered reply for a passing DKIM signature aligned with your intended From domain. Do not substitute an old SPF include for the current white-labeling workflow. Groove’s setup instructions

This procedure covers Groove Classic, formerly commonly called Groove HQ. Helply is now the company’s master brand, but its newer AI-first platform is a separate product. Existing Classic accounts are not being migrated by this branding change. These instructions do not establish the authentication procedure for the separate Helply platform. Product and account distinction

This is a documentary guide. No customer inbox, DNS change or delivered reply was tested.

Confirm which service sends the reply

An inbox receiving messages successfully does not prove its outgoing replies are authenticated. Record the selected inbox, intended From address and outbound transport before changing DNS.

• Groove shared SMTP: This guide applies. Groove identifies the service as powered by Amazon SES and provides the white-labeling records inside the inbox.
• Gmail OAuth: Groove explicitly excludes this route from its shared-SMTP procedure. Work with the Google administrator instead. Use Google’s current sender-side instructions for that separate route.
• Another SMTP service: Authenticate the service actually sending the message. A Groove inbox label does not make that service use Groove’s DNS configuration.

The first two distinctions are explicit in Groove’s white-labeling documentation. The third is the operational consequence of tracing the actual transport: use its own supported configuration rather than combining unrelated providers’ records.

You need permission to edit that inbox and authorized access to the domain’s authoritative DNS. The public procedure does not establish a universal subscription-tier requirement or a particular admin-role name. If the SMTP tab or white-label controls are absent, confirm account eligibility and permissions with Groove before editing DNS.

Collect the inbox-generated record set

In Groove, open Settings > Channels > Email, edit the intended inbox using its pencil control, then open SMTP configuration. The current official article describes two CNAME records and one TXT record. Copy the complete set displayed for your inbox, including each owner, type and target or value. Locate the records

The native DNS-entry illustration shows an older SendGrid destination while the current text identifies SES; neither screenshot infrastructure nor its example TTL overrides the current inbox packet. Do not create extra records just to match a screenshot or another tutorial’s count. If your account differs from the current article, obtain clarification for that account. Record count alone cannot identify whether an alias is for DKIM, a return path or another purpose.

Identify the DKIM owner ending in ._domainkey and retain its generated selector and destination. The documentation illustrates the owner pattern groove._domainkey.yourdomain.com; that illustration is not a universal target or permission to replace your own displayed selector. DKIM verification retrieves the public key under the signature’s selector and signing domain. Publish the supplied public DNS information, never a private signing key. DKIM key lookup

Read the TXT record’s owner and contents before applying it. If it is a DMARC policy, reconcile it with the domain’s existing policy rather than adding a duplicate or weakening protection. A domain-owner verification token is a different purpose and can coexist with unrelated TXT records at an owner where no CNAME conflict exists.

Understand SPF without guessing the envelope domain

SPF authenticates the SMTP MAIL FROM domain, commonly reflected in the delivered Return-Path, rather than the visible From address. The receiver tests the sending IP against the policy at that exact envelope domain. The HELO identity is relevant for a null reverse path, not a reason to treat the visible From domain as the SPF identity. SPF identities and evaluation

Groove’s current official white-labeling procedure directs users away from the older SPF/DKIM setup toward the inbox-generated CNAME workflow. It does not publish a universal current customer MAIL FROM format or promise exact SPF alignment. Do not infer either from the fact that Amazon SES is involved. After setup, inspect smtp.mailfrom on a real reply to establish the identity used.

You may encounter the older include:smtp.groovehq.com recommendation in third-party material. Do not add it merely because you found that string. Follow the current inbox configuration and ask Groove to resolve an existing legacy deployment before removing its authorization. Current migration notice

If Groove supplies an explicit SPF change for your route, merge it into the existing policy at the specified owner. Keep one v=spf1 TXT policy there, preserve legitimate senders and the existing terminal qualifier, and assess the ten DNS-lookup-term limit including nested includes. SPF ignores redirect= whenever any all mechanism is present, regardless of ordering; terms after all are unreachable. Preserve a redirect-only policy’s intended control flow rather than adding an all that disables it. Qualifiers define SPF outcomes, not guaranteed acceptance or rejection. The evaluated include, a, mx, ptr, exists and redirect terms count toward the limit, including recursive evaluation; ip4, ip6 and all do not. SPF all precedence. A policy on example.com does not automatically authorize bounce.example.com. A generated return-path CNAME must not receive a conflicting TXT record at the same owner.

Publish safely in the correct DNS zone

Save a before-change inventory of SPF, DMARC, existing DKIM selectors and every owner Groove asks you to use. Preserve inbound MX records, website records and other applications’ verification tokens. Confirm the authoritative nameservers; the registrar is not always the DNS host.

The following examples explain owner-name entry, not records to copy. Substitute the actual selector and domain supplied for your inbox:

• For SELECTOR._domainkey.example.com in the example.com zone, a relative-name editor usually expects SELECTOR._domainkey.
• For SELECTOR._domainkey.support.example.com managed in the parent example.com zone, enter SELECTOR._domainkey.support.
• If support.example.com is a separately delegated zone, enter SELECTOR._domainkey inside that child zone instead.
• If _domainkey.support.example.com is separately delegated, publish full owner SELECTOR._domainkey.support.example.com through its authoritative administrator using relative name SELECTOR. Preserve NS delegations and DNSSEC, rather than removing them to make a parent-zone record work.
• For a supplied return-path owner such as bounce.support.example.com, the relative name is bounce.support in the parent zone or bounce in the delegated child zone. That hostname is illustrative, not a documented universal Groove bounce name.

An editor accepting fully qualified names may need the complete owner instead. Avoid duplicated suffixes such as .example.com.example.com. CNAME targets must remain the exact supplied hostnames, without https://, paths or added copies of your domain. Keep mail-authentication CNAMEs DNS-only where your host offers web proxying.

Keep authentication CNAMEs unflattened so a public CNAME query returns the required alias, not only address records. On Cloudflare, this requires DNS-only proxy status, the applicable record’s Flatten setting off where available, and assurance that zone-wide CNAME flattening for all CNAME records does not conceal the required alias. Check both scopes. Cloudflare identifies either flattening setting as a cause of failed CNAME verification. Coordinate any shared zone-setting change with the DNS owner and assess its effect on other services before applying it; do not remove a legitimate child-zone delegation as a shortcut. Cloudflare’s CNAME verification guidance

Cloudflare flattens apex aliases by default and same-zone targets regardless of that setting. If mandatory behavior prevents a required literal CNAME answer, stop and coordinate a supported configuration rather than inventing a switch or deleting a delegation. Cloudflare flattening controls.

A CNAME cannot coexist with unrelated data at its owner. Stop and reconcile an existing CNAME, TXT, A or AAAA conflict rather than overwriting another service. DNS conflict explanation

Groove’s guide accepts a 3,600-second TTL. Cached older answers can remain until their prior TTL expires. Retain legacy DKIM keys while queued mail or another active sender still needs them; migration is not a blanket deletion instruction.

Validate public DNS and activate white labeling

Use the actual names from your inbox. These are read-only command patterns; uppercase names are placeholders and example.com is illustrative:

dig +short NS example.com
dig @AUTHORITATIVE_NS SELECTOR._domainkey.example.com CNAME +noall +answer
dig +short CNAME SELECTOR._domainkey.example.com
dig +short TXT ACCOUNT_DKIM_CNAME_TARGET
dig +short CNAME ACCOUNT_RETURN_PATH_OWNER
dig +short TXT OBSERVED_MAIL_FROM_DOMAIN
dig +short TXT _dmarc.example.com

Use the return-path query only when the account actually supplies such an alias. Query every supplied record at its specified type, including the TXT owner. For a delegated child zone, use that zone’s authoritative server. The authoritative answers should match the account; compare recursive answers to detect stale caches. Follow a DKIM alias chain to the public key. An empty response needs investigation of name, type, delegation and target; it is not evidence that setup is complete.

Return to the same inbox’s SMTP tab and select Test DNS. Groove shows Valid or Invalid for the CNAMEs. Resolve each failure, then repeat the test. The official guide describes this as the white-labeling check; it does not document a separate universal “enable DKIM” switch. A valid record check is still not proof that the intended reply is signing correctly. Provider verification

Keep the records afterward. Groove documents a daily verification at midnight Pacific Time and says detected DNS problems disable white labeling. Recheck immediately after a DNS migration rather than waiting for that scheduled verification.

Keep DMARC policy and reporting intact

DMARC passes when at least one passing SPF or DKIM identity aligns with the visible From domain. Relaxed alignment uses the same organizational domain; strict alignment requires an exact domain match. Reply-To, a display name and a provider-owned DKIM signature do not by themselves establish alignment. DMARC alignment

For support@example.com, inspect _dmarc.example.com. For help@support.example.com, inspect _dmarc.support.example.com and any applicable inherited parent policy. In the parent zone, the child-policy owner is _dmarc.support; in a delegated support.example.com zone, it is _dmarc.

Preserve established p, sp, adkim, aspf and reporting settings. Only if no effective policy exists and the domain owner approves a monitored rollout might an initial TXT value be:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Use an approved mailbox that is actually monitored, and publish only one policy at the intended owner. When the Organizational Domain of the report destination host differs from that of the domain where the DMARC policy was found, the report-generating receiver must check DNS authorization. Destinations within the same Organizational Domain are excepted; a different hostname alone does not trigger this rule. DNS authorization does not replace domain-owner approval of report-data sharing and the recipient. RFC 9990 section 4. Review reporting coverage and failures over time; missing reports do not prove that no mail failed. Aggregate reporting and external authorization

RFC 9989 replaces RFC 7489 and removes the old pct tag. It also requires valid DKIM rather than SPF-only reliance for domains publishing p=reject. Do not weaken an existing policy to hide a broken support-mail route or advance enforcement on the strength of one successful reply.

Accept the setup only after a delivered reply

Have an authorized operator use a controlled recipient to create a harmless ticket and reply through the specific Groove inbox. Avoid real customer conversations or personal data. Save the received raw message and use results produced inside the actual receiving service’s known processing boundary. Establish through receiver documentation or its administrator how externally supplied Authentication-Results fields are removed or isolated, or obtain an authenticated receiver trace. A familiar authserv-id, header position or display label alone is not proof. Ignore attacker-supplied results and leave acceptance open if provenance is uncertain. Authentication-Results trust boundary

Capture the From domain, smtp.mailfrom, Return-Path, sending IP where available, every DKIM d= and s=, the SPF/DKIM results and the receiver’s DMARC result. The acceptance checklist is deliberately stronger than “DMARC passed”:

1. The reply uses the intended branded From address and expected shared-SMTP route.
2. The intended branded DKIM signature passes and aligns with From under the effective adkim mode. A provider-owned passing signature or SPF-only DMARC pass does not complete DKIM setup.
3. SPF is evaluated at the observed envelope identity. Distinguish a legitimate provider-owned SPF pass that does not align from an actual failure.
4. Investigate spf=fail, softfail, none, permerror or temperror; do not dismiss them just because aligned DKIM lets DMARC pass. Duplicate policies and lookup-limit problems commonly produce permanent errors; DNS availability problems can produce temporary errors.
5. The receiver reports dmarc=pass for the intended From domain, and other senders sharing the DNS zone remain unaffected.

For illustration, a passing d=example.com signature aligns exactly with support@example.com. A passing d=mailer.example.net signature does not. A MAIL FROM at bounce.example.com can align with example.com in relaxed mode but not strict mode. A passing intended DKIM signature with d=mail.example.com also aligns with From: support@example.com under relaxed alignment (assuming the same Organizational Domain), but not strict alignment; d=example.com matches exactly under either mode. These are protocol examples, not observed Groove headers. Never accept a provider-owned From rewrite as authentication of the intended brand. See raw DKIM versus aligned DKIM results for the distinction.

Troubleshoot the failing layer

Test DNS remains Invalid: Compare full public owner names and targets with the inbox. Check a doubled domain suffix, wrong zone, web proxying, CNAME conflicts and stale recursive answers. Do not repeatedly recreate the inbox to fix a DNS typo.

DNS is Valid but branded DKIM is absent: Confirm that the sample came from this inbox after setup and used shared SMTP. Compare its d= and s= with the intended configuration. Send Groove the timestamp and sanitized header evidence through an approved support channel; never expose private keys.

Replies fail after a website move: Restore the approved mail records from the change inventory, run Test DNS and check a new reply. Yesterday’s green screenshot is not today’s evidence.

SPF passes but DMARC fails: Check whether the envelope identity aligns, then inspect branded DKIM. Adding an include to the visible From domain will not repair an unrelated MAIL FROM identity.

Gmail OAuth inbox is still failing: Stop applying shared-SMTP records. Resolve Google-side authentication and inspect a reply from that transport.