SPF、DKIM、DMARCの説明：完全なメール認証ガイド（2026年）

メールには信頼性の問題があります。メッセージが実際に主張されているドメインから送信されたことを証明する組み込みの方法がないため、わずか数分の設定で、あたかも上司、銀行、またはビジネスから送信されたかのように見えるメールを送信できます。

SPF、DKIM、DMARCは、この問題を解決する3つのDNSレコードです。これらを組み合わせることで、受信メールサーバーに、どのサーバーがドメインからの送信を許可されているか、各メッセージが転送中に改ざんされていないか、そしてそれらのチェックのいずれかが失敗した場合にどうすべきかを伝えます。

このガイドでは、3つのプロトコルがどのように機能するか、それらがどのように連携するか、正しい順序で設定する方法、そして問題が発生した場合の対処法を解説します。2026年現在、これら3つすべてが、メールを送信するあらゆるビジネスにとって事実上必須となっています。Gmail、Yahoo、Microsoftはこれを直接強制しており、いずれかをスキップすると受信トレイへの配置率が低下します。

SPF vs DKIM vs DMARCの概要

とにかく早く知りたい場合は、この表で要点をまとめています。各プロトコルは他のプロトコルにはできないことを行うため、3つすべてを一緒に使用する必要があります。

WordPressメールを今すぐ修正する

30秒でわかる説明

パーティーでメール認証について説明するように求められたら、3文で説明できるバージョンはこちらです。

• SPFは、どのサーバーがドメインのメール送信を許可されているかを指定します。
• DKIMは、メールが転送中に誰かによって変更されていないことを証明します。
• DMARC は、SPFまたはDKIMが失敗した場合に受信サーバーに何を行うべきかを指示します：配信、迷惑メール送信、または拒否。

それぞれが他のものが欠落しているものを修正するため、3つすべてが必要です。

SPF、DKIM、およびDMARCはどのように連携して機能するか

メールがGmail、Outlook、またはその他の受信トレイに届くと、3つのチェックが順番に行われます。

まず、受信サーバーはメッセージが送信されたIPアドレスを取得し、SPFレコードを確認します。SPFレコードは、ドメインのメール送信を承認したサーバーのリストです。送信IPがリストにあれば、SPFはパスします。

次に、サーバーはメールに添付されたDKIM署名をチェックします。DKIMは送信時に適用される暗号署名であり、DNSには対応する公開鍵が含まれています。署名が鍵に対して検証されれば、DKIMはパスし、送信者と受信者の間でメールの内容が変更されていないことが証明されます。

次に、サーバーはDMARCレコードを確認します。DMARCは2つのことを伝えます：どちらのチェックがアラインメントして表示されるFrom:アドレスと一致する必要があるか、そしてどちらも一致しない場合に何を行うか。3つのオプションは、通常どおり配信、迷惑メール送信（検疫）、またはメッセージ全体を拒否することです。

「アラインメント」の部分が重要です。これがないと、攻撃者は表示されるFrom:行であなたのドメインを偽装しながら、自分のドメインのSPFをパスさせることができます。DMARCは、認証されたドメインを受信者が表示するものと一致させることを要求することで、そのギャップを閉じます。

SPFとは？

SPF（Sender Policy Framework）は、ドメインの代わりにメールを送信することを承認されたすべてのサーバーとサービスをリストするDNSのTXTレコードです。ドメインなりすましに対する最初の防御線です。

基本的なSPFレコードは次のようになります：

v=spf1 include:sendlayer.net ~all

内訳：

• v=spf1 は、これがSPFレコードであることを宣言します。
• include:sendlayer.net は、この場合SendLayerである送信サービスを承認します。各送信ツールには独自のinclude:ディレクティブがあります。
• ~all は、一致しないすべてのものに対するキャッチオールルールです。チルダは「ソフトフェイル」（許可するが疑わしいとしてフラグを立てる）を意味します。すべての正当な送信者をカバーしていると確信したら、「ハードフェイル」（拒否）には-allを使用してください。

メールが届くと、受信サーバーは送信元のIPを取得し、そのIPがSPFレコードで許可されているかを確認します。許可されていればSPFはパスします。許可されていなければSPFは失敗します。

SPFでできないこと

SPFには2つのよく知られた制限があります。メール転送で壊れます：誰かがあなたのメールを転送すると、転送サーバーはあなたのSPFレコードに含まれていない独自のIPを使用します。元のメールは正当なものであったにもかかわらず、SPFは失敗します。そして、表示されるFrom:アドレスではなく、リターンパスのみをチェックします。攻撃者は、From:行をあなたのもののように見せながら、自分が制御するドメインでSPFをパスさせることができます。だからこそDMARCアラインメントが重要なのです。下のDMARCセクションを参照してください。

10-DNSルックアップ制限

SPFレコードは、DNSルックアップが合計10回までという制限があります（RFC 7208）。include:、a、mx、ptr、exists: の各ディレクティブは、この制限に含まれます。送信サービスを多く追加しすぎるとPERMERRORに達し、その時点で全ての認証がサイレントに失敗します。

ほとんどのドメインは、複数のマーケティングツール、CRM、トランザクションサービス、ヘルプデスクを積み重ねた場合にこの制限に達します。制限に近い場合は、複数のSPFレコードを単一のフラット化されたレコードにマージする方法に関するガイドに従ってください。

また、注意点として、ドメインごとにSPFレコードは1つしか作成できません。2つ目のレコードを追加しようとすると、RFC 7208 によると、受信者は設定全体を無効として扱う必要があり、SPFがないのと同じ効果になります。

DKIMとは？

DKIM（DomainKeys Identified Mail）は、送信するすべてのメールに暗号署名を追加します。署名は、送信サービスが保持する秘密鍵を使用して生成され、対応する公開鍵はDNSに保持されます。受信サーバーは、これら2つを比較して、メールが実際にドメインから送信されたものであり、転送中に内容が変更されていないことを確認します。

DNSのDKIMレコードは次のようになります：

selector1._domainkey.example.com.    IN    TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQ..."

セレクター（この例では「selector1」）は、受信サーバーにどのDKIMキーを検索すべきかを伝えます。ほとんどのプロバイダーは定期的にキーをローテーションし、異なる送信ストリームに異なるセレクターを使用するため、セレクター名はレコードの場所の一部となります。

送信するすべてのメールには、次のようなDKIM-Signatureヘッダーが含まれます：

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; h=from:to:subject:date; bh=...; b=...

d=タグは署名を主張するドメインです。s=タグはセレクターです。これは受信サーバーが検索するDNSレコードです。

DKIMでできないこと

DKIMは強力ですが、限界があります。どのサーバーがドメインの送信を許可されているかを示しません。それはSPFの仕事です。攻撃者はDKIM署名なしでドメインをなりすますことができ、DKIM単独ではそれについて何も判断できません。また、リレーサーバーがメッセージ本文を変更した場合に破損する可能性があります。たとえば、送信メールにフッターを追加するメーリングリストなどです。そしてDKIMには強制力が組み込まれていません。DMARCが指示しない限り、受信サーバーは署名の失敗を無視できます。

DKIMキーの長さ

最新のDKIMキーは2048ビットであり、公開鍵文字列は255文字を超えます。これは単一のTXTレコード値の最大長です。ほとんどのDNSプロバイダーは、値を複数の引用符付き文字列に分割することでこれを自動的に処理しますが、そうでない場合もあります。DKIMレコードが保存できない、または検証できない場合は、DKIMレコードを分割する方法に関するガイドを参照してください。

DMARCとは？

DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、SPFとDKIMを連携させ、認証が失敗した場合の対応を受信サーバーに指示します。3つの中で唯一、レポートを生成してあなたに送信するものです。

典型的なDMARCレコードは次のようになります：

_dmarc.example.com.    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100; aspf=r; adkim=r"

各タグには役割があります：

• v=DMARC1 は、これがDMARCレコードであることを宣言します。
• p= はポリシーです：none、quarantine、またはreject。
• rua= は、集計レポートが送信される場所です。
• pct= は、ポリシーが適用されるメールの割合です（段階的なロールアウトに便利です）。
• aspf= および adkim= は、アライメントモード（リラックスrまたはストリクトs）を制御します。

ポリシーの進行：p=none → p=quarantine → p=reject

DMARCの実施は、旅であり、スイッチではありません。3つのポリシーは段階であり、自信が高まるにつれてそれらを進行します。

• p=none：監視モード。失敗したメールは通常どおり配信されますが、それらに関するレポートを受け取ります。常にここから開始してください。
• p=quarantine：失敗したメールは受信者の迷惑メールフォルダに送信されます。p=noneで2〜4週間、正当なメールが失敗することなく経過した後、ここに移動してください。
• p=reject：失敗したメールは完全に拒否されます（550 SMTPエラー）。p=quarantineでさらに2〜4週間経過した後、ここに移動してください。

p=rejectに直接ジャンプすることは、DMARC関連の停止の最も一般的な原因です。拒否された後にのみ、忘れていた正当な送信元（CRM、マーケティングツール、サポートデスク）を発見するでしょう。常にp=noneから開始し、レポートを読み、それからエスカレートしてください。

DMARC集計レポート

DMARCレコードにrua=を設定すると、ドメインのメールを処理するすべてのメールプロバイダー（Google、Microsoft、Yahooなど）から毎日XMLレポートを受け取るようになります。これらのレポートは、ドメインの下でメールを送信したすべてのIPと、それぞれについてSPFとDKIMが合格し、アライメントされたかどうかを示します。

生のXMLはノイズが多く、機械可読であるため、ほとんどのチームはrua=アドレスをDMARCレポートサービス（Postmark、dmarcian、EasyDMARCなど）に接続して、レポートを読みやすいダッシュボードに解析します。ポリシーを強化する前に見逃していた可能性のある正当な送信元を発見する唯一の方法です。

DMARCアライメント

DMARCは、他のプロトコルにはない概念であるアライメントを導入します。SPFとDKIMはそれぞれ、それぞれのチェックが有効な場合に合格しますが、DMARCは、認証されたドメインが表示されるFrom:アドレスと一致する場合にのみ、その合格をカウントします。

2つの種類：

• SPFアライメント：smtp.mailfrom（リターンパス）ドメインがFrom:ドメインと一致します。
• DKIMアライメント：DKIM署名のd=タグがFrom:ドメインと一致します。

DMARCは、これらのうち少なくとも1つがアライメントされ、かつ、基になるチェックが合格した場合に合格します。

リラックスアライメント（デフォルト）はサブドメインの一致を許可します。mail.example.comからのメールはexample.comのFrom:とアライメントされます。ストリクトアライメントは正確な一致を必要とします。ほとんどの送信者は、ストリクトの特定のセキュリティ上の理由がない限り、リラックスを使用します。

アライメントは、SPFとDKIMが個別に両方パスする場合でも、DMARCの失敗の最も一般的な原因です。多くの送信サービスは、あなた自身のドメインではなく、独自のドメイン（例：sendgrid.net）を使用して認証するため、SPFとDKIMはパスしますが、example.comと一致するものがないためDMARCは失敗します。アライメントの修正は、通常、プロバイダーが提供するカスタムリターンパスまたはブランドDKIM署名への切り替えを意味します。

DMARCレコードを追加する方法

メールプロバイダーから特定のDMARCレコードが提供されている場合は、それを追加してください。提供されていない場合は、_dmarc.yourdomain.comに以下の安全な汎用スターターレコードを追加してください。

v=DMARC1; p=none; rua=mailto:[email protected];

これにより、管理しているメールボックスにレポートが届く監視モードに入ります。レポートの処理とポリシーの進行を含む完全な設定については、DMARCレコードの作成方法に関する専用ガイドをご覧ください。

なぜすべて3つが必要なのか（そして1つしかない場合に何が起こるか）

各プロトコルは、他のプロトコルでは解決できない問題を解決します。内訳は次のとおりです。

SPFのみで実行すると、アライメントベースのなりすましに対して脆弱になります。攻撃者は自分のドメインで認証しながらあなたのドメインを表示します。DKIMのみで実行すると、どのサーバーでもあなたになりすますことができます。DMARCのみで実行すると、強制するための基盤となる認証がありません。3つすべてを組み合わせたものが、実際に機能する唯一の設定です。

2026年にSPF、DKIM、DMARCは必須になりますか？

メール認証は、2024年から2026年の間に「ベストプラクティス」から「交渉不可」へと移行しました。現状は以下の通りです。

大量送信者（1日あたり5,000通以上のGmailまたはYahooへのメール）

• 2024年2月：GmailとYahooは大量送信者の要件を導入しました。SPF、DKIM、DMARCがすべて必要です。ワンクリックで解除できるヘッダーが必要です。スパム苦情率は0.3%未満に維持する必要があります。
• 2025年5月：Microsoftは、Outlook.com、Hotmail、Live.comに同等の要件を導入しました。
• 2025年11月：Gmailは、準拠していないメッセージに対するソフトディファラル（一時的な421エラー）から、恒久的な拒否（550エラー）に移行しました。猶予期間はもうありません。準拠していないメールは完全に拒否されます。

低ボリューム送信者（1日あたり5,000通未満）

あなたは厳密には一括送信者のルールには従っていませんが、基盤となる認証チェックはすべての接続に適用されます。SPF、DKIM、またはDMARCの欠落は、低ボリュームでも受信トレイ配置率を最大76％低下させます。ルールは名目上は一括送信者を対象としていますが、スパムフィルターはすべての人に同じシグナルを使用します。

コンプライアンスのコンテキスト

• PCI DSS v4.0には、支払いカードデータを処理する組織向けの電子メール認証要件が含まれています。
• CISA Binding Operational Directive 18-01は、すべての米国連邦機関に、p=rejectでSPF、DKIM、およびDMARCを展開することを義務付けています。
• 英国（NCSC）、オーストラリア（ACSC）、カナダ（CCCS）でも、政府および重要インフラストラクチャに対して同様の要件が存在します。

結論：連絡フォームから月に50通のメールを送信している場合でも、3つのレコードすべてが必要です。

重要な設定順序（ほとんどの人が間違える点）

まずSPFを追加します。次にDKIM。次にDMARC。それぞれに間隔を空けてください。この順序は交渉の余地がなく、間違えると新しいデプロイメントで配信が壊れる最も一般的な理由です。

なぜこの順序なのか？

DMARCはSPFとDKIMの結果をチェックします。これら2つが設定され検証される前にDMARCを追加すると、すべてのメールが認証に失敗します。p=quarantineまたはp=rejectポリシーの場合、DMARCが伝播した瞬間にメールがスパムフォルダに入り始めたり、拒否されたりすることを意味します。多くのプロバイダーは、SPFが検証に合格するまでDMARCレコードの追加を許可しません。

それぞれのアクティブ化までの時間

• SPF： 5〜30分
• DKIM： 1〜4時間
• DMARC： 1〜24時間

各レコードが伝播した後、管理しているGmailアドレスにテストメールを送信し、「元の表示」でヘッダーを確認してください。DMARCを追加する前に、SPFとDKIMの両方がPASSと表示されるはずです。

SPF、DKIM、およびDMARCレコードを追加する場所

3つのレコードすべてが、ドメインのDNS設定（Aレコード、MXレコード、ネームサーバーを管理するのと同じ場所）にTXTレコードとして追加されます。正確な場所は、DNSを管理している人によって異なります。

共有ホスト（Bluehost、SiteGround、HostGator）

ほとんどの共有ホストには、コントロールパネルの「ドメイン」または「DNS管理」の下にDNSゾーンエディターが含まれています。TXTレコードを追加するオプションを探してください。

ドメインレジストラ（GoDaddy、Namecheap、Google Domains）

ホスティングとドメインが別々の場合、DNSは通常レジストラにあります。ドメインダッシュボードで「DNS設定」または「DNSの管理」を探してください。

Cloudflare

Cloudflareダッシュボードを開き、ドメインを選択し、左側のメニューでDNSをクリックして、新しいTXTレコードを追加します。エディタビューは次のとおりです。

Vercel

VercelがドメインのDNSをホストしている場合は、プロジェクトを開き、設定 → ドメイン → DNSレコードをクリックして、新しいTXTレコードを追加します。ホストフィールドは、ルート（SPFに使用）の場合は@、DMARCの場合は_dmarcを受け入れます。

Netlify

Netlify DNSは、チームダッシュボードのドメインの下にあります。ドメインをクリックし、まだ設定していない場合は「Netlify DNSの設定」をクリックしてから、「DNSレコード」の下にレコードを追加します。

Squarespace

Squarespaceは、ドメイン → [ドメイン名] → DNS設定 → カスタムレコードを通じてDNSを処理します。ルートドメインの場合はホスト=@、DMARCの場合は_dmarcでTXTレコードを追加します。

SPF、DKIM、DMARCのテスト方法

3つのレコードすべてが期待どおりに機能していることを確認する3つの信頼性の高い方法。

方法1：Gmailの「元のメッセージを表示」

自分で管理しているGmailアドレスに、自分のドメインからテストメールを送信します。メールが届いたら、メールを開き、右上にある3つの点のメニューをクリックして、元のメッセージを表示を選択します。上部近くにある次の3行を探します。

• SPF: PASS（自分のドメインで）
• DKIM: PASS（header.d=に自分のドメインが表示されていること）
• DMARC: PASS

これらのいずれかがFAILまたはNEUTRALを示している場合は、下のトラブルシューティングセクションに進んでください。

方法2：オンラインチェッカー

MxTooltool、dmarcian、HostedScanはすべて無料のSPF、DKIM、DMARCルックアップを提供しています。ドメインを入力すると、各レコードの簡単な合格/不合格ステータスと、DNSルックアップが多すぎる、構文の問題などの一般的なエラーの診断が表示されます。

方法3：WP Mail SMTPのドメインチェッカー

WP Mail SMTPのメールテストツールは、個別のツールを必要とせずに、テストメールを送信するたびに3つのレコードすべてを自動的に検証します。WordPress管理画面から、レコードの欠落、複数のSPFレコード、DKIM署名の問題、DMARCアラインメントの失敗、PTRレコードの問題などをすべてフラグ付けします。

SPF、DKIM、DMARCの失敗のトラブルシューティング

レコードが設定されているにもかかわらず認証が失敗している場合は、これらのシナリオのいずれかがほぼ常に原因です。それぞれが同じテンプレートに従います：症状→可能性のある原因→診断→修正。

1. SPFはパスするがDMARCが失敗する

症状: Gmailの「元のメッセージを表示」でSPF: PASSと表示されるが、DMARC: FAILと表示される。

可能性のある原因: SPFアラインメントの失敗。リターンパスドメインが表示されているFrom:ドメインと一致しません。

診断: ヘッダーのsmtp.mailfrom値を確認してください。From:のドメインと一致しますか？

修正: 送信サービスのReturn-Pathを自分のドメインに変更する（ほとんどのプロバイダーは「カスタムReturn-Path」または「バウンスドメイン」設定を提供しています）、または代わりにDKIMアラインメントに依存する（これは設定が簡単なことが多いです）。

2. 受信メールにDKIM署名がない

症状: ヘッダーにDKIM-Signature:行がまったく表示されない。

可能性のある原因: DKIMが送信側で実際に設定されていないか、間違ったセレクターが使用されている。

診断: 比較のために、別のツール（Gmail直接または他のSMTPサービス）からテストを送信してください。DKIMステータスの確認は、SMTPプロバイダーのダッシュボードで行ってください。ほとんどの場合、セレクターが検証済みかどうかが表示されます。

修正: DKIM CNAMEまたはTXTレコードがプロバイダーの指定通りに正確に存在することを確認してください。DNSレコードのセレクター名は、プロバイダーが署名しているものと一致する必要があります。ここでのタイプミスは非常に一般的です。

3. SPF「permerror: DNSルックアップが多すぎます」

症状: メールサーバーがSPF PERMERRORでメッセージを拒否します。

原因: SPFレコードに10件を超えるDNSルックアップが含まれています（RFC 7208のハードリミット）。複数のサービスにinclude:ディレクティブをスタックする場合に一般的です。

診断: SPFフラットナーツールを使用してルックアップ数を数えてください。include:、a、mx、ptr、exists:のそれぞれがカウントされます。

修正: 不要なインクルードを削除するか、インクルードを直接IPエントリに解決するSPFフラット化サービスを使用してください。詳細な手順はSPFマージガイドをご覧ください。

4. 同じドメインに複数のSPFレコード

症状: 有効に見えるレコードがあるにもかかわらず、SPF PERMERRORまたはNEUTRALが発生します。

原因: SPF TXTレコードが2つ以上あります。RFC 7208ではこれは無効であり、受信者はSPFレコードが存在しないものとして扱います。

診断: dig TXT yourdomain.comを実行するか、MxToolboxのSPFルックアップを使用してください。v=spf1で始まる2つのレコードが表示された場合、それが問題です。

修正: 両方のレコードのinclude:ディレクティブを1つのレコードに結合してください。詳細な手順はこちら。

5. DMARCアライメントの失敗（サイレントキラー）

症状: SPF: PASSおよびDKIM: PASSですが、DMARC: FAILです。

原因: 個別にパスしても、どちらのプロトコルもFrom:ドメインとアライメントされていません。

診断: ヘッダーの3つの値、From:ドメイン、smtp.mailfromドメイン、およびDKIM d=タグを比較してください。最後の2つのうち少なくとも1つは最初の値と一致する必要があります。

修正: 送信サービスを設定して、リターンパス（SPFアライメント用）またはDKIM署名（DKIMアライメント用）にドメインを使用してください。ほとんどのプロバイダーはデフォルトで独自のドメインを使用するため、アライメントをオプトインする必要があります。

6. DNSに対してDKIMレコードが長すぎる

症状: プロバイダーからDKIMキーが提供されましたが、DNSで受け付けられません。

原因: 単一のTXTレコードには、1文字列あたり255文字の制限があります。DKIM 2048ビットキーはこの制限を超え、同じレコード内で複数の引用符付き文字列に分割する必要があります。

診断: キーの文字数を数えてください。255文字を超える場合は、この問題が原因です。

修正: 値を255文字のチャンクに分割し、それぞれを引用符で囲みます: "v=DKIM1; k=rsa; p=ABC..." "DEF..." "GHI..."。ほとんどの最新のDNSプロバイダーはこれを自動的に行いますが、一部行わない場合があります。完全なガイドはDKIMレコードの分割方法にあります。

7. SPFはプロバイダーを含んでいるが、メールがまだ失敗する

症状: SPFレコードにはメーラーが正しく含まれています（例: include:sendlayer.net）が、メールはSPF認証に失敗します。

原因の可能性: インクルードが解決するIPとは異なるIPから送信しています。これは通常、複数のサービスが同じドメイン（例: SendLayer経由のトランザクションメール、Mailchimp経由のマーケティングメール）で送信しているが、1つしかインクルードしていない場合に発生します。

診断: ヘッダーで実際の送信IPを確認します。それをインクルードのSPFレコードのIPと比較します。

修正: ドメインから送信するすべてのサービス、各マーケティングツール、トランザクションサービス、ヘルプデスク、CRMのインクルードを追加します。それでも10ルックアップ制限を超える場合は、問題#3を参照してください。

8. DMARCのp=rejectが正当なメールをブロックしている

症状: 顧客がトランザクションメール（パスワードリセット、領収書）を受信できなくなりますが、テスト送信は正常に機能します。

原因の可能性: SPFで正当な送信元をすべて捕捉する前に、p=rejectに移行しすぎた。

診断: DMARC集計レポートを確認します。これには、ドメインで失敗しているすべての送信者が表示されます。正当な送信者は明らかでしょう（CRM、マーケティングツール、ヘルプデスクなど）。

修正: p=quarantineまたはp=noneに戻します。DMARCレポートを使用して、SPFに不足している正当な送信者を追加します。レポートで正当なメールの失敗率が0%になるまで2〜4週間待ち、その後再度適用します。

9. レコードが追加されたが、伝播していない

症状: レコードを追加しましたが、ツールはまだ欠落していると表示します。

原因の可能性: レジストラ、ローカルリゾルバ、または受信サーバーでのDNSキャッシュ。以前にキャッシュされた高TTLレコードに対する低TTLの変更でよく発生します。

診断: 別のネットワークからdig +trace TXT yourdomain.comを実行するか、dig @8.8.8.8 TXT yourdomain.comでGoogle DNSに直接クエリします。これらがレコードを表示しているのにテスターが表示しない場合は、キャッシュの問題です。

修正: 待ちます。ほとんどの伝播はSPFで1時間以内、DMARCで最大24時間で完了します。48時間経過しても何も表示されない場合は、レジストラでレコードが正しく保存されたか再確認してください。よくある間違いは、見落とした確認ステップが必要なインターフェースです。

10. テストメールは合格するが、実際のメールは失敗する

症状: WP Mail SMTPのテストメールはすべて緑色で表示されますが、実際のWordPressメール（フォーム通知、パスワードリセット）は認証に失敗します。

原因の可能性: 送信パスの違い。プラグインのテストは設定されたメーラー経由で送信されますが、一部のプラグインやフォームによって生成されたWordPressメールはそれをバイパスする可能性があります。

診断: 送信エラーになっているメールのFrom:アドレスを確認してください。それはあなたのドメインですか、それとも[email protected]ですか？後者の場合、Fromアドレスの不一致が発生しています。

修正: WP Mail SMTPで「Fromメールアドレスを強制する」を有効にすると、どのプラグインが送信元であっても、すべてのWordPressメールが認証済みアドレスを使用するようになります。

WordPress固有の注意点

WordPressには特有のメール送信問題があります。デフォルトではPHPのmail()関数を使用しており、これは認証なしでメッセージを送信します。SPF、DKIM、DMARCレコードが完璧に設定されていても、WordPressがウェブホストの共有IPからPHP mail()経由でメールを送信し、そのIPがSPFレコードに含まれていない場合、すべての認証チェックが失敗します。

解決策は、すべてのWordPressメールを認証済みSMTPサービス経由でルーティングすることです。WP Mail SMTPは、SendLayer、SMTP.com、Brevo、Gmail/Google Workspace、Microsoft 365、Amazon SES、Mailgun、SendGrid、Postmark、SparkPostなどに対応したワンクリック統合を提供します。各統合は、適切に認証し、ドメインと一致するように事前設定されています。

WordPressのメールが迷惑メールに分類される場合、認証の不備または不一致が原因であることがほとんどです。詳細な診断は、WordPressのメールが迷惑メールになる理由に関するガイドに記載されています。

WordPressメールを今すぐ修正する

v=DMARC1; p=none; rua=mailto:[email protected];

v=spf1 include:sendlayer.net ~all

v=spf1 include:sendlayer.net include:_spf.google.com ~all

次に、PTRレコードを確認する

SPF、DKIM、DMARCは、メール到達可能性に重要な4つのDNSレコードのうちの3つです。4つ目はPTRレコード、つまり送信IPをドメインにマッピングするリバースDNSエントリです。メールボックスプロバイダーはすべての接続でこれをチェックし、PTRレコードがないか汎用的なレコードは、SPF、DKIM、DMARCがすべてパスしても到達可能性を損ないます。

詳細については、PTRレコードとリバースDNSのガイドをご覧ください。大量のメールを送信する場合は、Google Postmaster Toolsを設定して、Gmailが送信者の評判をどのように見ているかを監視することもできます。

メールの修正準備はできましたか？今日から始めましょう WordPressの最高のSMTPプラグインで。メールを修正する時間がない場合は、追加購入で完全なWhite Glove Setupアシスタンスを利用でき、すべての有料プランで14日間の返金保証が付いています。

この記事がお役に立った場合は、WordPressのヒントやチュートリアルについては、FacebookとTwitterでフォローしてください。