ドキュメントExperience Cloud KCS

SendGridを使用したAdobe Commerce on Cloud インフラストラクチャでの送信メールのDMARC エラーのトラブルシューティング

最終更新日： 2026年10月30日

ストアからの送信メール（注文の確認、パスワードリセット、Adobeの組み込みのSendGrid統合を介して送信された類似のトランザクションメール）がDMARC チェックに失敗した場合、迷惑メールとしてマークされた場合、受信者メールサーバーによって拒否された場合、2つの考えられる原因があります。 DNSを変更する前に、どのDNSが適用されるかを確認してください。

説明 description

環境

  • Adobe Commerce on Cloud インフラストラクチャ（任意のバージョン）。Adobeの組み込みのSendGrid統合を介して送信メールを送信します。このSendGrid サブアカウントは、Cloud プロジェクト用に自動的にプロビジョニングされ、サポートケースを介してDKIM/SPF ドメイン認証が要求されます。 この記事は、独自のSendGrid アカウントを使用してメールを送信する場合、またはAdobeを通じてプロビジョニングされていない他のSMTP/メールプロバイダーを使用する場合は適用されません。代わりに、DKIM/SPF/DMARCをそのプロバイダーに直接設定します。
  • DKIM/SPF ドメイン認証（したがって、このDMARC トラブルシューティングパス）は、実稼動環境とステージング環境でのみPro プロジェクトで使用できます。 スターター環境ではサポートされていません。スターターの配信品質は本質的に制限されており、このパスを介して利用可能なDNS ベースの修正はありません。

問題/症状

開始する前に：これは実際に認証の問題であることを確認してください。

DMARC モニタリングと並行して報告されるすべての配信エラーがDMARC/DKIM/SPFによって引き起こされるわけではありません。受信者の側のバウンス（メールボックス全体、グリーリスト、IP スロットリング）は、レポートでは似ていますが、ドメイン認証とは関係ありません。 このガイドが当てはまると仮定する前に、SendGrid アクティビティフィードで特定のバウンス/ブロックの理由を確認してください。

  • DMARC関連のエラーにより、送信メールがバウンスまたは拒否される
  • Microsoft/OutlookおよびGoogleがホストする受信者ドメインを中心に、迷惑メールとして配信される電子メール

各症状の確認方法

DMARC関連のエラーによるバウンスまたは拒否： メールクライアントでバウンスまたは拒否されたメッセージの生のソースを開き、Authentication-Results ヘッダーを確認します。

例：

Authentication-Results: mx.google.com;
       dkim=fail;
       spf=fail (google.com: domain of bounce@mail.adobe.com does not designate XXX.XXX.XXX.XXX as permitted sender);
       dmarc=fail (p=REJECT sp=REJECT dis=REJECT) header.from=adobe.com

検索対象：このヘッダーのdmarc=fail件の結果は、拒否がDMARC関連であり、関連のないバウンス（メールボックス全体、グレイリスト、IP スロットリング）ではないことを確認します。

解決策 resolution

問題を解決するには、次の手順に従います。

手順1：ドメインが既にDMARC レコードを公開しているかどうかを確認する

これを実行して、ポリシーが既に存在するかどうかを確認します。

dig TXT _dmarc.yourdomain.com +short

検索対象： ポリシーが存在する場合、v=DMARC1;で始まる引用符で囲まれたTXT値が返されます（例："v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com"）。 コマンドが何も返さない場合、そのドメインに対してDMARC レコードは公開されません。 検証済みの例：_dmarc.adobe.comをクエリすると、現在は何も返しません。つまり、adobe.comには公開されたDMARC レコードがありません。

シナリオ A: DMARC レコードが既に存在します（最も一般的）

レコードが返された場合、ドメインには既にDMARC ポリシーがあります。通常、Adobe Commerceとは関係なく、組織のIT部門またはセキュリティ部門によって個別に設定されます。 この場合、DMARCの失敗は、ほとんどの場合、SendGridのドメイン認証（DKIMとSPF）が送信ドメイン用にまだ設定されていないか、調整されていないことを意味しますが、DMARC レコード自体に何も問題があるわけではありません。

解決策：既存のSendGrid メールサービスのドキュメント ​に従って、サポートケースを介してDKIMとSPF ドメインの認証をリクエストします。 SendGridのDKIM/SPF レコードがDNSに正しく追加され、送信ドメインにアラインメントされると、既存のDMARC ポリシーが渡され始めます。DMARC レコード自体は変更する必要はありません。

DNS レコードの値は、時間の経過とともに変化する可能性があります。古いサポート ケースまたは内部ドキュメントからCNAME/TXT値を再利用しないでください。 SendGrid サブアカウントの割り当ては再発行できるため、過去に正しかったレコードが現在のSendGrid設定と一致しなくなる可能性があります。 過去の値を再適用するのではなく、新しいサポートケースを通じて常に現在の値をリクエストします。

これがステージング環境または実稼動以外の環境である場合： SendGridはステージング環境と実稼動環境に対してデフォルトで有効になっていますが、DKIM/SPF ドメイン認証は実稼動環境でのみ一般的に要求され、ステージング環境ではフォローアップされません。 数ヶ月間機能するように見える（寛大なDMARCポリシーまたは欠席ポリシーに乗っている）場合、組織がDMARCの適用を強化するとすぐに失敗する可能性があります。 実稼動環境が正常である間にステージングでエラーが発生した場合のみ、ステージング環境に対してDKIM/SPF認証を具体的に要求してください。実稼動環境のリクエストで既にカバーされていると思い込まないでください。

DKIM/SPF レコードが反映されていることを確認します

DKIM/SPF ドメイン認証が要求され、適用されたら、レコードが実際にDNSに反映されていることを確認してから、DMARCの整合性を再テストするか、ケースを再度開きます。 SendGridのドメイン認証は、送信サブドメイン用に3つのCNAME レコードを公開します。1つはリンクブランディング用（em）で、2つはDKIM署名キー（s1._domainkey、s2._domainkey）です。

dig CNAME em.yourdomain.com +short
dig CNAME s1._domainkey.yourdomain.com +short
dig CNAME s2._domainkey.yourdomain.com +short

検索対象：各コマンドは、.sendgrid.net.で終わるCNAME ターゲットを返す必要があります。コマンドが何も返さない場合、そのレコードはまだ追加されていないか、伝播されていません。 検証済みの例：s1._domainkey.adobe.comおよびs2._domainkey.adobe.comをクエリすると、次が返されます。

s1.domainkey.uXXXXXXX.wlXXX.sendgrid.net.
s2.domainkey.uXXXXXXX.wlXXX.sendgrid.net.

この例のem.adobe.comに対して同じチェックで返される空の結果は、特定のレコードが設定されていないことを意味します。 以前のDKIM/SPF リクエストに含まれていると仮定するのではなく、明示的にリクエストしてください。 レコードが追加されてから24～48時間後にまだ解決しない場合は、新しいレコードを開くのではなく、既存のサポートケースをフォローアップしてください。

シナリオ B: DMARC レコードが存在しない

上記のコマンドが何も返さない場合、ドメインにはDMARC ポリシーがまったくありません。 この場合、シナリオ AごとにDKIM/SPFを設定することに加えて、DMARC レコードも公開する必要があります。 実行ではなく監視モードで開始：

_dmarc.yourdomain.com   TXT   "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=100"
  • p=none - モニターのみ。メール配信には影響しません。 ここから始めましょう。
  • rua=mailto:... – 集計レポートが送信される場所。ストアフロントの送信アドレスではなく、実際に監視するメールボックスを使用します。
  • 数週間レポートを確認し、正規のメール （SendGridを含む）が調整を通過していることを確認したら、p=quarantineに移動し、最終的には p=reject に移動します。

独自の正規のメールパスを確認する前に、p=quarantineまたはp=rejectに直接ジャンプしないでください。これにより、独自のトランザクションメールが受信者サーバーによってサイレントに拒否される可能性があります。

関連トピックス

recommendation-more-help
experience-cloud-kcs-help-kbarticles