SPF kaydınız e-posta teslim edilebilirliğinizi sabote ediyor olabilir ve bunun farkında bile olmayabilirsiniz. Birçok kuruluş DMARC politikalarına odaklanırken, gizli bir SPF yanlış yapılandırması meşru e-postaların kimlik doğrulamayı geçememesine ve spam klasörüne düşmesine yol açabilir.

Suçlu? SPF 10 sorgu sınırı — aşıldığında kimlik doğrulamayı sessizce bozan katı bir üst sınır. Bu durum özellikle birden fazla ESP, pazarlama aracı ve bulut gönderici kullanıyorsanız belirgin biçimde hissedilir.

SPF 10 Sorgu Sınırını Anlamak

SPF (Sender Policy Framework), alıcılara hangi sunucuların alan adınız adına posta gönderebileceğini bildirir. RFC 7208'e göre SPF değerlendirmesi en fazla 10 DNS sorgusu yapabilir. Bu sınır aşıldığında alıcılar SPF'yi permerror olarak kabul etmelidir.

Bu durumla karşılaştığınızda şunlar yaşanır:

  • Anlık DMARC kimlik doğrulama hataları
  • Meşru e-postaların spam olarak işaretlenmesi
  • Teslim edilebilirlik düşüşleri ve itibar kaybı

Neyin Sorgu Sayıldığına Dikkat Edin

DNS sorgusu tetikleyen mekanizmalar ve değiştiriciler:

  • include:
  • a (değişmez bir sunucu adı olmaksızın)
  • mx
  • exists
  • redirect=

Her include:, zincirleme biçimde daha fazla include:'a yol açabilir; sorgu bütçeniz çok hızlı tükenebilir.

Yaygın SPF Hataları

"Her Şeyi Dahil Et" SPF'si

v=spf1 include:_spf.google.com include:mailchimp.com include:spf.protection.outlook.com include:amazonses.com ~all

Düzenli görünür ancak iç içe geçme nedeniyle çoğunlukla 10 sorguyu aşar.

Eski Sağlayıcı Birikimi

Kayıtta bırakılan eski sağlayıcılar sorgu tüketmeye devam eder.

İç İçe Geçmiş Include Zincirleri

Bazı ESP'ler birden fazla dahili SPF kaydına başvurur ve her biri ek sorgular ekler.

Gelişmiş SPF Optimizasyon Stratejileri

1) IP Adresi Düzleştirme

Yoğun include:'ları, sağlayıcıların mevcut IP aralıklarıyla değiştirin (bu aralıklar kararlı ve sözleşmeyle belgelenmiş olduğunda).

Önceki hali

v=spf1 include:_spf.google.com include:mailchimp.com ~all

Sonraki hali

v=spf1 ip4:209.85.128.0/17 ip4:64.233.160.0/19 ip4:198.2.128.0/18 ~all

Bu yaklaşım birden fazla sorguyu sıfıra indirebilir; ancak sağlayıcılar IP'lerini değiştirdiğinde bakım gerektirir.

2) Alt Alan Adları Aracılığıyla SPF Delegasyonu

# Kök
example.com: v=spf1 include:_spf.google.com redirect=spf.marketing.example.com

# Pazarlama alt alan adı
spf.marketing.example.com: v=spf1 include:mailchimp.com include:servers.mcsv.net ~all

# Destek alt alan adı
spf.support.example.com: v=spf1 include:mail.zendesk.com ~all

3) Düzenli SPF Denetimi

  • Kullanılmayan include'ları ve sağlayıcıları kaldırın
  • Sorgu sayısını ölçün (baş odası bırakmak için hedef: ≤ 8)
  • Sağlayıcı SPF değişikliklerini üç ayda bir doğrulayın

Uygulama Planı (KOBİ dostu)

  1. 1. Hafta: Sağlayıcıları listeleyin; kullanılmayan include'ları kaldırın
  2. 2. Hafta: En çok sorgu tüketen sağlayıcıları düzleştirin (IP'leri belgeleyin)
  3. 3. Hafta: Ağır yapılandırmaları alt alan adlarına devredin
  4. 4. Hafta: DMARC geçiş oranlarını ve gelen kutusu yerleşimini izleyin

SPF + DMARC: Neden Önemlidir?

DMARC'ın çalışması için SPF veya DKIM'in hizalanmış olması gerekir. SPF sık sık permerror veriyorsa DKIM'e gereğinden fazla bağımlı oluyorsunuz; bu da tek bir başarısızlık noktası oluşturur. Sağlıklı bir SPF, DMARC geçiş oranlarını ve kararlılığını artırır.

SPF'nizin Zaten Sınırı Aştığının İşaretleri

Birçok kuruluş, toplu raporlarda açıklanamayan DMARC hatalarını görene kadar SPF'lerinin bozuk olduğunu fark etmez. Yaygın uyarı işaretleri şunlardır:

  • Mesajların önemli bir bölümü için DMARC raporlarında spf=permerror görünmesi
  • Yetkili bir ESP'den gönderilmesine rağmen meşru pazarlama e-postalarının spam'e düşmesi
  • SPF kontrollerinin bazı alıcılarda geçmesi, diğerlerinde başarısız olması (farklı çözümleyiciler önbelleği farklı yönetebilir)
  • Sınırı aşmanıza neden olan yeni bir pazarlama aracı veya CRM'in yakın zamanda eklenmesi

En güvenli yaklaşım, sorguları tepkisel değil proaktif biçimde saymaktır. Adınıza e-posta gönderen her hizmetin belgelenmiş bir envanterini tutun ve her birini SPF mekanizmasıyla eşleştirin. Bu envanteri üç ayda bir — veya yeni bir e-posta aracı eklediğinizde — gözden geçirin.

SPF'nizi dakikalar içinde düzeltin
Sorguları sayın, güvenli biçimde düzleştirin ve hizalamayı doğrulayın.

Sık Sorulan Sorular

Sorgu sayımı nasıl kontrol ederim? DMARCFlow'un SPF denetleyicisini kullanın (ya da dig ile izleyin) ve DNS çözümleyen her mekanizmayı sayın.

Birden fazla SPF kaydı yayınlayabilir miyim? Hayır. Kök düzeyde yalnızca bir TXT SPF kaydı bulunmalıdır. Bunun yerine kayıtları birleştirin veya düzleştirin.

10'u aşarsam ne olur? Alıcılar permerror döndürebilir → DMARC çoğunlukla başarısız olur → gelen kutusu yerleşimi kaybolur.

Düzleştirme her zaman en iyi yöntem midir? Etkilidir; ancak bakım gerektirir. Çok dinamik sağlayıcılar için alt alan adı delegasyonunu değerlendirin.

Alan adınızın gerçekte ne kadar korumalı olduğunu görmek ister misiniz? Ücretsiz DMARCFlow alan adı taramasını deneyin ve anında rapor alın.