web-dev-qa-db-ja.com

Office365 SPFレコードの参照が多すぎます

非常にばかげた管理上の理由により、Office365にメールボックスが1つある分割ドメインがあり、SPFレコードにinclude:Outlook.comを追加する必要があります。これに関する問題は、そのルールだけがnine最大10の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.comのルールが必要です。これにより、13のDNSルックアップが実行されます。これにより、厳密なSPFバリデーターでPERMERRORsが発生し、厳密でない/正しく実装されていないバリデーターで完全に信頼できない/予測できない検証が行われます。

肥大化したOutlook.comレコードからこれらのinclude:ルールの3つを何らかの方法で削除することは可能ですが、それでもO365が使用するサーバーをカバーできますか？

編集：

コメント者は、短い[spf.protection.Outlook.com]レコードを使用する必要があると述べています。 isは私にとってのニュースであり、isは短いですが、レコードは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リゾルバーがTXT 255バイトを超えるレコードを適切に受け入れます。
emailspfmicrosoft-office-365
11
Sammitch

最近のいくつかの日付で、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クライアントが "Too many lookups" PermErrorを下回らないようにするのに役立ちますが、世界中のすべてのメールサーバーに、接続するすべてのIPアドレスに対して（高価な）PTRルックアップを強制することでそうします。

SPF仕様 に従って：

可能であれば、このメカニズムをSPFレコードで使用することは避けてください。このメカニズムを使用すると、高価なDNSルックアップが多数発生するためです。

3
John Hart

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

それを回避する方法は2つありました。

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

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

1
Steve Shipway