メールアドレス検証 — RFC 5322 / 使い捨てドメイン / ロール検出

メールアドレスは個人特定子 — リストごと送信することの重さ

メールアドレス 1 件は個人の識別子であり、GDPR / 個人情報保護法において個人情報に該当します。1 行 1 件で貼り付けてバリデーションするということは、多くの場合、顧客リスト・購読者リスト・社内連絡先の一部をそのまま外部に送信することを意味します。オンラインのメール検証サービスがそのリストを保存・売却・広告ターゲティングに使わないという保証は、利用規約の文言と運営者の誠実さにしか依拠しません。

B2B 企業の連絡先リストや、マーケティングキャンペーンの配信リストが外部サービスに送信されると、競合他社が同じサービスを使っている場合にクロス汚染が起きる可能性があります。「バリデーションのために」送った顧客リストが、サービス提供者側のビジネスインテリジェンスの一部になりえます。

メール検証 API に潜む構造的な問題

多くのメール検証 API は disposable ドメインの検出に「リアルタイム DNS 照会」「SMTP 疎通確認」を提供しています。しかしこの機能はメールアドレスを確実に外部サーバーに送ることを意味します。DNS 照会ログはアドレス存在確認の証跡として残り、SMTP 疎通確認は実際にそのサーバーにコネクションを試みます。「本当に存在するアドレスかを確認したい」という目的で外部 API を呼ぶことは、確認対象のアドレスを複数の中継点に記録させる行為でもあります。

本ツールは DNS 照会も SMTP 疎通確認も行いません。その代わり、RFC 構文・disposable ドメインリスト (ビルド時内蔵の 100+ 件)・role アドレス判定を、ブラウザ内の JavaScript のみで実行します。「完全な存在確認」より「リストを外部に出さない検証」を優先する設計です。

ブラウザ内 JavaScript のみで構文 / disposable / role を判定する仕組み

バリデーションロジックは RFC 5322 の実用サブセット (実際の SMTP サーバーが受け付ける形式) を正規表現で実装しています。disposable ドメイン判定は mailinator / 10minutemail / guerrillamail / temp-mail.org / yopmail / sharklasers などの主要 100+ ドメインをビルド時に静的リストとして内蔵し、入力されたドメイン部と照合します。Gmail 正規化は local 部のドット除去と +tag の除去、googlemail.com → gmail.com の変換を文字列操作だけで行います。

入力された全メールアドレスはブラウザのメモリ内にのみ存在し、ネットワーク送信は発生しません。DevTools の Network タブを開いてバリデーションを実行すると、リクエストがゼロであることを確認できます。結果の CSV ダウンロードもブラウザのダウンロード API のみを使い、サーバーを経由しません。

リスト配信前のチェックリストとして

メールマーケティングや通知配信の前に、送信リストを一括バリデーションするとバウンス率を下げ、スパムフィルターのスコア悪化を防ぐことができます。特に有効なのは、role アドレス (admin@ / noreply@ / postmaster@) の除去と disposable アドレスの排除です。前者はバウンスだけでなくスパム報告のリスクを高め、後者はキャンペーン指標を歪めます。本ツールでは Valid / Invalid / Disposable / Role の 4 分類で結果を整理するので、そのまま各種後処理の判断材料として使えます。

RFC 5322 / 5321 / 6531 が定める実用的な構文サブセット

メールアドレスの厳密な構文は RFC 5322 の addr-spec 文法で定義され、local 部はコメント付き引用文字列 ("Hello,World"@example.com) まで許容しますが、現実の SMTP サーバー (RFC 5321) ではほぼ拒否されます。本ツールは「実際に配信可能なサブセット」に絞った正規表現でバリデーションする方針で、local 部 64 オクテット・domain 部 255 オクテット・全体 254 オクテットの上限 (RFC 5321 §4.5.3.1) もチェックします。

国際化メールアドレス (EAI、RFC 6531) は 田中@example.jp のように local 部に UTF-8 を許可しますが、対応 MTA がまだ限定的なため、本ツールは「構文としては妥当」と判定しつつ「配信可能性は受信側次第」というスタンスを取ります。domain 部の Punycode 変換 (xn--...) はメール送信時に自動で行われるため、入力時点では Unicode 表記のままで構いません。+tag (RFC 5233 サブアドレス) と Gmail のドット無視は、両方ともサーバー側ローカル方針で標準仕様ではない点も把握しておくと、リスト正規化の方針が決めやすくなります。

disposable ドメインリストの精度と DNS / SMTP 検証との棲み分け

100+ ドメインを内蔵した disposable リストは、mailinator・10minutemail・guerrillamail のような長期運営の主要プロバイダを網羅していますが、新規発生する一時メールサービスには追従できません。実運用ではリストベース検出を「強い陽性 (確実に弾く)」として使い、不明ドメインは通常メール扱いにする運用が現実的です。本ツールも完全な検出を保証せず、リストにヒットしたものを Disposable に分類する方針を取っています。

MX レコードによる存在確認、SMTP RCPT TO での疎通確認は本ツールでは行いません。これらはアドレスを外部に送信する操作で、サイト方針と相容れないためです。同時に、SMTP 疎通確認はグレイリスティングや catch-all 設定の影響を受けてフォールスネガティブが多く、商用 API でも精度は完璧ではありません。配信前の最終的な存在確認は実際の配信プラットフォーム (SendGrid・Postmark など) のバウンスレポートに任せ、本ツールでは構造的に明らかなノイズの除去に集中する設計です。判定結果の CSV を更にドメイン別の比率や欠損率で俯瞰したい場合は csv-stats に流すと per-column の最頻ドメインまで取れますし、リスト中に含まれる申込フォーム由来の URL を分解したいときは url-parse で host / path / query を同じローカル経路で抽出できます。