EN / JA
Server & WordPress

メール到達率：コンタクトフォームのためのSPF、DKIM、DMARC設定

· 4 min read

正当なメールの約20%は受信トレイに届きません。スパムフォルダに振り分けられるか、ゲートウェイで隔離されるか、受信サーバーに静かに破棄されます。パスワードリセット、注文確認、請求書などのトランザクションメールにとって、この数字は十分に深刻です。しかしコンタクトフォームの送信メールの場合はさらに厄介です。メッセージが失われたことに誰も気づかないからです。顧客は連絡したと思っています。あなたは何も受け取っていません。取引は沈黙の中で消えます。

WordPressサイトでコンタクトフォームを運用しているなら、email deliverability（メール到達率）は他人の問題ではありません。あなた自身の問題です。そしてボットがそのフォームを攻撃しているなら、緊急の問題です。

このガイドでは、フォーム送信メールが受信トレイに届くかどうかを決定する3つのDNSベースの認証プロトコル――SPF、DKIM、DMARC――を解説し、これらのいずれかが未設定または設定ミスの場合にスパムボットの悪用がどのようにダメージを加速させるかを説明します。

問題：コンタクトフォームのメールが消えている

毎週数千のWordPressサイトで繰り返されているシナリオを紹介します。

訪問者がContact Form 7のフォームに記入し、送信ボタンをクリックします。サーバーは受信トレイに通知メールを送信します。訪問者は成功メッセージを見て、メッセージが届いたと確信します。しかしメールは届きません。Gmailに拒否されたか、Microsoft 365にフラグを立てられたか、企業のメールゲートウェイに静かに破棄されたかです。

スパムフォルダを確認します。何もありません。サーバーログを確認します。メールは送信されています。wp_mail()はtrueを返しました。SMTPハンドシェイクも完了しています。メッセージはサーバーから送出されています。

では、どこに行ったのでしょうか？

受信サーバーがあなたを信頼できないと判断した

最新のメールサーバーはメールの本文だけを見るわけではありません。件名を読む前に、3つのことをチェックします：

  1. 送信サーバーはこのドメインのメールを送信する権限があるか？（SPF）
  2. メッセージは、送信元と称するドメインによって暗号的に署名されているか？（DKIM）
  3. 最初の2つのチェックが失敗した場合、どうすべきか？（DMARC）

ドメインにこれらのレコードが設定されていない場合、あるいは設定が間違っている場合、受信サーバーはメールが正当であるかどうかを検証する手段がありません。フィッシング攻撃やスパムと同じように扱います：疑いの目で見るか、完全に拒否します。

これは受信サーバーの過剰反応ではありません。ポリシーです。Google、Microsoft、Yahooはすべて、受信メールに対して厳格な認証要件を適用しています。2024年時点で、Googleは1日あたり5,000通以上のメッセージをGmailアカウントに配信する送信者に対して、SPFかつDKIMかつDMARCを要求しています。その閾値以下でも、認証レコードの欠如はスパムに振り分けられる確率を大幅に高めます。

スパムボットがすべてを悪化させる

認証の問題の上にボットの悪用が重なるとどうなるか。

スパムボットがコンタクトフォームのエンドポイントを発見し、数千のエントリを送信し始めます。各送信がサーバーからの通知メールをトリガーします。突然、あなたのドメインは1時間に数百通のメール――すべて医薬品キーワード、フィッシングURL、キリル文字の意味不明な文字列を含むゴミコンテンツ――を送信しています。

SPF、DKIM、DMARCレコードが完璧に設定されていても、この急増は2つのことを引き起こします：

  • ボリューム異常。 メールプロバイダーはドメインの通常の送信パターンを追跡しています。1日20通から5,000通への急増は、自動的なスロットリングまたは一時的なブラックリスト登録をトリガーします。
  • コンテンツ評判の損傷。 サーバーが忠実に中継した通知メール内のスパムペイロードが、ドメインのコンテンツ評判スコアを汚染します。フィルターはあなたのドメインからのメールにスパムのようなコンテンツが含まれることを学習します。

認証レコードはメールが本当にあなたから送信されたことを証明します。それが問題なのです。あなたはゴミの洪水を認証してしまい、ドメインがそれを所有することになります。

技術詳解：SPF、DKIM、DMARC

これら3つのプロトコルは信頼の連鎖として機能します。それぞれが認証パズルの特定のピースを解決します。順に解説します。

SPF（Sender Policy Framework）

SPFは一つの質問に答えます：あなたのドメインに代わってメールを送信する権限を持つサーバーはどれか？

ドメインに公開されたDNS TXTレコードを通じて機能します。受信メールサーバーがyou@yourdomain.comからのメッセージを受け取ると、yourdomain.comのSPFレコードを検索し、送信サーバーのIPアドレスが認可リストにあるかどうかをチェックします。

設定方法

SPFレコードはルートドメインの単一のTXTレコードです。一般的な例を示します：

yourdomain.com.  IN  TXT  "v=spf1 ip4:203.0.113.50 include:_spf.google.com include:spf.mailgun.org ~all"

内容の説明：

  • v=spf1 — これがSPFレコード（バージョン1）であることを宣言。
  • ip4:203.0.113.50 — この特定のIPアドレスに対して、ドメインのメール送信を直接認可。これはWebサーバーまたは専用SMTPサーバーになります。
  • include:_spf.google.com — Google WorkspaceのSPFレコードに記載されたサーバーを認可。Gmail/Google Workspaceでメールを送信する場合に使用。
  • include:spf.mailgun.org — Mailgunのサーバーを認可。使用するトランザクションメールプロバイダー（Postmark、SendGrid、Amazon SESなど）に置き換えてください。
  • ~all — リストにないサーバーに対するソフトフェイル。受信サーバーにメッセージを受け入れるが疑いの目で見るよう指示。-all（ハードフェイル）はより厳格で、受信者に不正な送信者を完全に拒否するよう指示します。

よくある間違い

  • SPFレコードが存在しない。 驚くほど一般的です。これがないと、インターネット上のどのサーバーでもあなたのドメインとしてメールを送信でき、受信サーバーにはそれを拒否する根拠がありません。
  • DNSルックアップが多すぎる。 SPFには評価あたり10回のDNSルックアップというハード制限があります。各include:ディレクティブは少なくとも1回のルックアップをトリガーします。ネストされたinclude（includeされたドメインのSPFレコードが独自のinclude:を含む場合）もカウントに含まれます。10回を超えるとSPFチェック全体がpermerrorを返し、ほとんどの受信者はこれを失敗と同じに扱います。
  • 複数のSPFレコード。 ドメインあたり1つのSPF TXTレコードのみが許可されます。2つある場合（新しいメールサービスを追加して統合を忘れた場合に一般的）、結果は未定義の動作になり、ほとんどのサーバーはチェック全体を失敗させます。
  • +allの使用。 インターネット上のすべてのサーバーにドメインとしての送信を認可します。SPFレコードがないのと同じですが、意図的に見える分さらに悪い。

WordPress固有の考慮事項

WordPressサイトがサーバーのローカルなsendmailまたはPHPのmail()関数を通じてフォーム通知メールを直接送信している場合、送信IPはWebサーバーのIPです。そのIPがSPFレコードに含まれている必要があります。共有ホスティングの場合、そのIPは潜在的に数百の他のサイトと共有されています。それらのスパム問題があなたの到達率に影響します。

これは、サーバーのローカルメールトランスポートに頼らず、専用のSMTPサービスを通じてWordPressメールをルーティングすべき最も強い理由の一つです。

DKIM（DomainKeys Identified Mail）

DKIMは別の質問に答えます：このメールは実際に送信元と称するドメインから送信されたものか、そして送信中に改ざんされていないか？

SPFはサーバーをチェックします。DKIMはメッセージそのものをチェックします。

仕組み

DKIMは公開鍵暗号を使用します。メールサーバーがメッセージを送信する際、主要なメッセージヘッダー（From、Subject、Date）と本文の暗号署名を生成し、その署名をDKIM-Signatureヘッダーとして添付します。署名の生成に使用される秘密鍵はメールサーバーに保管されます。対応する公開鍵はDNS TXTレコードで公開されます。

受信サーバーがメッセージを受信すると、DKIM署名を抽出し、DNSから公開鍵を検索し、署名を検証します。一致すれば、受信サーバーは2つのことを確認できます：(1) メッセージがあなたのドメインから本当に送信されたこと、(2) 送信中に誰も改ざんしていないこと。

DNSレコードの例

DKIM公開鍵はセレクターを含むサブドメインのTXTレコードとして公開されます。セレクターは、複数のDKIM鍵（異なるサービスや鍵ローテーション用）を持つための任意のラベルです。

selector1._domainkey.yourdomain.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1Z2..."

内容の説明：

  • selector1 — セレクター名。メールプロバイダーが指定します。Google Workspaceはgoogle、Mailgunはmailoのようなもの、Postmarkは20221121のような日付付きキーを使用します。
  • _domainkey — DKIMの仕様で必須の固定サブドメイン。
  • v=DKIM1 — DKIMバージョン。
  • k=rsa — 鍵のアルゴリズム（RSAが標準、Ed25519のサポートも拡大中）。
  • p=MIIBIj... — 実際の公開鍵（base64エンコード）。

よくある間違い

  • DKIMを有効にしていない。 多くのホスティングプロバイダーやSMTPサービスはDKIMをサポートしていますが、デフォルトでは有効になっていません。明示的にキーペアを生成し、DNSレコードを公開する必要があります。
  • プロバイダー切り替え後の古いキー。 MailgunからPostmarkに移行したが、DNS上にMailgunのDKIMレコードを残し、Mailgun側から鍵を削除した場合、古いキーで署名されたメッセージは検証に失敗します。
  • 鍵長が短すぎる。 RSA鍵は最低1024ビットであるべきで、2048ビットが現代の標準です。一部の古い設定ではまだ512ビットの鍵が使われていますが、これは脆弱とされています。

DKIMがコンタクトフォームに重要な理由

WordPressサイトがDKIM署名付きの適切に設定されたSMTPサービスを通じてフォーム通知を送信する場合、受信サーバーはメッセージがあなたのドメインから送信されたことを暗号的に検証できます。DKIMなしでは、フォーム通知にわずかでも怪しい要素（URL、HTMLフォーマット、特定のキーワード）が含まれている場合、スパムフォルダ行きまであと一歩の状態です。

DMARC（Domain-based Message Authentication, Reporting, and Conformance）

DMARCはSPFとDKIMを統合し、認証が失敗した場合に受信サーバーが何をすべきかを指示します。

DMARCがなければ、SPFとDKIMは情報提供に過ぎません。受信サーバーはチェックできますが、ドメイン所有者が「これらのチェックが失敗したらメッセージを拒否してください」と公表するポリシーがありません。DMARCがそのポリシーを提供します。

仕組み

DMARCは2つのものを追加します：

  1. ポリシー（none、quarantine、またはreject）。SPFおよびDKIMのアラインメントチェックに失敗したメッセージの処理方法を受信サーバーに指示します。
  2. レポーティングメカニズム。認証結果に関する集約レポートとフォレンジックレポートを送信し、誰があなたのドメインとしてメールを送信しているか、パスしているか失敗しているかを確認できます。

重要な概念はアラインメントです。DMARCは、From:ヘッダーのドメインが、SPFまたはDKIMで認証されたドメインと一致する（またはそのサブドメインである）ことを要求します。これにより、攻撃者が自身のドメインでSPFをパスしつつ、From:ヘッダーであなたのドメインを偽装することを防ぎます。

DNSレコードの例

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; pct=100; adkim=r; aspf=r"

内容の説明：

  • v=DMARC1 — DMARCバージョン。
  • p=quarantine — ポリシー。 選択肢は：
  • none — 監視のみ。失敗に対してアクションを取らない。DMARCを初めてデプロイし、適用前にデータを収集する際に使用。
  • quarantine — 失敗したメッセージをスパム/迷惑メールフォルダに送信。
  • reject — 失敗したメッセージを完全にドロップ。最も厳格な設定。
  • rua=mailto:dmarc-reports@yourdomain.com — 集約レポートの送信先。受信サーバーからの日次XMLレポートで、認証のパス/失敗数を示します。PostmarkのDMARC監視ツール、dmarcian、Valimailなどのサービスでパースできます。
  • ruf=mailto:dmarc-forensic@yourdomain.com — 個別の失敗メッセージの詳細を含むフォレンジック（失敗）レポートの送信先。すべての受信者がこれを送信するわけではありません。
  • pct=100 — ポリシーをメッセージの100%に適用。ロールアウト中は下げることができます（例：pct=25でメッセージの25%のみに適用）。
  • adkim=r — DKIMアラインメントモード：rは緩和（サブドメイン許可）、sは厳格（完全なドメイン一致が必要）。
  • aspf=r — SPFアラインメントモード：rは緩和、sは厳格。

推奨されるデプロイパス

いきなりp=rejectにしないでください。推奨されるアプローチ：

  1. p=noneから開始し、ruaレポーティングを設定。2〜4週間データを収集。レポートを確認して、あなたのドメインとしてメールを送信しているすべての正当なサービスを特定します。
  2. 認証のギャップを修正。 レポートで見つかったすべての正当な送信サービスにSPF includeとDKIMレコードを追加します。
  3. p=quarantineに移行し、低い割合で開始（pct=25）。誤検出――正当なメールがスパムに振り分けられること――を監視します。
  4. 徐々にpctを100に引き上げ、すべての正当なメールが正しく認証されていることが確認できたらp=rejectに移行します。

このプロセスを飛ばすと、自分自身の正当なメールをブロックするリスクがあります。

スパムボットが送信評判を破壊する仕組み

SPF、DKIM、DMARCが完璧に設定されていても、コンタクトフォームを悪用するスパムボットは別のチャネルを通じてemail deliverabilityを台無しにします：ドメイン評判です。

メールプロバイダーはIP評判とドメイン評判の2つのレベルで評判スコアを維持しています。認証レコードはアイデンティティの問題を処理します。評判スコアは信頼の問題を処理します。完璧に認証されていても、評判が悪ければスパムフォルダに振り分けられます。

メカニズム

ボットがコンタクトフォームに押し寄せたとき、ステップバイステップで何が起こるかを示します：

  1. ボットが24時間で5,000件のフォームエントリを送信。 それぞれにスパムペイロード（偽の名前、ジャンクURL、埋め込みリンク付きのランダムテキスト）を含みます。
  2. サーバーが5,000通の通知メールを送信。 管理者の受信トレイへ（さらに悪い場合は、フォームにCCや自動返信機能があれば動的な受信者アドレスへ）。
  3. ボリュームの急増。 GoogleとMicrosoftはドメインの過去の送信量を追跡しています。1日20通から5,000通への突然の急増は、自動的なスロットリングまたは一時的なブラックリスト登録をトリガーします。
  4. コンテンツ分析。 通知メールの本文にはボットのペイロードが含まれています。スパムフィルターがこのコンテンツをスキャンします。医薬品キーワード、短縮URL、過剰なリンク、フィッシングに関連するパターンはすべて、ネガティブなコンテンツスコアに寄与します。
  5. エンゲージメントシグナルの崩壊。 通知メールが受信トレイに届いても、誰もクリックしません（ゴミだからです）。ゼロエンゲージメントは、エンゲージメントベースのフィルタリングを使用するプロバイダーにとってネガティブなシグナルです。
  6. 評判の低下。 ドメインの送信者評判スコアが下がります。これはフォーム通知だけでなく、ドメインからのすべてのメールに影響します。マーケティングメール、トランザクションメール、@yourdomain.comアドレスからの個人的なやり取りがスパムに振り分けられ始めます。

最悪のフィードバックループ

最悪のシナリオは、自動返信機能を持つフォームの場合です。送信者が提供したメールアドレスに確認メールを自動送信するフォームです。

ボットがランダムなメールアドレス（またはデータ侵害から取得した実在のメールアドレス）を入力すると、サーバーはそれらのアドレスに確認メールを送信します。受信者はこのメールを依頼していません。スパムとしてマークするか無視します。それらのアドレスの一部はスパムトラップ――ブラックリストオペレーターが迷惑メール送信者を捕捉するために保持しているメールアドレス――です。

スパムトラップにヒットすることは、DNSBL（DNSベースのブラックホールリスト）に掲載される最も早い方法の一つです。Spamhaus、Barracuda、SpamCopに掲載されると、インターネットのかなりの部分があなたのメールの受信を完全に拒否します。リスト解除は手動プロセスで、数日から数週間かかり、問題が解決されたことの証明が必要です。

DMARCレコードはp=reject、SPFとDKIMは完璧、それでもブラックリストに載ることになりました。認証はアイデンティティを証明します。意図は証明しません。

解決策：あらゆる層で到達率を守る

コンタクトフォームのemail deliverabilityを修正するには、DNS認証、送信インフラ、フォームレベルの保護の3つのレベルでの作業が必要です。

レベル1：DNSレコードを正しく設定する

これは最低限です。まだ設定していないなら、今すぐ設定してください。

SPFチェックリスト：
– ルートドメインに単一のSPF TXTレコードを公開する。
– ドメインとしてメールを送信するすべてのサービス（ホスティングサーバー、Google Workspace、トランザクションメールプロバイダー、マーケティングプラットフォーム）をincludeする。
– DNSルックアップ10回以下を維持する。必要に応じてSPFフラットニングツールを使用。
– ~allまたは-allで終わる。決して+allにしない。

DKIMチェックリスト：
– メールプロバイダーまたはSMTPリレーでDKIM署名を有効にする。
– 正しいセレクターを使用してTXTレコードとして公開鍵を公開する。
– 最低2048ビットのRSA鍵を使用する。
– dkimvalidator.comやmail-tester.comなどのツールで署名を検証する。

DMARCチェックリスト：
– p=noneと集約レポーティングから開始し、現在の認証状況を把握する。
– 認証に失敗しているすべての正当な送信者を修正する。
– 段階的にp=quarantine、次にp=rejectに移行する。
– レポートを継続的に監視する。Postmark DMARC、dmarcian、EasyDMARCなどのサービスで管理可能になります。

Google WorkspaceとMailgunを使用するドメインの最小限かつ完全なDNS設定を示します：

; SPF — GoogleとMailgunを認可し、それ以外はソフトフェイル
yourdomain.com.  IN  TXT  "v=spf1 include:_spf.google.com include:spf.mailgun.org ~all"

; DKIM — Google Workspaceキー
google._domainkey.yourdomain.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhk..."

; DKIM — Mailgunキー
mailo._domainkey.yourdomain.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3..."

; DMARC — レポーティング付きquarantineポリシー
_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100"

レベル2：WordPressメールを専用SMTPサービス経由でルーティングする

PHPのmail()関数やサーバーのローカルMTAでのメール送信をやめてください。トランザクションメールサービスを使用しましょう：

  • Postmark — トランザクションメールに特化。厳格なスパム対策ポリシーによりIPプールをクリーンに維持。優れた到達率。
  • Mailgun — 柔軟なAPIとSMTPリレー。大量送信に適しています。
  • Amazon SES — 大規模で最も安価。より多くの手動レピュテーション管理が必要。
  • SendGrid — 広く使われています。下位プランの共有IPプールにより評判はまちまち。

選択したサービスをWordPress SMTPプラグイン（WP Mail SMTP、FluentSMTP、Post SMTP）で設定します。これにより以下が得られます：

  • ホスティング隣人に汚染されない専用送信IP（またはよく管理された共有プール）。
  • サービスによる自動DKIM署名。
  • 各メッセージに何が起きたかを正確に確認できる配信ログとバウンストラッキング。
  • 問題発生時のアラート付きレピュテーション監視。

レベル3：メール生成前にスパムを阻止する

ほとんどのガイドがスキップする部分であり、間違いなく最も重要な部分です。

DNS認証と優れたSMTPサービスはインフラを保護します。しかし、スパムボットが依然として数千のフォームエントリを送信しているなら、サーバーは依然としてジャンクコンテンツ満載の数千の通知メールを送信しています。認証はそれらのメールが本当にあなたからのものであることを証明します。高品質なSMTPサービスはそれらを確実に配信します。あなたはゴミを認証し、確実に配信しているだけです。

ドメイン評判を守る唯一の方法は、スパム送信がメールを生成する前に阻止することです。

サーバーレベルのレート制限が役立ちます：

# Nginx: CF7の送信をIPあたり毎分5件に制限
limit_req_zone $binary_remote_addr zone=cf7:10m rate=5r/m;

location ~* /wp-json/contact-form-7/ {
    limit_req zone=cf7 burst=2 nodelay;
}

しかし、レート制限だけでは不十分です。最新のボットは数千のIPアドレスをローテーションします。処理パイプラインがwp_mail()に到達する前に、自動化された送信をブロックするフォームレベルの保護が必要です。

ここでサーバーサイドのスパム防止は、利便性の機能ではなく到達率のツールになります。ボットの送信を捕捉し、メールが送信される前に静かに破棄するHoneypotは、SPF、DKIM、DMARCへの投資を直接保護しています。送信しなかったスパムメール1通ごとに、ドメイン評判を低下させるデータポイントが1つ減ります。

Contact Form 7には、Samurai Honeypot for Formsがメールパイプラインに入る前にスパム送信を遮断します。多態的Honeypotフィールド、タイミング解析、サーバーサイドトークン検証による多層検出がフォーム層でボットを止めるため、通知メールが生成されず、SMTP接続は開かれず、評判を損なうコンテンツがサーバーから送出されることはありません。DNS認証設定と送信インフラの間にある、欠けていたレイヤーです。

設定の検証

すべてを設定したら、チェーン全体を検証します：

  1. SPFを確認。 MXToolbox SPF Lookupを使用して、レコードが正しくパースされ、10ルックアップ以内であることを確認します。
  2. DKIMを確認。 check-auth@verifier.port25.comにテストメールを送信するか、mail-tester.comを使用します。レポートでDKIM署名が検証されているかどうかを確認できます。
  3. DMARCを確認。 MXToolbox DMARC Lookupでレコードの構文を確認します。その後、集約レポートの到着を待ちます（通常、レコード公開後24〜48時間以内）。
  4. レピュテーションを確認。 Google Postmaster ToolsでGmailにおけるドメインの評判を確認します。Microsoft SNDSはOutlookに対して同様のことを行います。
  5. フルパスをテスト。 コンタクトフォームを送信し、通知メールを追跡します。生のヘッダーでAuthentication-Resultsを確認します。spf=pass、dkim=pass、dmarc=passが表示されることを確認してください。

パスしているヘッダーの例：

Authentication-Results: mx.google.com;
       dkim=pass header.i=@yourdomain.com header.s=google header.b=abc123;
       spf=pass (google.com: domain of noreply@yourdomain.com designates 203.0.113.50 as permitted sender) smtp.mailfrom=noreply@yourdomain.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=yourdomain.com

いずれかがfailまたはsoftfailを示している場合は、該当するDNSレコードを遡って確認し、ギャップを修正してください。

主なポイント

  1. SPF、DKIM、DMARCは任意ではない。 主要なメールプロバイダーは認証要件を適用しています。3つすべてがなければ、コンタクトフォームのメールはますますスパムに振り分けられるか、完全に拒否されます。

  2. 認証は必要だが十分ではない。 これらのプロトコルはアイデンティティを証明します。評判は保護しません。完璧に認証されたスパムメールの洪水は、同等に効果的にドメインにダメージを与えます。受信サーバーがそれが本当にあなたからのものだと知っている分、むしろより深刻かもしれません。

  3. スパム防止は到達率戦略である。 ボットの送信がメールを生成する前にブロックすることが、送信者評判を守る最も直接的な方法です。送信しなかったスパムメール1通ごとに、受けずに済むレピュテーションダメージです。

  4. 専用SMTPサービスを使用する。 WebサーバーのローカルMTAでWordPressメールを送信するのをやめてください。トランザクションメールサービスは、優れた到達率、DKIM署名、レピュテーション管理を標準提供します。

  5. 継続的に監視する。 レポーティング有効でDMARCレコードを公開する。Google Postmaster Toolsを確認する。バウンス率を監視する。到達率は「一度設定すれば完了」の設定ではなく、継続的な運用上の関心事です。

コンタクトフォームは、送信するメッセージが実際に届いてはじめて役に立ちます。SPF、DKIM、DMARCを正しく設定することが基盤です。スパムボットがパイプラインを悪用しないようにすることが、その基盤にひびが入るのを防ぎます。

この投稿はWordPressフォームのセキュリティと到達率に関するシリーズの一部です。前回の記事：スパムの隠れたコスト：IPブラックリストとサーバー負荷。

← すべてのコラム