診断結果に表示される各項目の意味・判定基準・改善方法をまとめています。あわせて読みたい公式情報へのリンク付き。
すべて読む必要はありません。診断結果で「要対応」「注意」になった項目だけ確認すれば十分です。
SPFは「このドメインのメールは、これらのサーバーから送ります」とDNSで宣言する仕組みです。受信側は送信元IPアドレスを宣言と照合し、第三者によるなりすまし送信を見分けます。未設定のドメインからのメールは、Gmailをはじめ多くの受信環境で迷惑メール判定されやすくなります。
ドメインのDNSにTXTレコードを追加します（例: v=spf1 ip4:203.0.113.10 ~all）。レンタルサーバーやメール配信サービスを利用している場合は、各事業者が指定するSPFレコード（include:形式）をそのまま設定すれば大丈夫です。
診断結果ページには、あなたのドメイン・送信元に合わせた設定案（コピーしてそのまま使えるレコード）が表示されます。
SPFは「設定してあるのに無効」になっている事故が多い項目です。この診断では次の3つを検査します。いずれも認証エラー（permerror）や、なりすまし対策の無効化につながります。
DKIMは送信サーバーがメールに電子署名を付け、受信側がDNS上の公開鍵で検証する仕組みです。「途中で改ざんされていないこと」と「ドメインの正当な送信であること」を証明します。SPFと違い、転送されても認証が維持されるのが強みです。
メールサーバーの管理画面でDKIMを有効化します。多くのレンタルサーバーは数クリックで有効化でき、DNSレコードも自動登録されます。鍵はサーバー側で生成されるため、設定作業はサーバーの管理画面で行います。
DMARCは、SPF・DKIMの認証に失敗したメールを受信側がどう扱うべきか（そのまま受け取る／隔離／拒否）をドメイン所有者が宣言する仕組みです。差出人欄のドメインと認証されたドメインの一致（アライメント）も検証するため、差出人の偽装に最も直接効きます。2024年2月以降、Gmail宛て送信の事実上の必須要件になりました。
最小構成は、DNSに _dmarc.あなたのドメイン のTXTレコードで v=DMARC1; p=none を1行追加するだけです。運用が安定したら p=quarantine → p=reject と段階的に強化します。
診断結果ページには、あなたのドメイン・送信元に合わせた設定案（コピーしてそのまま使えるレコード）が表示されます。
スパム送信の実績があるIPアドレスを集めた共有データベース（DNSBL）です。多くの受信サーバーが受信可否の判断に使っており、掲載されると認証設定が完璧でも届かなくなります。この診断では Spamhaus（SBL/XBL/PBL）・SpamCop・PSBL を照会します。
各リストのサイトから掲載解除（delisting）を申請できます。レンタルサーバー等の共有サーバーでは同居ユーザーの影響で掲載されることがあるため、サーバー事業者への連絡が近道です。掲載理由（マルウェア感染・大量送信など）を解消しないまま解除しても再掲載されます。
逆引きは「IPアドレス→ホスト名」を引けるようにするDNS設定です。Gmailの要件は逆引きの存在だけでなく、引けたホスト名を正引きすると元のIPに戻ること（FCrDNS）まで求めます。この往復が一致しない送信サーバーは迷惑メール判定されやすくなります。
逆引きはIPアドレスの管理者（サーバー事業者・VPS事業者）側の設定です。管理画面に設定項目が無い場合は事業者へ依頼してください。正引きの不一致は、診断結果ページに表示される設定案（Aレコード）で解消できます。
MXレコードは、そのドメイン宛のメールをどのサーバーで受け取るかを示す設定です。返信を一切受け取れないドメインからの送信は、迷惑メール送信者の典型的な特徴のひとつとして扱われることがあります。
メールを受信しているサーバーがあるなら、その事業者が指定するMXレコードをDNSに設定します。送信専用のドメインでも、受信用のMX（例: 自ドメインのメールサーバー、または受信を担うサービスの指定値）を設定しておくことを推奨します。
このサービスの受信サーバー（Cloudflare）がメール受信時に付与する簡易的なスパム判定スコアです。低いほど良好で、5以上は内容・構成が迷惑メールの特徴に近いことを示します。受信側それぞれの本番判定とは別物ですが、内容面の改善余地を知る手がかりになります。
まず認証系（SPF・DKIM・DMARC）の要対応項目を解消するのが近道です。そのうえで、件名や本文の煽り表現・過剰なリンク・画像だけの本文などを見直します。
正規のメールサーバー・メールソフトが必ず付与する基本ヘッダの有無と妥当性を確認します。自作プログラムからの送信で漏れやすい項目です。
通常はメールソフト・サーバーが自動付与します。自作プログラムの場合はライブラリの設定で自動付与させ、時刻ズレはサーバーの時計（NTP同期）とタイムゾーンを確認します。
日本語メール特有のトラブルを検査する項目です。受信側の環境やメールソフトによって、次のようなケースで文字化けが起きます。
件名は =?UTF-8?B?…?= 形式にエンコードして送ります（通常のメールソフトは自動で行います）。機種依存文字（丸数字①・㈱・半角カナなど）は通常の文字への置き換えか、UTF-8での送信を推奨します。
迷惑メール判定に影響しやすい内容面の基本を検査します。
件名を必ず付ける、multipart/alternativeでテキスト版を併送する、リンクはhttpsに統一する、の3点です。
メールマガジン等の一括送信メールで、受信者がワンクリックで配信停止できるようにするヘッダ設定（RFC 8058）です。Gmailへ1日5,000通以上送る「一括送信者」の必須要件で、メール本文の解除リンクとは別に、ヘッダとして実装する必要があります。
メール配信サービスを利用している場合は、多くのサービスが設定で対応できます。自前実装の場合は2つのヘッダを付与します。
DMARCを強化したドメインが、Gmailなど対応環境の受信トレイに自社ロゴを表示できる仕組みです。到達性そのものより、ブランド保護と開封率向上が目的の上級・任意項目です。
DMARCを p=quarantine 以上に強化し、認証マーク証明書（VMC）を取得したうえで、default._bimi のTXTレコードにロゴ（SVG）のURLを設定します。
自ドメイン宛のメール通信の暗号化（TLS）を強制するMTA-STSと、その失敗レポートを受け取るTLS-RPTです。盗聴・中間者攻撃への対策で、金融機関や大手サービスを中心に採用が進んでいます。
_mta-sts のTXTレコードとポリシーファイルの公開、_smtp._tls のTXTレコード（レポート送り先）を設定します。上級項目のため、まずは送信ドメイン認証3点の整備を優先してください。
2024年2月以降にGmailが適用している送信者要件との対応表です。「すべての送信者」の要件と、1日5,000通以上をGmailへ送る「一括送信者」の要件に分けて、このメールが満たしているかを表示します。ここが未達のままだと、Gmail宛のメールは拒否・迷惑メール判定の対象になります。
継続的な到達状況（迷惑メール率・ドメイン評価）は、Googleが提供する無料ツールで確認できます。
最終更新: 2026-07-24 ／ 診断エンジンの更新にあわせて随時改訂します。