Yanlış Yapılandırılmış SPF Kayıtları: Sessiz Tehlike

E-posta güvenliği denildiğinde akla çoğu zaman antivirüs, spam filtresi veya güçlü şifreler gelir. Ancak bir e-posta altyapısının görünmeyen ama kritik yapı taşlarından biri de SPF (Sender Policy Framework) kaydıdır. SPF kaydı, alan adınızın hangi sunucular üzerinden e-posta gönderebileceğini belirler. Ancak birçok sistemde bu kayıt yanlış yapılandırıldığı için ya etkisiz kalır ya da meşru gönderimleri engeller.

Bu yazıda, yanlış SPF yapılandırmalarının ne gibi sorunlara yol açabileceğini, sık yapılan hataları ve doğru yapılandırma yöntemlerini detaylıca ele alıyoruz.

SPF Kaydı Nedir?

SPF (Sender Policy Framework), alan adınız adına gönderilen e-postaların hangi IP adreslerinden ya da sunuculardan gönderileceğini belirten bir DNS kaydıdır. Bu kayıt, alıcı mail sunucularının sizin adınıza gönderilen maillerin yetkili kaynaklardan gelip gelmediğini kontrol etmesini sağlar.

Doğru yapılandırılmış bir SPF kaydı, sahte e-posta gönderimlerinin (spoofing) ve marka suistimalinin önüne geçer.

Sık Yapılan SPF Hataları

1. ~all Yerine -all Kullanılmaması

SPF kaydının sonunda yer alan ~all ifadesi "softfail" anlamına gelir. Yani SPF'e uymayan IP’lerden gelen e-postalar sadece işaretlenir ama engellenmez.
Oysa -all kullanılırsa, bu IP’lerden gelen e-postalar doğrudan reddedilir.

Yanlış:

Doğru:

???? Not: Eğer SPF geçiş aşamasındaysa, ~all tercih edilebilir; ama kalıcı çözüm için -all önerilir.

2. Üçüncü Taraf Hizmetleri Dahil Etmemek

Birçok şirket, e-posta gönderiminde CRM sistemleri, SMTP relay hizmetleri veya e-posta pazarlama araçları (örneğin: Mailchimp, Sendgrid, Zoho, Outlook, Gmail) kullanır. Ancak bu servislerin IP adresleri SPF’e “include” yöntemiyle eklenmezse, bu hizmetler üzerinden yapılan gönderimler SPF testinden geçemez.

Örnek:

Bu yapılandırma sayesinde hem kendi sunucunuzdan hem de Google Workspace’ten gönderilen mailler SPF testinden geçer.

3. SPF Lookup Sınırının Aşılması (10 DNS Sorgusu)

SPF kayıtları, en fazla 10 dış DNS sorgusuna izin verir. Her include, redirect veya a, mx kullanımı bu sorgu sayısını artırır. Bu sınır aşıldığında, SPF geçersiz sayılır. Çoğu zaman fark edilmez ama SPF hiçbir şekilde çalışmaz.

Çözüm:
– SPF flattening araçları kullanın.
– Gereksiz include ifadelerini kaldırın.
– Alt domainleri doğrudan ip4 ile tanımlayın.

4. PTR (Reverse DNS) Kaydının SPF ile Uyumsuzluğu

Mail sunucusunun IP adresi için PTR (Reverse DNS) kaydı yoksa veya alan adınızla eşleşmiyorsa, SPF düzgün olsa bile e-postalar spam'e düşebilir. Özellikle Gmail ve Outlook gibi büyük sağlayıcılar bu uyumsuzluğu dikkate alır.

5. SPF Kayıtlarıyla DMARC Uyumsuzluğu

SPF tek başına yeterli değildir. SPF’in DMARC ile birlikte çalışması için, SPF doğrulaması yapılırken "align" (uyum) olması gerekir. Yani, SPF’ten geçen sunucu, aynı zamanda “From” adresiyle aynı domain'den gönderilmiş olmalıdır. Aksi takdirde DMARC başarısız olur.

SPF Kaydınızı Test Etmek İçin Araçlar

• MXToolbox SPF Checker

• Google Admin Toolbox Check MX

• Kitterman SPF Validator

Bu araçlarla SPF kaydınızı test ederek hataları görebilir, DNS sorgu sayısını kontrol edebilir ve önerileri inceleyebilirsiniz.

Sonuç: SPF Varsa Güvendeyim Demeyin

SPF kaydının varlığı güvenliği garanti etmez. Yanlış yapılandırılmış bir SPF kaydı, sizi hem sahtecilik saldırılarına açık bırakır hem de meşru maillerinizin spam’e düşmesine yol açar. SPF'in etkili olabilmesi için:

Doğru bitiş parametresi (-all) kullanılmalı
 Tüm yetkili servislerin IP’leri veya SPF kayıtları dahil edilmeli
 10 DNS sorgu sınırı aşılmamalı
PTR ve DMARC ile uyum sağlanmalı

 Daha Fazlası İçin

Bu konuyla ilgili detaylı destek almak veya SPF, DKIM, DMARC gibi kayıtların sizin adınıza kontrol edilmesini isterseniz bizimle iletişime geçebilirsiniz