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

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

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

このガイドでは、それぞれの機能、連携方法、設定順序、テスト方法について説明します。2026年現在、メールを送信するすべてのビジネスで3つすべてが必須となります。Gmail、Yahoo、Microsoftが直接強制しており、いずれかをスキップすると受信トレイへの到達率が低下します。

クイックアンサー

• SPF、DKIM、DMARCとは？ メールが正当なものであることを確認するために連携する3つのDNSレコードです。SPFは、どのサーバーがあなたのドメインから送信できるかを承認し、DKIMはメッセージが転送中に変更されていないことを証明する暗号署名を追加し、DMARCはSPFまたはDKIMが失敗した場合の受信側の対応を指示します。
• 3つすべて必要ですか？ はい。それぞれが他のレコードの欠点を補い、2024年2月以降、GmailとYahooは1日あたり5,000通以上のメールを送信する送信者に対してこれらを要求しています。
• 設定順序は？ SPFを最初に、次にDKIM、最後にDMARCを設定し、各ステップ間で検証を行います。
• 今すぐ確認： このページの無料チェッカーを使用して、ドメインの3つのレコードすべてをテストしてください。

SPF、DKIM、DMARC：メール認証の説明

これら3つのレコードは独立したチェックですが、1つのポリシーに統合されます。これらが設定されると、パスワードリセットが届かなかった理由や、トランザクションメールが迷惑メールフォルダに入った理由を推測する必要がなくなります。

SPF、DKIM、DMARCとは？

SPF、DKIM、DMARCは、ドメインから送信されるメールを認証する3つのDNSレコードです。

• SPF（Sender Policy Framework）は、あなたのドメインからメールを送信することを許可されているすべてのサーバーをリストアップします。
• DKIM（DomainKeys Identified Mail）は、各メッセージに暗号署名を追加し、受信者が転送中にコンテンツが変更されていないことを確認できるようにします。
• DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、SPFまたはDKIMが失敗した場合の受信側の対応を指示し、両方のチェックを可視的なFrom:アドレスに紐付けます。

それぞれが異なるギャップを埋めます。SPFは、不正なサーバーがあなたのドメインを主張するのを防ぎ、DKIMは、メッセージが転送中に変更されるのを防ぎ、DMARCは、攻撃者が可視的なFrom:行であなたのドメインを偽装しながらSPFまたはDKIMを通過させるのを防ぎます。

簡単な比較

	SPF	DKIM	DMARC
機能	ドメインからのメール送信を許可されているサーバーのリスト	各メールに署名し、受信者が改ざんされていないことを確認できるようにする	SPFまたはDKIMが失敗した場合の対処法を受信者に伝える
仕組み	受信者が送信IPをDNSのリストと比較する	受信者が公開鍵に対して暗号化署名を検証する	受信者が失敗したメールにポリシー（配信、スパム、拒否）を適用する
できないこと	可視的なFrom:アドレスをチェックしない、転送時に破損する	どのサーバーが送信できるかを指定しない、リレーがメールを変更すると破損する可能性がある	それ自体では何も認証しない、SPFとDKIMに依存する
DNSでの場所	ルートドメインのTXTレコード	[selector]._domainkey.yourdomain.comのTXTレコード	_dmarc.yourdomain.comのTXTレコード
2026年に必須？	はい	はい	はい

Gmail、Outlook、またはその他の受信トレイにメールが届くと、3つのチェックが順番に行われます。受信者はあなたのSPFレコードを参照し、送信IPをリストと比較します。受信者はDKIM署名をDNS内の公開鍵と照合します。次に受信者はあなたのDMARCポリシーを読み取り、結果をどう扱うかを決定します。

SPFとは？

SPFは、ドメインに代わってメールを送信することを許可されたすべてのサーバーとサービスをリストする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つのよく知られた制限があります。メール転送で壊れます。誰かがあなたのメールを転送すると、転送サーバーは独自のIPを使用しますが、これはSPFレコードに含まれていないため、オリジナルは正当であってもSPFはフェイルします。また、表示されるFrom:アドレスではなく、リターンパスのみをチェックします。攻撃者は、From:行をあなたのもののように見せかけながら、自分が管理するドメインでSPFをパスさせることができます。だからこそDMARCアライメントが重要になるのです（詳細は後述）。

10-DNSルックアップ制限

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

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

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

DKIMとは？

DKIMは、送信するすべてのメールに暗号署名を追加します。署名は、送信サービスが保持する秘密鍵を使用して生成され、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は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）を制御します。

ポリシーの進行、noneからquarantine、そして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つがアラインし、かつ基盤となるチェックが合格した場合に合格となります。

緩和アライメント（デフォルト）ではサブドメインの一致が許可されるため、example.comのFrom:とmail.example.comからのメールがアラインします。厳格アライメントでは完全一致が必要です。ほとんどの送信者は、厳格な理由がない限り緩和アライメントを使用します。

アライメントは、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つすべてが必要な理由

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

	SPF	DKIM	DMARC
防止するもの	許可されていないサーバーがあなたのドメインになりすまして送信すること	転送中にメールの内容が変更されること	他のチェックがパスしても、攻撃者があなたのFrom:アドレスをなりすますこと
チェックするもの	送信IPと承認済みリストの照合	公開鍵と暗号署名の照合	認証結果とFrom:ドメインのアライメント
一般的な失敗	転送時に正当なメールが破損する	メーリングリストリレーが本文を変更し、署名を破損する	SPFとDKIMの両方が、表示ドメインとのアライメントに失敗する
スキップした場合	どのサーバーでもあなたのドメインになりすまして送信できる	誰でも転送中にあなたのメールを検知されずに変更できる	認証失敗に強制措置がない

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

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

メール認証は、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レコードを追加します。

WP Engine

WP EngineはデフォルトではDNSをホストしないため、ドメインに使用しているレジストラ（GoDaddy、Namecheap、Cloudflareなど）でSPF、DKIM、DMARCレコードを追加します。WP Engineから必要なのは、SPFのinclude:の正しい値であり、これによりメールサーバーがサイトに代わって送信できるようになります。これは、WP Engineユーザーポータルの環境のDNSまたはメール設定の下にあります。通常のSPF includeはmail1.wpengine.comです。これを既存のSPFレコードに追加してください。他の送信者と一緒に追加し、2番目のv=spf1レコードとして追加しないでください。

SPF、DKIM、DMARCのテスト方法

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

Gmail「元の表示」

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

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

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

WP Mail SMTPのドメインチェッカー

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

オンラインチェッカー

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

一般的な失敗のトラブルシューティング

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

1. Gmailが「550-5.7.26」でメールを拒否した

症状。 Gmailが550-5.7.26 SMTP拒否でバウンスします。完全なテキストは通常、「Gmailでは、すべての送信者がSPFまたはDKIMのいずれかで認証する必要があります」のような内容になります。

可能性のある原因。 送信ドメインに有効なSPFまたはDKIMがない、または両方が誤って設定されている。

診断。 このページの先頭にあるチェッカーでドメインを実行するか、WP Mail SMTPドメインチェッカーを使用してください。結果により、3つのレコードのうちどれが欠落しているか、または失敗しているかが表示されます。

修正。 有効なSPFレコードを追加し、DKIMが送信ドメインに署名していることを確認してください。両方のレコードが伝播した後、再送信してください。完全な診断については、Gmailがメールをブロックするのを修正するガイドを参照してください。

2. 「アクションが必要です：SMTPサーバーで必要とされるSPFレコードが追加されていません」

症状。 SMTPプロバイダーのダッシュボードに、SPFレコードが欠落しているか、それらが含まれていないという警告が表示されます。

可能性のある原因。 プロバイダーのinclude:ディレクティブがドメインのSPFレコードに含まれていません。

診断。 dig TXT yourdomain.comを実行するか、上記のチェッカーを使用してください。SPFレコードを探し、プロバイダーのドメイン（例：sendlayer.net、_spf.google.com）がリストに含まれているか確認してください。

修正。 プロバイダーのinclude:を既存のSPFレコードに追加してください。たとえば、SendLayerとGoogle Workspaceを使用するSPFレコードは、v=spf1 include:sendlayer.net include:_spf.google.com ~allのようになります。同じドメインに2番目のSPFレコードを作成しないでください。

3. SPFはパスしたがDMARCが失敗する

症状。 Gmailの元の表示にSPF: PASSと表示されるが、DMARC: FAILと表示される。

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

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

修正。送信サービスのリターンパスを自分のドメインに変更するか（ほとんどのプロバイダーは「カスタムリターンパス」または「バウンスドメイン」設定を提供しています）、DKIMアライメントに頼るかのどちらかです。これは設定が簡単な場合が多いです。

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

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

原因。送信側でDKIMが実際に設定されていないか、間違ったセレクターが使用されています。

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

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

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

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

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

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

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

6. 同じドメインに複数のSPFレコードがある

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

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

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

修正。両方のレコードのinclude:ディレクティブを1つのレコードに結合してください。上記のマージ手順を参照してください。

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

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

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

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

修正。値を255文字のチャンクに分割し、それぞれを引用符で囲みます。例："v=DKIM1; k=rsa; p=ABC..." "DEF..." "GHI..."。ほとんどの最新のDNSプロバイダーはこれを自動的に行います。一部行わないプロバイダーもあります。完全なガイドは、上記のDKIMキーの長さのセクションを参照してください。

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

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

原因。 両方のプロトコルが個別にパスしても、どちらも From: ドメインと一致していません。

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

修正。 送信サービスを設定して、SPF アライメントの場合はリターンパス、DKIM シグネチャの場合は DKIM アライメントでドメインを使用するようにします。ほとんどのプロバイダーはデフォルトで独自のドメインを使用します。アライメントをオプトインする必要があります。

9. DMARC p=reject による正当なメールのブロック

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

原因。 SPF で正当な送信元をすべてキャッチする前に、p=reject に移行しすぎました。

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

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

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

症状。 レコードを追加しましたが、ツールではまだ見つからないと表示されます。

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

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

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

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などに対応したワンクリック統合でこれを実現します。各統合は、適切に認証され、ドメインと一致するように事前設定されています。WP Mail SMTPのメール到達率向上機能には、WordPress内でSPF、DKIM、DMARCレコードの欠落または誤設定をフラグ付けする無料のドメインチェッカーが含まれています。

WordPressのメールが迷惑メールに分類される場合、認証の欠落またはずれが原因であることがほとんどです。詳細な診断は、WordPressのメールが迷惑メールになる理由に関するガイドに記載されています。設定については、WordPressメール検証ガイドでレコードの確認方法を説明しています。

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

SPF、DKIM、DMARCに関するFAQ

これらは、メール認証に関する最も検索されている質問であり、最もよく尋ねられるものから最も技術的なものまで順に整理されています。各回答は自己完結型です。

SPF、DKIM、DMARCの違いは何ですか？

SPFは誰が送信できるかを指定し、DKIMはメールが本物で改ざんされていないことを証明し、DMARCはいずれかのチェックが失敗した場合の処理を強制します。

SPFは送信サーバーを承認し、DKIMは改ざん防止の暗号署名を追加し、DMARCはSPFまたはDKIMの整合性が失敗した場合に受信者が従うポリシーを設定します。それぞれが他のものが残すギャップをカバーするため、3つすべてが必要です。SPFのみでは転送メールで問題が発生します。DKIMのみでは不正なサーバーがドメインを主張できるようになります。DMARCなしの両方では、問題が発生した場合の強制指示を受信サーバーが受けられません。

SPF、DKIM、DMARCの3つすべてが必要ですか？

はい。2024年2月以降、GmailとYahooは1日あたり5,000通以上のメールを送信する送信者に対して3つすべてを要求しており、Gmailは2025年11月に非準拠のメールを完全に拒否し始めています。このしきい値を下回っても、3つのうちいずれかが欠けていると、受信トレイへの配置が低下します。

SPFとDKIMはそれぞれ異なる状況で失敗します（SPFは転送で失敗し、DKIMは中継がメッセージを変更すると失敗します）ので、単一プロトコルの設定は予測不能に失敗します。

SPFまたはDKIMなしでDMARCを使用できますか？

技術的には、SPFまたはDKIMのいずれかが合格し、整合性が取れていればDMARCは合格するため、1つだけでDMARCを実行できます。実際には、それぞれが他のものが生き残るシナリオで失敗するため、両方を設定する必要があります。

SPFのみでDMARCを実行すると、転送されたメールが失敗します。DKIMのみで実行すると、転送中に変更されたメッセージが失敗します。両方を組み合わせることで、信頼性の高い認証が得られます。

p=none、p=quarantine、p=rejectとはどういう意味ですか？

これらはDMARCの強制レベルであり、厳格さの順に並んでいます。

p=noneは監視モードです。失敗を報告しますが、何もブロックせず、すべてのドメインがここから開始する必要があります。p=quarantineは、失敗したメールを迷惑メールフォルダに送信します。p=rejectは、失敗したメールを完全にブロックします。

レポートで正当なメールが失敗していないことを確認した後、徐々にnoneからquarantine、そしてrejectに移行してください。

SPF、DKIM、DMARCを設定する順序は何ですか？

まずSPF、次にDKIM、最後にDMARCを設定します。DMARCはSPFとDKIMの結果を読み取るため、最初にDMARCを追加すると、すべてのメールがすぐに認証に失敗します。

SPFを追加し、伝播を待ってからDKIMを追加し、Gmailの元の表示チェックで両方のパスを確認してから、p=noneから始めてDMARCを追加します。

SPF、DKIM、DMARCが正しく設定されているかどうかの確認方法は？

チェッカーツール（このページのトップにある無料ツールなど）を使用して、ドメインの3つのレコードすべてを検索し、ステータスを確認します。

手動で確認することもできます。Gmailアドレスにメールを送信し、開き、3点メニューをクリックして元の表示を選択し、SPF、DKIM、DMARCがそれぞれPASSと表示されていることを確認します。

DMARCアライメントとは何ですか？

アライメントは、DMARCを意味のあるものにするチェックです。SPFまたはDKIMに合格したドメインが、メールの表示されているFrom:アドレスのドメインと一致することを確認します。

SPFアライメントでは、リターンパスドメインがFrom:ドメインと一致する必要があります。DKIMアライメントでは、署名のd=タグがそれに一致する必要があります。DMARCの失敗の最も一般的な原因は、SPFまたはDKIMの完全な失敗ではなく、アライメントのずれです。

Gmailのエラー「550-5.7.26」はどういう意味ですか？

550-5.7.26エラーは、送信ドメインが認証されていないため、Gmailがメールを拒否したことを意味します。Gmailは現在、すべての送信者にSPFまたはDKIMでの認証を要求しています。

これを修正するには、送信ドメインに有効なSPFレコードとDKIM署名を追加し、再送信する前に両方がパスすることを確認します。上記の最初のトラブルシューティング項目で、完全な診断手順を説明しています。

Gmailの「元の表示」でSPF、DKIM、DMARCがPASSと表示されるのはどういう意味ですか？

メールが正しく認証されたことを意味します。SPF PASSは、メールが承認されたサーバーから送信されたことを確認します。DKIM PASSは、メッセージが転送中に改ざんされていないことを確認します。DMARC PASSは、認証されたドメインが表示されているFrom:アドレスと一致することを確認します。

3つすべてがパスすることが望ましい結果です。これにより、受信トレイへの配置が最大化されます。

SPF、DKIM、DMARCは迷惑メールへの送信を停止しますか？

これらは必要ですが、十分ではありません。認証は、メールが本当にあなたから送信されたものであることをメールプロバイダーに伝えます。これは受信トレイへの配置の前提条件ですが、他の要因も依然として重要です。これらには、送信者の評判、コンテンツの質、エンゲージメント率、リストの衛生状態、および有効なPTRレコードが含まれます。

まず3つすべてを設定し、次に他のメール配信要因に対処します。

DMARC、SPF、DKIMをチェックするのに最適なツールは何ですか？

最も簡単な方法は、このページにある無料ツールのように、3つすべてを同時にテストするチェッカーを使用することです。継続的な監視には、Google Postmaster ToolsがGmailが認証をどのように評価するかを示し、WP Mail SMTPの組み込みドメインチェッカーはWordPress内で直接3つのレコードすべてを検証します。

SPF、DKIM、DMARCの正式名称は何ですか？

SPFはSender Policy Frameworkの略です。DKIMはDomainKeys Identified Mailの略です。DMARCはDomain-based Message Authentication, Reporting, and Conformanceの略です。

これらを組み合わせることで、メール認証の標準スタックを形成し、ドメインをなりすましから保護します。

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

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

詳細については、PTRレコードとリバースDNSのガイドをご覧ください。

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

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