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:の各ステートメントはスペースで区切る。
• 任意のドメインまたはサブドメインに対して、include:ステートメントを10個まで追加できる。
• SPFのバージョン（v=spf1）を指定する必要があるのは、レコードの最初に1回だけ。
• -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フラグは、ポリシーを適用する、認証に失敗した一意の送信の合計の割合を指定するために使用されます。指定する値は数値でなければならず、その他の文字は全て除外する必要があります（つまり、%記号を含めることはできません）。