E-Posta Güvenliği
Tek Seferlik Hizmet
SPF Kaydı Yapılandırma
SPF, alan adınız adına hangi sunucuların e-posta gönderebileceğini DNS üzerinden ilan eden ilk kimlik doğrulama katmanıdır. Doğru kurulduğunda yetkisiz gönderimin bir kısmını daha kapıda eler; yanlış kurulduğunda meşru postalarınızı spam’e düşürür veya "permerror" nedeniyle tamamen etkisiz kalır. Biz kaydınızı gönderim envanterinize göre tasarlar, 10 DNS sorgu limitini yönetir ve sözdizimini üretim öncesi doğrularız.
7 teknik alan
5 adımlı süreç
5 teslimat
Süreç
1Kaynak envanteri
2Mevcut durum analizi
3Kayıt tasarımı
4Kontrollü yayın
5Doğrulama
Neden ihtiyacınız var?
Bu hizmet hangi sorunu çözer?
Çoğu alan adında ya hiç SPF kaydı yoktur ya da yıllar içinde eklenen include’larla şişmiş, limit aşan veya birden fazla "v=spf1" satırı içeren bozuk bir kayıt bulunur. SPF’in en yıkıcı sessiz hatası, kaydın 10 DNS sorgu limitini aşarak "permerror" üretmesidir; bu durumda kayıt görünürde vardır ama fiilen hiçbir gönderiyi doğrulamaz. Ayrıca SPF yalnızca zarf gönderici (MAIL FROM) alanını denetler, kullanıcıların gördüğü "From" başlığını değil — bu yüzden tek başına sahteciliği durdurmaz.
- Kaydın olmaması nedeniyle meşru postaların bazı alıcılarda spam olarak işaretlenmesi
- 10 DNS sorgu limitinin aşılmasıyla oluşan "permerror" ve SPF’in tümüyle etkisizleşmesi
- Birden fazla "v=spf1" satırının aynı anda bulunması ve kaydın geçersiz sayılması
- Çok geniş "+all" veya gereksiz include’larla yetkisiz IP’lere kapının açık bırakılması
- Otomatik iletme (forwarding) senaryolarında SPF’in kırılıp postaların reddedilmesi
Neden önemli?
Bu sorunu görmezden gelmenin riski
Teslimat itibarının temeliSPF geçmesi, alıcı sunucuların spam skorunu düşüren temel sinyallerden biridir; eksikliği doğrudan gelen kutusu yerleşimini zayıflatır.
DMARC’ın ön koşuluDMARC alignment’ı SPF veya DKIM üzerinden çalışır. SPF hizalanması olmadan DMARC’ı reject’e taşımak riskli ve eksik olur.
Sahtecilik yüzeyini daraltırSPF tek başına yeterli değildir ama "-all" ile birlikte yetkisiz sunuculardan gönderimin bir bölümünü reddedilebilir hale getirir.
Sessiz arızaları önlerDoğru tasarlanmış bir kayıt, limit aşımı ve sözdizimi hatalarından kaynaklanan görünmez teslimat kayıplarını ortadan kaldırır.
Ölçeklenebilir gönderimYeni bir gönderim aracı eklendiğinde kaydın kontrollü biçimde genişletilmesi, ileride limit patlaması yaşanmasını engeller.
Kapsam
Neyi değerlendirir ve düzeltiriz?
Envanter ve keşif
- Alan adı adına gönderim yapan tüm kaynakların (posta sunucuları, SaaS, pazarlama araçları) çıkarılması
- Mevcut SPF kaydının ve varsa çakışan/yinelenen TXT satırlarının tespiti
- DNS sorgu ağacının çıkarılıp 10 lookup limitine göre değerlendirilmesi
Kayıt tasarımı
- Doğru include mekanizmalarının seçimi ve gereksizlerin ayıklanması
- ip4/ip6 mekanizmaları ile include kullanımı arasında limit odaklı denge
- Politika seçimi: softfail (~all) mi, hardfail (-all) mı — kademeli geçiş önerisi
Uygulama ve doğrulama
- DNS üzerinde tek geçerli kaydın yayınlanması ve yayılma kontrolü
- Bağımsız araçlarla sözdizimi, lookup sayısı ve geçiş testi
- Gerekirse SPF flattening ile limit altına çekme (yan etkileri açıklanarak)
Teknik kapsam
Ele aldığımız teknik alanlar
v=spf1 sözdizimi ve mekanizma sıralamasıinclude, a, mx, ip4, ip6, exists mekanizmaları10 DNS sorgu (lookup) limiti ve void lookup sınırı~all (softfail) ve -all (hardfail) niteleyicileriMAIL FROM / Return-Path (zarf gönderici) ile From başlığı farkıSPF flattening ve dinamik kaynaklarda getirdiği bakım maliyetiForwarding kaynaklı SPF kırılması ve SRS ile ilişkisi
Metodoloji
Nasıl çalışırız?
Kaynak envanteriGönderim yapan tüm sistemleri listeler, gölge/unutulmuş kaynakları ortaya çıkarırız.
Mevcut durum analiziKayıttaki hataları, yinelenen satırları ve limit aşımını belgeler, riskleri sınıflandırırız.
Kayıt tasarımıLimit dostu, en az yetki ilkesine uygun bir kayıt taslağı hazırlarız.
Kontrollü yayınDeğişikliği düşük TTL ile yayınlar, yayılmayı ve etkiyi izleriz.
DoğrulamaBağımsız araçlarla geçiş, lookup sayısı ve alignment sonuçlarını teyit ederiz.
Örnek bulgular
Tipik olarak neler tespit ederiz?
Aşağıdakiler illüstratif örneklerdir; gerçek müşteri verisi değildir.
Kritik
EtkiSPF kaydı 10 DNS sorgu limitini aşıyor (permerror) (örnek bulgu)
Kayıt görünürde var ama hiçbir alıcı sunucuda değerlendirilemiyor; SPF fiilen devre dışı.
ÖneriGereksiz include’ları ayıklayın; kritik kaynakları ip4/ip6 ile sabitleyin veya kontrollü flattening uygulayın.
Yüksek
EtkiAynı alan adında iki adet "v=spf1" satırı (örnek bulgu)
RFC gereği birden fazla SPF kaydı geçersizdir; değerlendirme permerror’a düşer.
ÖneriSatırları tek geçerli kayıtta birleştirin, fazlalıkları kaldırın.
Orta
EtkiPolitika "+all" olarak ayarlanmış (örnek bulgu)
Her sunucunun sizin adınıza göndermesine izin verilir; SPF koruma sağlamaz.
Öneriİzlemeye başlamak için ~all, olgunlaştıkça -all niteleyicisine geçin.
Düşük
EtkiKayıtta artık kullanılmayan eski sağlayıcı include’u (örnek bulgu)
Gereksiz DNS sorgusu limit baskısı yaratır ve saldırı yüzeyini genişletir.
ÖneriKullanılmayan kaynakları kayıttan çıkarın.
Sonuç
Ne teslim alırsınız, kimler için?
Ne teslim alırsınız?
- Gönderim kaynakları envanter tablosu
- Yayına hazır, limit doğrulanmış SPF TXT kaydı
- Softfail→hardfail geçiş planı ve zamanlaması
- Mevcut kayıttaki hataların ve düzeltmelerin özeti
- Bakım notu: yeni araç eklerken kaydı güvenle genişletme kılavuzu
Kimler için?
- Kendi alan adından e-posta gönderen her kurum
- Birden çok gönderim aracını tek alan adında toplayan ekipler
- Teslimat ve spam sorunlarını kökten çözmek isteyenler
- DMARC yolculuğuna sağlam bir temelle başlamak isteyen kurumlar
Ne zaman?
Bu hizmeti ne zaman düşünmelisiniz?
- Postalarınız alıcılarda düzensiz biçimde spam’e düşüyorsa
- Yeni bir e-posta gönderim aracı entegre ediyorsanız
- DMARC raporlarında SPF fail/soft-fail oranı yüksekse
- Alan adı taşıma veya sağlayıcı değişikliği yaptıysanız
Karşılaştırma
SPF, DKIM ve DMARC — rolleri nasıl ayrışır?
| SPF | DKIM | |
|---|---|---|
| Neyi doğrular | Gönderim yapan IP’nin yetkili olup olmadığını | Mesajın kriptografik imzasını ve bütünlüğünü |
| Kontrol ettiği alan | Zarf gönderici (MAIL FROM / Return-Path) | İmzalayan alan (d= etiketi) |
| Forwarding’de dayanıklılık | İletmede kolayca kırılır | İçerik değişmezse iletmede korunur |
| DMARC’a katkısı | SPF alignment sağlar | DKIM alignment sağlar |
SSS
Sıkça Sorulan Sorular
SPF tek başına sahteciliği durdurur mu?
Hayır. SPF yalnızca zarf gönderici (MAIL FROM) alanını denetler; kullanıcıların gördüğü "From" başlığını doğrudan korumaz. Görünen adres üzerinden yapılan sahteciliği durdurmak için SPF’in DKIM ve DMARC ile birlikte kullanılması gerekir.
Neden "-all" yerine "~all" ile başlanması öneriliyor?
Hardfail (-all) yetkisiz sunuculardan gelen postaların reddini ister. Envanteriniz eksikse meşru bir kaynak yanlışlıkla reddedilebilir. Softfail (~all) ile başlayıp DMARC raporlarıyla tüm kaynakları doğruladıktan sonra -all’a geçmek daha güvenli bir yoldur.
10 DNS sorgu limiti tam olarak nedir?
SPF değerlendirilirken include, a, mx, ptr, exists gibi mekanizmalar DNS sorgusu tetikler. Toplam sorgu sayısı 10’u aşarsa değerlendirme "permerror" verir ve SPF fiilen etkisiz kalır. Bu limit, kaydın kötüye kullanımla DNS’i yormasını önlemek için vardır.
SPF flattening iyi bir çözüm mü?
Limit sorununu çözebilir ama sağlayıcının IP aralıkları değiştiğinde kaydınız güncellenmezse gönderim kırılır. Flattening’i yalnızca IP’leri sık değişmeyen kaynaklar için ve düzenli bakım planıyla öneririz.
E-posta iletme (forwarding) SPF’i neden bozar?
Bir posta iletildiğinde gönderen IP, iletici sunucunun IP’sine döner; bu IP genellikle sizin SPF kaydınızda yer almaz, dolayısıyla SPF fail üretir. Bu durum SRS (Sender Rewriting Scheme) veya DKIM ile telafi edilebilir.
Birden fazla SPF kaydım olabilir mi?
Hayır. Bir alan adı için yalnızca tek bir "v=spf1" TXT kaydı geçerlidir. Birden fazlası varsa değerlendirme geçersiz sayılır. Tüm kaynaklar tek kayıtta birleştirilmelidir.
Değişiklik ne kadar sürede etkili olur?
DNS yayılması TTL değerine bağlıdır; genellikle dakikalar ile birkaç saat arasında sürer. Geçiş dönemlerinde TTL’i düşük tutmak riski azaltır.
Alt alan adlarım (subdomain) için ayrı SPF gerekir mi?
Evet. SPF alt alan adlarına devralınmaz. E-posta gönderen her alt alan adı için ayrı bir kayıt tanımlanmalı; hiç gönderim yapmayan alt alanlar için ise gönderimi tamamen reddeden bir kayıt önerilir.
Sadece SPF kurarak teslimat sorunlarım biter mi?
SPF önemli bir katmandır ancak teslimat; IP/alan itibarı, içerik, DKIM ve DMARC gibi birçok faktörün bileşkesidir. SPF’i doğru kurmak temeli sağlamlaştırır, ancak bütünsel bir yaklaşım gerekir.
Sonraki adım
İlgili hizmetler, araçlar ve rehberler
SPF Yapılandırma için başlayalım
Kapsamı netleştirelim, önceliklerinizi belirleyelim ve size özel, şeffaf bir güvenlik yol haritası çıkaralım — abartılı vaat değil, ölçülebilir risk azaltma.