メールサーバのSPF(Sender Policy Framework)対応化

送信元アドレスを偽称した迷惑メール、フィッシングサイトへの誘導メールなどの被害を軽減できる仕組み。

【送信側の設定】
送信側がSPFに対応するメリットは、自分の管理ドメインになりすまされたメールの送信をSPFチェックによって判定できるようになる。(受信側が対応されていれば、自分の管理ドメインによるなりすましメール被害を軽減できる)

DNSサーバにSPFレコード(TXTレコード)を登録しておく
IN TXT v=spf1 +ip4:(送信元IPv4アドレス) -all”

MyDNSの場合には自動的にSPFレコードが追加される。
SPFレコードの詳細は送信ドメインを認証するためのSPFレコードに詳しくなろうが詳しい。

併せて、DMARCレコードにも対応しておくことが望ましい
_dmarc IN TXT v=DMARC1; p=none; rua=mailto:(集計レポートの送付先)
DMARCレコードは、MyDNSを使っている場合には、個別にレコード定義する必要がある。

【受信側】
受信側がSPFに対応するメリットは、SPFレコードが登録されたドメインにてなりすましされたメールを受信しないようにできることで、なりすましメールの被害を軽減できる。

Postfixの場合には、「備忘録」 Postfix(CentOS)でSPF対応しちゃう。に従って実装するとSPF対応できるようになる。

SPF対応するとメールヘッダに
Received-SPF: Pass (sender SPF authorized) …
のようなヘッダが付加されるようになる。

また、
$sudo grep ‘policyd-spf’ /var/log/maillog
とすることで正常に動作していることを確認することが出来る。

また、SPFチェックに引っかかる場合には、
Received-SPF: Permerror (SPF Permanent Error: Void lookup limit of 2 exceeded)
Received-SPF: Softfail (domain owner discourages use of this host)
Received-SPF: Neutral (access neither permitted nor denied)
Received-SPF: Fail (SPF fail – not authorized)
のようなヘッダが記録される。

SPFレコードが登録されていないドメインからのメールを受信した場合には、
Received-SPF: None (no SPF record)
のようなヘッダが記録される。

Received-SPF の内容については、postfix で postfix-policyd-spf-python ( or postfix-policyd-spf-perl ) を使ってSPF認証する(CentOS/ScientificLinux編)に詳しく記載されているので、参考になる。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です