ユーザーがあなたのサインアップフォームの入力を終えます。名前を入力し、パスワードを選び、メールアドレスを [email protected] と入力します——1文字が入れ替わっています。彼らは送信ボタンを押します。あなたのダッシュボードからは、すべてが正常に見えます。また1件のサインアップ、ユーザーテーブルにまた1行。しかしウェルカムメールは届きません。領収書も届きません。3日後にパスワードをリセットしようとすると、そのリンクもどこにも届きません。このユーザーは離脱したのではありません。彼らはアクティベーションのチャンスを一度も得られなかったのです。なぜなら、たった1文字の誤りが、あなたが将来彼らと接触できるすべての機会を静かに断ち切ってしまったからです。
あなたはおそらく、アクティベート済みユーザーに変換されないサインアップ数を見つめていることでしょう。そしてそのギャップのかなりの部分は、入力時点で防げたはずのタイプミスです。あるメール検証分析では、収集されたメールアドレスのおおよそ2〜5％にタイプミスが含まれていることが判明しました——これは年間10,000件のサインアップごとに200〜500件の失われた連絡先に相当します。教会管理プラットフォームのPlanning Centerは、システム内で gmail.con という単一のスペルミスを37,000回以上発見し、これが数十万件の配信不能メッセージを引き起こしていました。これらのバウンスの一つ一つが送信者レピュテーションを低下させ、獲得コストを膨らませ、配信可能性の指標を汚染します。この記事では、入力時にリアルタイムでメールのタイプミスを検出する方法、修正すべきかブロックすべきかの判断基準、そして流出を止める検証レイヤーの構築方法を紹介します。
目次
- メールのタイプミスがすり抜ける理由と、それが実際にもたらすコスト
- 最も一般的なメールのタイプミスと、その背後にあるパターン
- クライアントサイド vs. API検証——タイプミスをどこで捕捉すべきか？
- サインアップを取り戻す「もしかして？」提案フローの構築
- いつ修正し、いつブロックし、いつレビュー用にフラグを立てるか
- サインアップフローへのリアルタイムタイプミス検出の統合
- あなたのメールタイプミス防御チェックリスト
- よくある質問
メールのタイプミスがすり抜ける理由と、それが実際にもたらすコスト
タイプミスを正確に修正するには、まずどこで発生するのかを知る必要があります。すべてのメールアドレスには4つのゾーンがあり、それぞれが異なる種類のエラーを集めます。
ローカル部——@ の前のすべて——は、文字の欠落や余分な文字を拾います。素早く入力するユーザーは john@ を jhon@ にしてしまったり、余計な文字を追加したりします。@ 記号自体が二重になったり（user@@domain.com）、完全に抜け落ちて user.gmail.com になり、これはもはやメールアドレスですらありません。ドメインは最も大量のエラーが集まる場所です。gmial.com、gamil.com、gmal.com、gnail.com、yaho.com、yahooo.com、hotmal.com、outlok.com のようなプロバイダー名のスペルミスです。最後に、TLDは .com の代わりに .con、.cmo、.ne、.co のようなミスを集めます——n はキーボード上で m のすぐ隣にあり、これこそが gmail.con だけである本番システムで37,000回以上出現した理由です。
不正なアドレスが実際に壊すもの
無効なアドレスはハードバウンスを引き起こします——これは無効なアドレス、存在しないドメイン、またはブロックされた受信者によって引き起こされる恒久的な配信失敗です。それはソフトバウンスとは異なります。ソフトバウンスは一時的なもので、受信箱の満杯、一時的なサーバーエラー、一時的にクォータを超過したメールボックスなどです。ソフトバウンスは再試行で解決します。ハードバウンスは決して解決しません。
被害は連鎖的に進行します。メールインフラプロバイダーのSMTP.comによると、しきい値を超えるハードバウンスは送信者レピュテーションを低下させ、そのレピュテーションが下がると、ISPはあなたのメールをフィルタリングし、スロットリングし始めます——有効な受信者へのメールでさえもです。ほとんどの配信可能性の情報源が一致するヒューリスティックは次の通りです。合計バウンス率が2％未満なら健全、5％を超えると有害、そしてハードバウンスは特に、おおよそ0.5％未満に保つべきです。これらはベンダーやESPの経験則であり、規制された基準ではありません——情報源によって「問題あり」のラインは2％から10％までさまざまに引かれています——ので、法律ではなく運用上の目標として扱ってください。
無駄な支出という側面が配信可能性への打撃をさらに悪化させます。あなたは今や決して連絡できないリードを獲得するために支払ったのです。トランザクションフローは静かに壊れます——領収書、パスワードリセット、確認リンクがすべて虚空へと送られます。そしてあなたの分析はあなたに嘘をつき、決してアクティベートできないサインアップをカウントし、これがコンバージョンの分母を静かに膨らませ、本当の問題を隠します。
静かなタイプミスは、ダッシュボードにエラーとして表示されません——二度と戻ってこないユーザーとして表示されるのです。
1つの重要な区別：タイプミスは使い捨てメールではない
ここに、後のすべてのポリシー判断を左右する区別があります。正直なタイプミスと意図的な偽アドレスは、データベース上では似ていますが、正反対の対応を要求します。タイプミスは救済可能で善意のミスです——ユーザーは本物の受信箱に届けたかったのに、キー操作を誤ったのです。ですから正しい対応はそれを修正して彼らを引き留めることです。使い捨てまたは一時的なアドレスは意図的な回避です——無料トライアルを悪用したり、フォローアップを避けたりしている誰か——ですから正しい対応はそれを拒否することです。使い捨てメールアドレスチェッカーは2つ目のケースを処理し、提案フローは1つ目を処理します。この2つを混同すると、本物の顧客をブロックするか、悪用者を受け入れるかのどちらかになります。このガイドの残りの部分では、この2つを別々のトラックに保ちます。
最も一般的なメールのタイプミスと、その背後にあるパターン
修正ロジックを構築する前に、何を修正しているのか、そしてなぜそのようにクラスタ化するのかについての参照が必要です。
| ユーザーが入力したもの | 本来の意図 | エラーの種類 | 構文だけで捕捉可能か？ |
|---|---|---|---|
gmial.com |
gmail.com |
ドメインの文字入れ替え | いいえ——ドメインインテリジェンスが必要 |
gamil.com |
gmail.com |
ドメインの文字入れ替え | いいえ |
yaho.com |
yahoo.com |
文字の欠落 | いいえ |
yahooo.com |
yahoo.com |
余分な文字 | いいえ |
hotmal.com |
hotmail.com |
文字の欠落 | いいえ |
gmail.con |
gmail.com |
TLDエラー | 部分的（TLDルール） |
user@@domain.com |
[email protected] |
二重の @ |
はい |
user@gmail |
[email protected] |
TLDの欠落 | はい |
3つのメカニズムがこれらのほぼすべてを説明します。キーボードの隣接は gmial（i と a が入れ替わった）と gamil を生み出します——指が隣接するキーに着地したり、順序が狂って動いたりするのです。音声による推測は hotmal と yaho を生み出し、ユーザーは記憶ではなく音でスペルを綴ります。そしてオートコンプリートとモバイルの誤操作が残りを生み出します。小さなタッチキーボードと積極的なオートコレクトが文字を落としたり入れ替えたりし、.con のようなTLDミスは n がキーボード上で m の隣にあるために起こります。
これらは高頻度のパターンであり、エッジケースではありません。Planning Centerの単一システムでの37,000件以上の gmail.con のカウントがその証拠です——1つの特定のスペルミスが、数万回繰り返されたのです。ValidateListによる数百万件の検証済みメールの分析でも、Gmail、Yahoo、Outlookのバリエーションを中心とした同じクラスタ化が示されています。提案リストのすぐ使える骨格が欲しいなら、GitHubのオープンソース common-email-domain-typos リポジトリが何百ものスペルミスを意図されたドメインにマッピングしており、少なくとも1つの商用タイプミス修正モジュールは150以上の一般的なドメインタイプミスをカバーしていると主張しています——これは対処可能な集合が大きいが有限であることを示しています。
さて、下流のすべてを形作るニュアンスです。これらのタイプミスの中には純粋な構文ルールで捕捉できるものもあれば、できないものもあります。二重の @、@ の欠落、またはTLDの欠落はアドレスの形状に違反しています——正規表現はそれらを即座に捕捉します。しかし gmial.com は完全に整った形式のアドレスです。ローカル部があり、@ があり、ドメインがあり、.com のTLDがあります。それは構造だけをチェックするメールアドレス検証を通過します。それを捕捉するにはドメインインテリジェンスが必要です——距離アルゴリズムと組み合わせた既知プロバイダーリスト、またはドメインとメールボックスが実際に存在することを確認するライブルックアップです。その区別こそが、単一のチェックではなくレイヤーが必要な理由のすべてです。
クライアントサイド vs. API検証——タイプミスをどこで捕捉すべきか？
タイプミスを捕捉するための4つのアプローチが存在し、それぞれが他のアプローチが見逃す異なる失敗を捕捉します。以下のマトリックスはそれらを評価しています。解説はそれぞれがどこで価値を発揮するかを説明します。
| アプローチ | ドメインタイプミスを捕捉？ | 無効なメールボックスを捕捉？ | UXの摩擦を追加？ | 使い捨てをフラグ？ |
|---|---|---|---|---|
| 正規表現／構文チェック | いいえ | いいえ | なし | いいえ |
| クライアント「もしかして？」 | 部分的（既知リスト） | いいえ | 低 | いいえ |
| MX／DNSルックアップ | いいえ | いいえ（ドメインのみ） | 低 | いいえ |
| リアルタイム検証API | はい | はい | 低 | はい |
正規表現と構文チェックは形状エラー——@ の欠落、二重の @、TLDの欠落——を即座に、ネットワークコストゼロで捕捉します。それらはリクエストが発生する前にブラウザで実行されます。それらの盲点は、形式の整ったスペルミスに対して完全です。gmial.com はこれまでに書かれたすべての構文ルールを通過します。なぜなら、それは構文的に有効だからです。メンテナンスはほぼゼロであり、これがこのレイヤーが常に無料の第一段階として存在すべき理由です。
クライアントサイドの「もしかして？」提案は、静的なプロバイダーリストと編集距離の計算（通常はレーベンシュタイン距離）を使って、ニアミスのドメインタイプミスを捕捉します。これは優れたUXを提供します——修正が即座に表示され、サーバーへの往復がありません——しかし、それは背後のリストと同程度にしか良くありません。リストにないドメインは手つかずのまますり抜け、新しいプロバイダーや企業ドメインが現れるにつれてリストは継続的なメンテナンスが必要です。一般的なプロバイダーの正直なミスを回復しますが、いかなるメールボックスが実際に存在するかどうかは保証できません。
MX／DNSルックアップは、ドメインがメールを受信するように構成されていることを確認し、存在しないドメインや死んだドメインを捕捉します。それができないのは、特定のメールボックスを確認することです。ドメインは有効なMXレコードを持ちながら、個別のアドレスがバウンスすることがあり得るので、このレイヤーは問題を狭めますが解決はしません。
リアルタイム検証APIは、入力の瞬間に3つすべて——構文、ドメインとMXの解決、メールボックスレベルのチェック——を組み合わせます。Clearoutのリアルタイム検証の定義がこれを捉えています。アドレスが入力された瞬間に形式および配信可能性を検証し、配信可能なアドレスだけがリストに到達するようにします。決定的に重要なのは、よく作られたAPIは同じレスポンスで使い捨てアドレスもフラグ付けし、2つのシステムではなく1回の呼び出しでタイプミス対偽物のギャップを埋めることです。
正規表現はアドレスが正しく整形されているかを教えてくれます。メールボックスが本物かどうかは教えてくれません。
結論は、単一の勝者ではなく多層防御です。正規表現は無料で即座なので、最初に実行します。提案は正直なニアミスを低コストで回復します。メールボックスが存在することを確認し、使い捨てをスクリーニングできるのはライブAPIだけです——ですからそれが最強の単一レイヤーであり、より安価なチェックがすでに明白なケースをフィルタリングした後の、チェーンの最後に属します。
ただし、上限については正直になりましょう。リアルタイム検証でさえ絶対確実ではありません。既知のプロバイダーリストの外に落ちるタイプミスは、フラグなしで通過することがあります。一部のメールボックスプロバイダーはプライバシーのために検証を制限し、決定的なものではなく曖昧な結果を返します。そして断続的なDNSの問題は、実際には問題ないドメインで誤検出（偽陰性）を生む可能性があります。APIはあなたの最強のレイヤーです——それとして扱ってください。悪いアドレスが決して通過しないという保証としてではなく。
サインアップを取り戻す「もしかして？」提案フローの構築
ここでの支配的な原則は、罰よりも修正です。良い提案は、ハードブロックなら失っていたであろうサインアップを回復します。そこにたどり着くためのシーケンスは次の通りです。
1. すべてのキーストロークではなく、ブラー時に構文を検証する。 各キー押下で検証を発火させると、ユーザーがまだ入力途中の間にエラーが投げられます——ドメインを完成させる前に赤い表示を見てしまうのです。ブラー時に検証すると、彼らがフィールドを離れるまで待つので、完全な入力に対してチェックが実行されます。この1つのタイミングの決定が、役に立つと感じるフォームと、敵対的だと感じるフォームの違いです。
2. ドメインを既知プロバイダーリストと編集距離に対して実行する。 入力されたドメインと各既知ドメインの間のレーベンシュタイン距離を計算します。gmial.com は gmail.com から距離2に位置し、ニアミスのしきい値に快適に収まります。オープンソースの common-email-domain-typos リポジトリからリストをシードするか、Planning Centerが展開したような厳選されたトップ50から始めましょう。距離のしきい値は、本当に珍しいドメインに対して突飛な修正を提案するのを防ぎます。
3. ブロックしないインライン提案を表示する。 フィールドの下に「もしかして [email protected] ですか？」を表示します。決してハードエラーにせず、決して送信ボタンをブロックしないでください。ユーザーはコントロールを維持します——彼らはあなたの提案を受け入れるか、無視して進むことができます。ブロックする提案は、よりフレンドリーなラベルを身につけた拒否にすぎません。
4. ワンクリックで受け入れて自動修正する。 1回のタップで、フィールドの値を修正されたアドレスに置き換えるべきです。ユーザーに何も再入力させないでください——再入力は摩擦であり、摩擦はサインアップが死ぬ場所です。全体の要点は、修正を努力なしにすることです。
5. 既知リスト外のドメインについてはリアルタイムAPI検証にフォールバックする。 静的リストは、新しいドメイン、企業ドメイン、または小規模プロバイダーのロングテールをカバーできません。入力されたドメインがリストになく、リスト上のどれのニアミスでもない場合、APIに引き継ぎます。APIはあなたがカタログ化したものだけでなく、あらゆるドメインの配信可能性を確認します。これこそが、リストベースの提案が見えなくなり、ライブのメールアドレス検証がカバレッジを引き継ぐ場所です。
6. すべての修正をログに記録する。 ユーザーがどの提案を受け入れるかを捕捉します。時間が経つにつれて、これはあなたの特定のオーディエンスの実際のエラーパターンを教えてくれ——それは一般的なリストと異なるかもしれません——推測ではなく実際のデータに対してプロバイダーリストを拡張し調整することを可能にします。
Planning Center自身の結果は、覚えておく価値のあるベンチマークです。厳選されたトップ50のスペルミスドメインリストを入力フィールド全体に展開したところ、配信不能メールが測定可能なほど減少しました。この数字を動かすのに機械学習モデルは必要ありません。必要なのは、良いリスト、編集距離の計算、そしてブロックしないUIです。
いつ修正し、いつブロックし、いつレビュー用にフラグを立てるか
すべての疑わしいアドレスが同じ扱いに値するわけではありません。各シグナルをアクションにマッピングし、各アクションをビジネス上の成果に結びつけましょう——出荷する前に、サポートチケットが届いた後ではなく。
修正（自動提案）：
gmial.comのようなニアミスのドメインタイプミス、.conのようなTLDミス、そして明白な文字入れ替え。成果： さもなければ失われていたサインアップを回復し、送信者レピュテーションに触れる前にバウンスを防ぎます。完全にブロック： 救済不可能な構文、確認された存在しないドメイン、そして無料トライアルを悪用するために使われる使い捨てまたは一時的なドメイン。成果： トライアルの整合性を保護し、無効なものを完全にリストから遠ざけます。あるリスト衛生分析では、典型的なリスト上のアドレスの約15％が無効で、有効なアドレスのおよそ22.5％が毎年古くなると推定しています。これこそが入力時の厳格なゲートが報われる理由です——ゴミが下流のすべてを希釈する前に、その取り込みを止めているのです。ここが、正直なミスを修正するのと同じパスで意図的な回避をスクリーニングする使い捨てメールアドレスチェッカーがフローに属する場所です。
フラグ／ソフト摩擦： ロールベースのアドレス（
admin@、info@）、キャッチオールドメイン、そして信頼度の低い結果。成果： それらを許可しつつ拒否ではなく監視し、共有受信箱を本当に使っている正当なビジネスユーザーを誤って追い返すことを避けます。ホワイトリスト／常に許可： 決して摩擦を追加したくない既知のパートナーおよびエンタープライズドメイン。成果： 最も価値の高い関係に対する摩擦ゼロ、検証ルールが誤って署名済み契約をブロックするリスクなし。
タイプトラップの注意点
すべてを盲目的に自動修正すべきでない理由があります。タイプトラップは、大手プロバイダーから1文字違いに位置するように意図的に登録されたドメインです——gnail.com、yahoo.cmo——これは、確認せずにアドレスにメールを送る送信者を捕らえるために特別に設けられています。配信可能性の業界誌Email on Acidによると、Spamhausのアナリスト、Tom Mortimer氏を引用して、これらのトラップは、アドレスが販売時点で収集されるときに頻繁にリストに入り込み、過度に積極的な正規化は実際にメールをトラップドメインから遠ざけるのではなく、敵対的なトラップドメインの方へルーティングする可能性があります。
その安全策はダブルオプトインです。アカウントがアクティベートされる前にクリックされなければならない確認メールと修正ロジックを組み合わせます。誤入力されたアドレスは確認を受け取ることが決してないので、大規模にメールされることは決してありません——そしてトラップもそうです。ダブルオプトインは、積極的な修正ポリシーを安全にするものです。たとえあなたの提案が間違っていても、それが生成したアドレスは、他の何かを送る前に、それが本物で同意していることを証明しなければなりません。修正は意図を処理し、ダブルオプトインは検証を処理します。両方が必要です。
サインアップフローへのリアルタイムタイプミス検出の統合
ポリシーが定義されれば、統合は短く、繰り返し可能な道です。5つのステップで、生の入力フィールドから強制された決定まで到達します。
1. 入力を捕捉する。 ロジックをメールフィールドのブラーおよび送信イベントにバインドします。ブラーは送信前の早期チェックを提供し、送信はあなたの最終ゲートです。両方が同じ検証パスをトリガーすべきです。
2. 検証APIを呼び出す。 ブラー時または送信時にアドレスを送信します。これは一連のものではなく、単一の送信リクエストです。
3. 単一のレスポンスを解析する。 よく設計されたAPIは、必要なすべてを1つのペイロードで返します。3つの別々の往復——1つは構文用、1つはMX用、1つは使い捨てスクリーニング用——の代わりに、valid、suggested_correction、disposable フィールドを一緒に運ぶ1つのレスポンスを得ます。それが、3つのネットワーク呼び出しを待つフォームと、1つを待つフォームの違いです。
4. ポリシーを強制する。 前のセクションの修正・ブロック・フラグ・ホワイトリストのルールをそれらのフィールドに対して適用します。suggested_correction が入力されている場合、提案を表示します。disposable が true の場合、ブロックします。結果が信頼度の低いものの場合、フラグを立てて許可します。
5. UXフィードバックを返す。 決定に応じて、提案、ブロックメッセージ、または静かな通過を表示します。ユーザーは、修正すべき本当の問題があるときにのみ摩擦を目にするべきです。
1回のAPI呼び出しで、3つのことを同時に教えてくれるべきです。有効かどうか、他の何かを意図していたか、そして使い捨てかどうか。
エッジケースの処理
計画を立てなければ、3つの失敗モードがあなたに噛みつきます。非同期処理： リクエストが進行中の間、決してフォームをフリーズさせないでください。バックグラウンドスレッドで検証し、ユーザーが動き続けられるようにします。最終チェックが要求する場合にのみ送信をブロックします。タイムアウトとフォールバック： APIが遅いか到達不能な場合、オープンに失敗させます。APIの停止は決して正当なユーザーをブロックすべきではありません——構文のみの検証に優雅に低下させ、サインアップを通過させてください。なぜなら、停止中に失われたサインアップは、まれなスクリーニングされていないアドレスよりも悪い結果だからです。過度にブロックしない： 優れたAPIがあっても、ダブルオプトインを配信可能性のバックストップとして保ち、あなた側の偽陽性が決して本物の人を恒久的に締め出さないようにします。
自動化されたパイプラインを構築するチームにとって、同じチェックはAIエージェントのワークフロー内で実行されます。MCPサーバーは、CursorやClaude Desktopのようなツールが、同一の検証ロジックをプログラム的に呼び出すことを可能にします——インポートされたリストをクリーニングしているとき、サインアップを一括でレビューしているとき、または人間を介さずに登録を処理するエージェントに検証を組み込んでいるときに便利です。検証の契約は同じです。変わるのは呼び出し元だけです。
アプローチ全体が機能する理由に立脚させましょう。入力の瞬間に形式と配信可能性を検証することは、配信可能なアドレスだけがリストに入ることを意味します。これはClearoutのリアルタイム検証のフレーミングに沿っています。そしてアドレスがすり抜けたとき、Infobipの配信可能性ガイダンスは、無効なメールのエラーコードを検出を洗練させるトリガーとして獲得フローにフィードバックすることです——あなたに届くすべてのバウンスは、捕捉時に捕まえ始められるタイプミスパターンに関するデータです。
あなたのメールタイプミス防御チェックリスト
これが出荷準備の整った設計図です。各項目はその位置を獲得しており、それぞれに1行の理由があるので、習慣でリストに載っているものは何もありません。
- フィールドのブラー時に構文検証を追加する——
@の欠落、二重の@、TLDの欠落を、ネットワークコストゼロで即座に捕捉します。 - 主要プロバイダー向けに「もしかして？」ドメイン提案を実装する——厳選されたトップ50リストでシードします。Planning Centerのアプローチは配信不能メールを測定可能なほど削減しました。
- メールボックスとドメインの存在についてリアルタイムAPI検証を重ねる——
gmial.comが間違っていることそして有効に見えるアドレスの背後のメールボックスが本物であることを確認する唯一のレイヤーです。 - 明示的な修正・ブロック・フラグのポリシールールを設定する——苦情の後ではなく、出荷する前に各シグナルをアクションにマッピングします。
- 信頼できるドメインをホワイトリストに登録し、既知の使い捨てをブロックする——同じ検証パスでエンタープライズ関係と無料トライアルを保護します。
- ダブルオプトインを配信可能性のバックストップとして有効にする——誤入力またはトラップのアドレスが大規模にメールされないことを保証します。
- APIエラー時にオープンに失敗する——構文のみに低下させ、停止が決して正当なサインアップをブロックしないようにします。
- 修正をログに記録し、成功指標としてバウンス率を監視する——運用KPIとして、合計バウンスを2％未満、ハードバウンスをおおよそ0.5％未満に目指します。
これがあなた自身のサインアップにとって重要かどうかを知る最速の方法は、実際の入力でそれが起こるのを見ることです。50回のAPI呼び出しの無料枠を使って、クレジットカード不要で、あなた自身のライブフォームに対してリアルタイムタイプミス提案と使い捨てフラグを試すことができ、今まさにユーザーが入力しているアドレスに実際の suggested_correction と disposable フィールドが入力されるのを見ることができます。その1つのテスト——直近100件のサインアップを検証にかけること——は、通常、ほとんどのチームが予想するよりも多くの回復可能なタイプミスを浮かび上がらせます。
よくある質問
サインアップを遅くせずにメールのタイプミスを検出できますか？
はい。すべてのキーストロークではなくフィールドのブラー時に非同期で検証し、ネットワーク呼び出し中に決してフォームをフリーズさせないでください。ブラー時の構文チェックは事実上即座であり、API検証はバックグラウンドで実行され、送信をブロックせずに提案を返します。タイムアウト時にはオープンに失敗させ、遅いレスポンスが決して正当なユーザーを止めないようにします。正しく行えば、検証はフォームを記入している人に何か有用なことを伝えるまで見えません。
タイプミスと無効なメールの違いは何ですか？
タイプミスは救済可能なミスです——ユーザーは本物のアドレスを意図して誤入力したのです。たとえば gmail.com のつもりの gmial.com のように——ですからそれを修正して彼らを引き留めます。無効なメールは本当に配信不能です。存在しないメールボックスや、ブロックすべき死んだドメインです。典型的なリスト上のアドレスのおおよそ15％が無効であり、これがブロックゲートを修正ゲートと同じくらい重要にします。両方の問題は同じフィールドを通じて到着しますが、正反対の対応を要求します。
これまで見たことのないドメインのタイプミスをどうやって捕捉しますか？
静的な「もしかして？」リストは既知のプロバイダーのみをカバーするので、新しいドメインや企業ドメインのタイプミスはそのまますり抜けます。そこがライブのMX／DNSルックアップとメールボックスレベルの検証が価値を発揮する場所です——それらはリスト上のものだけでなく、あらゆるドメインの配信可能性を確認します。2つのアプローチを組み合わせましょう。一般的なプロバイダーの即座でコストゼロのカバレッジにはリストを使い、リストが認識できないすべてについてはAPIにフォールバックします。
タイプミスを修正すると実際に配信可能性が向上しますか？
はい、間接的ですが測定可能に。修正されたすべてのタイプミスは回避されたハードバウンスであり、ハードバウンスは送信者レピュテーション低下の主要な要因です。合計バウンス率を2％未満、ハードバウンスをおおよそ0.5％未満に保つことは、時間の経過とともに受信箱への配置を保護します。捕捉時に修正することは、それらのバウンスが送信指標に到達する前に止めます——つまり、レピュテーションへの打撃が、事後に修復されるのではなく、そもそも起こらないのです。
タイプミスと使い捨てメールでは、どう扱うべきかがどう違いますか？
正反対の意図、正反対のアクションです。タイプミスは修正して引き留めるべき正直なエラーです——その人はあなたから連絡を受けたいのです。使い捨てアドレスは意図的な回避であり、多くの場合トライアルの悪用であり、完全にブロックすべきです。suggested_correction と disposable フラグの両方を返す単一のAPIレスポンスは、1回のチェックで両方のポリシーを適用することを可能にし、2つの別々のシステムを実行することなく、本物のミスを回復し、意図的な偽物を拒否します。