メールアドレス形式・MX レコード検証

概要

別々の 2 つの問いが混同されています。「このアドレスは正しい形か」は文字列から 答えられます。「ここに送ったメールは届くか」は DNS から部分的に答えられます。 「このメールボックスは存在するか」はメールを送らずには答えられず、答えられると 主張するものは推測しています。

このツールは最初の 2 つに答え、3 つ目についてははっきりとそう述べます。まず メールサーバーが実務で強制している規則で形式を検査し、続いてドメインの MX・ A/AAAA・SPF・DMARC を解決します。打ち間違いと、メールを受け取れないドメインと、 認証が壊れているドメインを区別するには十分な情報です。

使い方

1. アドレスを入力するか貼ります。
2. 上段の 2 つの結果を読みます。Syntax と Domain accepts mail です。
3. 注記を読みます。判定ではなく具体的な問題を述べています。

形式検査が強制していること

RFC 5322 はメールシステムが受け付ける範囲よりはるかに多くを許しています。括弧に よるコメント、空白を含む引用付きのローカルパート、入れ子の折り返し空白は、いずれも 正当な文法でありながら実運用のサーバーのかなりの割合が拒否します。正当なものを すべて通す検査は、バウンスするアドレスを「問題ない」と告げます。

そこで適用しているのは実務的な規則です。

• ローカルパートには英数字と !#$%&'*+-/=?^_`{|}~. を許します。アポストロフィを 含むのは o'[email protected] のような名前が実在するためで、+ を含むのは Gmail 式のサブアドレスが日常的に使われているためです。
• 先頭のドット、末尾のドット、連続したドットは不可です。
• RFC 5321 によりローカルパートは 64 文字、ドメインは 255 文字までです。ドメインの 各ラベルは 63 文字までです。
• ドメインは 2 文字以上の TLD を持つ妥当なホスト名でなければなりません。 user@localhost は拒否します。1 台の機械の中でしか意味を持ちません。
• 非 ASCII は Punycode が必要です。user@日本語.jp は xn-- の形を求めて拒否 します。Unicode の形への配送には、すべてのホップで SMTPUTF8 の対応が必要だからです。

DNS の結果の読み方

MX レコードは優先度の低い順に並べます。複数あるのは正常で、退避先として 機能し、同じ優先度は負荷を分散します。

null MX（RFC 7505）は優先度 0 でホストが空の単一レコードです。ドメインが 意図的にメールを受け取らないことを意味し、暗黙 MX への退避を抑止します。Web サイトだけに使うドメインでは正しい設定で、example.com がこれを使っています。

暗黙 MX は逆の状況です。MX レコードが全く無いため、送信側は A または AAAA の アドレスへ退避します。技術的には配送可能で、結果は通常偶発的です。メールは Web サーバーの 25 番ポートにいるものへ届き、つまり有用な場所には届きません。

SPF は書き方ではなく配送を壊す不備について検査します。DNS ルックアップを伴う 機構（include・a・mx・ptr・exists・redirect）が 10 を超えると RFC 7208 §4.6.4 により恒久的エラーになり、認証はそのまま失敗します。ベンダーを 1 つ足すだけで超えやすい上限です。+all はインターネット上のすべての送信者を 許可し、SPF を完全に無意味にします。ptr は非推奨です。all 機構が無い レコードは開きっぱなしですが、redirect= を使っている場合は all を書かないのが 正しい形です。

1 つのドメインに SPF が 2 つあるのも恒久的エラーで、これも報告します。原因不明の 断続的な配送失敗として現れるからです。2 つ目のベンダーのレコードを、1 つ目に include: で取り込むのではなく並べて追加したときに必ず起きます。

DMARC は _dmarc.<ドメイン> から読みます。p=none は印を付けます。レポートを 集めるだけなので、失敗は記録されたうえで配送されます。始点としては正しく、 留まる場所としては正しくありません。

使用例

• 登録フォームが実在するアドレスを弾く — ご自身の検証をここでの結果と比べて ください。ウェブから写した正規表現は + 付き、アポストロフィ、長い TLD を 日常的に拒否します。
• 「メールが届かない」 — まず受信側のドメインを確認します。null MX や MX の 欠落なら即座に説明が付き、話題が自社サーバーから離れます。
• 自社の送信ドメインの点検 — SPF のルックアップ数、+all、p=none のままの DMARC は、メールが迷惑メールに入る理由として最も多く見つかる 3 つです。
• メールのベンダーを追加した後 — ベンダーは include: を渡してきますが、 10 ルックアップの上限に触れることはまずありません。追加した行ではなく合計を 確認してください。
• 特定のメッセージの調査 — メールヘッダー解析は配送経路と、 受信側が記録した SPF・DKIM・DMARC の判定を表示し、.eml ビューアは保存したメッセージを開きます。このツールは送信前の 問いに、その 2 つは送信後の問いに答えます。

注意事項

DNS は DNS-over-HTTPS で、クエリごとに 5 秒のタイムアウトで解決します。クエリが 失敗した場合、その項目はエラーではなく「無い」として報告するので、TXT の解決が 遅いことで正しい MX の結果が捨てられることはありません。

ドメインは妥当なホスト名の場合のみ問い合わせます。構造の検査に落ちたアドレスは DNS の通信を一切発生させません。

使い捨てドメインの一覧は広く知られた事業者を注意喚起として収録するもので、 権威ではありません。新しいドメインは絶えず現れるので、一覧に無いことは何も 意味しません。ロールアカウントの検査も同様に参考情報です。info@ や admin@ は 完全に妥当なアドレスで、単に個人のものではないだけです。

メールの送信、SMTP 接続は一切行わず、アドレスのローカルパートを DNS クエリに 含めることはありません。詳細はプライバシーポリシーに書いてあります。