WordPressフォームでメールアドレスを検証する方法

WordPressのフォームプラグインは、asdf@asdfや入力ミスのある大量のGmailアドレスでも、そのまま受け付けてメーリングリストに渡してしまいます。WordPressフォームでメールアドレスを検証するのに、新しいプラグインは必要ありません。必要なのは、送信の瞬間に検証APIを呼び出すか、エントリーをエクスポートして一括でクリーニングすることです。このガイドでは、主要な3つのフォームプラグイン（Contact Form 7、WPForms、Gravity Forms）について、どのプラグインでも使えるパターンで両方の方法を紹介します。

結論#

サポートしている方法は2つです。どちらを選ぶかは、お使いのプラグインとそのプランによって決まります。

1. リアルタイム：プラグインの送信イベントまたはバリデーションイベントにフックし、エントリーが確定する前にQualisend APIを呼び出します。多くのプラグインでは、バリデーションフィルターに短いPHPスニペットを追加します（アドレスをその場で拒否できるのはここだけです）。上位プランでは、非同期のタグ付け用にWebhookのステップも使えます。
2. 一括：プラグインに保存されたエントリーをCSVにエクスポートし、Qualisendの一括検証で定期的に処理します。コードは不要で、エントリーを保存するすべてのプランで使えます。

送信時にWordPressフォームのメールアドレスを検証する#

ほとんどのフォームプラグインは、送信を受け取る際にサーバー側のイベントを発行します。このイベントが連携ポイントです。重要なのは、フックがいつ実行されるかです。これによって、不正なアドレスをブロックできるのか、事後に対応するしかないのかが決まります。

訪問者に「このアドレスは配信できない可能性があります」と表示して修正してもらいたい場合は、バリデーションフィルターが必要で、多少のPHPを書くことになります。配信不能なアドレスを下流のツールに渡したくないだけなら、Webhookで十分で、コードは不要です。

ここでは、Contact Form 7のメール検証フィルターを使ったバリデーションフィルターの例を示します。同じ形はGravity FormsやWPFormsにも応用できます。変わるのはフック名（Gravity Formsではgform_field_validation、WPFormsではwpforms_process）とエラーの付け方だけです。Gravity Formsをお使いの場合は、Gravity Formsでメールアドレスを検証するガイドで、gform_field_validationフックの具体的な設定を最初から最後まで解説しています。APIキーはwp-config.phpの定数に置き、ショートコード、テーマファイル、フロントエンドのJavaScriptには決して書かないでください。

// In a snippet plugin, or your theme's functions.php.
// In wp-config.php:  define( 'QUALISEND_API_KEY', 'YOUR_API_KEY' );

add_filter( 'wpcf7_validate_email*', 'qs_verify_email', 20, 2 );
add_filter( 'wpcf7_validate_email',  'qs_verify_email', 20, 2 );

function qs_verify_email( $result, $tag ) {
    $field = $tag->name;
    $email = isset( $_POST[ $field ] ) ? trim( wp_unslash( $_POST[ $field ] ) ) : '';
    if ( $email === '' ) {
        return $result; // let the plugin's own required-field check handle it
    }

    // Check /developers for the exact endpoint and request body.
    $response = wp_remote_post( 'https://app.qualisend.com/api/v1/verify', array(
        'timeout' => 4, // don't let a slow probe stall the form
        'headers' => array(
            'Authorization' => 'Bearer ' . QUALISEND_API_KEY,
            'Content-Type'  => 'application/json',
        ),
        'body' => wp_json_encode( array( 'email' => $email ) ),
    ) );

    // Fail open: never block a real visitor because our API had a bad moment.
    if ( is_wp_error( $response ) || wp_remote_retrieve_response_code( $response ) !== 200 ) {
        return $result;
    }

    $data    = json_decode( wp_remote_retrieve_body( $response ), true );
    $verdict = $data['result'] ?? array();

    if ( ( $verdict['status'] ?? '' ) === 'undeliverable' ) {
        $result->invalidate( $tag, "That address doesn't look deliverable — please check it." );
    } elseif ( ! empty( $verdict['sub_flags']['disposable'] ) ) {
        $result->invalidate( $tag, 'Please use a permanent email address.' );
    }

    return $result;
}

このスニペットを支える要点は3つで、どの言語でも共通です。キーはサーバー側に置くこと、リクエストに短いタイムアウトを設定すること、そしてフェイルオープンにすることです。つまり、呼び出しがエラーになった場合、タイムアウトした場合、200以外が返った場合は、送信をそのまま通します。検証APIは品質フィルターであり、門番ではありません。一時的な障害のために本物のリードを失うほうが、より大きな損失です。API呼び出しの詳細（ヘッダー、エラー処理、レスポンスの形式）については、PHPでのメールアドレス検証ガイドで同じリクエストを最初から最後まで解説しています。

カスタムPHPを使えない場合、コード不要の代替手段がWebhookです。お使いのプラグインがWebhookに対応している場合（Gravity FormsはWebhooks Add-On、WPFormsはWebhooksアドオンで、どちらも上位ライセンスが対象です）、キーを保持してAPIを呼び出す小さなサーバーレス関数をWebhookの送信先にします。ただし、上の表のとおり、これらのWebhookはエントリーの保存後に実行されるため、その場でエラーを表示することはできません。できるのは、非同期で検証し、その判定に基づいて動作することです。たとえば、タグを付ける、自動返信をスキップする、配信不能なアドレスをメールツールに届く前に除外する、といった処理です。ZapierやMakeのようなノーコードのWebhookステップでも同様に動作します。フォームの送信を受け取り、APIを呼び出し、判定を返します。

プラグインがWebhookに対応しているか、カスタムPHPを実行できるかは、プラグインとそのプラン次第です。無料版のContact Form 7にはバリデーションフィルターがありますが、WebhookのUIはありません。Gravity FormsとWPFormsでは、Webhookは有料アドオンの対象です。方法を決める前に、お使いのプランに何が含まれるかを確認してください。

判定結果に応じた対応#

APIはresultオブジェクトを返します。その中には、deliverable、risky、undeliverable、unknownのいずれかを示すstatus、0～100のscore、reasonコード、そしてdisposable、role、free_mail、catch_allのサブフラグが含まれます。上のスニペットが読み取っている$data['result']と同じものです。これらをフォームの動作に対応づけます。

公開中のフォームに適しているのは、構文、ドメイン、使い捨て、役割アドレスを確認する即時のローカル判定です。応答が速く、不正な送信の大半を検出できます。負荷の高いSMTPメールボックスプローブは、数秒の遅延が問題にならない、後述の一括処理に向いています。各チェックがなぜその位置にあるのかを知りたい場合は、メール検証の仕組みで処理の流れを詳しく解説しています。

CSVエクスポートからエントリーを一括検証する#

すべてのフォームにリアルタイムのゲートが必要なわけではなく、プラグインによってはカスタムコードが扱いにくい場合もあります。コード不要の代替手段は、送信を蓄積しておき、スケジュールに沿ってクリーニングする方法です。

1. エントリーをCSVにエクスポートします。 Gravity FormsではImport/Export → Export Entries、WPFormsではPro版のエントリーエクスポートを使います。Contact Form 7は標準では何も保存しないため、無料のFlamingoプラグインを併用して、先に送信内容を記録します。
2. CSVを一括検証します。 Qualisendの一括検証にアップロードします。SMTPプローブを含む全工程が全行に対して実行され、スコア付きのファイルが返ります。
3. 絞り込んで同期します。 deliverableは残し、riskyは確認し、undeliverableは除外してから、残ったアドレスをメールプラットフォームにインポートします。

これは通常のリストクリーニングと同じ手順で、元データがフォームのエントリーテーブルというだけです。エクスポート、検証、再インポートの流れは、メールリストのクリーニングガイドで詳しく解説しています。一括検証は、リアルタイム検証を導入する前に収集済みのアドレスにも最適です。過去分を一度クリーニングし、その後は送信時のフックでリストをクリーンに保ってください。

リアルタイムか一括か、それとも併用か#

2つの方法は解決する課題が異なるため、多くのサイトでは両方が必要になります。

• リアルタイムは予防です。送信時に入力ミスを見つければ、1行の修正案内でリードを救えます。存在しないドメインをその場で拒否すれば、バウンス率を悪化させるハードバウンスにもなりません。
• 一括はクリーンアップです。転職やドメインの失効などでアドレスは劣化していくため、入口を完璧に管理しているリストでも、定期的な再検証が必要です。

送信時のフックと月1回の一括検証を組み合わせる考え方は、検証とダブルオプトインの仕組みを組み合わせるのと同じです。明らかな不正は入口で止め、残りは定期的に洗い出します。

導入の準備はできましたか？無料プランには、両方の方法を試せるクレジットが含まれています。フックやサーバーレス関数に必要な/verifyリクエストの詳細はAPIリファレンスで確認でき、コードを書く前に個別のアドレスを試すなら無料メールチェッカーが便利です。