What Is SPF (Sender Policy Framework)? How It Protects Your Email

Her gün sahte gönderici adresleriyle milyonlarca e-posta gönderilmektedir. Siber suçlular, müşterilerinizi, çalışanlarınızı ve iş ortaklarınızı kandırmak için alan adınızı taklit eder. Sender Policy Framework —kısaca SPF— bu duruma karşı kullanılan en eski ve en yaygın savunmalardan biridir. SPF'nin nasıl çalıştığını, neler yapıp neler yapamayacağını ve özellikle DMARC bağlamında neden önemli olduğunu anlamak, e-posta güvenliğini ciddiye alan her kuruluş için vazgeçilmezdir.

SPF entry for dmarcflow.com

SPF Nedir?

Sender Policy Framework, RFC 7208'de tanımlanan bir e-posta kimlik doğrulama standardıdır. Bir alan adının sahibinin, o alan adı adına e-posta göndermesi yetkilendirilmiş posta sunucularını ve IP adreslerini DNS'te yayımlamasına olanak tanır. Alıcı bir posta sunucusu e-posta aldığında bu listeyi sorgulayarak gönderen sunucunun listede olup olmadığını denetleyebilir.

SPF, zarf düzeyinde çalışır; özellikle MAIL FROM adresi (return-path veya zarf göndereni olarak da bilinir) üzerinde. Bu, gönderen sunucunun SMTP işleminde kullandığı adrestir ve e-posta istemcinizin "From" alanında gördüğünüz adres olmayabilir. Bu ayrım kritik öneme sahiptir; aşağıda DMARC hizalamasını ele alırken bu konuya geri döneceğiz.

SPF tek başına kullanışlı bir ilk filtredir. Ancak iyi bilinen sınırlılıkları vardır; bu nedenle DKIM ile birlikte kullanıldığında ve DMARC tarafından yönetildiğinde en iyi sonucu verir.

SPF Nasıl Çalışır? — Adım Adım

Bir posta sunucusu gelen iletiyi aldığında SPF değerlendirmesi şu adımları izler:

1. Alıcı sunucu, SMTP işleminin MAIL FROM (zarf göndereni) adresindeki alan adını çıkarır. MAIL FROM boşsa —teslimat durum bildirimleri için bu durum söz konusu olabilir— bunun yerine HELO/EHLO alan adı kullanılır (HELO kapsamı).
2. Alıcı sunucu, söz konusu alan adındaki SPF kaydı için bir DNS TXT sorgusu gerçekleştirir; örneğin _spf.example.com veya doğrudan example.com.
3. Sunucu, gönderen IP adresinin herhangi biriyle eşleşip eşleşmediğini görmek için SPF kaydındaki mekanizmaları sırayla değerlendirir: ip4, ip6, include, a, mx vb.
4. Bir eşleşme bulunduğunda, ilişkili niteleyici (+, -, ~ veya ?) sonucu belirler: pass, fail, softfail veya neutral. Hiçbir mekanizma eşleşmezse sondaki all mekanizması varsayılan sonucu sağlar.
5. Sonuç e-posta başlıklarına eklenir ve alıcı sunucu tarafından iletiyi teslim etme, karantinaya alma veya reddetme kararı için kullanılabilir.

raw DMARC view for dmarcflow.com

SPF Kaydının Anatomisi

SPF kaydı, alan adınızda yayımlanan bir DNS TXT kaydıdır. Her zaman v=spf1 ile başlar ve bir all mekanizmasıyla sona erer. Tipik bir örnek şöyledir:

v=spf1 include:_spf.google.com include:mailgun.org ip4:203.0.113.10 ~all

Temel bileşenler şunlardır:

Her mekanizmanın önündeki niteleyiciler şunlardır:

• + (varsayılan, pass): gönderen IP yetkilendirilmiş.
• - (fail): gönderen IP açıkça yetkilendirilmemiş.
• ~ (softfail): gönderen IP büyük olasılıkla yetkilendirilmemiş; hafif bir uyarı olarak kullanılır.
• ? (neutral): gönderen IP hakkında herhangi bir iddiada bulunulmaz.

SPF Sonuçları Açıklandı: pass, fail, softfail, neutral ve daha fazlası

SPF değerlendirmesi çeşitli sonuçlardan birini üretir:

DMARC amaçları doğrultusunda SPF'yi yalnızca pass sonucu karşılayabilir — ancak bu hikâyenin yalnızca yarısıdır. Alan adının da hizalı olması gerekmektedir.

SPF ve DMARC — Hizalama Her Şeydir

Pek çok yöneticinin kafasının karıştığı yer burasıdır. SPF mükemmel şekilde geçebilir — gönderen IP SPF kaydında listelenmiştir — ve yine de DMARC başarısız olabilir. Bunun nedeni: SPF hizalaması.

DMARC, SPF tarafından doğrulanan alan adının (MAIL FROM / envelope-from alan adı) görünür Header-From adresiyle — alıcılarınızın gelen kutusunda gördükleri adresle — hizalı olup olmadığını denetler. İki mod mevcuttur:

• Esnek hizalama (aspf=r, varsayılan): kurumsal alan adları eşleşmelidir. Örneğin, bounce.example.com, example.com ile hizalıdır.
• Katı hizalama (aspf=s): alan adları birebir aynı olmalıdır. bounce.example.com, example.com ile hizalı değildir.

Pek çok e-posta hizmet sağlayıcısı (ESP) ve bulut platformu, sizin adınıza gönderim yaparken MAIL FROM adresi olarak kendi alan adını kullanır. Google Workspace, Amazon SES, Mailchimp, HubSpot — hepsinin farklı varsayılan davranışları vardır. Bazı durumlarda SPF pass'ı onların alan adı için gerçekleşir; bu alan adı ise sizin Header-From alan adınızla hizalı olmadığından ham SPF geçse de DMARC SPF başarısız olur.

Insights for SPF/DKIM reasons

DMARCFlow, DMARC Raporlarında SPF Hizalamasını Nasıl Açıklar?

DMARC XML raporlarını okumak sıkıcıdır. Ham veriler yalnızca SPF'nin geçip geçmediğini söyler; bunun DMARC için neden önemli olduğunu değil. DMARCFlow, her DMARC toplu rapor kaydını ayrıştırır ve ham sonucu anlaşılır bir dile çeviren özel bir SPF içgörü analizi çalıştırır. Beş olası sonuç mevcuttur:

Şifreli XML'ye bakmak yerine DMARCFlow, raporlarınızdaki her gönderim kaynağına hangi senaryonun uygulandığını — doğrulanmış alan adı, Header-From alan adı ve hizalamanın başarılı olup olmadığı bilgisiyle birlikte — tam olarak gösterir. Bu sayede yanlış yapılandırılmış göndericileri tespit etmek ve hedefe yönelik adımlar atmak kolaylaşır.

Yaygın SPF Sorunları ve Çözümleri

SPF sorunlarının büyük çoğunluğu birkaç tekrarlayan kategoriye girer:

• Eksik göndericiler. Yeni bir e-posta hizmeti (CRM, pazarlama platformu veya işlemsel e-posta sağlayıcısı) eklediniz; ancak bunu SPF kaydınıza eklemeyi unuttunuz. Bu hizmetten gelen e-postalar, alan adınız için SPF'de başarısız olur.
• Hizalama uyuşmazlığı. ESP'niz MAIL FROM alanında kendi alan adını kullanıyor. SPF, ESP'nin alan adı için geçiyor; ancak ESP'nin alan adı Header-From adresinizle hizalı olmadığından DMARC SPF başarısız oluyor. Çözüm genellikle ESP'de kendi alan adınızla eşleşen özel bir MAIL FROM (return-path) alan adı yapılandırmaktır.
• Yönlendirilen e-posta. E-posta bir üçüncü tarafça yönlendirildiğinde gönderen IP değişir. Yeni gönderen sunucu SPF kaydınızda listelenmediğinden SPF başarısız olur. Bu, SPF'nin temel bir sınırlılığıdır — DKIM gönderen IP yerine kriptografik imzaya dayandığından yönlendirmeyi daha iyi yönetir.
• Fail yerine softfail. SPF kaydınızın sonunda ~all kullanmak, kimliği doğrulanmamış iletilerin kesin hata yerine softfail üretmesine yol açar. Bu durum ilk dağıtım sırasında daha güvenli olsa da katı reddi uygulamaz. Tüm meşru göndericilerin kapsandığından emin olduğunuzda -all'a geçin.
• Birden fazla SPF kaydı. Bir alan adının tam olarak bir SPF TXT kaydı olmalıdır. İki kayıt varsa posta sunucuları permerror döndürür ve SPF başarısız olur. Tüm mekanizmaları tek bir kayıtta birleştirin.
• 10 sorgu sınırını aşmak. Bir sonraki bölüme bakın.

SPF Sınırları: 10 Sorgu Tuzağı

SPF katı bir sınır getirir: tek bir kaydın değerlendirilmesi 10'dan fazla DNS sorgusunu tetikleyemez. Sorguya neden olan mekanizmalar arasında include, a, mx, ptr ve exists bulunur. Bu sınırın aşılması permerror ile sonuçlanır; bu da DMARC amaçları doğrultusunda SPF başarısızlığı sayılır.

Bu durum, pek çok üçüncü taraf hizmet kullanan kuruluşlar için yaygın bir sorundur. Her include bir sorgu olarak sayılır; ancak o alan adı içindeki iç içe include'lar da sayıma dahil olur. Örneğin Google Workspace, _spf.google.com içinde kendi iç içe include'larına sahiptir. Üç veya dört büyük ESP eklendiğinde sınıra hızla yaklaşabilir ya da onu aşabilirsiniz.

Çözüm, SPF kaydınızı düzleştirmektir — include referanslarını çözümlendikleri gerçek IP aralıklarıyla değiştirmek — ya da aplanmış bir kaydı otomatik olarak koruyan yönetilen bir SPF hizmeti kullanmak. DMARCFlow, raporlarda permerror sonuçlarını işaretler ve sorgu sınırının temel neden olduğu durumları tespit eder.

DMARCFlow SPF Karmaşıklığını Nasıl Netliğe Dönüştürür?

SPF'yi tek başına anlamak bir şeydir. Onlarca gönderim hizmeti ve alan adındaki gerçek e-posta trafiği bağlamında harekete geçmek ise bambaşka bir şeydir. DMARCFlow burada önemli bir değer katar.

DMARCFlow, e-posta kimlik doğrulamasını anlaşılır ve eyleme geçirilebilir kılmak üzerine kurulu bir DMARC izleme ve raporlama platformudur. Özellikle SPF söz konusu olduğunda DMARCFlow şunları sunar:

• Kayıt bazında SPF içgörü analizi. Her DMARC raporundaki her kayıt tek tek analiz edilir. DMARCFlow, DMARC SPF'nin geçip geçmediğini değil, neden geçip geçmediğini belirler; bunu yukarıda açıklanan beş içgörü senaryosundan biriyle eşleştirir: hizalı MAIL FROM pass, hizalanmamış MAIL FROM pass, yalnızca HELO pass, pass olmayan MAIL FROM sonucu veya hiç ilgili SPF yok.
• Hizalama modu farkındalığı. DMARCFlow, gerçek DMARC politikanızdaki aspf etiketini okur ve her SPF sonucunu doğru hizalama moduna — esnek veya katı — göre değerlendirir; böylece analiz her zaman gerçek yapılandırmanızı yansıtır.
• Kimlik doğrulama hatası analizi. SPF hataları birden fazla kayıtta göründüğünde DMARCFlow bunları gruplandırır, hata oranlarını hesaplar ve en çok hata veren gönderim kaynaklarını öne çıkarır; böylece hangi IP adreslerini ve göndericileri önce inceleyeceğinizi bilirsiniz.
• Politika doğrulama. DMARCFlow, DMARC politikanızı tutarsızlık sorunları açısından çapraz denetler; örneğin hizalama modunuzun gönderim altyapınız için uygun olup olmadığını ve uygulama düzeyinizin (none / quarantine / reject) gördüğünüz geçiş oranlarıyla örtüşüp örtüşmediğini kontrol eder.
• Olgunluk düzeyi takibi. DMARCFlow, alan adınıza 0 (koruma yok) ile 5 (katı hizalama ve tam reject uygulamasıyla maksimum koruma) arasında bir DMARC olgunluk düzeyi atar. SPF hizalaması doğrudan bir girdi olmaktadır: SPF'niz düzgün hizalanmamışsa daha yüksek olgunluk düzeylerine ulaşmak engellenir ve DMARCFlow bunun tam nedenini gösterir.
• Bileşen dökümü ile güvenlik skoru. Her alan adı 100 üzerinden bir güvenlik skoru alır. Döküm, SPF, DKIM, politika uygulaması, kapsam ve raporlamanın genel skora nasıl katkıda bulunduğunu ya da onu nasıl düşürdüğünü şeffaf bir biçimde ortaya koyar.
• Öneri motoru. Gerçek verilerinize dayanarak DMARCFlow, önceliklendirilmiş ve eyleme geçirilebilir öneriler üretir. SPF'niz belirli bir ESP'deki hizalanmamış bir MAIL FROM nedeniyle başarısız oluyorsa ne yapılandırmanız gerektiğini ve nasıl yapacağınızı söyler.
• GDPR uyumlu, AB'de barındırılmış. Tüm rapor verileri yalnızca Avrupa Birliği içinde işlenir ve depolanır. Kişisel veriler saklanmaz. Bu durum, GDPR'a tabi kuruluşlar ve AB vatandaşlarının verilerini işleyenler için önem taşır.

Sonuç

SPF, e-posta kimlik doğrulamasının temel bir bileşenidir. Alan adınız adına hangi sunucuların e-posta gönderebileceğini ilan eder ve alıcı posta sunucularına bu iddiayı doğrulama imkânı tanır. Ancak SPF tek başına yeterli değildir — yönlendirme durumunda işlevsiz hale gelir, yalnızca zarf düzeyinde çalışır ve DMARC için değeri tamamen doğrulanan alan adının alıcılarınızın gerçekten gördüğü Header-From adresiyle hizalı olup olmadığına bağlıdır.

Beş SPF hizalama senaryosunu anlamak — temiz hizalı bir pass'tan DMARC değeri taşımayan yalnızca HELO sonucuna kadar — yalnızca SPF kaydına sahip olan kuruluşları e-postalarını gerçek anlamda güvence altına alanlardan ayırt eden şeydir. "SPF mevcut" noktasından "SPF hizalamasıyla DMARC uygulaması" noktasına ulaşmak, posta akışlarınızda gerçekte neler olduğuna dair görünürlük gerektirir.

DMARCFlow bu görünürlüğü sağlar. DMARC raporlarınızı ayrıştırır, her SPF sonucunu hizalama çıktısına göre sınıflandırır, hata kalıplarını öne çıkarır ve boşlukları kapatmak için hedefe yönelik öneriler sunar. İster e-posta kimlik doğrulamasına yeni başlıyor olun, ister zaten quarantine politikasıyla çalışıp reject'e geçmeyi planlıyor olun; DMARCFlow size güvenle ilerlemeniz için gereken içgörüyü verir.