ドメインのレピュテーション確認
メールドメインのレピュテーションを公開ソースで確認し、各結果の意味を理解して、到達率を左右する送信IPやメールの証拠と結び付けます。
ドメインレピュテーションとは
ドメインレピュテーションとは、メールボックスプロバイダーや迷惑メールフィルターが送信ドメインをどれだけ信頼するかの評価です。メールが受信トレイに届くか、迷惑メールフォルダに入るか、まったく届かないかを左右します。苦情率、バウンス率、受信者の反応、SPF・DKIM・DMARCによる認証の有無で決まります。IPレピュテーションと違ってドメイン自体に付くため、送信サービスを変えてもリセットされません。
ドメインレピュテーションの結果の見方
| 結果 | 意味 | 対処法 |
|---|---|---|
| 掲載 | ドメインか、その背後のWeb・メールサーバーのIPが、応答したブロックリストの1つ以上に記録されています。 | 各掲載の根拠を開き、送信方法や乗っ取りなど根本の問題を直してから、各運営者の審査手続きに従ってください。 |
| 正常 | 応答したブロックリストはいずれも、ドメインとサーバーIPのどちらも掲載していません。 | 対応は不要ですが、ブロックリストで正常なのは到達率の証拠の一部にすぎません。 |
| 正常(ドメイン用リストは応答なし) | ドメイン用ブロックリストは応答しませんでしたが、ドメインのWeb・メールサーバーのIPは確認でき、正常でした。 | 部分的な証拠として扱い、対応中のインシデントで重要なら後で再実行してください。 |
| 不明 | どのブロックリストも応答せず、判断できる証拠がありません。 | 正常ではなく不明として扱い、少し待って再度お試しください。 |
| 「未確認」のリスト | そのブロックリストが照会を拒否、タイムアウト、回数制限したか、アドレスの種類に対応していません。 | そのソースは不明として読みます。上の判定では、応答しなかったリストは合計から除外済みです。 |
| MXレコードがない | ドメインがメールホストを公開しておらず、確認できる受信経路の宣言がありません。送信側はRFC 5321の暗黙のMXルールに従い、アドレスレコードに送ります。 | MXチェックで確かめ、送信専用のドメインならnull MXを公開してください。 |
このチェックが実際に照会する内容
チェックごとに2つの層を実行します。ドメイン自体は、メールフィルターが参照する主要なドメイン用ブロックリストへ。その背後のインフラ、つまりWebサーバーのIPと最初のメールホストのIPは、より多くのIP用ブロックリストへ照会します。2つ目の層が重要なのは、多くのネットワークではドメイン用リストだけでは使える結果が返らず、また見た目は正常なドメインが除外され始める原因として、サーバーの乗っ取りがよくあるためです。
各ブロックリストには2回照会します。1回は対象のドメイン、もう1回は必ず応答が返るテスト用エントリです。この2回目で「掲載なし」と「このソースが応答を拒否した」を区別します。主要なリストの中には、未登録や公開のリゾルバーに黙って何も返さないものがあり、確かめないと正常な応答と見分けられません。この検証に失敗したソースは「未確認」とし、正常に数えずに合計から除外します。
インシデントの状況とあわせて確認
差出人に表示されるドメインを入力し、キャンペーンやメールの経路、送信時刻、送信サービス、報告された症状を記録しておきます。ドメインのチェックは、特定の配信トラブルと結び付けたときに最も役立ちます。拒否や迷惑メール判定が問題なら、元のメールのヘッダーかバウンスを調べ、実際の送信IPと認証の識別子を特定してください。
ドメインが正常でも受信トレイは保証されない
公開されたドメイン情報は証拠の一部です。メールボックスプロバイダーは、非公開のレピュテーション、苦情、反応、受信者ごとのシグナルも持っており、このチェックでは参照できません。WebサイトのホストのIPが、メールの送信システムと無関係なこともあります。確認できた送信アドレスをIPレピュテーションで調べ、代表的なメールをメール送信テストで送ってください。
関連する評価チェック
メール認証ナレッジベース
このチェックでわかること、わからないことは?
公開ブロックリストが現在、ドメインやその背後のサーバーを記録しているかがわかります。メールボックスプロバイダーが非公開でどう評価しているかはわかりません。Gmail、Microsoft、Yahooはそれぞれ独自のレピュテーションシグナル(苦情率、反応、受信者単位の履歴)を持ち、外部ツールからは読めません。ブロックリストは正常なのにメールが迷惑メールに入るのは、よくある、意味のある組み合わせです。問題は公開の掲載ではなく、非公開のシグナルか認証にあります。
「掲載なし」ではなく「未確認」と出るのはなぜ?
意味が違い、混同すると誤解を招くからです。主要なブロックリストの中には、公開や未登録のリゾルバーからの照会を拒否し、何も返さないものがあり、正常な応答とまったく同じに見えます。そのため各リストに2回照会します。1回は対象のドメイン、もう1回は必ず応答が返るテスト用エントリです。テスト用の照会に失敗したソースは「未確認」とし、正常に数えずに合計から除外します。
ドメインとIPのレピュテーションの違いは?
ドメインレピュテーションは、どこから送ってもドメインに付いて回るため、送信サービスを変えてもリセットされません。IPレピュテーションはメールの送信元アドレスに付くもので、多くの企業では自社で管理できない送信サービスの共有インフラです。どちらも配信に影響します。実務上のルールは、自社の責任であるドメイン側の原因を直し、IPの問題を自社で直すべきと考える前に、メールヘッダーから実際の送信IPを特定することです。
ドメインだけでなくWebサーバーのIPも確認するのはなぜ?
Webサイトの乗っ取りは、それまで正常だったドメインが除外され始める最も多い原因の1つだからです。WebホストのIPがマルウェアやスパムの配布で掲載されていると、メールがまったく別の送信サービス経由でも、ドメインの評価に響きます。インフラの層は、ドメイン用リスト自体が応答しないネットワークでも使える結果を返します。
ドメインが掲載されました。解除するには?
掲載解除を認めるのは各リストの運営者で、チェックツールではありません。各掲載の根拠を開き、乗っ取られたアカウント、悪用されたフォーム、購入リスト、乗っ取られたサブドメインといった根本原因を直してから、運営者の審査手続きに従ってください。原因を直す前に解除を依頼すると、たいてい再掲載され、最低掲載期間が長くなることもあります。
新しく取得したドメインでも問題はありますか?
はい、2つあります。取得前に他人が登録して悪用していた可能性があるため、まっさらと思い込まず履歴を確認してください。また、送信履歴のない新しいドメインは最初から慎重に扱われるため、初日に大量に送るとうまくいかないことが多いです。どちらも掲載ではありませんが、配信に影響します。
メール認証とレピュテーションの関係は?
認証があって初めて、レピュテーションが自社のものとして扱われます。SPFとDKIMで、受信側はメールが自社ドメインの正規の送信元から来たと確認でき、DMARCはどちらも一致しないときの扱いを伝えます。認証がないと、自社ドメインになりすます誰もがドメインの評価に影響し、どのメールが本当に自社のものか証明できません。
確認の頻度は?
送信サイクルを無駄にする前に掲載に気付ける頻度で確認します。大量送信なら毎週、たまに送るなら毎月、メールが届かないという報告があれば直ちに確認してください。単発のチェックでわかるのは実行した時点だけなので、すぐに知る必要があることは継続して監視する必要があります。
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
- 管理者向けの任意のメモ欄です。必要なときだけ使うことを推奨します。