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

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

当然、Web制作会社の一番の強みは、「Webサイト」を構築することである。それは即ち「高品質なWebデザイン」と場合によっては「運用代行」を提供することだ。
大きな会社であれば、その中にはシステムの専門部隊がおり、その中でITインフラの調達（DNSの設定やWebサーバーの設定等）を行ってくれるが、それほど大きな会社でない場合は、お名前.comやエックスサーバーが提供しているレンタルサーバーを使うことになる。
ところが、Web制作会社に構築を依頼したにも関わらず、ひょんなことでとある設定を忘れてしまい、問い合わせフォームでお問い合わせをしたにも関わらずそのメールがクライアントに届かないことがある。
実は、この設定、高確率で失念しやすくトラブルのもとになりやすい。特に、ドメインをすでに取得しWebサイトがすでに構築されている前提で、他のWebサーバー上でサイトをリニューアルする際に最も発生しやすい。
その設定とは、いったい何なのか？

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

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

@ "v=spf1 ip4:xxx.xxx.xxx.xxx -all"

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

SPFレコードの機構(mechanism)

include

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

@ "v=spf1 include:hoge.com -all" // hoge.comのTXTレコードを参照する

a

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

@ "v=spf1 a:www.hoge.com -all" // www.hoge.comのIPアドレスを許可する

mx

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

@ "v=spf1 mx -all" // 対象ドメインMXに指定されているメールサーバーのIPアドレスを許可する

ip4, ip6

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

@ "v=spf1 +ip4:xxx.xxx.xxx.xxx +ip6:xxxx.... -all" // xxx.xxx.xxx.xxxまたはxxxxからのメール送信を許可する

all

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

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

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

redirect

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

@ "v=spf1 redirect=hoge.com" // hoge.comのドメイン内で認証を行う

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

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

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

  @ "v=spf1 +ip4:xxx.xxx.xxx.xxx" "+ip4:xxx.xxx.xxx.xxx ~all"

  ただし、総文字数が450文字を超える場合は、includeを活用して文字列を分割する必要がある。

  @    "v=spf1 include.spf1.hoge.com include.spf2.hoge.com ~all"
  spf1 "v=spf1 +ip4:xxx.xxx.xxx.xxx +ip4:xxx.xxx.xxx.xxx ~all"
  spf2 "v=spf1 +ip4:xxx.xxx.xxx.xxx +ip4:xxx.xxx.xxx.xxx ~all"
  

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

最後に

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