Marketing Cloud Engagement からの送信メールで、突然SPF/DKIM等の認証エラーが発生した際の確認ステップとよくある要因

お問合せ時に必要な情報

DKIMやSPFの認証失敗（Fail）を確認した場合、お問い合わせ前に以下の3点を行ってください。

1.複数のドメインへのテスト送信 特定の宛先だけでなく、Gmail、Outlook.com などの個人向けメールサービスを含む複数の宛先へテスト送信を行ってください。（このとき、企業のメールアドレスへの送信テストのみをもって判断しないことを推奨します）

　　確認すること: 　Fail は「すべての宛先」か、「特定のドメインだけ」か

2.メールヘッダー全文の取得（Fail時） 認証エラー（Fail）になったメールの「メールヘッダー（またはソース）」の全文を取得してください。メールアドレスや件名などの個人情報はマスクすることを推奨します。

3.比較用ヘッダーの取得（Pass時） 比較調査のため、以下などの認証がOKになった場合のヘッダーも可能な限り取得してください。

• • 同じドメインで過去に成功（Pass）したメールのヘッダー

  • 別のドメインで成功（Pass）したメールのヘッダー

注意：企業メールサービスへのテスト送信による切り分けが非推奨な理由

サポートへお問い合わせいただく際、企業のメールアドレス宛のテスト結果（ヘッダー）の一部のみをご提示いただくケースが多くあります。
企業のメール環境では、セキュリティ対策（ウイルスチェックやリンク書き換え）によってメールの中身が変更されることがあります。 
DKIM署名は「送信時から指定した文字列が変更されていないこと」を保証するものです。受信側のセキュリティ製品が必要な部分を少しでも書き換えると、Marketing Cloud側の設定が正しくても認証エラーになります。

一方、個人向けメールは基本的にメールをそのまま受信するため、純粋にMCE側の設定が正しいかを確認するのに適しています。故に複数の個人用メールサービスを利用して確認することを推奨しています。

詳細な手順と切り分け

上記のアクションが必要な理由と結果の判断基準を解説します。

1.テスト結果による判断の方針:

• 「特定の企業ドメイン」でのみFailする場合: MCEの設定が正常なケースが多くを占めます。受信側のセキュリティ製品や転送設定が原因である可能性が高いです。

• 複数の個人向けメールも含めて、ほぼすべてでFailする場合: MCEのMTAサーバー等の設定やDNSレコード（SPF/DKIM）そのものに問題がある疑いがあります。DNSの設定状況（委任やSPF/DKIMのレコードが解決できること）を確認のうえ、問題がみられない、判断が難しい場合は詳細を添えてサポートへお問い合わせください。

2. メールヘッダーの簡易チェックポイント

取得したヘッダーを見ることで、エラーの原因をある程度ご自身で絞り込むことができます。

SAP/PrivateドメインのDNS設定が正しく行われている場合、Failの主な原因は受信側（または中継経路）にあります。企業のメールアドレス宛であれば受信側のシステム管理者へ、個人向けメールであればメールの転送設定などを行っていないか受信者自身にご確認ください。

A. SPFが Fail している場合

ヘッダー内の認証結果付近（Authentication-Results: など）に記載されたIPアドレスを確認してください。これがMCE のIPアドレスではなく、自社のゲートウェイや中継サーバーのIPになっていないか確認します。その中継サーバーがメールを「転送」したことで、送信元が変わったとみなされSPFが失敗しています。

B. DKIMが Fail している場合

途中でメールの中身が書き換えられています。 企業のセキュリティゲートウェイが、DKIM検証に必要なデータを書き換えたりすることが疑われます。これが行われるとDKIM署名と中身が一致しなくなり、エラーになります。

C. 転送の形跡がないか（Receivedヘッダー）

Received: という行を下から順に追っていくと、送信者から受信者までのメールの経路がわかります。 
特定のクラウドサービスや自社MTAサーバー、その他のセキュリティサービスを経由していてその過程で SPF やDKIMのための情報が失われることがあります。
受信者の設定でメールの転送を行なっていると、送信元がMCE ではなく受信者のメールサービスとなっているケースなどもあります。メールが転送されると、通常は認証が壊れやすくなります。
これを防ぐには「誰が転送したか」を証明する情報（ARCヘッダーなど）が必要ですが、これがないまま転送されると、最終的な受信側は「なりすまし」と疑ってエラーにします。
こちらは基本的に受信側のサービスで対応する必要があります。