IP評価チェック
送信IPを主要なブラックリストとレピュテーションDBで確認します。
IPレピュテーションとは
IPレピュテーションとは、メール送信やオンライン活動の履歴に基づく、IPアドレスの信頼度です。メールサーバーやセキュリティシステムは、特定のIPからのメールを配信するか、迷惑メールとして扱うか、ブロックするかの判断に使います。影響する要素は、迷惑メールの苦情、送信量、ブラックリストへの掲載、受信者の反応などです。このチェックはアドレスの逆引きDNSも照会し、IPをホスト名に対応付けるPTRレコードを返します。メールボックスプロバイダーは送信IPにPTRレコードがあることを前提にしており、PTRがないと、ほかに問題のないIPからのメールでも不審と見なされることがよくあります。
メール認証ナレッジベース
逆引きDNSとは
逆引きDNSは、IPアドレスからどのホスト名に対応するかをDNSに問い合わせる仕組みです。答えはPTRレコードから返ります。PTRは自社ドメインのゾーンではなく専用の名前空間で公開されます。IPv4アドレスはオクテットを逆順にしてin-addr.arpaの下に置かれ、192.0.2.25は25.2.0.192.in-addr.arpaとして照会されます。IPv6アドレスはip6.arpaの下です。ホスト名からアドレスを返す通常の照会とは逆方向です。このツールは入力したIPで照会を実行し、返ったホスト名を表示します。PTRレコードがなければ、そのことをはっきり示します。
送信メールサーバーに逆引きDNSが必要なのはなぜ?
受信側のメールサーバーは、SMTP接続を開いた相手の基本的な身元確認に逆引きDNSを使います。PTRレコードのないIPは匿名に見え、それだけでメールを不審と見なしたり拒否したりする受信側もあります。Googleの送信者ガイドラインは、大量送信者に正引きと逆引きのDNSが有効なIPアドレスからの送信を求めています。設定を探す前に知っておきたいのは、通常PTRレコードは自分では公開できないことです。逆引きDNSはIPアドレス帯の所有者(ホスティング事業者、クラウド基盤、メールサービス)が管理するため、PTRがないときは自社のDNSゾーンを編集するのではなく、所有者に依頼するのが普通です。
正引き確認付き逆引きDNSとは
正引き確認付き逆引きDNS(FCrDNS)は、双方向で確認する仕組みです。IPアドレスを照会してPTRレコードからホスト名を得たら、そのホスト名をIPv4ならAレコード、IPv6ならAAAAレコードで照会し、元のIPアドレスが答えに含まれるか確かめます。PTRレコードだけでは誰かが名前を公開したことしか証明できません。正引きで確認すると、名前とアドレスが互いに一致することが証明でき、身元のシグナルとして役立ちます。RFC 1912は、インターネット上のホストでPTRとアドレスのレコードを一致させるよう推奨しています。このチェックに通っても認証に通ったことにはならず、メールがSPF、DKIM、DMARCをパスしたかは何も示しません。
IPレピュテーションが到達率に重要なのはなぜ?
IPレピュテーションは、メールサーバーがメールをどう受け止め、どう扱うかを決めるため、到達率に大きく影響します。メールを送ると、受信側のサーバーは送信IPのレピュテーションを確認し、受信トレイに届けるか、迷惑メールとして扱うか、完全にブロックするかを判断します。苦情が少ない、送信量が安定している、認証が正しいといった良い送信習慣で築いた高いIPレピュテーションがあれば、メールは受信者に届きます。逆にIPレピュテーションが低いと、メールが迷惑メールフォルダに振り分けられたり拒否されたりして、連絡やマーケティングに大きな支障が出ます。
IPレピュテーションを下げる要因は?
IPレピュテーションを下げ、到達率を妨げる要因はいくつかあります。大きいのは迷惑メールの苦情率の高さです。報告が頻繁だと、メールが望まれていないとプロバイダーに伝わります。無効なアドレスや古いアドレスに送るとバウンス率が高くなり、リストの管理不足を示します。ブラックリストへの掲載も大きな問題で、多くはスパムに似た内容の送信やベストプラクティス違反が原因です。特に適切なIPウォームアップなしの急な送信量の増加は、受信側のサーバーに疑われます。開封率やクリック率が低いと受信者の関心がないと見なされ、さらに評価が下がります。購入したリストや収集したリストを使うと、スパムトラップに当たり、反応のない受信者も増えがちです。SPF、DKIM、DMARCといったメール認証を正しく導入していないと、メールの信頼性が低く見え、迷惑メールと判定されやすくなります。
専用IPと共有IPでは、レピュテーションにどんな違いがありますか?
専用IPと共有IPの主な違いは、レピュテーションの築かれ方と維持のされ方です。専用IPは1つの送信者だけが使うため、IPレピュテーションはその送信者のメール運用だけで決まります。到達率を完全に自社で管理でき、大量に送信し、安定したレピュテーションを築きたい企業に向いています。一方、共有IPは複数の送信者が使い、レピュテーションは利用者全体の行動で決まります。単独でレピュテーションを築けるほど送信量がない小規模な送信者には利点がありますが、リスクもあります。同じIPを使う他の送信者がスパム送信のような悪い運用をすると、全員の到達率が下がります。どちらを選ぶかは、送信量、送信の安定性、レピュテーションをどこまで自社で管理したいかで決まります。
下がったIPレピュテーションの回復にかかる期間は?
下がったIPレピュテーションの回復には、被害の大きさと対処内容によって、数日から数週間かかります。苦情のわずかな増加や一時的な送信量の急増といった軽い問題なら、送信方法を改善してリストを整理すれば、数日で解決することもあります。しかし、IPがブラックリストに載った場合や、悪い送信習慣が続いていた場合は、完全な回復に数週間から数か月かかることがあります。回復を早めるには、苦情を減らし、反応率を高め、SPF、DKIM、DMARCでメールを認証し、少量で安定した送信(IPウォームアップ)で少しずつ信頼を取り戻すことが重要です。改善を確かめ、長期的に到達率を保つには、IPレピュテーションの定期的な監視が欠かせません。
ブラックリスト掲載はIP評価にどう影響しますか?
ブラックリストへの掲載は、IPレピュテーションと到達率に大きな悪影響を与えます。IPアドレスがブラックリストに追加されると、メールプロバイダーや迷惑メールフィルターに、そのメールが不審または不要かもしれないと伝わります。その結果、メールはブロックされたり受信者の迷惑メールフォルダに入ったりしやすくなり、開封率や反応が大きく下がります。掲載の理由はさまざまで、スパムに似た内容の大量送信、過剰な苦情、スパムトラップへの送信、リスト管理の不備などがあります。ブラックリストに長く載るほどレピュテーションは下がるため、原因を特定してすぐに解決し、掲載解除を依頼することが欠かせません。定期的な監視と良い送信習慣が、掲載を防ぎ、健全なIPレピュテーションを保つ鍵です。
新しいIPでも評価が低いことはありますか?
はい、新しいIPアドレスでもレピュテーションが低いことはあります。通常はメールの送信を始めるまで「中立」と見なされますが、以前に悪い送信習慣の送信者に割り当てられていた場合、低いレピュテーションを引き継ぐことがあります。その場合、最初のメールを送る前から到達率の問題が起きかねません。また、レピュテーションが確立していない新しいIPは、メールプロバイダーに慎重に扱われることがあります。そのため、送信量を少しずつ増やして信頼を築く「ウォームアップ」が欠かせません。IPのレピュテーションを監視し、正しいメール認証(SPF、DKIM、DMARC)、リストの整理、高い反応率といったベストプラクティスを実践すれば、良いレピュテーションを築き、長く保てます。
IPとドメインのレピュテーションの違いは?
IPレピュテーションとドメインレピュテーションは、どちらも到達率に重要ですが、信頼度を別の角度から評価します。IPレピュテーションは、特定のIPアドレスに結び付いた送信の振る舞いに基づきます。メールプロバイダーは、迷惑メールの苦情、バウンス率、送信パターンなどから、そのIPのメールを配信するかブロックするかを判断します。これは、送信者がIPのレピュテーションを完全に管理できる専用IPを使う企業で特に重要です。一方、ドメインレピュテーションはIPアドレスではなく送信者のドメインに注目します。異なるIPやメール配信サービスをまたいでドメインに付いて回るため、より一貫した信頼の指標になります。IPアドレスを変えても、ドメインレピュテーションが低ければ到達率は下がります。メールプロバイダーは、ブラックリストを逃れるためにIPを頻繁に変える悪用を防ぐために、ドメインレピュテーションを使います。要するに、IPレピュテーションはメールを送るインフラに、ドメインレピュテーションは送信者の身元に結び付いています。どちらも重要で、両方を良好に保つことで受信トレイへの到達とメール全体の成果が高まります。
IPレピュテーションの監視頻度は?
IPレピュテーションは定期的に監視してください。頻度は送信量と業務上の必要性で決まります。毎日、特に大量に送信する企業なら、到達率に影響する問題をすぐに見つけて対処できるよう、毎週、あるいは毎日の監視をおすすめします。送信頻度が低ければ月1回のチェックで足りることもありますが、重要なキャンペーンの実施中や、反応が急に落ちたときは、頻度を上げると効果的です。先回りの監視で、ブラックリスト掲載、迷惑メールの苦情、バウンス率の上昇などを早く見つけ、メールの成果が損なわれる前に対処できます。自動のレピュテーション監視ツールを使えば作業を効率化でき、変化があればリアルタイムで通知を受けられます。
DMARC、SPF、DKIMのタグと仕組みを1か所でまとめて解説します。
DMARC
- vバージョン
- バージョンタグはDMARCレコードに必須で、値は「DMARC1」に限られます。値が正しくない場合やタグがない場合、DMARCレコードは無効とみなされ、無視されます。
- pポリシー
- DMARCポリシータグは、DMARCに失敗したメールについて3つの値を取ります。noneは隔離・拒否を求めず、quarantineは不審なメールとしての扱いを、rejectは受信拒否を求めます。最終的な処理は受信側が決め、p=noneでも別の仕組みで振り分けや拒否をする場合があります。集計レポートは、ruaタグで別途要求します。
- rua集計レポートの送信先
- 集計レポートの送信先を「mailto:」形式のURIで指定します。受信側のメールボックスプロバイダーがこの宛先に集計レポートを送ります。必須ではありませんが、省略するとレポートは届きません。
- ruf失敗レポートの送信先
- 失敗(フォレンジック)レポートの送信先を「mailto:」形式のURIで指定します。失敗レポートを送る受信側プロバイダーはここへ届けますが、送らない事業者も多くあります。このタグがないと失敗レポートは届きません。
- spspポリシー
- サブドメインのポリシーは、特に指定がない限り、前述のメインドメインのポリシータグ(p=)を継承します。指定できる値はドメインのポリシーと同じく「none」「quarantine」「reject」です。ただし、現在の運用ではあまり使われていません。
- adkimDKIMアライメント
- DKIM署名のアライメント、つまりDKIMのドメインとヘッダーFromの送信元ドメインとの一致を指定するタグです。値は「r」(relaxed)と「s」(strict)です。既定の「r」はドメインの部分一致を許容し、「s」はドメインの完全一致を求めます。
- aspfSPFアライメント
- SPFアライメント、つまりSPFのドメイン(送信元)とヘッダーFromのドメインとの整合性を指定するタグです。値は「r」(relaxed)と「s」(strict)の2つです。既定は「r」で、ドメインの部分一致を許容します。一方「s」では、ドメインの完全一致が必要です。
- fo失敗レポートの条件
- 失敗レポートのオプションは「0」「1」「d」「s」です。既定の「0」は、SPFとDKIMのアライメントがどちらもパスしない場合にのみ失敗レポートを生成します。「1」は、SPFかDKIMのどちらかがパス以外の結果になった場合に使います。「d」はDKIMの検証失敗、「s」はSPF関連の問題についてレポートを生成します。失敗レポートを実際に受け取るには、「ruf」タグの指定が必要です。
- rf失敗レポートの形式
- 失敗レポートの形式は「afrf」と「iodef」の2つから選べます。
- pct適用割合(旧仕様)
- 旧来の適用割合タグは、DMARCに失敗したメールの一部にだけquarantineやrejectを適用するよう受信側に求めるものでした。受信側の実装がばらついたため、RFC 9989でpctは廃止されました。新しいレコードでは省略し、集計レポート、ポリシー全体の変更、送信量の少ないサブドメインで段階的に移行します。
- riレポート間隔
- レポート間隔は、XMLレポートを受け取る頻度を秒単位で指定します。標準値は86400秒で、1日1回のレポートにあたります。ただし、指定した間隔にかかわらず、インターネットサービスプロバイダー(ISP)は通常、独自のスケジュールでレポートを送ります。多くの場合、それも1日1回です。
SPF
- v
- バージョンタグの値は「spf1」のみです。誤りや欠落があると、SPFレコードは無視されます。
- ip4
- そのドメインでメール送信を許可するIPv4アドレスを指定します。
- ip6
- そのドメインの名義でメール送信を許可するIPv6アドレスを指定します。
- a
- ドメインのIPアドレス(Aレコード)で送信元を検証します。指定がなければ現在のドメインが対象です。
- mx
- メールサーバーのMXレコードで送信元を検証します。指定がなければ現在のドメインが対象です。
- ptr
- 接続元IPのホスト名をPTRで照合します。DNSルックアップが多すぎるため、RFC 7208では非推奨です。
- exists
- 指定したドメインにAレコードが存在するかを確認します。
- include
- 正確なSPFレコードに欠かせないタグです。指定したドメインやサブドメインを、正規の送信元として受信側に示します。
- all
- SPFレコードの末尾に置くメカニズムです。限定子(~、+、-、?)で、記載のない送信元からのメールの扱いを受信側に示します。RFC 7208では必須ではなく、ない場合の結果はneutralです。
DKIM
- v
- 任意のタグです。指定する場合は値を「DKIM1」とし、レコードの先頭に置きます。
- p
- 公開鍵のタグです。DKIMの設定時に生成される文字列で、空のままでは有効になりません。
- t
- フラグをコロン区切りで列挙するタグです。定義済みのフラグは「y」と「s」で、未定義のフラグは無視されます。
- s
- レコードが対象とするサービスの種類を示すタグです。指定がない種類や不明な種類は、受信サーバーが無視します。
- h
- 許可するハッシュアルゴリズムを指定するタグで、既定ではすべて許可します。一覧は送信側が決め、受信側は不明なアルゴリズムを無視します。
- n
- 管理者向けの任意のメモ欄です。必要なときだけ使うことを推奨します。