自分自身に転送したメールがスパムに入った理由 — 編集用イラスト

read receipts

自分自身に転送したメールがスパムに入った理由

あなたは何も間違っていません。SPFが原因です。プロバイダーの誰も説明しない仕組みをここで解き明かします。

·3分で読めます

古いアカウントから新しいアカウントへの自動転送を設定すると、メールの一部が静かにスパムに消えます。プロバイダーが壊れているからではなく、転送がメッセージの送信元を書き換えるのに対して、暗号証明を書き換えないからです。SPFは間違ったサーバーをチェックし、DMARC判定は失敗に反転し、自分自身に送った正当なメールが隔離されます。この修正の名前はARC、2019年にRFC 8617で定義されたものです。

転送によってメールがSPFに失敗するのはなぜですか?

SPFはメッセージをリレーした最後のサーバーをチェックし、転送がそのサーバーを変更するからです。SPF(Sender Policy Framework)はドメインのメール送信が許可されているIPアドレスを列挙するDNSレコードです。bank.comが領収書を送信すると、受信側サーバーはチェックします。このメールは認可されたIPアドレスからbank.comを代表して到着しましたか?はい。パスです。

次に、その領収書をGmailから新しいアドレスに転送します。Googleのサーバーがそれをリレーして送信します。最終的に受信側サーバーはSPFチェックを実行し、次のように尋ねます。Googleはbank.comの代表としてメール送信が認可されていますか?いいえ、認可されていません。SPF失敗です。Googleの自社Workspaceドキュメンテーションは明白に説明しています。転送されたメッセージがSPFに失敗する理由は、転送サーバーが元のドメインのSPFレコードに入っていないからです。何もなりすまされていません。チェックが単に間違ったホップを見ているのです。

ではそれはなぜスパムに送られるのですか?

DMARC。単独ではSPF失敗は以前は耐えられていました。DMARCはそれを判定に変えました。DMARCはSPFとDKIMを結びつけ、両方が失敗した場合の対処を受信者に指示します。何もしない、隔離、または拒否です。2024年までに、大規模な送信者に選択肢はありませんでした。GoogleとYahooはユーザーに1日5000件以上のメッセージを送信する誰もがDMARCを要求し始めました。

もう一つの柱であるDKIMはメッセージに焼き込まれた署名です。理論的には転送を生き残ります。ルートではなくコンテンツに署名するからです。実際には、メッセージに触れるものは何でもそれを壊します。「購読しています、こちらでアンサブスクライブ」フッターを追加するメーリングリスト、件名行を書き換えるサーバー、行の折り返し方の変更さえも、署名はもう一致せず、DKIMも失敗します。今や両方の柱が倒れ、DMARCは失敗と言い、自分自身の領収書はジャンクフォルダにあります。

ARCとは何ですか、本当にこれを修正しますか?

ARC(Authenticated Received Chain、RFC 8617)は、正直な転送者がメールがそれに触れる前に認証を通過したことを保証することを許可します。転送サーバーはメッセージに密閉レコードでスタンプを押して「これが私に到達した時、SPFとDKIMは有効でした。検証できないレッグについては私の言葉を信頼してください」と言います。最終受信者は、その転送者を信頼すれば、DMARC失敗を上書きして配信できます。

引っかかりは「信頼する場合」にあります。ARCはパスワードではありません。それは評判システムです。受信者はARCシーラーが既知の、行動の良いオペレーターであるかどうかを判断します。GoogleはARCヘッダーにスタンプを押し、信頼する送信者からのものに尊重を与えます。これがGmailからGmailへの転送は通常、生き残る一方で、古い大学リレーを通した転送は生き残らない理由です。

転送を自分で実行する場合、2つの具体的な対策が役に立ちます。ホストが提供する場合、Server-Side Redirect/SRSスタイルの書き換えを使用してください。これはエンベロープ送信者を書き換えるため、SPFチェックは元のドメインではなくあなたの転送者に対して行われます。また、ARC両方をサポートするプロバイダー間での転送を選んでください。アカウントを統合し、宛先が認証の混乱を処理するようにしたい場合、それはまさにAIメールプラットフォームが吸収するために構築されている配管の種類です。

プロバイダーを非難するのをいつやめるべきですか?

パターンが「転送されたメールだけ失敗する」場合、プロバイダーは正しく仕事をしています。プロトコルが問題です。ここが識別ポイントです。見落とされたメッセージのヘッダーを開いて、Authentication-Results行を探してください。元の送信者ではなく転送者に属する送信IPと一緒にspf=failが表示される場合、それはSPFが間違ったホップをチェックしています。リストまたはメッセージを編集するリレーを通ったメールでdkim=failが表示される場合、それは偽造ではなく、歪んだ署名です。

不快な真実は、メール認証が2十年にわたって層ごとに、誰もが嘘をつくと想定しなかったシステムにボルトで留められたということです。SPFは2006年に来て、DKIMは2007年に、DMARCは2015年に、ARCは2019年に来ました。各々が最後のものが開けた穴をパッチします。転送は4つが互いにこすり合う継ぎ目であり、あなたのインボックスはその摩擦を感じるところです。

daily messages that trigger Google & Yahoo's DMARC requirement (2024)

出典

  1. IETF RFC 8617 — Authenticated Received Chain (ARC) specification, 2019
  2. Google Workspace Admin Help — SPF, forwarding and authentication for forwarded mail
  3. Google Email sender guidelines — 2024 bulk sender DMARC requirements and 5,000/day threshold

← すべての記事