メールが届かない!?迷惑メール&メール不達対策 – DNS(SPF)の設定

メールが届かない!?迷惑メール&メール不達対策 – DNS(SPF)の設定

最近はだいぶ少なくなったが、お問い合わせフォームや予約受付フォームを持つようなサイトを構築する場合、決まって問題になるのが「メールが届かない!」というクレームだ。特にWeb制作会社とタッグを組む(弊社もWeb制作を行っているが笑)と、かなりの高確率でこのようなメール不達問題に直面する。

今回は、そのような場合に、どのように対処すべきかについてお伝えする。

Web制作会社がサーバーを調達した場合に発生しがちな問題

当然、Web制作会社の一番の強みは、「Webサイト」を構築することである。それは即ち「高品質なWebデザイン」と場合によっては「運用代行」を提供することだ。
大きな会社であれば、その中にはシステムの専門部隊がおり、その中でITインフラの調達(DNSの設定やWebサーバーの設定等)を行ってくれるが、それほど大きな会社でない場合は、お名前.comやエックスサーバーが提供しているレンタルサーバーを使うことになる。

ところが、Web制作会社に構築を依頼したにも関わらず、ひょんなことでとある設定を忘れてしまい、問い合わせフォームでお問い合わせをしたにも関わらずそのメールがクライアントに届かないことがある。

実は、この設定、高確率で失念しやすくトラブルのもとになりやすい。特に、ドメインをすでに取得しWebサイトがすでに構築されている前提で、他のWebサーバー上でサイトをリニューアルする際に最も発生しやすい。

その設定とは、いったい何なのか?

ドメインのメール送信を認証するためのSPF

それは、所謂SPF(Sender Policy Framework)レコードの設定だ。SPFレコードとは、そのドメインの送信元メールサーバーを許可しているかを記載したものだ。
最近の受信側メールサーバーではSPF認証が一般化しており、SPF設定が行われていないとかなりの高確率でメールが届かない事態が発生する。

では、そのSPFレコードは、どこで設定し、どこで定義するか?というと、ドメインのTXT(テキスト)レコードに記載する。

上記は何を定義しているか?というと、そのドメインからメールの送信を許可すべきメールサーバーのIPアドレスだ。
記載方法は、以下の様にいくつかの機構(mechanism)が存在する。記載した内容は左から順に評価される。

SPFレコードの機構(mechanism)

include

include機構は、ドメイン名を引数とする。
TXTレコードは、文字列の長さに制限があるので、かなり多くのメールサーバーから送信を許可する場合は、このinclude機構を用いることが多い。
include先ドメインのSPFレコードで認証処理が通る場合は認証される。include先でさらにinclude機構があった場合は、再帰的に評価される。

a

a機構は、ドメイン名を引数とする。
送信サーバのIPアドレスが、与えられたドメインのAレコードもしくはAAAAレコードで解決されるならば、認証を通すようになっている。
主に使われるケースとしては、レンタルサーバ―内にWebサーバーとメールサーバーを同居させるような場合だ。

mx

mx機構は、ドメイン名を引数とする。
送信サーバのIPアドレスが、与えられたドメインのMXレコードで解決されるならば、認証を通す。
Webサーバー側で指定されているメールサーバーがMXで定義されているメールサーバーと異なる場合は、定義してもあまり意味はない。

ip4, ip6

ip4機構とip6機構は、もっとも一般的な機構でIPアドレスを引数とする。
CIDR記法によるブロック指定(例 192.168.0.0/16)も可能。送信サーバのIPアドレスが、与えられたIPアドレスに含まれるならば、認証を通すようになっている。

all

all機構は、引数を取らず常に認証を通すようになっている。
SPFレコードの末尾で使うケースが大半である。特にallの後に認証結果を失敗にする検証子(qualifier)を加えることで、ホワイトリスト的な使い方をするのが一般的である。認証結果を失敗にする検証子(qualifier)は、以下の様にチルダ(~)とハイフン(-)で意味が異なるので注意が必要である。

  • -all:設定以外のアドレスは当該ドメインのメールサーバとして認証しない。
  • ~all:設定以外のアドレスは当該ドメインのメールサーバとして認証しないが、正当なメールであっても認証失敗する可能性もある。

少々わかりずらいかもしれないが、-allのほうがより厳密にチェックされると理解しておけばよいだろう。

redirect

redirectは、正確には機構ではなく変更子(modifier)と呼ばれるもので、redirect先ドメインのSPFレコードを使って認証処理が行われる。
redirect変更子を利用する場合、他の機構は使うことはできない。

SPFレコードを定義する際の注意点

SPFレコードを定義する際は、主に以下の注意点がある。

  • TXTレコードの1つの文字列の最長は255文字制限がある。255文字以上長い記載を書く際は、以下の様に連結部分に空白を入れる

    ただし、総文字数が450文字を超える場合は、includeを活用して文字列を分割する必要がある。
  • include、a、mx、redirect等のDNSに問い合わせが発生する機構は、1つのSPFレコード内での使用回数が10回までと制限されている。
    include機構は再帰問い合わせを行えるため、include先のSPFレコード内でさらに2つのinclude機構を含んでいた場合は、合計3回使用されたとみなされる。
  • PTR機構は使わないこと。相手方のメールサーバーの仕様によっては認証エラーとなってしまう場合がある。
    名前解決のために受信サーバのメモリと帯域を多く消費することがある。
    受信サーバによっては、ptr機構が含まれているだけで、認証を弾いてしまう場合も。

最後に

SPFの設定漏れは、Webサイトの新規構築時もそうだが、どちらかというとレンタルサーバーの切り替え等のリニューアル案件で発生しやすい。
Web制作会社だけに丸投げせず、作業チェックシートを使ってドメイン設定がどこまで終わっているか?トレースするのが良いだろう。