ナレッジベース

認証済みの送信者

送信ドメインが公開しているレコードが一致している場合に、送信者の横にマークを表示する。

詳細

受信したすべてのメッセージには、Details の下に Sender checks の行があり、3つの仕組みそれぞれが何を報告したか、通過したかどうか、そして誰がそう述べたかが示される。判定は受信リレーの報告をもとに到着時に計算されるため、メッセージを開いたときに実行される検査ではなく、実際に起きたことの記録である。
判定は読み取られるものであり、再計算されるものではない。メールを受信するサーバーが、到着時点のメッセージに対して署名を検証し、その結果をメッセージの中ではなく配信そのものに添えて報告する。シールが示しているのはその結果である。ここで判定を導き直すことはない。署名を自分で検証するには、すべてのメッセージの元のバイト列を永久に保持する必要があるが、ここでのメールボックスは代わりに解析済みのスレッドを保持しているからである。ツールチップはその旨を明示し、シールに別の含みを持たせることはない。
メッセージの中に書かれた判定は決して信用しない。Authentication-Results は通常のヘッダーにすぎず、どの送信者も「通過した」と書ける。そのため、メッセージが運んでくる主張は、検証結果ではなく見知らぬ相手からの報告として表示される。シールが描かれるのは、メッセージを受け取ったサーバーが計算し、配信とともに届いた判定に対してだけである。それは、到着したメッセージの中で送信者が書き換えられない唯一の部分である。
基準にするのは DMARC と DKIM であり、SPF ではない。転送元は元ドメインのレコードに含まれないため、正当に転送されたメッセージは必ず SPF に失敗する。SPF を必須にすれば、メーリングリストやリダイレクト経由で受信トレイに届くメールの大半からシールが失われてしまう。3つすべてを通過したメッセージは Sender checks の行にその旨が表示される。すべてはそろわずに DMARC を通過したメッセージもその旨が表示され、SPF だと決めつけずに実際に失敗した仕組みの名前が示される。DMARC 通過と同時に DKIM が失敗している場合、これは失敗として扱われない。DMARC はアラインしたいずれかの仕組みで通過し、メーリングリストのフッターによって署名が壊れることが、この組み合わせの一般的な原因だからである。
フィッシング判定はこれより優先される。乗っ取られたアカウントは完全に認証されたメールを送るため、危険と判定されたメッセージにはシールを表示しない。シールはドメインが名乗ったとおりの相手かどうかに答えるものであり、メッセージが安全かどうかに答える警告を和らげることは決して許されない。
BIMI をシールの一部にしないのは意図的である。公開ロゴにマークを結び付けると、すべての検証を通過しているドメインでも、ロゴを購入していないというだけで何も表示されないことになる。それはメールではなくマーケティング予算についての事実である。ロゴは本来の場所、つまり送信者のアバターとして描画され、DMARC を通過しなかったメッセージでは表示されない。偽装されたアドレスの横にブランド自身のマークを置くことは、メールクライアントが攻撃者のためにできる最も説得力のある行為だからである。
マークがないことは、何かが失敗したという意味ではなく、何も証明されなかったという意味である。これらの検証が存在する前に保存されたメールには判定がまったくないため、得ていない合格を借りるのではなく「not checked」と表示される。