SPF kaydı, alan adınız adına e-posta göndermeye yetkili sunucuları listeleyen tek bir DNS TXT kaydıdır. Kaydı oluşturmak için e-posta gönderen tüm hizmetlerinizi belirler, bunları include, ip4 veya ip6 mekanizmalarıyla tek bir kayıtta toplar, kaydı ~all veya -all ile bitirir ve toplam DNS sorgu sayısının 10'u aşmadığından emin olursunuz.

SPF nedir ve neden gereklidir?

SPF (Sender Policy Framework), RFC 7208 ile tanımlanmıştır. Alıcı e-posta sunucusu, gelen iletinin zarf göndericisindeki (Return-Path) alan adının SPF kaydına bakar ve iletiyi gönderen IP adresinin yetkili olup olmadığını kontrol eder.

SPF tek başına Kimden (From) adresini korumaz; bu yüzden DMARC ile birlikte kullanılmalıdır. Yine de SPF, DMARC'nin iki temel bileşeninden biridir ve büyük e-posta sağlayıcıları tarafından gönderen alan adlarından beklenmektedir.

Adım adım SPF kaydı oluşturma

1. Gönderim kaynaklarını envanterleyin

Alan adınız adına e-posta gönderen her şeyi listeleyin:

  • Kurumsal e-posta hizmeti (ör. Google Workspace, Microsoft 365)
  • Bülten ve pazarlama araçları
  • CRM, destek talebi ve fatura sistemleri
  • Web sitenizin iletişim formu veya kendi e-posta sunucunuz

2. Her hizmetin SPF bilgisini bulun

Hizmet sağlayıcılar genellikle eklenmesi gereken ifadeyi belgelerinde yayımlar. Örneğin Google Workspace için include:_spf.google.com, Microsoft 365 için include:spf.protection.outlook.com kullanılır. Kendi sunucunuz için doğrudan IP adresi yazabilirsiniz.

3. Kaydı oluşturun

Örnek bir kayıt (alan adı ve IP adresi örnektir):

v=spf1 include:_spf.google.com include:bulten-saglayici.example ip4:203.0.113.10 ~all
AlanDeğer
TürTXT
Ad (host)@ (kök alan adı)
DeğerYukarıdaki SPF ifadesi

4. Mekanizmaları ve niteleyicileri anlayın

İfadeAnlamı
v=spf1Sürüm; kayıt bununla başlamalıdır
ip4: / ip6:Belirtilen IP adresi veya aralığı yetkilidir (DNS sorgusu gerektirmez)
include:Başka bir alan adının SPF kaydı dahil edilir
a / mxAlan adının A veya MX kayıtlarındaki sunucular yetkilidir
~allListede olmayanlar softfail (şüpheli)
-allListede olmayanlar fail (yetkisiz)

10 DNS sorgusu sınırı

RFC 7208, bir SPF değerlendirmesinde DNS sorgusu gerektiren mekanizmaların (include, a, mx, ptr, exists ve redirect değiştiricisi) toplamda en fazla 10 olmasını şart koşar. İç içe include ifadeleri de bu sayıya dahildir. Ayrıca boş yanıt dönen sorgu (void lookup) sayısı için de 2 ile sınırlandırma önerilir.

Sınırı aşmamak için:

  1. Artık kullanmadığınız hizmetlerin include ifadelerini kaldırın.
  2. ptr mekanizmasını kullanmayın; RFC 7208 bunu önermez.
  3. Pazarlama gibi yoğun gönderimleri bulten.ornek.com.tr gibi ayrı bir alt alan adına taşıyın; her alt alan adının kendi SPF kaydı ve kendi 10 sorgu bütçesi olur.
  4. Sabit IP adresli kendi sunucularınız için ip4/ip6 kullanın.
SPF "düzleştirme" (include yerine IP adreslerini yazma) hizmetlerin IP adresleri değiştiğinde kaydınızı bozabilir. Bu yöntemi yalnızca otomatik güncellenen bir çözümle uygulayın.

E-posta göndermeyen alan adları ve alt alan adları

Kurumların çoğu, yalnızca marka koruması için kayıtlı tuttuğu ve hiç e-posta göndermediği alan adlarına sahiptir. Bu alan adları saldırganlar için caziptir; çünkü kimse onları izlemez. Bu tür alan adları için şu kaydı yayımlayın:

v=spf1 -all

Bu ifade, alan adı adına hiçbir sunucunun e-posta gönderemeyeceğini açıkça bildirir. Aynı alan adına v=DMARC1; p=reject; politikalı bir DMARC kaydı eklemek korumayı tamamlar.

SPF kaydı alt alan adlarına kalıtsal olarak uygulanmaz. bulten.ornek.com.tr gibi bir alt alan adından gönderim yapıyorsanız bu alt alan adı için ayrı bir SPF kaydı oluşturmanız gerekir. Bu durum, yoğun gönderim yapan hizmetleri alt alan adlarına ayırarak ana alan adının sorgu bütçesini korumanızı da kolaylaştırır.

SPF değişikliklerini yapmadan önce mevcut kaydın bir kopyasını alın. Hatalı bir değişiklikte eski kayda hızla dönebilmek, teslim sorunlarını kısa sürede çözmenizi sağlar.

Sık yapılan hatalar

  • İki ayrı SPF kaydı: Yeni bir hizmet eklerken ikinci bir v=spf1 kaydı oluşturmak SPF'yi tamamen bozar.
  • +all kullanmak: Bu ifade herkesi yetkili kılar ve SPF'yi anlamsız hâle getirir.
  • Uzun kaydı bölmemek: Tek bir TXT dizesi en fazla 255 karakter olabilir; daha uzun kayıtlar birden fazla tırnaklı dizeye bölünmelidir.
  • Yalnızca SPF'ye güvenmek: İletiler yönlendirildiğinde SPF bozulabilir; DKIM ve DMARC ile tamamlayın.

Nasıl doğrularım?

Kaydı yayımladıktan sonra SPF kontrol aracımızla sözdizimini ve DNS sorgu sayısını kontrol edin. DMARC ile birlikte genel durumu e-posta güvenlik testi üzerinden görebilir, ardından DMARC kontrol aracıyla politikanızı doğrulayabilirsiniz. Gönderdiğiniz bir test iletisinin başlıklarında spf=pass sonucunu görmek de iyi bir son kontroldür.

Sık sorulan sorular

Bir alan adında birden fazla SPF kaydı olabilir mi?

Hayır. RFC 7208'e göre bir alan adında yalnızca bir SPF kaydı bulunmalıdır. Birden fazla kayıt varsa sonuç permerror olur ve SPF doğrulaması başarısız sayılır; tüm mekanizmaları tek kayıtta birleştirmelisiniz.

-all mı ~all mı kullanmalıyım?

-all (hardfail) listede olmayan kaynakların kesinlikle yetkisiz olduğunu, ~all (softfail) ise şüpheli olduğunu bildirir. DMARC kullanıyorsanız nihai kararı DMARC politikası verdiği için ~all yaygın ve güvenli bir tercihtir; tüm kaynaklarınızdan eminseniz -all kullanabilirsiniz.

10 DNS sorgusu sınırını aşarsam ne olur?

SPF değerlendirmesi permerror ile sonuçlanır ve alıcılar SPF'yi başarısız kabul edebilir. Kullanılmayan include ifadelerini kaldırmak, hizmetleri alt alan adlarına taşımak veya ip4/ip6 mekanizmalarını tercih etmek sorgu sayısını azaltır.

Sık sorulan sorular

Bir alan adında birden fazla SPF kaydı olabilir mi?

Hayır. RFC 7208'e göre bir alan adında yalnızca bir SPF kaydı bulunmalıdır. Birden fazla kayıt varsa sonuç permerror olur ve SPF doğrulaması başarısız sayılır; tüm mekanizmaları tek kayıtta birleştirmelisiniz.

-all mı ~all mı kullanmalıyım?

-all (hardfail) listede olmayan kaynakların kesinlikle yetkisiz olduğunu, ~all (softfail) ise şüpheli olduğunu bildirir. DMARC kullanıyorsanız nihai kararı DMARC politikası verdiği için ~all yaygın ve güvenli bir tercihtir; tüm kaynaklarınızdan eminseniz -all kullanabilirsiniz.

10 DNS sorgusu sınırını aşarsam ne olur?

SPF değerlendirmesi permerror ile sonuçlanır ve alıcılar SPF'yi başarısız kabul edebilir. Kullanılmayan include ifadelerini kaldırmak, hizmetleri alt alan adlarına taşımak veya ip4/ip6 mekanizmalarını tercih etmek sorgu sayısını azaltır.

Kaynaklar

  1. RFC 7208 — Sender Policy Framework (SPF)
  2. Google Workspace Yönetici Yardımı — SPF kaydı tanımlama
  3. RFC 7489 — DMARC

#dmarc #spf #e-posta #dns

İlgili içerikler