Help Scoutの​SPF・DKIM・DMARC設定。

Help Scoutを認証すべき理由

GoogleとYahooは現在、認証されていないメールを拒否するか、迷惑メールフォルダーに振り分けています。Help Scout自身も、1日あたり5,000通以上を送信するドメイン（Help Scoutだけでなくすべての送信元の合計）にはDMARCレコードが必要だと案内しています。DKIMのCNAMEがないと、Help Scoutのサーバーから送った返信には、自社ドメインの「on behalf of」（代理）としてhelpscout.netの署名しか付きません。Fromアドレスとアライメントが一致する署名がないためDMARCに失敗し、迷惑メールに振り分けられるかバウンスします。その結果、到達率とサポートアドレスの送信者レピュテーションの両方が損なわれます。

Help ScoutにおけるSPFの実情

Help Scoutは珍しいケースで、SPFのincludeの追加を求めておらず、追加してもDMARCには何の効果もありません。Help Scoutのサーバーから送信する場合、SMTPエンベロープのreturn-pathは、Help Scoutが所有するドメイン上のVERP（variable envelope return path）アドレスになります。従来のSPFのincludeが許可していたのと同じhelpscoutemail.comです。そのためSPFはHelp Scoutのドメインに対して評価され、Help Scout側で成功しますが、そのドメインはFromドメインではないのでSPFの「アライメント」は一致しません。つまり、この方法で送るメールでは、SPFがDMARCの条件を満たすことはありません。DKIMのCNAMEが重要なのはまさにこのためです。DKIMは自社ドメインとして署名し、Help Scoutから送信するメールでDMARCのアライメントを一致させる唯一の手段です。以前にinclude:helpscoutemail.com（または同様のHelp Scoutのメカニズム）をSPFレコードに追加した場合は、削除してください。Help Scoutも、これは従来方式で今は不要だと明言しています。自社のメールボックスサービス（Google Workspace、Microsoft 365など）用の既存のSPFレコードはそのままで、Help Scoutが追加するものはありません。唯一の例外は受信トレイをCustom SMTPまたはGoogle OAuthに切り替えた場合で、メールは利用中のサービスのサーバーから送信されるため、Help ScoutのCNAMEではなく、そのサービスのSPFとDKIMが適用されます。

設定手順

追加するレコード

正確な値はHelp Scoutのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。

DNSルックアップの10回制限

SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Help Scoutの設定がこの上限のうち何回を消費するかは、次のとおりです。

正しく設定できたか確認する

確認は2段階で行います。まずHelp Scout内で、DNSの反映後に受信トレイのOutgoing EmailセクションにあるTest Settingsをクリックし、DKIMのステータスがActiveと表示されることを確認します。次に、アライメントを実際に確かめます。受信トレイから自分が管理するメールボックスに返信を送り、メールの生データを開いてAuthentication-Resultsを確認します。dkim=passでheader.d=yourdomain.com、そしてdmarc=passとなっていれば成功です。別途、2つのCNAMEがhelpscout.netに解決されること（MX ToolboxなどでのCNAME検索）を確認し、_dmarcのTXTが正しく解析されることも外部のSPF/DKIM/DMARCチェックツールで確認してください。Help Scoutのステータス表示だけに頼らないでください。確認できるのはレコードが解決されることだけで、DMARCのアライメントがエンドツーエンドで一致していることまではわかりません。

よくある注意点

• DNS設定

  プロキシが有効なCNAMEでは、気付かないうちにDKIMが機能しなくなります。DNSホストがトラフィックをプロキシしている場合（CloudflareのオレンジのクラウドまたはCDNプロキシ）はオフにし、strong1._domainkeyとstrong2._domainkeyの両方をDNS onlyに設定してください。プロキシが有効なレコードはhelpscout.netではなくプロキシに解決され、Test SettingsはいつまでもActiveになりません。

• DNS設定

  Hostフィールドにドメイン全体を貼り付けないでください。GoDaddy、Cloudflare、Namecheapはドメインを自動で付加するので、strong1._domainkey / strong2._domainkeyだけを入力します。レコードがstrong1._domainkey.yourdomain.com.yourdomain.comになると解決されません。cPanel系のホストは逆で、値の末尾にドットが必要です。

• 認証失敗の原因

  Help ScoutのSPFは手順ではなく、むしろ罠です。include:helpscoutemail.comを追加してもDMARCには効果がありません。Help ScoutのVERPのreturn-pathは自社ドメインではなくHelp Scoutのドメイン上にあるため、SPFに成功してもアライメントは一致しません。Help Scoutも、includeが残っていれば削除してDKIMに頼るよう案内しています。

• DNS設定

  1つ目だけでなく、両方のCNAMEを追加してください。strong2._domainkeyは鍵のローテーションに使われます。これがないと、次にHelp Scoutが鍵をローテーションした際に署名が失敗することがあり、数週間後、気付かないうちにメールがDMARCに失敗し始めます。

• DNS設定

  DKIMの委任はドメイン単位ですが、「Use Help Scout」の設定は受信トレイ単位です。2つのCNAMEはそのドメインのすべての受信トレイをカバーしますが、新しい受信トレイではOutgoing EmailをUse Help Scoutに切り替えて再テストする必要があります。DNSはすでに設定済みなので、変更するのは受信トレイの設定だけです。

• DNS設定

  受信トレイをCustom SMTPまたはGoogle OAuthに切り替えると、前提がすべて変わります。メールは利用中のサービスのサーバーから送信されるため、そのサービスのSPFとDKIMがアライメントを一致させ、Help ScoutのCNAMEは署名に使われなくなります。切り替えた後は認証を再確認してください。

• DNS設定

  DNSの反映の遅れによって、誤って失敗と判定されることがあります。CNAMEの反映には最大24～48時間かかることがあります。Test Settingsをクリックする前に少なくとも1時間待ち、DKIMがActiveと表示されてレポートでアライメントの一致を確認するまでは、DMARCをquarantine/rejectに引き上げないでください。

• 適用範囲

  デフォルトの…@helpscoutapp.comアドレスでは、この設定は一切不要です。DKIMの委任が関係するのは、Help Scoutのサーバーから独自ドメインで送信する場合だけです。Help Scoutに組み込みの受信トレイアドレスのみを使っているなら、設定するものはありません。

SPFレコードを作成

Help Scoutでは、ルートドメインにSPFのinclude:を追加する必要はありません。作成ツールを使って他の送信元用のクリーンなレコードを1つ組み立て、1行に収めてください。

Help ScoutのSPFに関するよくある質問

関連記事

ヘルプデスク・CRMの他のサービス

• HubSpot
• Intercom
• Pipedrive
• Salesforce
• Zendesk
• Zoho CRM
• Zoho Desk
• Freshdesk

公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。