Office365 SPFレコードのルックアップが多すぎます

まったくばかげた管理上の理由から、Office365に1つのメールボックスを持つ分割ドメインinclude:outlook.comがあり、SPFレコードに追加する必要があります。これに関する問題は、そのルールだけで最大10の9つの DNSルックアップが必要なことです。

真剣に、それは恐ろしいです。それを見てください：

v=spf1
include:spf-a.outlook.com
include:spf-b.outlook.com
ip4:157.55.9.128/25
include:spfa.bigfish.com
include:spfb.bigfish.com
include:spfc.bigfish.com
include:spf-a.hotmail.com
include:_spf-ssg-b.microsoft.com
include:_spf-ssg-c.microsoft.com
~all

我々は我々自身の大っぽいメールシステムを持っていることを考えると、我々はのためのルール持っている必要がありa、mx、include:_spf1.mydomain.com、およびinclude:_spf2.mydomain.com13件のDNSの原因検索のプットたちをPERMERRORsの厳格なSPFのバリデータと、非厳密/ひどく実装バリデータと完全に信頼できない/予測不可能な検証を。

include:肥大化したoutlook.comの記録からこれらのルールのうち3つを何らかの形で削除することはできますが、それでもO365が使用するサーバーをカバーできますか？

編集：

コメンテーターは、短いspf.protection.outlook.comレコードを使用する必要があると述べています。それは一方である私にニュース、そしてそれがある短い、それは1つのレコードだけ短いです。

spf.protection.outlook.com
  include:spf-a.outlook.com
  include:spf-b.outlook.com
  include:spf-c.outlook.com
  include:spf.messaging.microsoft.com
    include:spfa.frontbridge.com
    include:spfb.frontbridge.com
    include:spfc.frontbridge.com

編集²

技術的にこれを次のように切り分けることができると思います：

v=spf1 a mx include:_spf1.mydomain.com include:_spf2.mydomain.com include:spf-a.outlook.com include:spf-b.outlook.com include:spf-c.outlook.com include:spfa.frontbridge.com include:spfb.frontbridge.com include:spfc.frontbridge.com ~all

しかし、これに関して私が目にする潜在的な問題は次のとおりです。

1. 親spf.protection.outlook.comとspf.messaging.microsoft.comレコードの変更に遅れないようにする必要があります。何かが変更されたり、[god forbid]が追加された場合、それを反映するために手動で更新する必要があります。
2. 実際のドメイン名では、レコードの長さは260文字であり、TXTレコードに2つの文字列が必要になります。また、そこにあるすべてのDNSクライアントとSPFリゾルバーが255バイトを超えるTXTレコードを適切に受け入れるとは信じていません。

いくつかの最近の日付で、Microsoftはすべてのサブレコードを削除し、代わりに2つまたは3つの「ptr」レコードを使用することにより、この問題を「修正」しました。

$ dig TXT spf.protection.outlook.com
spf.protection.outlook.com. IN  TXT "v=spf1 ptr:protection.outlook.com ptr:o365filtering.com -all"

$ dig TXT spf.messaging.microsoft.com
spf.messaging.microsoft.com. IN TXT "v=spf1 ptr:protection.outlook.com ptr:messaging.microsoft.com ptr:o365filtering.com -all"

問題は次のとおりです。これは、Office 365クライアントが「ルックアップが多すぎる」PermErrorを下回らないようにするのに役立ちますが、世界中のすべてのメールサーバーに、それらに接続するすべてのIPアドレスに対して（高価な）PTRルックアップを強制することで回避します。

SPF仕様ごと：

可能な場合は、SPFレコードでこのメカニズムを使用しないでください。高価なDNSルックアップが大量に発生するためです。

この問題も発見しました。マイクロソフトは、新しいアイテムを追加する余地がないため、メール専用にOffice 365を使用するよう「奨励」しています。

回避方法は2つありました。

最初に、他のエントリを明示的なIPv4エントリとして追加することにより、DNSルックアップを削減できます。これにより、明示的なIPをいくつか追加してから、include:outlook.com

次に、Office 365向けにメインドメインの下に別のサブドメインを設定します。このようにして、@ foo.company.comにメールを送信するとOffice 365 SPFが取得され、@ comapny.comにメールを送信すると通常のSPFが取得されます。完璧ではありませんが、幸いなことに、Office 365を使用した場所はすべて、ベースドメインではなくサブドメイン内の電子メールアドレスを使用できます。