YOKOTA’s diary

最近はドローン関連が多いですが…ECやデータ解析、3Dプリンタなども。

TXTレコードが正しく登録できていないのでSPF認証が失敗で迷惑メールになっちゃうよ

メール メルマガ 迷惑メール

私は直接タッチしていないECサイトのプロジェクトが最近ローンチして
プロモーションなどやり始めているんだが、DNSの設定をちゃんとしていないので、
メルマガが迷惑メールに入っている…非常にもったない。 その時の説明内容を以下に整理。

SPFとは

SPFとは、簡単にいうと、メールの送信者が詐称されている可能性がないかをチェックするメールの仕組み。 Fromアドレスに使用するメールアドレスのドメインに紐付けられたサーバーと、実際に配信に利用されたメールサーバーと関係性があるかを判定し認証する仕組み。

認証なので、結果的には失敗もしくは成功します。
その時に失敗だと迷惑メールにフィルタリングされてしまう可能性があります。

Sender Policy Framework (SPF) Authorizing Use of Domains in E-Mail, Version1

SPFの認証結果例

SPFの認証結果はメールのヘッダから確認ができます。多くのメーラーでは「ヘッダー」や「ソース」と表現されていてその中に「Received-SPF: {認証結果}」が出力されています。
※英語表記の場合はShow original

f:id:ashyktj:20150416212007p:plain

Huffingtonpost.comからのメールヘッダ例（Delivered-ToからFromまで抜粋）

Delivered-To: *******@gmail.com
Received: by 10.182.116.4 with SMTP id js4csp3065550obb;
Wed, 11 Mar 2015 15:59:55 -0700 (PDT)
X-Received: by 10.140.44.134 with SMTP id g6mr48454415qga.85.1426114795177;
Wed, 11 Mar 2015 15:59:55 -0700 (PDT)
Return-Path: <delivery@mx.sailthru.com>
Received: from njmta-12.sailthru.com (njmta-12.sailthru.com. [173.228.155.12])
by mx.google.com with ESMTPS id 89si4817441qgh.112.2015.03.11.15.59.54
for <*******@gmail.com>
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 11 Mar 2015 15:59:55 -0700 (PDT)
Received-SPF: pass (google.com: domain of delivery@mx.sailthru.com designates 173.228.155.12 as permitted sender) client-ip=173.228.155.12;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of delivery@mx.sailthru.com designates 173.228.155.12 as permitted sender) smtp.mail=delivery@mx.sailthru.com;
dkim=pass header.i=@huffingtonpost.com
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; s=mt; d=pmta.sailthru.com;
h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type:List-Unsubscribe;
bh=ROx2ClUiy4LDDN20URe1UbjHCoU=;
b=VqDlxv3gR2vGQRY77waTO4kc5LEUojNzhAcR7RNM65HvG2l6KbV8L1Q/6mBUFpFkl9yi56Tz+uFE
iCFLsh9/NfyH+nsmSi2KXccglUAwHPIYlx5qM+MwPsY4cfyEvvP8pnpoBzR1I+BajWA0Adll+oq3
7RJeGLwgKP9NdllFPc8=
Received: from nj1-p-fattan-prd-jma-13.flt (172.18.20.18) by njmta-12.sailthru.com id h034em1qqbso for <*******@gmail.com>; Wed, 11 Mar 2015 18:58:11 -0400 (envelope-from <delivery@mx.sailthru.com>)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; t=1426114691;
s=sailthru; d=huffingtonpost.com;
h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type:List-Unsubscribe;
bh=aR604u8bpknrnhxHgmJAPI4JY/Prd4epeBGbR1UUNz4=;
b=EiBBLS0s9VZWpbunQcrs3o64doD3iNhpgRSYVdoYECRKW5kRYGNcnnuPI5oC4JbU
AYTjqhZSu+TipBTIISxFllOOzQsckcYkthNLS6i9Z837Ra8uEct+4ZJICTIYlKzrd8y
YOLt8BN9TEV2l7VZlnXUZFjjiKeIBzy5eoJAVGZY=
Date: Wed, 11 Mar 2015 18:58:11 -0400 (EDT)
From: HuffPost Japan <dailybrief@huffingtonpost.com>
…

SPFの認証結果は「pass」であれば問題ないが、
よく見かけるものとしては以下がある

  • 「None」＝SPFレコード自体が未公開
  • 「fail」＝認証失敗(-)
  • 「softfail」＝弱い認証失敗。(~)
  • 「Neutral」＝中立(?)
  • 「pass」＝認証成功(+)

※rfc4408#section-2.5
※()で指定した「+, -, ~, ?」は実際のSPFレコードを記載するときの修飾子

softfailとNeutralの違いを日本語で説明するのは難しいが、
どちらも、failと同様に、SPFレコードが送信サーバーとマッチはしていないことは伝えており、
SPFの仕様では、softfailはfailとNeutralの間として判断するべしと記載がある。

SPFを正しく設定していないと

SPFは結果的に上記の認証結果が返ってくるが、受信メールのプロバイダによってはfailに近しいものは迷惑メールとして拒否してしまう可能性もあるため、特別な事情がなければ、passすることを前提にSPFの設定を行うべきだと思います。

よくあるのが、冒頭でも記載したように、ECサイトを新規にローンチ・サイトをリニューアルする際に、
メールも含めてドメインをすべて取りなおしたが、SPFレコード（TXTレコード）の登録を失念して、
リプライメールやメルマガや迷惑メールに入ってしまうことなど実際に起こったのを何度か見てます。

せっかく、良い商品やサービスを作って、プロモーションして、ようやく顧客獲得したのに、
いざ、メールを送ってみても、こういう不注意で相手に情報が届かないのは非常にもったいないです。

また、Gmail等は「多くのユーザが迷惑メールフォルダにいれているメール」を
迷惑メールとして判断するアルゴリズムもあるようです。 つまり、1回の迷惑メール配信が、今後に影響することが大いにありえるということです。

※参考：Gmailの迷惑メールに振り分けられる理由
https://support.google.com/mail/answer/1366858?hl=ja&ref_topic=3395161

SPFの設定状況の確認

認証結果が成功ではない場合は即座に対応する必要があります。まずは正しくSPF認証の際に必要な設定であるTXTレコードが正しく登録されているかをwindow/linuxのコマンドで簡単に確認をすることができます。以下は上記ヘッダであるハフィントン・ポストのFromアドレスのドメイン「huffingtonpost.com」がTXTレコードが登録されているかを調べます。

コマンド例（windows/linuxともに同じ）

$ nslookup -type="txt" huffingtonpost.com
;; Truncated, retrying in TCP mode.
Server:         172.19.1.1
Address:        172.19.1.1#53

Non-authoritative answer:
huffingtonpost.com      text = "spf2.0/pra ptr:mx.aol.com include:sendgrid.net include:aspmx.sailthru.com include:_spf.google.com include:amazonses.com ip4:74.205.21.242 ~all"
huffingtonpost.com      text = "v=spf1 a mx ptr:mx.aol.com include:sendgrid.net include:aspmx.sailthru.com include:_spf.google.com include:amazonses.com ip4:74.205.21.242 ~all"

Authoritative answers can be found from:
com     nameserver = k.gtld-servers.net.
...

SPF認証に関係するTXTレコードは下記の部分です。

huffingtonpost.com      text = "v=spf1 a mx ptr:mx.aol.com include:sendgrid.net include:aspmx.sailthru.com include:_spf.google.com include:amazonses.com ip4:74.205.21.242 ~all"

これをある程度、要素分解して解説すると、

  • 「v=spf1」SPFのバージョン1
  • 「ptr:mx.aol.com」送信元ホストのIPをリバースルックアップし、
  • 得られたホスト名でさらに正引きしIPを得て、
  • さらに、そのIPと送信元のホストのIPが含まれる場合、そのホスト名と引数のホストが一致していたら認証成功とする
  • 「include:sendgrid.net」引数のホスト名を利用して認証処理を行う。仮にfail系の結果であっても結果はかえさないため、後続の記述に進む。
  • 「ip4:74.205.21.242」送信元のIPが引数のIPと一死していたら認証成功とする。
  • 「~all」allはすべての送信元ホストにマッチすることを意味し、チルダ（~）の場合はsoftfailを返す

となります。TXTレコードは左から読んでいくため、最後まで認証結果が返らない場合は、最後の「~all」がかえることとなる。ここでチルダの指定を「-」とすれば、failを意味させることもできるし、「?」であればNeutralとすることができる。

上記のハフィントン・ポストはptfやincludeのように複雑な書き方をしているが、ptrのようなリバースルックアップなどは多少負荷がかかるしし、書き方も複雑なので事情がなければ、見た目もわかりやすくIPでの記述をシンプルに行っても問題ないです。

SPF・TXTレコード設定方法

上記のようにTXTレコードを設定するには、ドメイン側での作業が必要となるため、ドメイン管理している担当の方に対応をお願いする必要があります。
例えばドメインの管理をお名前ドットコムで行っていれば、管理メニューの中でTXTレコード（もしくはSPFレコード）やAレコードなどが編集できるDNSレコードの編集メニューがあるはずです。

※参考：http://www.onamae.com/option/dnsrecord/

これらの対応をするための準備や流れとしては、下記になります。

  1. メール送信元のサーバーを特定し、そのグローバルIPを取得
  2. 現在のTXTレコードに1のIPを追加※基本的にTXTレコード自体はドメインに対して1つです。
  3. メール送信してみて正しく反映されているかを確認

1は該当のサーバー情報を知っているはずなのでIPを確認するだけです。
2は書き方に注意がいります。1文字でも誤った書き方をすると、認証結果が成功でも失敗でもなくエラーとなりからです。以下は、もともと「11.22.33.44」というIPが含まれるSPFレコードに「55.66.77.88」という送信サーバーのIPを追加するケースです。

（変更前のレコード）  
mail.ykt.jp text = "v=spf1 +ip4:11.22.33.44 ~all"  

（変更後のレコード）
mail.ykt.jp text = "v=spf1 +ip4:11.22.33.44 +ip4:55.66.77.88 ~all"

※参考：SPFと迷惑メールについて
http://salt.iajapan.org/wpmu/anti_spam/admin/tech/explanation/spf/