SPFレコードでのDNS-Interactive Termsの最大制限の回避策はありますか？

ホスティングプロバイダーとして、クライアントに代わってメールを送信するため、お客様がDNSにDKIMおよびSPFメールレコードを設定し、メール配信を適切に行えるように支援します。http://mail-tester.comを使用して、何も見逃していないことをテストするようアドバイスしてきましたが、このツールはとても気に入っています。

数回遭遇した問題の1つは、ドメイン名に基づいたSPFレコードのDNSの「制限」です。これがある場合：

v=spf1 a include:aspmx.googlemail.com include:campaignmonitor.com include:authsmtp.com include:mail.zendesk.com include:salesforce.com include:_hostedspf.discourse.org ~all

あなたが得る

example.com ... campaignmonitor.com: Maximum DNS-interactive term limit (10) exceeded

そのようです：

これについていくつか質問があります。

1. ここでは10ではなく6つのドメイン名をカウントしているのに、なぜ「10」個のDNS要求をここでヒットするのですか？ ここで回答

2. この10 DNSインタラクティブ用語は、警告または実際のエラーを制限していますか？たとえば、気にする必要がありますか？顧客に少し口うるさいので、彼らはサポートのために私たちに電子メールを送ります。 ここで回答

3. この10のDNSインタラクティブ用語は、今日のWebでの実際の問題を制限していますか？ご覧のように、この顧客には多くのサービスがあり、彼らはメールを送信しており、すべて正当なものです。おそらく、このDNS制限は、このような電子メールサービスの委任が一般的ではなかった2000年に設定されたのでしょうか？

はい、お客様にSPFレコード内のIPへのインクルードを変​​更させることができますが、IPを変更した場合、多くのお客様のものが壊れてしまいます。そんなことしたくない

これにはどのような回避策がありますか？

1. ほとんどの場合、すでに回答があります。Googleを含むこの方法は間違っていることに注意してください。_spf.google.comリダイレクトにペナルティを使用するか、ペナルティを科します

   ○ → host -t txt aspmx.googlemail.com
   aspmx.googlemail.com descriptive text "v=spf1 redirect=_spf.google.com"
   
   ○ → host -t txt _spf.google.com
   _spf.google.com descriptive text "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
   

このルックアップは、それ自体で5/10を消費します。4/ 10は依然として消費量が20％少なくなります。

2. 処理を停止し、永続的なエラーを返します。永続的なエラーの処理方法を決定するのは、SPFを使用するエンジン次第です。

3. はい-処理の制限がなければ、SPFメカニズムをサードパーティまたはサードパーティに対するDoS増幅器として使用できます。

回避策として、community.largecorporation.comたとえば、メインプロパティのサブドメインからメールを送信できます。

1. 冗長性（複数の参照_spf.google.comやそれが参照するレコードなど）が1回だけカウントされると仮定すると、すでに最初のレコードをルックアップしたポイントから17回のルックアップをカウントします。（下記参照。）

2. SPFレコードを評価するために必要なすべてのレコードを検索することは拒否します。これは、「作業が多すぎる」ためです。おそらくこれは、ドメインがSPFレコードを持たない（または拒否する可能性がある）かのようにドメインを処理することを意味します。仕様書によるとこれはpermerrorになり、受信者が何をするかを決定するためにかなりオープンにします。

3. 虐待は、一般的には減少するのではなく増加していると思います。この制限は、悪意のある送信者ドメインを阻止することを意図しているように思われ、そうでなければ、DoSにつながる可能性のあるSPFの巨大なチェーンで受信者を圧倒できます。

電子メールのアウトソーシングは一般的ですが、実際には、6つの異なるプロバイダーに電子メールをアウトソーシングすることはそれほど一般的ではないと思います。どういうわけか、SPFレコードを最適化する必要があります。
（1つには、への参照aspmx.googlemail.comはすぐに別の名前にリダイレクトされるため、無駄に思えます。）

<lookup of example.com A>                   #1
$ dig aspmx.googlemail.com TXT +short       #2
"v=spf1 redirect=_spf.google.com"
$ dig _spf.google.com TXT +short            #3
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
$ dig _netblocks.google.com TXT +short      #4
"v=spf1 ip4:64.18.0.0/20 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:173.194.0.0/16 ip4:207.126.144.0/20 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"
$ dig _netblocks2.google.com TXT +short     #5
"v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"
$ dig _netblocks3.google.com TXT +short     #6
"v=spf1 ~all"
$ dig campaignmonitor.com TXT +short        #7
"google-site-verification=HcHoB67Mph6vl5_x4gK5MN9YwN5gMgfZYdNmsP07tIg"
"v=spf1 mx ptr ip4:23.253.29.45/29 ip4:203.65.192.250 include:cmail1.com include:_spf.google.com include:stspg-customer.com ~all"
$ dig cmail1.com TXT +short                 #8
"google-site-verification=HSJ8sL4AxQo0YHHNk9RwDqs0p3lJPGmc1nCrSsmous8"
"mailru-verification: 95d4c6eb0645b43c"
"v=spf1 ip4:103.28.42.0/24 ip4:146.88.28.0/24 ip4:163.47.180.0/22 ip4:203.55.21.0/24 ip4:204.75.142.0/24 ~all"
$ dig stspg-customer.com TXT +short         #9
"v=spf1 ip4:166.78.68.221 ip4:166.78.69.146 ip4:23.253.182.103 ip4:192.237.159.42 ip4:192.237.159.43 ip4:167.89.46.159 ip4:167.89.64.9 ip4:167.89.65.0 ip4:167.89.65.100 ip4:167.89.65.53 -all"
$ dig authsmtp.com TXT +short               #10
"v=spf1 include:spf-a.authsmtp.com include:spf-b.authsmtp.com ~all"
"google-site-verification=skc1TleK4GylDiNZUayfvWWgqZIxmmiRj4KgXlCgB8E"
$ dig spf-a.authsmtp.com TXT +short         #11
"v=spf1 ip4:62.13.128.0/24 ip4:62.13.129.128/25 ip4:62.13.136.0/22 ip4:62.13.140.0/22 ip4:62.13.144.0/22 ip4:62.13.148.0/23 ip4:62.13.150.0/23 ip4:62.13.152.0/23 ~all"
$ dig spf-b.authsmtp.com TXT +short         #12
"v=spf1 ip4:72.52.72.32/28 ip4:64.49.192.16/29 ip4:209.61.188.242 ip4:64.49.192.24 ip4:64.49.192.25 ip4:64.49.210.64/29 ip4:64.49.210.72/30 ip4:64.49.210.76 ip4:64.49.210.77 ip4:64.49.210.78 ~all"
$ dig mail.zendesk.com TXT +short           #13
"v=spf1 ip4:192.161.144.0/20 ip4:185.12.80.0/22 ip4:96.46.150.192/27 ip4:174.137.46.0/24 ~all"
$ dig salesforce.com TXT +short             #14
"adobe-idp-site-verification=898b7dda-16a9-41b7-9b84-22350b35b562"
"MS=749862C9F42827A017A6EA2D147C7E96B3006061"
"MS=ms68630177"
"v=spf1 include:_spf.google.com include:_spfblock.salesforce.com include:_qa.salesforce.com ip4:136.146.208.16/28 ip4:136.146.210.16/28 ip4:136.146.208.240/28 ip4:136.146.210.240/28 ip4:85.222.130.224/28 ip4:136.147.62.224/28 ip4:136.147.46.224/28 mx ~all"
$ dig _spfblock.salesforce.com TXT +short   #15
"v=spf1 ip4:96.43.144.0/20 ip4:182.50.76.0/22 ip4:202.129.242.0/23 ip4:204.14.232.0/21 ip4:62.17.146.128/26 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:68.232.207.20 ip4:207.67.38.45 ip4:198.245.81.1 ip4:198.245.95.4/30 ip4:136.146.128.64/27  ~all"
$ dig _qa.salesforce.com TXT +short         #16
"v=spf1 ip4:199.122.122.176/28 ip4:199.122.121.112/28 ip4:199.122.122.240/28 ip4:66.231.95.0/29 ~all"
$ dig _hostedspf.discourse.org TXT +short   #17
"v=spf1 ip4:64.71.148.0/29 ip6:2001:470:1:3c2::/64 -all"

リンクされた質問のいずれかに受け入れ答えは、 UNIX上のほぼすべてである-明確にし、UNIXシステムの基礎となるツールの多くは、実際にそれらを使用するすべてのSPFの実装よう（ではないが、すべて正確に同じように）この制限を強制しません-これらの制限も強制します。Windowsシステムはそれ自体が法律であり、それらに光を当てることはできません。

回避策は、アウトソーシングされたSPFレコードのチェーンを評価し、それらをすべてipv4およびipv6ネットブロックとして表現し、それをレコードにするcronジョブを持つことです。 忘れないでください-all。

あなたの場合、顧客がSPFレコードを公開できるようにしたいので、SPFレコードを維持する必要はありません。1つの可能性は、各顧客にを含むレコードを公開redirect=spf.client1.jeffs-company.exampleさせ、ネットブロックのリストを維持するというレッグワークを行うことjeffs-company.exampleです。

おそらく、このDNS制限は、このような電子メールサービスの委任が一般的ではなかった2000年に設定されたのでしょうか？

この制限により、6〜7つの大規模なオペレーションにメールを外部委託することは難しくなります。しかし、もしあなたがそれをしているとしたら、とにかくあなたのすべての実用的な目的のためにあなたの電子メールのコントロールを失いました。

いつかどこかで、あなたが完全に気づかず、自分がコントロールできない下請けのプログラマがセミコロンを置き忘れてしまい、大量の偽の電子メールがSPFに無条件に送信されます。電子メールを完全に制御するには、電子メールインフラストラクチャを完全に制御する必要がありますが、これはそのようなアウトソーシングとは完全に矛盾しています。