Defaults.Exposed › Raporlar

SPF ptr Mekanizması Nedir — ve Neden Hâlâ 950,631 Kayıtta Yer Alıyor? (2026)

Yayımlanma 2026-07-03

2026-06-29 itibarıyla rakamlar · metodoloji v7. 261 milyon notlandırılmış alan adı genelinde toplu sayım. Tüm rakamlar toplamdır — asla tek bir işletmenin kaydı değildir. Bkz. nasıl notlandırdığımız.

ptr, göndericileri ters DNS (reverse-DNS) araması yoluyla yetkilendiren bir SPF mekanizmasıdır — ve SPF standardının kendisi 2014’ten beri “bunu kullanmayın” diyor. 12 yıl sonra, 950,631 alan adı hâlâ bunu yayımlıyor. Bu, internetteki 139 milyon SPF kaydının kabaca 146 tanesinden biri anlamına geliyor; üstelik bu mekanizma, o alan adlarının bazıları henüz kaydedilmeden önce spesifikasyon tarafından kullanımdan kaldırılmıştı.

ptr’nin ne yapması gerekiyordu

ptr şunu söyler: “ters DNS’i benim alan adıma çözümlenen herhangi bir sunucudan gelen postayı kabul et.” Kulağa şık geliyor — bakımı gereken hiçbir IP listesi yok. Uygulamada ise alıcının, bağlanan IP üzerinde ters bir arama yapmasını, ardından geri gelen her sunucu adını ileri yönde doğrulamasını gerektirir. RFC 7208 (§5.5) bunu açık sözlerle kullanımdan kaldırdı: mekanizma “yavaştır, DNS hatalarında diğer mekanizmalar kadar güvenilir değildir ve .arpa ad sunucularına büyük bir kaynak yükü bindirir” — ve “KULLANILMAMALIDIR” talimatını verir.

2026’da neden hâlâ bir tuzak

12 yıl önce kullanımdan kaldırılan bir mekanizmanın hâlâ önemli olmasının üç nedeni:

• Sorgu bütçenizi tüketir. Her ptr, SPF’in kontrol başına 10 DNS sorgusu şeklindeki katı tavanına dahil edilir — bu, bir kez aşıldığında tüm kaydı bir PermError ile geçersiz kılan sınırdır. Güvenilir hiçbir şey yapmayan bir mekanizma, yine de gerçek include: mekanizmalarınızın ihtiyaç duyduğu bütçeyi tüketir.
• Öngörülemez biçimde başarısız olur. Ters DNS, çoğu ağın en az bakımı yapılan köşesidir. ptr araması zaman aşımına uğradığında ya da ileri yönde doğrulama başarısız olduğunda, meşru postanız güvendiği SPF geçişini kaybeder.
• Bazı alıcılar bunu tümüyle atlar. Standart bunu kullanımdan kaldırdığı için, bazı uygulamalar ptr’yi doğrudan yok sayar — dolayısıyla yetkilendirmesi gereken göndericiler zaten en başından beri korunmamış olur.

Nereden geliyor

Bugün neredeyse hiç kimse ptr’yi bilerek seçmiyor. Bu, miras yoluyla geliyor: 2009’da yazılmış bir kurulum kılavuzu, eski bir sunucu yapılandırmasından kopyalanmış bir şablon, üç barındırma taşınmasının ardından olduğu gibi taşınan “çalışan” bir kayıt. Sayımımızın kullanımdan kaldırılmış-ama-mevcut her mekanizmada gördüğü örüntü tam da bu: eski tavsiyeler ölmez, kopyala-yapıştır edilir. ptr taşıyan alan adları dikkatsiz değil — 12 yıl önce emekliye ayrılmış talimatları izliyorlar.

Nasıl düzeltilir — ücretsiz, beş dakika

1. SPF kaydınızı bulun (dig TXT yourdomain.com veya ücretsiz kontrol edin).
2. Eğer ptr içeriyorsa, hangi sunucuların buna güvendiğini belirleyin.
3. ptr’yi kesin biçimle değiştirin: kontrol ettiğiniz sunucular için bir ip4:/ip6: bloğu veya sağlayıcınızın belgelediği include:.
4. Zaten oradayken, kaydın gerçek bir niteleyiciyle bittiğini doğrulayın — bkz. ~all vs -all.

Sıkça sorulan sorular

Bir SPF kaydında ptr ne anlama gelir? Ters DNS’i alan adınıza çözümlenen herhangi bir sunucuyu yetkilendirir. RFC 7208 §5.5 bunu 2014’te yavaş ve güvenilmez olduğu gerekçesiyle kullanımdan kaldırdı ve KULLANILMAMALIDIR diyor — yine de 2026-06-29 itibarıyla 950,631 alan adı hâlâ bunu yayımlıyor.

SPF ptr mekanizması hiç geçerli olur mu? Hâlâ ayrıştırılıyor ve bazı alıcılar hâlâ değerlendiriyor — ancak standart tüm durumlarda buna karşı tavsiyede bulunuyor, bazı alıcılar bunu yok sayıyor ve on DNS sorgunuzdan birini harcıyor. ptr’nin doğru yanıt olduğu modern bir yapılandırma yok.

ptr yerine ne kullanmalıyım? Kontrol ettiğiniz sunucular için ip4:/ip6: blokları veya sağlayıcınızın belgelediği include:. Her ikisi de belirlenimci, hızlı ve güvenilirdir — ptr’nin olmadığı her şey.

ptr, SPF 10 sorgu sınırına dahil edilir mi? Evet — her ptr, bir alıcının bir PermError ile pes etmeden önce gerçekleştireceği on DNS sorgusundan en az birine mal olur. Zaten include: mekanizmalarıyla dolu kayıtlarda, bu ölü mekanizma sizi sınırın üzerine iten mekanizma olabilir.

Kaydınızı hayaletlere karşı kontrol edin

12 yıl önce kullanımdan kaldırılıp hâlâ DNS’inizde duran bir mekanizma, tam da kimsenin aramadığı türden bir şeydir. Bakmak yarım dakika sürer.

Alan adınızı kontrol edin → · SPF’i düzeltin → · İki SPF kaydı = hiçbiri → · SPF olgunluk modeli → · Yalnızca toplu veriler. Veriler AB’de saklanır ve işlenir.