Eメール認証の問題のトラブルシューティング

HubSpotでEメール認証を設定しているときに問題が発生した場合は、以下のセクションのステップに従って、よくあるSPFとDMARCの問題を修正できます。

SPFのトラブルシューティング

SPFを正しく設定するには、DNSプロバイダーにTXTレコードを追加し、HubSpotのinclude文をコピーする必要があります。よくあるSPFの設定エラーについて、以下のセクションで詳しく説明します。

複数のSPFレコード

HubSpot以外のEメールプロバイダーでもEメールを送信している場合、DNSプロバイダーに別のSPFレコードがすでに設定されている可能性があります。この場合、同じTXTレコードの既存の include: 文の後にHubSpotのSPFレコードを追加できます。

以下に、GoDaddyのようなプロバイダーを使用していてTXTレコードに複数のSPFを設定する場合の例を示します。

複数のSPFレコードを組み合わせる際には、以下の点に注意してください。

• 各 include: ステートメントはスペースで区切る必要があります。
• 任意のドメインまたはサブドメインに対して最大 10 個の include: ステートメントを使用できます。
• SPFバージョン(v=spf1)は、レコードの先頭に一度だけ指定する必要があります。
• -allフラグは一度だけ入れる必要がある。このフラグは、SPFレコードに記載されているサーバーだけが、そのドメインを代表してEメールを送信することを許可されていることを示します。リストにないサーバーからのEメールは拒否されることになります。

ハードコーディングされたIPアドレス

Eメール送信ドメインの設定ページに表示されるHubSpotのSPFレコードは、ご使用のアカウントのEメール送信元となる全てのIPアドレスを自動的に取得するように作成されています。そのため、設定が完了したら、DNSプロバイダーでレコードを更新する必要はありません。

SPFレコードに、他のEメール サービス プロバイダーからのハードコーディングされたIPアドレスが含まれている場合、SPF認証でエラーが発生する可能性があります。SPFレコードにIPアドレスやCIDRをハードコーディングすることは、ベストプラクティスとはみなされません。SPFレコードにハードコーディングされたアドレスまたはCIDRがある場合：

• SPFレコードの内容を監査し、ハードコーディングされたHubSpot IPアドレスまたはCIDRを全て削除します。こちらの 記事 の手順に従い、相互参照に使用できるHubSpotの送信先アドレスとCIDRのリストを見つけることができます。
• 他にもハードコードされたEメールアドレスを管理する必要がある場合（別のサードパーティーEメールサービスプロバイダーを利用している場合など）、HubSpotのinclude:ステートメントをハードコードされたEメールアドレスの最後に追加し、その後に-allフラグを追加してください。構文は、プレースホルダー（仮挿入）値を持つ以下のSPFレコードの例を参照してください。

v=spf1 ip4:.../24 ip4:.../24 include:123456.spf01.hubspotemail.net -all

DMARCのトラブルシューティング

DMARCレコードは、SPFおよびDKIMチェックに失敗した、ご使用のドメインのEメールをEメール事業者でどのように処理するかに基づいてカスタマイズできるTXTレコードで構成されます。以下のセクションでは、よくあるDMARCの設定の問題について概説します。

複数のレコード

DMARCが適切に設定されていることを確認するために、バージョンフラグで始まるTXTレコードを1つだけ持つべきである（すなわち、v=DMARC1）。複数のDMARCレコードが存在する場合、受信Eメールサーバーは即座にポリシー検出プロセスを終了し、DMARCポリシーは適用されません。

必要なDMARCタグの不足

いくつかのDMARCポリシータグはオプションであるが、バージョンとポリシータグを指定しなければならない（例：v=DMARC1; p=YOUR_POLICY_VALUE;）。

全ての利用可能なDMARCタグおよびそれらに定義できる値は、Eメール認証の概要で確認できます。 

無効なDMARCポリシー値

HubSpotでEメール送信ドメインを設定中に、Invalid DMARC policyエラーが表示された場合、pまたはspタグのポリシー値が無効であることが原因である可能性があります。有効な値はnone、reject、quarantineのいずれかである。これらの値では大文字と小文字が区別され、小文字である必要があります。

無効なレポート送信先アドレス

rufおよびruaタグは、DMARC 報告データを送信する E メールアドレ スを指定するためのオプションパラメーターです。いずれかのタグに値を指定した場合、指定したEメールアドレスは有効で、適切な形式である必要があります。

• 提供するEメールアドレスはURI mailto形式でなければなりません。この場合、Eメールアドレスの前にmailto:（例：mailto:reporting@example.com）を付ける必要があります。
• ruaとrufの両タグは、カンマで区切られている限り、報告用の複数のEメールアドレスをサポートしています。以下の例では、レポート送信用に2つの異なるEメールアドレスを指定しています。

• ruaまたはrufタグに有効な値はEメールアドレス（またはアドレス）のみです。ドメイン名（例：rua=example.com）のみを記載した場合、、有効とはみなされません。

無効なDMARC位置合わせモード

adkimとaspfフラグは、DKIMとSPFのアライメント モードを指定する。リラックスしたアライメントの場合は、両方のフラグをrに設定する。ほとんどのDNSサービスでは、これがDMARCのデフォルトの設定になっているはずです。

無効なDMARCパーセンテージ形式

pctフラグは、ポリシーを適用する、認証に失敗した固有の送信の合計の割合を指定するために使用されます。指定する値は数値でなければならず、その他の文字は全て除外する必要があります（つまり、%記号を含めることはできません）。