Office365 メール受信に利用するSPFレコードの設定について

インターネットのメールシステムでは、ユーザー情報を偽装されたスパムメールが多く配信されることから、送信したメールサーバーが正しいサーバーなのかをDNSを通じて調べる仕組みがあります。

その仕組みはSPFと呼ばれ、昔から利用されているのですが、Exchange Onlineでメールを送信した場合、クラウドからの配信となるため、どのメールサーバーから配信されるのかわかりません。

そういった場合に備え、SPFにはinclude ステートメントという、DNSでいうところのCNAMEのような機能が内包されています。

しかしながらこのSPF、最近のクラウドをたくさん利用するSaaSの時代を意識できていなかったようで、確認可能な参照上限値が10となっています。(SPFレコードに直接記されたincludeステートメントが10以内というだけでなく、includeが入れ子の記述になっていた場合その中も含むこととなります。)

要するに送信メールドメインごとにSaaSシステムは最大10まで。という制約があるということです。

Office365で利用されているinclude状態をnslookupを使って調べてみました。
すると、以下図のようにspf.protection.outlook.com、spfa.protection.outlook.com、spfb.protection.outlook.comの3つ(その前に自身のドメインがあるので4つ)が利用されています。

f:id:mohessu:20180804184652p:plain

このペースだと、SaaSサービス2つの利用で利用数が上限に行ってしまいますね。

そういった状況が多いのか、この状況に対象する方法が以下サイトに記載されていました。

Office 365 において Sender Policy Framework (SPF) を使用して、スプーフィングを防止する方法: Exchange Online Protection Help

下の方に記載されていますが、送信専用にサブドメインを切りましょう。という内容になっていました。

f:id:mohessu:20180804171231p:plain

確かに送信用のアドレスをサブドメインに分ければSPFの制約はなくなりますね。
ちょっと考えれば出てきそうですが、盲点でした。

SPFのincludeステートメント不足が発生する前に、送信のアドレスについて、見直しが行えるか確認しておくとよいかもしれません。

音楽:CAT’S DELICACY