SPF'de çok fazla DNS sorgusu: ne anlama gelir ve nasıl düzeltilir

Sınır nereden geliyor

SPF belirtimi (RFC 7208), değerlendirmeyi DNS sorgusuna yol açan on mekanizma ve değiştiriciyle sınırlar. Sınırın amacı, tek bir iletinin denetlenmesinin alıcı sunucuya sınırsız sayıda sorgu yaptırmasını önlemektir.

On birinci sorgu gerektiğinde alıcı sunucu durur ve permerror döndürür. permerror yumuşak bir sonuç değildir: DMARC açısından SPF geçmemiştir, dolayısıyla ileti tümüyle DKIM'e bağlı kalır.

Neler sayılır, neler sayılmaz

include, a, mx, exists ve ptr mekanizmalarının her biri sayılır, redirect değiştiricisi de öyle. ip4, ip6 ve all mekanizmaları sayılmaz, çünkü sorgu gerektirmezler.

Çoğu kişinin gözden kaçırdığı nokta, sayımın özyinelemeli olmasıdır. Bir include başka bir domainin SPF kaydını içeri çeker ve o kaydın içindeki her sorgu sizin on sorguluk hakkınızdan düşer. Dört include içeren bir kayıt, sağlayıcıların kendi kayıtları çözümlendiğinde kolayca on ikiye ulaşabilir. Ayrıca iki boş sorguluk ayrı bir sınır da vardır. Boş sorgu, hiçbir kayıt döndürmeyen sorgudur.

1. Kendi kaydınızdaki her include, a, mx, exists, ptr ve redirect girdisini sayın.
2. Her include girdisini çözümleyin ve aynı mekanizmaları onun içinde, onun include ettiği her kayıtta da sayın.
3. Sayıları toplayın. Toplam onun üzerindeyse alıcı sunucular permerror döndürür.

Sınırın altına inmenin dört yolu

Kaldırmakla başlayın. Kayıtlarda artık kimsenin kullanmadığı servislerin include girdileri birikir: eski bir bülten aracı, önceki bir destek masası, sona ermiş bir deneme hesabı. Kaldırdığınız her include genellikle birden fazla sorgu kazandırır.

Bir sağlayıcı bölgeniz ya da ürününüz için daha dar bir include yayınlıyorsa, genel olan yerine onu kullanın. Bir servis her zaman az sayıda sabit adresten gönderiyorsa, include girdisini sorgu harcamayan ip4 ya da ip6 girdileriyle değiştirin. Buna düzleştirme (flattening) denir ve gerçek bir bedeli vardır: sağlayıcı adreslerini değiştirdiğinde kaydınız sessizce yanlış hale gelir. Bu yüzden yalnızca izleyebildiğiniz girdileri düzleştirin.

1. Domain adına artık e-posta göndermeyen servislerin include girdilerini kaldırın.
2. Sunucuların adresleri sabitse a ve mx yerine açık ip4 ya da ip6 girdileri yazın.
3. Yüksek hacimli bir göndereni, kendi SPF kaydı olan ayrı bir alt domaine taşıyın. Böylece ana domainin sorgu hakkını paylaşmaz.
4. Kararlı bir include girdisini, yalnızca sağlayıcı değiştirdiğinde uyarı alacaksanız IP aralıklarına düzleştirin.

Alt domainler neden işe yarar

SPF, zarf göndereninde yer alan domaine göre değerlendirilir. Her domainin ve alt domainin kendi kaydı ve kendi on sorguluk hakkı vardır. Pazarlama e-postaları news.example.com üzerinden, faturalar billing.example.com üzerinden gönderiliyorsa, her biri yalnızca ihtiyaç duyduğu sağlayıcıyı listeleyebilir.

Bu aynı zamanda zararı sınırlar: pazarlama kaydındaki bir hata faturaları bozamaz.

Niyet ettiğiniz kaydı değil, yayınlanan kaydı denetleyin

Elle sayım yanlış sonuç verir, çünkü sağlayıcı kayıtları değişir. Tüm include zincirini çözümleyen ve gerçek toplamı bildiren bir denetleyici kullanın, her değişiklikten sonra da yeniden denetleyin. CloudSpex zinciri çözümler, sorgu sayısını sınıra göre bildirir ve zincirin bir bölümü çözümlenemediğinde bunu açıkça söyler.

Adım adım bir örnek

Mütevazı görünen bir kayıt düşünün: posta kutusuyla ilgili iki include, iki gönderim servisi ve mx mekanizması. Açık yazıldığında sorgu gerektiren beş mekanizma içerir. Gerçek toplam, include edilen her kaydın içeriğine bağlıdır.

Baştan sona saymak, bir kaydın uzun görünmeden sınırı nasıl aştığını gösterir. Örnekteki sayılar temsilidir, çünkü sağlayıcılar kayıtlarını değiştirir. Önemli olan yöntemdir. Her include girdisini çözümleyin, içindeki sorgu mekanizmalarını sayın ve o kayıtların include ettiği her şey için aynısını tekrarlayın.

example.com.  TXT  "v=spf1 mx include:_spf.google.com include:spf.protection.outlook.com
                    include:sendgrid.net include:servers.mcsv.net ~all"

mx                                  1
include:_spf.google.com             1 + 3 nested includes   = 4
include:spf.protection.outlook.com  1 + 1 nested include    = 2
include:sendgrid.net                1 + 1 nested include    = 2
include:servers.mcsv.net            1 + 2 nested includes   = 3
                                                   total    = 12  -> permerror

Kendiniz saymak

Sayım bir DNS sorgu aracıyla elle yapılabilir. Zahmetlidir. Kayıtların fark edilmeden sınırı aşmasının nedeni de tam olarak budur.

1. Domainin kendi SPF kaydını okuyun ve her include, a, mx, exists, ptr ve redirect girdisini not edin.
2. Her include hedefinin TXT kaydını sorgulayın.
3. Bunların her birinde aynı mekanizmaları yeniden not edin ve varsa başka include girdilerini de sorgulayın.
4. Bir kayıt yalnızca ip4, ip6 ve all içerene kadar devam edin.
5. Not ettiğiniz bütün mekanizmaları toplayın. Alıcı sunucunun saydığı sayı budur.

dig example.com TXT +short | grep spf1
dig _spf.google.com TXT +short
dig _netblocks.google.com TXT +short

Hata kendini nasıl gösterir

Sorgu sınırı hatası, SPF'den söz eden bir geri dönen ileti üretmez. Fark edilmemesinin nedeni budur. Üç yerde ortaya çıkar. Alınan bir iletinin Authentication-Results başlığında SPF sonucu pass yerine permerror olarak görünür. DMARC toplu raporlarında, kaydınızda olduğunu bildiğiniz kaynaklar için SPF başarısız görünür. Uygulamada ise hizalı bir DKIM imzası da bulunmayan iletiler spam klasörüne düşmeye ya da kendi DMARC politikanız gereği reddedilmeye başlar.

permerror her ileti için geçerli olduğundan, etki en son eklediğiniz gönderenle sınırlı kalmaz. SPF'ye bağlı bütün e-postalar aynı anda etkilenir.

Authentication-Results: mx.example.net; spf=permerror (too many DNS lookups) smtp.mailfrom=example.com

Hiç ihtiyaç duymayabileceğiniz include girdileri

En ucuz çözüm, hiçbir zaman işe yaramamış include girdilerini kaldırmaktır. SPF, zarf göndereni domainine göre değerlendirilir. Birçok servis zarf göndereninde kendi domainini kullanarak gönderir. Bu durumda alıcı sunucular servisin SPF kaydına bakar, sizinkine hiç başvurmaz. Kaydınızda böyle bir servis için duran include sorgu harcar ve hiçbir şeyi değiştirmez.

Bunu anlamak için servisin gönderdiği bir iletinin Return-Path başlığına bakın. Oradaki domain servisin kendi domainiyse ya da servise devrettiğiniz bir alt domainse, servisin ana domaininizin SPF kaydında bulunması gerekmez. Kurulum kılavuzu yine de include eklemenizi söyleyebilir, çünkü o talimat her yapılandırma için yazılmıştır.

Boş sorgu sınırı

İlkinin yanında daha az bilinen ikinci bir sınır da geçerlidir. Hiçbir kayıt döndürmeyen bir sorguya ya da var olmayan bir ada yapılan sorguya boş sorgu (void lookup) denir ve belirtim tek bir değerlendirmede bunlardan yalnızca ikisine izin verir. Bunun ötesinde sonuç yine kalıcı hatadır.

Eski bir include girdisini hataya dönüştüren şey budur. Bir servis iptal edilir, include girdisi kayıtta kalır ve bir gün sağlayıcı arkasındaki DNS adını kaldırır. Tek bir ölü include hoş görülür. İkincisi ya da MX kaydı olmayan bir domaindeki mx mekanizması SPF'yi bozar. Bu nedenle kullanılmayan girdileri kaldırmak yalnızca bir düzen işi değildir.

Düzleştirme ve bedeli

Düzleştirme, bir include girdisini o anda çözümlendiği IP aralıklarıyla değiştirir. ip4 ve ip6 sorgu gerektirmediği için sorgular ortadan kalkar. Kayıt yazıldığı gün doğrudur, sağlayıcının bir aralık eklediği ya da taşıdığı gün yanlıştır ve bu olduğunda size hiçbir şey haber vermez. Büyük sağlayıcılar aralıklarını haber vermeden değiştirir.

Bazı servisler bunu otomatikleştirir: sizin include ettiğiniz bir ad altında düzleştirilmiş bir kayıt yayınlar ve kaynak kayıtlar değiştiğinde onu yeniler. Bu, bakım yükünü kaldırır ama bir bağımlılık ekler, çünkü SPF'niz artık o servisin erişilebilir ve doğru kalmasına dayanır. Elle düzleştirmeyi yalnızca küçük, belgelenmiş ve kararlı bir adres kümesi olan gönderenler için yapın ve neden yapıldığını kayda geçirin.

Sorgu hakkını bölmek için alt domain kullanmak

Kalabalık bir kayıt için kalıcı çözüm, her şeyi tek bir domainden göndermeyi bırakmaktır. Her alt domainin kendi SPF kaydı ve kendi on sorguluk sınırı vardır.

1. Her gönderim amacı için bir alt domain seçin. Örneğin pazarlama için news, faturalar için billing.
2. Her servisi, o alt domaini zarf göndereni ya da özel dönüş yolu olarak kullanacak şekilde yapılandırın.
3. Her alt domainde, yalnızca onu kullanan tek servisi listeleyen bir SPF kaydı yayınlayın.
4. O servisin include girdisini ana domainin kaydından kaldırın.
5. DMARC'ta gevşek hizalamayı koruyun. Böylece bir alt domainden gelen e-posta, ana domaindeki From adresiyle hizalı kalır.

example.com.          TXT  "v=spf1 include:_spf.google.com -all"
news.example.com.     TXT  "v=spf1 include:servers.mcsv.net -all"
billing.example.com.  TXT  "v=spf1 include:sendgrid.net -all"

DKIM bu sorunu neden daha az acil kılar

DMARC, SPF ya da DKIM'den biri hizalı olarak geçtiğinde geçer. Hizalı bir DKIM anahtarıyla imzalayan bir gönderen, DMARC'tan geçmek için SPF kaydınıza bağlı değildir. Her üçüncü taraf servis özel bir DKIM domainiyle kurulmuşsa, SPF permerror bir kesinti olmaktan çıkar ve bir zayıflığa dönüşür.

Bu, kaydı bozuk bırakmak için bir gerekçe değildir, çünkü bazı alıcı sunucular SPF'yi ayrıca değerlendirir ve iletme ender durumlarda DKIM'i bozabilir. Ancak iş sırasını değiştirir: SPF sınırı aşmışsa ve e-postalar başarısız oluyorsa, etkilenen gönderenlerde hizalı DKIM'i etkinleştirmek, kayıt sadeleştirilirken teslimatı geri getirmenin çoğu zaman en hızlı yoludur.

Tekrar yaşanmasını önlemek

Sınır çoğunlukla kendi kaydınızda hiçbir düzenleme yapılmadan, bir sağlayıcı iç içe bir include eklediğinde aşılır. Dokuz ya da on sorguda duran bir kayıt, başarısız olmaya tek bir sağlayıcı değişikliği kadar uzaktır. Yedi ve altında kalmayı hedefleyin, bir gönderim servisi eklendiğinde ya da kaldırıldığında kaydı gözden geçirin ve görünen sayıyı değil gerçek sayıyı izleyin. CloudSpex include zincirini belirli aralıklarla izler, ölçülen sorgu sayısını bildirir ve kayıt değiştiğinde ya da sınırı aştığında uyarı verir.