AR ホームベーカリー

オイラのアウトプット用ホームベーカリー!

SPF レコード

よく「受信側だっけ、送信側だっけ」となりがちなのでメモ。

  • 基本的に送信側のドメインに書く
  • 「おらが送信元はここだべ!」という証明
  • spf=v1 a mx -all のように、「該当するレコードを信頼してくれ〜」という概念
    • a mx のように特定のレコードタイプを雑に指定する以外に、複数の IP など列挙したい場合、 include:example.com のように書ける
      • AWS SES とか Gmail とか SaaS サービスに独自ドメインを持ち込んだことがある人は「進研ゼミでやったとこだ!」となると思う

識別子

?all ~all -all などあるのは受信側の動作識別子。

届いた時に SPF レコードを参照してその結果どう動作するか、を決める。

salt.iajapan.org

  • ?all
    • Neutral、拒否も許可も名言しないけど「まあ拒否すんなよ?」という俺 (送信元) を慮れよという動作。 明示的に拒否せず受け入れろ、ということらしいけど、普通に拒否していいんじゃねえかな、と個人的に思っている
  • ~all
    • Softfail、Neutral よりはあいまいなので信頼性が落ちるけど、これも「即時拒否はするな」という類の動作。 しらんがな、の気持ちで拒否していいと思う
  • -all
    • Fail、SPF レコードに一致しねえやんけ!拒否! という動作。 これは普通に即時拒否でオッケーですね

これらは詐欺目的で意図的に送信元の エンベロープ FROM とヘッダ FROM を一致させない、とかじゃなければまあ普通にやればあんまり気にしなくていいはず……。

というかアプライアンスとか厳しい運用していると -all 以外では通らないとか、そもそも SPF とか見てはいるけど別途 allow list で管理していて、そもそもメールが届かないことが発覚してそこから除外リストなり「なんで追加する必要があるんですか(憤怒」と言われて交渉のターンになったり、と場外ファイトが多すぎる。

christina04.hatenablog.com

ワイの理解も雑だしなんとなくで合ってない気がするのでこっち見た方がわかりやすい。

おまけ:SPF,DKIM, DMARC

qiita.com

大手メールベンダー (Gmail とか米 Yahoo で騒ぎになりましたね) は受信ポリシーとして、 SPF/DKIM どちらかと DMARC を PASS することがメール受信を円滑に行わせるための一貫として名言されている。

実際には Amazon の詐欺メールなどを受信する通り、各種設定を PASS しなくても届く場合があるが、まあ大体「詐欺メール」としてマークされるので恩恵としてわかりやすい。

Microsoft 365 (Office365 とか Exchange Online とか) の protection.outlook.com とかは、これ以外に特定の国に払い出されている IP を全部 BAN している、みたいな動作がたまに見受けられて

「オアアーッ!!」

となるので本当つらいし、こういうの発生した時、受信者送信者のどちらか Microsoft 365 有償契約している方がサポートケースを開くしかなくて、送信者側あならいいんだんけど受信者にやってくれ〜、と頼むとこじれがちで本当に困る……というのが言いたいことでした、 ゲイツ〜!