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

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

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

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

複数のSPFレコード

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

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

SPFレコードを組み合わせる場合は、次の点を考慮してください。

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

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

HubSpotのSPFレコードには、アカウントがマーケティングEメールとトランザクションEメールに使用する全てのIPアドレスが自動的に含まれます。Eメール送信ドメインでレコードを設定した後で、それ以上更新する必要はありません。

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

SPFレコードにハードコーディングされたアドレスまたはCIDRがある場合：

• SPFレコードの内容を監査し、ハードコーディングされたHubSpot IPアドレスまたはCIDRを全て削除します。詳しくは、HubSpotでの送信IPを確認する方法をご覧ください。 
• 他にもハードコードされたEメールアドレスを管理する必要がある場合（別のサードパーティーEメールサービスプロバイダーを利用している場合など）、HubSpotのinclude:ステートメントをハードコードされたEメールアドレスの最後に追加し、その後に-allフラグを追加してください。以下のSPFレコードの例に示されている構文をプレースホルダー値で使用できます。

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

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

DMARCレコードはTXTレコードで構成されます。このTXTレコードは、貴社のドメインから送信されるSPFおよびDKIMチェックに失敗したEメールを受信トレイプロバイダーがどのように処理するかに基づいてカスタマイズできます。以下のセクションでは、よくある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 フラグは、ポリシーが適用される認証に失敗した送信の総数(ユニーク)の割合を指定するために使用されます。指定する値は数値でなければならず、その他の文字は全て除外する必要があります（つまり、%記号を含めることはできません）。