SPF, DKIM & DMARC for Groove.

Why authenticate Groove?

Authenticating Groove isn't housekeeping — for a help desk it's the difference between a customer seeing your reply and it dying in spam, the worst possible place for a support answer to land. Since February 2024, Gmail and Yahoo require every bulk sender (roughly 5,000+ messages a day, a bar a busy shared inbox clears on ticket replies and notifications alone) to pass SPF, DKIM, and DMARC with alignment, and Microsoft began enforcing the same on consumer Outlook/Hotmail mail in 2025. Until you white-label, Groove sends on its own infrastructure: recipients see a "via groovehq.com" or "on behalf of" note, your From address doesn't cryptographically belong to you, DMARC can't pass, and your reputation is pooled with every other unauthenticated Groove sender. White-labeling fixes all of it in one move — DKIM aligns to your domain, the "via" tag disappears, DMARC passes, and the reputation you build accrues to your own domain. In support, where trust is the whole product, that alignment is what keeps customers reading and replying instead of reporting you as spam.

The SPF reality for Groove

Groove is technically an "include" provider — there really is a shared mechanism, include:smtp.groovehq.com — but it is NOT the path that makes DMARC pass, and it's not what Groove's current setup recommends. Two reasons. First, Groove sends every message with a Return-Path/envelope on its own bounce domain (Groove owns and processes the bounces), so SPF is always evaluated against Groove's domain, never your From domain. include:smtp.groovehq.com makes the raw SPF check pass for Groove's IPs, but it does not ALIGN with your organizational domain — and DMARC only counts SPF when it aligns. Groove's own deliverability documentation is blunt about this: it uses one of its own domains for the return-path, and it provides no mechanism that lets SPF alignment pass. Second, Groove's white-labeling flow doesn't ask for the include at all: in the inbox's SMTP configuration tab it hands you CNAME records — a DKIM key on the groove._domainkey selector plus a return-path CNAME (and a third CNAME on newer accounts) — and a DMARC TXT record. DKIM signed as d=yourdomain.com is the mechanism that aligns and carries your DMARC pass. Groove explicitly tells anyone who "previously set up DKIM and SPF records for your SMTP sending" to "migrate to the newer improved CNAME version." So the include still exists and old tutorials still cite v=spf1 include:smtp.groovehq.com ~all, but on the modern setup it's optional: it burns one of your 10 SPF lookups and buys no DMARC alignment. One scope note — white-labeling only applies to inboxes that send through Groove's own SMTP servers; if you connected an inbox via Gmail/Google Workspace or Microsoft 365 OAuth, Groove relays through that provider and you authenticate the domain there instead.

Two ways to set it up

Step by step

Records to add

Groove generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.

The 10-lookup budget

SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what Groove's setup costs against that budget.

Check it actually worked

Groove gives you two verification layers, and you should trust neither alone. In-app: the Test DNS button under the CNAME listing in the SMTP configuration tab flips from Invalid to Valid once the records resolve (propagation is usually minutes but can run 48–72 hours). Groove also re-runs verification automatically every day at midnight Pacific — and silently disables white-labeling if a record later stops resolving, so if mail suddenly shows "via groovehq.com" again, a CNAME almost certainly changed. Don't stop at the green badge: send a real reply (or a test) to a Gmail account, open it, and choose ⋮ → Show original. Confirm DKIM: PASS with d=yourdomain.com and selector groove (not groovehq.com), and DMARC: PASS — SPF may still show Groove's domain, which is expected because DKIM is what aligns here. Then run your domain through Qualisend's domain health check to confirm the DKIM CNAME, the return-path CNAME(s), and the DMARC record all resolve cleanly, and once aggregate reports arrive, drop one into the DMARC report analyzer to see Groove show up as an aligned, passing source.

Common gotchas

• DNS setup

  DKIM carries DMARC here, not SPF. Groove owns the return-path/bounce domain, so SPF passes against Groove's domain but doesn't ALIGN to yours. Adding include:smtp.groovehq.com will not make DMARC pass — the groove._domainkey DKIM CNAME is what does. Don't skip it thinking the SPF include has you covered.

• DNS setup

  White-labeling only applies to Groove-SMTP inboxes. If an inbox is connected through Gmail/Google Workspace or Microsoft 365, Groove sends through that provider — these CNAMEs don't apply and you authenticate the domain in Google/M365 instead.

• DNS setup

  Groove re-verifies daily at midnight Pacific and silently disables white-labeling if any record breaks. If mail reverts to 'via groovehq.com', a CNAME was changed or removed (a registrar edit, a Cloudflare proxy toggle) — re-add it and click Test DNS.

• DNS setup

  The record set is per-inbox. Each connected mailbox has its own SMTP configuration tab and its own CNAMEs — authenticate every inbox you send from, not just the first one you set up.

• DNS setup

  Host-field doubling and the Google Domains quirk: enter just groove._domainkey, not groove._domainkey.yourdomain.com; Google Domains additionally requires a trailing period on the CNAME target.

• DNS setup

  Cloudflare proxy breaks CNAME resolution. Set each Groove CNAME to 'DNS only' (grey cloud) — an orange-cloud proxied CNAME won't resolve to the Groove host and Test DNS stays Invalid.

• DNS setup

  Don't stack a redundant include:smtp.groovehq.com when you use the CNAME flow. It consumes one of your 10 SPF lookups and buys no alignment; Groove itself tells legacy SPF/DKIM users to migrate to the CNAMEs.

• Breaks auth

  Only one DMARC record per domain. Groove offers a DMARC TXT in its flow — skip it if you already publish _dmarc, because two DMARC records is invalid and neither will apply.

Build your SPF record

Groove doesn't need an SPF include: on your root domain — use the generator to assemble one clean record for your other senders, and keep it to a single line.

Groove SPF — FAQ

Related reading

Once it's published, confirm everything resolves with the domain health check, then read who's sending as you with the DMARC report analyzer. Browse all sending sources in the generator. Authentication is only half of deliverability, though — a listed sending IP or domain still lands you in spam no matter how clean your SPF is, so it's worth watching the blacklists with blacklist monitoring.