SPF kaydınız yıllardır sorunsuz çalışıyordu. Yeni bir servis eklediniz ve birdenbire e-postalarınız spam'e düşmeye başladı — üstelik yeni servisten değil, eskiden çalışan sistemlerden gidenler de.
Nedeni büyük ihtimalle SPF'in az bilinen bir sınırıdır. Bu yazı, e-posta kimlik doğrulamasında bu sınırı ve çözümünü anlatıyor.
Sorgu Limiti Nedir?
SPF kaydı doğrulanırken, alıcı sunucu bazı ifadeleri çözümlemek için ek DNS sorguları yapar. Bu sorgular için bir üst sınır vardır.
Sınırın gerekçesi teknik bir korumadır: sınırsız sorgu, kötüye kullanımla alıcı sunucuları meşgul edecek bir saldırı aracına dönüşebilirdi.
Ancak sonucu şudur: bu sınır aşıldığında SPF doğrulaması hata verir ve kayıt hiç yokmuş gibi değerlendirilir.
Kritik nokta, hatanın kapsamıdır: sınır aşıldığında yalnızca son eklenen servis değil, tüm gönderim kaynaklarınız doğrulamayı kaybeder.
Sorgu Tüketen Öğeler
| Öğe | Sorgu tüketir mi? |
|---|---|
| Başka bir alan adını dahil etme | Evet — ve iç içe olabilir |
| Alan adı üzerinden yetkilendirme | Evet |
| Posta sunucusu kaydı üzerinden | Evet, birden fazla |
| Ters kayıt üzerinden | Evet, pahalı |
| Doğrudan IP tanımı | Hayır |
Son satır çözümün anahtarını verir: doğrudan IP tanımları hiç sorgu tüketmez. Kayıt sadeleştirmenin temel yöntemi budur.
İlk satır ise en büyük tüketimi üretir ve gizlidir: dahil ettiğiniz bir servisin kendi kaydı da başka kayıtları dahil ediyor olabilir. Tek bir satır, arka planda çok sayıda sorgu üretebilir.
Sessiz Birikim
Bu sorunun sinsi yanı, zamanla oluşmasıdır:
- Başlangıçta basit bir kayıt vardır
- Pazarlama platformu eklenir
- Fatura sistemi eklenir
- Destek yazılımı eklenir
- Yeni bir bulut servisi eklenir
- Ve bir gün sınır aşılır
Her ekleme tek başına makuldür ve sorun üretmez. Sınır aşıldığı anda ise sorun, o son eklemeden değil tüm birikimden kaynaklanır — ama siz yalnızca son değişikliği hatırlarsınız.
Ayrıca sorun sizin değişikliğiniz olmadan da ortaya çıkabilir: kullandığınız bir servis kendi SPF kaydını genişletirse, siz hiçbir şey yapmadan sınır aşılabilir.
Teşhis
Bu sorunu tespit etmek için:
- SPF doğrulama araçları kullanın. Sorgu sayısını hesaplayıp gösterirler.
- İleti başlıklarına bakın. Doğrulama sonucunda kalıcı hata görünür.
- DMARC raporlarını inceleyin. SPF başarısızlıkları toplu olarak görünür.
- Değişiklik sonrası test edin. Yeni servis ekledikten sonra mutlaka.
İkinci madde kesin kanıt sağlar: kimlik doğrulama sonucu satırında SPF için kalıcı hata durumu görüyorsanız, büyük olasılıkla sorgu limiti aşılmıştır.
Dördüncü madde de bir alışkanlık olmalıdır: SPF kaydına her ekleme sonrası doğrulama aracıyla kontrol edin. Bu, otuz saniyelik bir işlemdir ve sorunu ortaya çıkmadan yakalar.
Çözüm Yolları
Kullanılmayanları Temizleyin
İlk ve en kolay adım: kayıtta artık kullanmadığınız servisler var mı?
Yıllar içinde eklenen ve artık kullanılmayan platformlar, kayıtta durmaya devam eder. Bu temizlik genellikle birkaç sorgu kazandırır ve güvenlik açısından da doğrudur — kullanmadığınız bir servisin sizin adınıza gönderim yapabilmesi gereksiz bir risktir.
Doğrudan IP Tanımına Geçin
Bir servisin IP adresleri sabitse, dahil etme yerine doğrudan IP tanımı kullanabilirsiniz. Bu, sorgu tüketimini sıfıra indirir.
Riski: servis IP değiştirirse gönderiminiz doğrulamayı kaybeder. Bu yüzden yalnızca IP'lerini sabit tutan ve değişikliği önceden duyuran servisler için uygundur.
Pahalı Mekanizmalardan Kaçının
Posta sunucusu kaydı ve ters kayıt üzerinden yetkilendirme, tek satır gibi görünse de birden fazla sorgu tüketir.
Bunları doğrudan IP tanımlarıyla değiştirmek belirgin kazanç sağlar.
Alt Alan Adı Ayrımı
En etkili yapısal çözümdür: farklı gönderim akışları için farklı alt alan adları kullanın.
Böylece her alt alan adının kendi SPF kaydı olur ve her biri kendi sorgu bütçesine sahip olur.
Örnek bir ayrım: pazarlama gönderimleri bir alt alan adından, işlemsel iletiler başka bir alt alan adından, kurumsal yazışmalar ana alan adından.
Bu yaklaşımın ek faydası itibar ayrımıdır: bir akıştaki sorun diğerlerini etkilemez.
Kayıt Düzleştirme
Dahil edilen kayıtların içeriği çözümlenip doğrudan IP listesine dönüştürülür. Sorgu tüketimi ortadan kalkar.
Ciddi bir dezavantajı vardır: servis IP'lerini değiştirdiğinde kaydınız eskir ve gönderim doğrulamayı kaybeder.
Bu yöntem kullanılacaksa otomatik güncelleme gerektirir — elle yönetilen bir düzleştirme, zaman içinde mutlaka bozulur.
Önerilen Yaklaşım
Sıralı bir strateji:
- Önce temizleyin. Kullanılmayan servisleri çıkarın.
- Pahalı mekanizmaları değiştirin. Doğrudan IP tanımlarına geçin.
- Hâlâ sınırdaysanız alt alan adı ayrımı yapın. Yapısal ve kalıcı çözüm.
- Düzleştirmeyi son çare olarak düşünün. Ve otomatikleştirin.
Üçüncü madde uzun vadede en sağlıklı çözümdür ve ek faydalar sağlar: hem sorgu bütçesi rahatlar hem itibar ayrımı kurulur hem de her akışın performansı ayrı izlenebilir.
Önleme
Bu sorunu hiç yaşamamak için:
- Kaydınızı düzenli kontrol edin. Yılda birkaç kez doğrulama aracıyla.
- Her eklemede test edin. Yeni servis sonrası mutlaka.
- Gönderim kaynağı envanteri tutun. Hangi servis neden ekli?
- Servis değişikliklerini takip edin. Sağlayıcılar SPF kayıtlarını güncelleyebilir.
- Baştan alt alan adı ayrımı kurun. Sonradan geçmek daha zordur.
Üçüncü madde temizlik yaparken kritik hâle gelir: bir servisin neden ekli olduğunu bilmiyorsanız, kaldırmaya cesaret edemezsiniz ve kayıt şişmeye devam eder.
Beşinci madde ise ileriye dönük bir yatırımdır: gönderim kaynaklarınız az sayıdayken bile akış ayrımını kurmak, ileride bu sorunu hiç yaşamamanızı sağlar.
DMARC ile İlişki
SPF hatası, DMARC politikanız nedeniyle daha ağır sonuçlar üretebilir:
- Yalnızca izleme modundaysanız iletiler geçer ama raporlarda hata görünür
- Spam klasörüne alma politikası varsa iletiler spam'e düşer
- Reddetme politikası varsa iletiler tamamen reddedilir
Üçüncü satır en sert senaryodur ve DKIM'in önemini gösterir: DKIM imzanız doğru çalışıyorsa, SPF hatası olsa bile DMARC geçebilir — çünkü ikisinden birinin uyumlu geçmesi yeterlidir.
Bu, pratik bir güvence üretir: DKIM'i eksiksiz kurmak, SPF tarafındaki bir sorunun tam kesintiye dönüşmesini engeller.
Gönderimlerinizi merkezi bir smarthost üzerinden yapmak da bu sorunu yapısal olarak azaltır: çok sayıda farklı servisi SPF kaydınıza eklemek yerine, tek bir gönderim noktası tanımlarsınız.
Sonuç
SPF sorgu limiti, sessizce biriken ve aşıldığında topluca zarar veren bir sınırdır: limit aşıldığında yalnızca son eklenen servis değil, tüm gönderim kaynaklarınız doğrulamayı kaybeder. Üstelik siz hiçbir şey yapmadan da ortaya çıkabilir — kullandığınız bir servis kendi kaydını genişletirse. Çözüm sırası nettir: önce kullanılmayanları temizleyin, sonra pahalı mekanizmaları doğrudan IP tanımlarıyla değiştirin, hâlâ sınırdaysanız alt alan adı ayrımına geçin — her alt alan adının kendi sorgu bütçesi olur.
Sıkça Sorulan Sorular (SSS)
SPF sorgu limiti nedir ve neden var?
SPF kaydı doğrulanırken bazı ifadeler ek DNS sorguları gerektirir ve bunun bir üst sınırı vardır. Sınır, kötüye kullanımla alıcı sunucuları meşgul edecek bir saldırı aracı oluşmasını engellemek için konmuştur.
Limit aşılırsa ne olur?
SPF doğrulaması kalıcı hata verir ve kayıt hiç yokmuş gibi değerlendirilir. Kritik nokta şudur: yalnızca son eklenen servis değil, tüm gönderim kaynaklarınız aynı anda doğrulamayı kaybeder.
Nasıl çözerim?
Önce kullanmadığınız servisleri kayıttan çıkarın — bu hem sorgu kazandırır hem güvenlik açısından doğrudur. Sonra posta sunucusu kaydı gibi pahalı mekanizmaları doğrudan IP tanımlarıyla değiştirin. Kalıcı çözüm ise farklı gönderim akışları için farklı alt alan adları kullanmaktır.
SPF hatası tüm iletilerimi engeller mi?
DKIM imzanız doğru çalışıyorsa hayır. DMARC için SPF ve DKIM'den birinin uyumlu geçmesi yeterlidir. Bu yüzden DKIM'i eksiksiz kurmak, SPF tarafındaki bir sorunun tam kesintiye dönüşmesini engelleyen bir güvencedir.
