Help Scout SPF, DKIM and DMARC setup, step by step

When a Help Scout inbox sends from your custom address through Help Scout servers, publish Help Scout's two DKIM CNAMEs and run Test Settings until DKIM is Active. You do not need the former include:helpscoutemail.com SPF entry for this route. Help Scout's envelope domain passes SPF but does not align with your custom From domain, so aligned DKIM is the important DMARC path. Current SPF requirements

The instructions below apply to Help Scout's customer-support email, not DNS hosting or a standalone SMTP service. A custom address sent through Google OAuth, Microsoft 365 Outlook OAuth or another SMTP server uses that external provider's authentication instead.

On this page

• Identify the inbox's actual sender
• Prerequisites and plan checks
• Publish the two documented DKIM CNAMEs
• Activate and verify in Help Scout
• What to do with an old Help Scout SPF include
• Why SPF pass can coexist with DMARC failure
• Run a public DNS and delivered-message acceptance test
• Troubleshooting
• Frequently asked questions
• Documentary review and next step

Identify the inbox's actual sender

Open Settings > Inboxes > select the inbox > Outgoing Email and record which option is active. The inbound forwarding destination does not establish the outbound sender. Outgoing email settings

This distinction matters when troubleshooting a mixed organization. One inbox can use Help Scout while another uses Microsoft 365. Do not conclude that a passing test from one authenticates every inbox sharing the same visible domain.

For an inbox using Microsoft 365 instead, follow the Microsoft 365 authentication guide; those settings do not replace Test Settings for Help Scout-managed sending.

Prerequisites and plan checks

First configure the inbox to use the custom email address. The Account Owner or an Administrator with permission to that inbox can adjust Outgoing Email. You also need access to the authoritative DNS zone and a receiving test mailbox. Access prerequisites Review the current plan and account controls before changing transport; the reviewed SPF, DKIM and outgoing-settings pages do not establish a universal paid-tier requirement for DKIM or guarantee every external connection on every account. Missing controls are a reason to verify entitlement, not to invent DNS values.

Inventory each inbox, outgoing route and From domain. Save existing SPF, DMARC, DKIM and MX records with their TTLs. Include a parent domain's DMARC policy when the From address uses a subdomain. Preserve unrelated services and know who can approve any collision at a DKIM owner.

You do not need to generate a private DKIM key for the Help Scout-managed route. The provider operates signing; the customer publishes aliases that let receiving systems locate its public keys. Do not paste private keys, passwords or OAuth tokens into DNS. Help Scout DKIM design

Publish the two documented DKIM CNAMEs

For a From address at example.com, the current official records are:

Replace example.com with the exact domain used by the custom sending address. Unlike tenant-specific record generators used by some platforms, Help Scout currently documents these provider targets publicly. Keep the documented strong1 and strong2 selectors; do not rename them arbitrarily. Compare the current Help Scout instructions and your selected inbox before publishing. Official record values

For support@service.example.com, the full owners are under service.example.com, not automatically the root domain. If DNS for that subdomain is delegated, publish at its authoritative host. Merely adding records to a registrar's inactive DNS panel does not make them public.

For an issued signing domain such as service.example.com, the illustrative full owner is strong1._domainkey.service.example.com. In an editor relative to the parent example.com zone use strong1._domainkey.service; in a separately delegated service.example.com zone use strong1._domainkey; in a delegated _domainkey.service.example.com zone use only strong1. Repeat for strong2 and retain both documented CNAME targets. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

Follow the DNS editor's naming rules. Some accept strong1._domainkey; others expect the full name. Check the resulting owner rather than guessing. The target is a hostname, not an HTTPS URL or TXT public-key string. Keep both aliases DNS-only on Cloudflare. If an ordinary TXT, A, AAAA or other record already occupies an owner, stop and resolve the dependency instead of replacing it blindly. A CNAME owner cannot carry unrelated ordinary record data.

The two records support the provider's signing design. Keep both even if the first delivered message uses only one selector. Do not remove the second because a single sample did not exercise it.

On Cloudflare, also leave flattening off for authentication aliases, including any zone-wide flatten-all-CNAME setting. DNS-only alone is insufficient if flattening hides the requested CNAME answer. Cloudflare verification guidance

Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.

Activate and verify in Help Scout

After the DNS records are public, return to the chosen inbox's Outgoing Email page and select Test Settings. The expected application result is Active beside DKIM. If it remains inactive, inspect the public CNAME answers and retry after caches expire. The official troubleshooting page suggests rechecking after an hour, but propagation depends on the actual TTLs and resolver caches. Verification workflow

Record the domain, inbox, observed status and time. A provider status confirms its configuration check; it does not prove a newly delivered message used the intended route or aligned with your DMARC policy.

What to do with an old Help Scout SPF include

Help Scout's pre-2024 custom-address workflow required an SPF entry. The current managed route uses a variable envelope return path on Help Scout's servers. Official guidance permits removing the old include:helpscoutemail.com authorization. Remove only that obsolete mechanism after confirming the affected inboxes use the documented route. Preserve all other senders and the existing final all policy. Never delete the whole SPF record because Help Scout no longer needs its own root-domain entry. SPF change notice

For example, if an existing policy authorizes Google Workspace and Help Scout, the intended cleanup removes the Help Scout mechanism, not Google's. Do not copy a sample policy onto a domain with additional senders. If a different SMTP provider is selected, follow that provider's current requirements rather than applying this removal as a universal rule.

SPF evaluates the SMTP MAIL FROM domain, normally visible in Return-Path, rather than the visible From address. Maintain one SPF policy per DNS owner. When adding authorizations for other senders, check the ten evaluated DNS-querying-term limit, including nested mechanisms. Counting the includes visible in the top-level TXT value is insufficient. SPF standard

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

Why SPF pass can coexist with DMARC failure

A Help Scout envelope domain can authenticate successfully while differing from your visible From domain. That does not make SPF broken. It means SPF is not the aligned identifier for this route. DKIM must pass with an aligned d= signing domain if DMARC is to pass through DKIM.

DMARC requires either aligned SPF or aligned DKIM, not both. Relaxed alignment permits matching organizational domains; strict alignment requires the exact domain. Evaluate the actual From and DKIM d= under your existing adkim policy. A passing signature from helpscout.net is not an aligned signature for example.com. DMARC specification

Keep an existing quarantine or reject policy. Do not lower it to p=none just to suppress delivery failures. For a genuinely new deployment with no established policy, plan monitoring and enforcement around every legitimate sender and inherited policy. Maintain one applicable DMARC record at each policy owner and preserve authorized reporting destinations.

First inspect the direct TXT policy at _dmarc.YOUR-FROM-DOMAIN and any applicable inherited policy. Only absent both, with owner-approved monitoring, an illustrative first TXT value is v=DMARC1; p=none. It requests no reports unless an authorized monitored rua destination is added. For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.

RFC 9989 supersedes RFC 7489 and removes pct, so do not use percentage enforcement as the rollout mechanism. Review aggregate reports under RFC 9990. Failure reports can expose message information; consider privacy and recipient authorization before enabling them under RFC 9991.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Run a public DNS and delivered-message acceptance test

For a domain you administer, replace example.com below:

dig +short CNAME strong1._domainkey.example.com
dig +short CNAME strong2._domainkey.example.com
dig +short TXT strong1._domainkey.helpscout.net
dig +short TXT strong2._domainkey.helpscout.net
dig +short TXT _dmarc.example.com

The two CNAME queries should return their corresponding documented targets. The target lookups should resolve usable public DKIM data. Check authoritative and recursive answers if Help Scout still reports a mismatch. Do not treat an empty response or DNS timeout as a pass.

Next, send a fresh reply and a new conversation from the configured inbox to a mailbox you control. Inspect the recipient's trusted Authentication-Results, visible From, Return-Path and DKIM-Signature. Record the selector s= and signing domain d=. For Help Scout-managed custom-address sending, expect SPF to authenticate the provider's envelope domain and DKIM to authenticate an aligned customer domain, producing dmarc=pass. This is an acceptance expectation, not a test performed for this manuscript. Receiver-result interpretation

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

Repeat for another inbox or sending subdomain rather than extrapolating. Test external OAuth/SMTP routes separately. Keep a redacted evidence row for each combination: inbox, transport, From, envelope domain, DKIM domain, authentication results and timestamp. A forwarded copy can have different SPF behavior, so distinguish direct and forwarded tests. Authentication success cannot guarantee placement in the primary inbox.

Investigate an actual spf=fail, permerror or temperror even if aligned DKIM makes DMARC pass. Check the observed envelope owner, authorized sender, evaluated lookup limit and DNS availability. A DMARC pass does not turn a broken SPF path into a healthy configuration.

At the actual observed envelope domain, diagnose SPF authorization fail or softfail separately from transient evaluation temperror (often DNS) and invalid-policy, duplicate-policy or lookup-budget permerror. Investigate each even when aligned DKIM supplies DMARC; do not add authorization at an unrelated apex to conceal the error. SPF result definitions.

Troubleshooting

If both CNAME owners are correct publicly but Help Scout remains inactive, give support the domain, DNS host, exact public answers and time of the check. Do not send private keys or OAuth credentials in a support screenshot.

Documentary review and next step

No authenticated account, customer DNS or delivery was tested, and no content was published. An EmailAuth review should connect the inbox setting to public DNS and receiver evidence, with no ranking or inbox-placement guarantee.