2026年、独立サイトの注文メールが迷惑メールに入ったら、まずSPFとDKIMのどちらを確認する？

RFC 9989は2026年5月に公開され、DMARCの標準文書を更新しました（RFC 9989）。ただし、これを理由に独立サイトの注文メールを自前のメールサーバーへ切り替える必要はありません。まず第三者メールサービスの送信ログで実際に送られたかを確認し、送信済みなら、そのサービスに指定されたSPF・DKIMとFromドメインの整合性、最後にDMARCポリシーを調べてください。認証に成功しても受信トレイへの到達は保証されません。

この手順は、注文確認や発送通知が届かないと連絡を受けた越境ECの運営者向けです。第三者メールサービスへの切り替え後にDNS設定を点検したい技術担当者や、複数ドメインのメール経路を管理する運用担当者にも役立ちます。

メール到達率とSPF・DKIMの確認順

「独立サイトの注文メールが迷惑メールに入ったら何から調べるか」という問いへの答えは、認証レコードではなく送信の有無です。WooCommerceの公式トラブルシューティングも、通知の生成、メール送信処理、配信、迷惑メール判定を別々の段階として扱っています（WooCommerceのメールトラブルシューティング）。

注文メールが送信済みと表示されるのに、顧客が受け取れない場合は？
注文画面の状態だけで配信済みと判断せず、サイトのメールログと第三者メールサービスの送信ログを照合してください。サービス側に記録があれば、宛先の拒否理由や認証結果を次に確認します。ログがなければ、通知の有効化やアプリ側の処理を先に調べます。

DNSの確認に進む条件

第三者メールサービスを使っているなら、サイトのサーバーがメールを直接届けていると決めつけないでください。WooCommerceの案内でも、外部のメールサービスを使う方法と認証設定が説明されています（メールサービス事業者の設定案内）。サービスごとのDNS指示は異なるため、別サービスの設定例をそのまま流用せず、現在使っている送信元と管理ドメインを特定します。

第三者メールサービスを使っていても、SPFとDKIMの設定は必要ですか？
必要かどうか、また必要な値は、サービス事業者の設定案内と実際の送信方式で確認します。独立サイトのDNSに、過去に使った送信元やほかの業務用メールの設定が残っている場合もあるため、今回のサービスだけを見て既存レコードを上書きしないでください。

Fromドメインと認証結果の読み合わせ

SPFは送信元の認可、DKIMはメール署名を検証する仕組みです。SPFが成功しても、表示されるFromのドメインとの整合性まで自動的に確認できたわけではありません。メールヘッダーでSPF・DKIMの結果とドメインを照合し、サービス事業者の設定案内も参照してください（WooCommerceのメール認証に関する説明）。

メールヘッダーの確認例

テストメールのヘッダーで、Authentication-Results、From、DKIM-Signatureを探します。以下は確認箇所を示す形式例であり、実際のドメインや結果を示すものではありません。

From: orders@example.test
Authentication-Results: ... spf=pass ... dkim=pass ... dmarc=fail
DKIM-Signature: ... d=signing.example.test; ...

この例ではSPFとDKIMが成功している表示でも、DMARCが失敗しています。Fromに表示されるドメインと、SPFで認証されたドメイン、DKIM署名内のd=ドメインをそれぞれ確認し、受信側が示す整合性の結果を見てください。SPFの仕様はRFC 7208、DKIMの仕様はRFC 6376で確認できます。

DMARCポリシーと受信側の判定

DMARCは、SPFまたはDKIMの認証だけでなく、認証されたドメインと利用者に見えるFromドメインとの整合性を確認する仕組みです。RFC 9989は2026年に公開されたDMARCの標準文書ですが、すべての受信サービスで一律に新しい必須要件が生じたという意味ではありません。自社ドメインの現在の設定と、対象サービスの公式要件を分けて確認します。

DMARCが通過しているのに、注文メールが迷惑メールに入るのはなぜですか？
DMARCの成功は、受信トレイへの振り分けを保証しません。受信側の判定、メール本文、送信サービス側の記録、受信者からの報告を合わせて調べてください。Gmailについては、一般の送信者と、Gmail宛てに1日あたり5,000通を超えて送信する送信者で、公式ガイドに示された要件が異なります。この条件を他の受信サービスにそのまま当てはめないでください（Googleの送信者向けガイド）。

症状から選ぶ次の対応

次の条件分岐で、アプリ、DNS、メールサービスのどこを調べるか決めてください。

• サービス側に送信記録がない場合：DNSを先に変更せず、注文状態、WooCommerceの通知設定、サイトのメールログを確認します。
• 送信記録があり、SPFまたはDKIMが失敗している場合：実際に使うサービスのDNS設定と、テストメールのヘッダーを照合してから該当レコードを修正します。
• SPF・DKIMは成功しているがDMARCが失敗している場合：From、SPF認証ドメイン、DKIM署名ドメインの整合性を確認し、DMARCレコードのポリシーと照合結果を見直します。
• 認証が通過していても拒否・隔離される場合：受信側の表示とサービス側の応答コードを記録し、第三者メールサービスのサポートへ共有します。認証レコードを根拠なく変更しないでください。

この順序なら、調査を次の手順で記録できます。

1. 注文状態と通知設定を確認します。
2. サイトのメールログで通知処理の記録を探します。
3. 第三者メールサービスの送信ログで、受理・拒否・配信状況を照合します。
4. テストメールのヘッダーからSPF、DKIM、DMARCの結果とドメインを記録します。
5. サービス事業者が指定するDNS値と現在のレコードを比較し、必要な変更だけを行います。
6. テスト注文を行い、異なる受信サービスの結果、発生時刻、注文状態、応答内容を記録します。

複数サイトを運用している場合は、ドメインごとに送信サービス、Fromアドレス、DNS設定、ログの保管先を記録すると、別サイトの設定を誤って適用するリスクを抑えられます。DNSの変更後は、各サイトの送信元を取り違えていないか確認してください。

サーバーの役割とメール送信の境界

サーバーの変更だけでメールの認証や受信側の判定が解決するとは限りません。共有環境ではCPUやメモリーを他の利用者と共有する場合があり、専用サーバーはそのリソースを分けて運用したい場面で比較対象になります。一方、どちらを選んでも、第三者メールサービスの設定やドメインDNSが正しくなければ、注文メールの到達は保証されません。

OSFP Cloudのサーバーを検討する場合も、メール送信・配信サービスそのものとは区別してください。サーバー移行の前後で確認する範囲は、OSFP Cloudのサービス提供範囲で確認できます。管理用の接続方法を先に把握したい場合は、サーバーへのシェル接続も参照してください。

Last updated: 2026年11月5日。 情報はGmailの送信者向けガイド、RFC 9989、WooCommerceのメールトラブルシューティングを基に確認しています。要件や文書が更新された場合は、各公式資料を再確認してください。

まず故障表に沿って、メール生成、第三者サービスの送信、ドメイン認証のどこで止まっているかを切り分けてください。サイトの実行環境も見直す段階なら、専用AMD物理サーバーは共有環境でのリソース競合を避けたい場合の比較候補になりますが、メールの認証や受信トレイへの到達を保証するものではありません。移行を検討する際は、メール経路を含む検証項目とサーバーの役割を分けて確認しましょう。