SPF（Sender Policy Framework） : 迷惑メール対策委員会
通常の運用ではやらないと思いますが、開発中などでメールアドレスをuser1@host1.example.comのようにホスト毎にサブドメイン付で使う場合、SPFのレコードもサブドメイン毎に作成する必要があるようです。
もともと以下のようなSPFレコードを設定していました（IPアドレスとドメインは例示用のものに書き換えています）。
example.com IN TXT "v=spf1 +ipv4:192.0.2.0/24 ~all"この状態で、開発サーバーからgmailにメールを送信したところ、メールは届きますが、ヘッダに以下のような内容が表示されていて、SPF認証は許可も拒否もされていないニュートラルな状態になっているようです。
Received-SPF: neutral (google.com: 192.0.2.101 is neither permitted nor denied by best guess record for domain of user1@host1.example.com) client-ip=192.0.2.101; Authentication-Results: mx.google.com; spf=neutral (google.com: 192.0.2.101 is neither permitted nor denied by best guess record for domain of user1@host1.example.com) smtp.mail=user1@host1.example.com
一方、以下のようにサブドメイン用のSPFレコードを作成した場合（一方、元のexample.comのほうのSPFレコードは削除しました）は
host1.example.com IN TXT "v=spf1 +ipv4:192.0.2.0/24 ~all"届いたメールのヘッダは以下のようになっていてSPF認証がパスしています。
Received-SPF: pass (google.com: domain of user1@host1.example.com designates 192.0.2.101 as permitted sender) client-ip=192.0.2.101; Authentication-Results: mx.google.com; spf=pass (google.com: domain of user1@host1.example.com designates 192.0.2.101 as permitted sender) smtp.mail=user1@host1.example.com
他のメモ
- +ipv4:アドレスの+はつけないほうがよい。デフォルトが+だし、DNSのレコード長制限を考えても短いほうがよいので。
- allの前は~(チルダ)よりも-(マイナス)にしたほうがよい。白黒はっきりつけたほうが影響がわかりやすいので。
ドコモに送信する限りは送信ドメイン認証（Sender ID／SPF）について | サービス・機能 | NTTドコモに書いてある通り、ipv4の前には+をつけて、-allではなく~allにしておいたほうがよさそうです。
短時間にいろいろSPFレコードの変更を試行錯誤したのでDNSが伝播していたか不明なため、きちんとした切り分けは出来ていませんが、"v=spf1 +ipv4:192.0.2.0/24 ~all"の書式にしてからは遅配になる率がほぼなくなりました。遅配のときは/var/log/maillogにstatus=deferredと出て、そうでないときはstatus=sent(250)になります。
推測ですが、ドコモのSPFレコードの解釈処理がRFCのフル実装ではなくサブセットなのではないかと思っています。
試行錯誤するときは、nslookup -type=txt host1.example.comで自分のところへ伝播するぐらいまではせめて待ってから試したほうがよかったです。gmailだとすぐ変化したように思えてばんばん変えてたのですが、ドコモで遅配になる率はすぐ変わらなかったので。
