Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Identify which service actually sends the reply
This guide applies to a Help Scout Inbox using your own address and sending through Help Scout’s servers. It does not apply unchanged to the default helpscoutapp.com address or to an Inbox that sends through your email provider using SMTP or OAuth. Record the chosen route before changing DNS; identical public From addresses can hide different transport dependencies. Help Scout SPF scope.
Assign the Inbox administrator and authoritative DNS owner. Save the current outgoing-email settings and relevant DNS answers. List every custom domain in use, including subdomains. A working root-domain configuration should not be assumed to cover a different subdomain. Plan a low-volume acceptance test before updating all support Inboxes or migrating a shared customer-facing address.
Use the current DKIM record design
For its own-server route, Help Scout documents two CNAME owners: strong1._domainkey.yourdomain.com and strong2._domainkey.yourdomain.com, pointing to matching strong1 and strong2 owners under _domainkey.helpscout.net. Replace the example domain with the actual sending domain. Configure Cloudflare records as DNS only. DKIM records.
Check how the DNS host handles relative names before saving. An editor that appends the zone should receive only the required relative owner, not a name that becomes duplicated. Inspect existing data at both owners and resolve any collision deliberately. Keep a record of the previous configuration and the time of the change. Do not delete other services’ selectors merely because this integration introduces new ones.
In Settings > Inboxes > the selected Inbox > Outgoing Email, use Test Settings and look for Active DKIM status. Help Scout also offers a documentation-page checker. If the result remains unsuccessful after propagation, inspect the actual CNAME answers and exact targets. Verification and troubleshooting.
Do not restore the retired SPF include
Help Scout’s change documented for 2024 removed the requirement to authorize its service in the customer’s SPF record for this route. It uses a provider-domain variable envelope return path, so SPF can pass without aligning to the customer From domain. Its documentation allows removing the old include:helpscoutemail.com entry. Customer-domain DKIM supplies the aligned authentication path instead. Current SPF requirements.
Review removal as a scoped cleanup: preserve other legitimate includes, IP authorizations and the existing terminal policy. Do not delete the entire SPF record. A historical DNS checker that recommends the retired token is not stronger evidence than the current route-specific documentation. For SMTP or OAuth delivery, follow the actual email provider’s requirements rather than applying this Help Scout-hosted exception.
DMARC succeeds through at least one passing aligned path. A valid but unrelated provider-domain signature is insufficient for customer-domain alignment. Compare the received signing domain with the visible From, taking the domain’s strict or relaxed alignment settings into account. Keep enforcement changes separate from this integration so a support-mail issue does not unnecessarily affect unrelated business mail. DMARC.
Confirm a customer reply at the destination
Original acceptance worksheet, not observed results: send a harmless response from the configured Inbox to a controlled external recipient. Record the Inbox, configured route, time, visible From domain, Return-Path, trusted SPF result and evaluated domain, all DKIM d= and s= pairs, and the trusted DMARC result. Repeat for each distinct sending domain. Check that a customer’s reply returns to the intended conversation as a separate functional test.
For the Help Scout-hosted route, an SPF pass with an unaligned provider envelope is not a failure of the documented design. The important question is whether an aligned DKIM signature passes and the receiver reports DMARC success. If DKIM passes for another domain only, revisit the selected sending route and custom-domain configuration rather than adding speculative SPF entries.
If a new rollout fails, pause further Inbox changes and preserve the previously working configuration where available. Retain DNS answers, received headers and timestamps for support. This guide reports documentary findings, not a completed installation: no live Inbox, DNS publication or received message was tested.
Route acceptance record
Complete this proposed worksheet with real evidence; blank fields are not passes.
- Account, sender domain, exact workflow and responsible owner: ____.
- Provider-approved record design and dated instructions: ____.
- Existing SPF/DMARC policy and preserved selector dependencies: ____.
- Authoritative owner/type/value answers and observation time: ____.
- Actual From, envelope, all signing domains/selectors and receiver results: ____.
- Reply destination and controlled functional result: ____.
- Unresolved scope, rollback trigger and human approval: ____.
Live account and message checks, visual inspection and owner/SME approval remain open publication gates.