よくある質問
echo.email は、1 つのアドレスにつき 1 通のメールを分析し、結果を説明します。以下の回答では、サービスの仕組みとレポートの各チェックの意味を説明します。
- echo.email はどのように動きますか?
- アドレスはどのくらいの間有効ですか?
- レポートはどのくらいの間保存されますか?
- メッセージの内容はどう扱われますか?
- SPF チェックでは何を確認しますか?
- DNS 参照の回数はなぜ重要ですか?
- DKIM で何がわかりますか?
- DMARC とは何ですか?
- アライメントとはどういう意味ですか?
- BIMI とは何ですか?
- 逆引き DNS はなぜ重要ですか?
- 汎用の逆引き DNS とは何ですか?
- どのような HELO 名がよいですか?
- TLS を確認するのはなぜですか?
- IPv6 を確認するのはなぜですか?
- メールのサイズはどのように測りますか?
- 画像の容量とは何ですか?
- 画像の無駄な容量とは何ですか?
- echo.email は画像をどのように扱いますか?
- リンクはどのように扱われますか?
- List-Unsubscribe とは何ですか?
- ワンクリックの配信停止とは何ですか?
- 操作不要の配信停止とは何ですか?
- 本文内の配信停止リンクがなぜ今も必要なのですか?
- List-Id とは何ですか?
- 推奨事項の一覧とは何ですか?
- メッセージはどのように表示されますか?
- MIME セクションには何が表示されますか?
- 元のメッセージのセクションには何が表示されますか?
- レポートではどのブロックリストを確認しますか?
- SpamAssassin のスコアは何を意味しますか?
- 送信者のドメインにメール サーバーが必要なのはなぜですか?
- 危険とみなされる HTML 要素はどれですか?
- 短縮 URL を警告するのはなぜですか?
- DNS セクションには何が表示されますか?
echo.email はどのように動きますか?
トップ ページは、power.file.tube@echo.email のような 3 つの単語からなる新しいアドレスを作ります。このアドレスに送られたメッセージは echo.email のメール サーバーに届きます。サーバーは SMTP のやり取りを記録し、メッセージを分析に回します。数秒後、ページに認証、コンテンツ、要件への準拠、配信についてのレポートが表示されます。インストールは不要で、アカウントもありません。
アドレスはどのくらいの間有効ですか?
アドレスはページを開いている間、有効です。ページは 2 秒ごとにサーバーと通信します。10 分以内に再読み込みすれば、同じタブで同じアドレスを使い続けられます。ページを閉じてから 10 分を超えると、メール サーバーはそのアドレスへの新しいメッセージを恒久的なエラーで拒否します。
対象になるのは最初に届いたメッセージだけです。同じアドレスへの 2 通目以降のメッセージは拒否されるため、1 つのレポートは必ず 1 通のメールに対応します。10 MB を超えるメッセージは、SMTP のやり取りの途中で拒否されます。
レポートはどのくらいの間保存されますか?
レポート、保存したメッセージ、取得した画像のデータは、メッセージが届いてから 24 時間後に自動で削除されます。この 24 時間の間は、リンクを知っている人なら誰でもレポートのリンクを開けます。その後、リンクは使えなくなります。唯一の例外はサンプル レポートです。サンプル レポートは、この目的のために送ったテスト メッセージから作られています。
メッセージの内容はどう扱われますか?
echo.email は、ヘッダー、本文、添付ファイルを含むメッセージ全体を保存します。送信元 IP アドレス、HELO 名、TLS のバージョンなど、SMTP セッションのデータも一緒に保存します。データは EU 内にとどまり、メール サーバーはドイツのファルケンシュタインで動いています。レポートのリンクを知っている人は誰でもメッセージ全体を見られるため、共有してよい内容でテストすることをおすすめします。ニュースレターには、トラッキング リンクや受信者ごとの配信停止リンクがよく含まれています。テスト用のリストにコピーを送れば、それらのリンクは非公開のままです。
次の 2 つのアドレスは、サービスの運営者に直接届きます: 質問や不正利用の報告は contact@echo.email、データに関する依頼は privacy@echo.email です。詳しくはプライバシー ポリシーをご覧ください。
SPF チェックでは何を確認しますか?
SPF は、return path にあるドメインでメールを送ってよいサーバーの一覧です。echo.email はエンベロープ送信者 (MAIL FROM アドレス、return path とも呼びます) のドメインを取り出し、そのドメインの SPF レコードを、メッセージを届けたサーバーの IP アドレスで評価します。良い結果とみなすのは pass だけです。softfail、neutral、none の場合、受信者は送信者についての SPF の証明を得られません。
HELO 名は確認しません。大手メール プロバイダーも、一括送信メールの SPF を評価するときに HELO 名を見ません。レポートには途中のすべてのレコードとメカニズムが表示されるため、最終結果に至る過程がわかります。
DNS 参照の回数はなぜ重要ですか?
SPF の評価で行える DNS 参照は最大 10 回です。include、a、mx、ptr、exists、redirect の各メカニズムがこの上限に数えられ、入れ子になった include の中のものも含まれます。上限を超えると結果は恒久的なエラーになり、受信者はそのメッセージに有効な SPF がまったくないものとして扱います。空の参照、つまりレコードが返らない参照には、別に 2 回という上限があります。よくある原因は外部サービスの include の長い連鎖で、サービスの一覧を短くすれば問題は解決します。
DKIM で何がわかりますか?
DKIM は、メッセージのヘッダーに暗号による署名を加えます。署名するドメインは、公開鍵をセレクターの下に DNS で公開します。echo.email はその鍵を取得し、届いたままのヘッダーと本文で署名を検証します。pass は、署名された部分が変更されずに届き、署名したドメインがその内容に責任を持つことを意味します。
レポートには、署名したドメイン (d=)、セレクター (s=)、署名されたヘッダー (h=)、鍵の種類と長さが表示されます。本文の長さの制限 (l=) があると警告します。この制限があると、署名の後に内容を書き足せるためです。
DMARC とは何ですか?
DMARC は、SPF と DKIM を、表示される From アドレスのドメインに結び付けます。From ドメインは _dmarc.<domain> にポリシーを公開し、認証に失敗したメールの扱いを受信者に伝えます: none、quarantine、reject のいずれかです。SPF か DKIM が From ドメインとアライメントされたドメインで pass になると、メッセージは DMARC に合格します。
DMARC 自体は認証を追加しません。DMARC の価値は、アライメントの要件と、受信者がドメインの所有者に送る集計レポート (rua=) にあります。
アライメントとはどういう意味ですか?
アライメントは、認証されたドメインを From ドメインと比べます。緩和モードのアライメントでは同じ組織ドメインであればよいため、mail.example.com は example.com とアライメントされます。厳格モードのアライメントでは、ホスト名が完全に一致する必要があります。組織ドメインは Public Suffix List から決まります。このリストにより、example.co.uk のような名前が 1 つの登録可能なドメインとして扱われます。レポートで特に説明なくアライメントと書かれている場合、比べる相手は From ドメインです。
BIMI とは何ですか?
BIMI はブランドのロゴを公開し、メール プロバイダーが認証済みのメッセージの横にそのロゴを表示できるようにします。レコードは default._bimi.<domain> にあり、SVG のロゴ (l=) を指します。ほとんどのプロバイダーでは、Verified Mark Certificate (a=) も指します。BIMI が使えるのは、DMARC ポリシーを適用しているドメイン、つまり quarantine か reject を 100 パーセントで設定しているドメインだけです。echo.email はレコードを表示し、DMARC ポリシーが要件を満たしているかを示します。
逆引き DNS はなぜ重要ですか?
メールを送るすべての IP アドレスには、ホスト名を指す PTR レコードが必要です。そのホスト名には、同じ IP アドレスを指し返す A レコードか AAAA レコードが必要です。この往復の確認を forward-confirmed reverse DNS、略して FCrDNS と呼びます。大手メール プロバイダーは FCrDNS を送信サーバーの最低条件としており、PTR レコードのない IP アドレスからのメールはその場で拒否されることがよくあります。
汎用の逆引き DNS とは何ですか?
一部の PTR レコードは、192-0-2-10.dynamic.example.net のように、インターネット プロバイダーの命名規則に従っています。このような名前は、家庭用の回線や、誰もメール用に設定していないサーバーを思わせるため、フィルターに疑われます。mail.example.com のように送信者のドメインにある専用の名前は、意図して設定したメール サーバーであることを示します。
どのような HELO 名がよいですか?
送信サーバーは、SMTP のやり取りの最初に HELO または EHLO の名前を名乗ります。よい名前は送信サーバーのもので、DNS で名前解決でき、送信元 IP アドレスの PTR レコードと一致します。名前のない IP アドレス、localhost のような名前、ランダムな文字列はマルウェアや snowshoe スパムによく見られ、フィルターはこの点を判断に使います。
TLS を確認するのはなぜですか?
日和見 TLS は、受信サーバーが STARTTLS を提供している場合に、SMTP のやり取りを暗号化します。echo.email はすべての接続で STARTTLS を提供し、送信者が選んだ TLS のバージョンと暗号スイートを記録します。TLS なしで送られたメールは 2 つのサーバーの間を平文で流れます。Google と Yahoo は一括送信者に TLS を求めています。レポートは、通常の http で読み込むリンクや画像の数も数えます。それらのリクエストも暗号化されずに送られるためです。
IPv6 を確認するのはなぜですか?
メッセージが IPv6 に対応しているかどうかは、2 つの質問で決まります。1 つ目は、送信者が IPv6 だけを使うメール サーバーに届けられるかどうかです。IPv6 で届いたメッセージは、その時点で答えがはいになります。IPv4 で届いたメッセージも、送信ホストに AAAA レコードがあり、その IPv6 アドレスの逆引き DNS が同じホストを指し、そのアドレスで SPF が pass になれば、IPv6 対応とみなします。ほとんどのメール サーバーは接続のたびに IPv4 か IPv6 を選ぶため、同じホストからの次のメッセージは IPv6 で届くことがよくあります。2 つ目は、メッセージの画像やリンクを提供するすべてのホストに AAAA レコードがあるかどうかです。AAAA レコードがあれば、IPv6 だけのネットワークや通信事業者の NAT (CGNAT) を使う読者もコンテンツを読み込めます。どちらの答えもはいの場合、レポートはそのメッセージを IPv6 対応と表示します。
メールのサイズはどのように測りますか?
メールのサイズは、送信されたときのバイト数です。すべてのヘッダー、各 MIME パート、添付ファイル、base64 や quoted-printable のエンコードで増えた分を含みます。Gmail は HTML が約 102 KB を超えるメッセージを途中で切り、残りをリンクの後ろに隠します。切られた部分には、配信停止リンクやトラッキング ピクセルが含まれていることがよくあります。
画像の容量とは何ですか?
画像の容量は、<img> タグで参照している外部画像の合計サイズで、各画像を 1 回ずつ取得して測ります。srcset 属性の画像や CSS の背景画像は数えないため、この数値は最小値です。容量の大きいメッセージはモバイル回線での読み込みが遅く、読者のデータ通信量を使います。
画像の無駄な容量とは何ですか?
画像の無駄な容量は、メッセージ内の表示サイズに近い大きさで各画像を提供した場合に、送信者が節約できるバイト数の推定値です。表示サイズの 2 倍までの画像は、高密度の画面が余分なピクセルを使うため、無駄な容量をゼロとみなします。表示サイズの 2 倍を超えると、余分なピクセルは精細さを増やさずにバイト数だけを増やします。スペーサーのような 1 KB 未満の画像は数えません。
echo.email は画像をどのように扱いますか?
分析では、各外部画像を 1 回だけ取得し、HTTP ステータス、リダイレクト、サイズ、コンテンツ タイプ、ピクセル単位の寸法を記録します。その後、その寸法を HTML で指定されたサイズと比べます。画像の取得は、読者がメッセージを開いたときにメール ソフトが行う処理と同じです。そのため、開封トラッキングには開封が 1 回記録されます。取得は Cloudflare のネットワークから行い、プライベート アドレスや内部アドレスへのリクエストは拒否します。
リンクはどのように扱われますか?
リンクは HTML から取り出してホストごとにまとめ、読みやすいようにクエリ パラメーターをデコードします。echo.email は通常のリンクを開きません。リンクを開くと、購読が確定したり、何かの処理が始まったり、クリックが記録されたりすることがあるためです。唯一の例外は、後で説明するワンクリックの配信停止 URL です。
List-Unsubscribe とは何ですか?
List-Unsubscribe は RFC 2369 で定義されたヘッダーです。このヘッダーには、mailto: アドレスや https: URL など、リストから配信停止する方法が 1 つ以上含まれます。メール プロバイダーはこのヘッダーを使い、送信者名の横に独自の配信停止ボタンを表示します。通常の http の URL は古い方式で、今は https が求められます。
ワンクリックの配信停止とは何ですか?
RFC 8058 は 2 つ目のヘッダー List-Unsubscribe-Post を追加します。値は List-Unsubscribe=One-Click で固定です。両方のヘッダーがある場合、メール プロバイダーは https の URL に POST リクエストを送り、受信者はどのページも開かずに配信停止できます。Google と Yahoo は一括送信者にワンクリックの配信停止を求めています。
echo.email は同じ POST リクエストを送り、その応答を表示します。2xx のステータスはすべて成功とみなします。このリクエストで配信停止されるのは、echo.email の一時アドレスだけです。
操作不要の配信停止とは何ですか?
操作不要の配信停止は、受信者がブラウザーを開いたり何かを確認したりしなくても完了します。推奨される方法は RFC 8058 の one-click です。List-Unsubscribe の mailto: アドレスも対象になりますが、メールによる配信停止は時間がかかり、受信者に完了の確認が届きません。そのため、プロバイダーは mailto を予備の手段として扱います。
本文内の配信停止リンクがなぜ今も必要なのですか?
ほとんどの国のマーケティング関連の法律は、メッセージの中に配信停止の方法をわかりやすく示すことを求めています。通常はフッターのリンクです。ヘッダーはメール プロバイダーのためのもので、フッターのリンクは読者のためのものです。echo.email は、配信停止の文言を含むリンクや、配信停止用に見える URL を探します。この検出は経験則に基づくため、違うリンクを選ぶこともあります。フッターのリンクに専用のトラッキング パラメーターを付けると、送信者の統計で、フッターからの配信停止とヘッダーからの配信停止を区別できます。
List-Id とは何ですか?
List-Id (RFC 2919) は、メッセージが属するメーリング リストに名前を付けます。たとえば News <news.example.com> のような形です。Google と Yahoo はこのヘッダーを求めていません。受信サーバーや受信者は、このヘッダーを使って送信の種類ごとにメールを並べ替えたり振り分けたりします。そのため、このヘッダーを付けることが推奨されます。
推奨事項の一覧とは何ですか?
この一覧は、Google と Yahoo が 2024 年に一括送信者向けに公開した要件に沿っています: SPF のアライメント、DKIM のアライメント、forward-confirmed reverse DNS (FCrDNS)、TLS、フリーメールではなく DMARC にも失敗しない From ドメイン、公開された DMARC ポリシー、少なくとも 1 つのアライメントされた認証方式、ワンクリックの配信停止、目に見える配信停止リンク。各行ははいかいいえで示します。赤い行は、大手プロバイダーで受信トレイでの扱いが悪くなる原因になりやすい項目です。すべての行を満たすことが、一括送信の基本です。
一部の行は、当てはまる場合にだけ数えます。配信停止の 2 つの行は、メッセージに一括送信のヘッダーがある場合に数えます: List-Unsubscribe、List-Unsubscribe-Post、List-Id、または値が bulk、list、junk の Precedence です。これらのヘッダーがどれもない個人的なメッセージでは、これらの行は数えません。エンベロープ送信者が SRS で書き換えられ、アライメントされた DKIM で DMARC に合格している場合、SPF のアライメントはスコアに含めません。SRS で書き換えた後、SPF は From ドメインではなく、アドレスを書き換えたサーバーのドメインを確認します。転送サービスは標準で SRS を使い、一部の送信サーバーはすべての送信メールに SRS を適用するため、SPF のアライメントが失われます。スコアは、数えた行のうちいくつを満たしているかを示します。
メッセージはどのように表示されますか?
表示ビューでは、HTML パートを隔離された枠 (サンドボックス) の中に表示します。表示を行うのはブラウザーなので、結果は特定のメール ソフトや端末ではなく、パソコンのブラウザーでの表示に対応します。プレビューでは、スクリプト、フォーム、リンクは無効です。ほかのビューでは、画像をブロックした状態や、各画像の代わりに代替テキストを表示した状態でメッセージを示します。多くの読者は、最初にこの状態でメッセージを目にします。
MIME セクションには何が表示されますか?
MIME はメッセージの内部構造です: パート、コンテンツ タイプ、文字セット、転送エンコード、パートを区切る境界線。一般的なニュースレターには、text/plain パートと text/html パートを含む multipart/alternative のコンテナーがあります。テキスト パートがない、終わりの境界線がない、入れ子が普通でない、といった点はツリーを見るとすぐにわかります。
元のメッセージのセクションには何が表示されますか?
元のメッセージのセクションには、受信したままのメッセージと、次の統計が表示されます: 全体のサイズ、行数、最長の行、ASCII 以外の文字、CR のない改行。RFC 5322 は 1 行を 998 文字までに制限しており、それより長い行を折り返したり拒否したりするサーバーもあります。復帰文字 (CR) のない改行は、途中のサーバーが書き換えるため、DKIM の失敗のよくある原因です。
元のメッセージのビューは、mx.echo.email が配信時に記録するトレース ヘッダーから始まります: Return-Path、Authentication-Results、Received-SPF、Received。その下に受信したままのメッセージがあり、ダウンロード リンクから変更のない .eml ファイルを取得できます。
レポートではどのブロックリストを確認しますか?
受信者は、送信元 IP アドレスと送信者のドメインを DNS のブロックリストで調べます。広く使われているリストに掲載されていると、メールは拒否されたり振り分けられたりします。レポートでは scan.mx と同じリストを確認します: IP アドレスは Spamhaus ZEN と AuthBL、From ドメインとエンベロープのドメインは Spamhaus DBL と ZRD、IPv4 アドレスはさらに SpamCop、GBUdb Truncate、PSBL です。各行は掲載ありか掲載なしを示し、リスト運営者の掲載解除ページへのリンクがあります。
Spamhaus PBL へのポリシーによる掲載は、家庭用の回線のように、メールを直接送るべきではないアドレス範囲を示します。そのようなアドレスからのメールは、プロバイダーのメール サーバーを通して送る必要があります。結果は 2 時間キャッシュされるため、修正が新しいテストに反映されるまで最大で 2 時間かかります。
SpamAssassin のスコアは何を意味しますか?
SpamAssassin は、多くの受信サーバーが使っているオープン ソースの迷惑メール フィルターです。メール サーバーは、毎日更新される標準ルールと SpamAssassin で各テスト メッセージを採点します。レポートには、合計、迷惑メールのしきい値 5、該当した各ルールが点数の高い順に表示されます。マイナスの点数はメッセージに有利に働きます。たとえば有効な DKIM 署名がその例です。
ネットワーク テストでは、送信元 IP アドレスとリンク先のドメインを Spamhaus (DQS 経由)、URIBL、SURBL、標準ルールにあるほかのリストで調べます。ベイズ学習と、共有ハッシュのネットワークである Razor、Pyzor、DCC は無効にしています。そのため、スコアはメッセージだけで決まり、学習のためにメッセージの情報がサーバーの外に出ることはありません。
このスコアは参考値で、推奨事項のスコアには含めません。受信者はそれぞれ独自のルールとしきい値を持つ独自のフィルターを使っており、Gmail と Outlook は SpamAssassin を使っていません。0 を超えるスコアは普通のことです。点数の高いルールを見ると、どこを変えると効果が大きいかがわかります。500 KB を超えるメッセージは採点しません。
送信者のドメインにメール サーバーが必要なのはなぜですか?
返信は From ドメインに、バウンスはエンベロープ送信者のドメインに届きます。どちらにも MX レコードか、少なくともメール サーバーが代わりに使うアドレス レコードが必要です。null MX、つまりドット 1 つを指す MX が 1 つだけあるレコード (RFC 7505) は、そのドメインがメールを一切受け付けないことを示します。そのようなドメインからのメッセージを拒否する受信者もいます。
危険とみなされる HTML 要素はどれですか?
スクリプト、フォーム、iframe、object、embed がメールで必要になることはまれです。ほとんどのメール ソフトはこれらを取り除き、迷惑メール フィルターはフィッシングの兆候として採点します。通常のリンクと画像なら、この減点なしで同じ役割を果たせます。コンテンツのセクションには HTML のサイズと HTML に含まれる表示テキストの量も表示されます。ほとんどがマークアップや画像だけのメッセージは、フィルターに疑われやすいためです。
短縮 URL を警告するのはなぜですか?
bit.ly のような公開の短縮 URL サービスは、本当のリンク先を隠します。フィッシングのキャンペーンでよく使われるため、フィルターは短縮 URL を経由するリンクを疑います。送信者のドメインに直接向かうリンクは、評判を築きます。
DNS セクションには何が表示されますか?
レポートのために行った DNS 参照はすべて DNS セクションに表示され、目的ごとにまとめられます: 逆引き DNS、SPF、DKIM、DMARC、BIMI、メール サーバー、IPv6 の確認。ブロックリストへの参照は、名前にアクセス キーが含まれるため表示しません。各項目には、名前、レコードの種類、応答コード、TTL 付きの応答、権威レコードがあればその内容が表示されます。この一覧を見ると、各結果がどのレコードから得られたかがわかります。最近の DNS の変更がまだすべてのリゾルバーに届いていない場合に役立ちます。