SPF Kaydı Nedir?

Sesli Dinle — Makale

SPF (Sender Policy Framework), bir alan adının hangi posta sunucularına kendi adını SMTP kimliği olarak kullanma yetkisi verdiğini bildiren e-posta yetkilendirme yöntemidir. Politika, DNS içinde yayımlanır; alıcı sistem bağlantıyı kuran IP adresini bu politikayla karşılaştırır.

SPF, kullanıcının gördüğü From üstbilgisini doğrudan doğrulamaz. Esas denetim, SMTP MAIL FROM alan adı üzerinde yapılır; ayrıca sunucunun kendisini tanıttığı HELO/EHLO alan adı ayrı değerlendirilebilir. Bu ayrım yüzünden başarılı SPF sonucu (spf=pass), görünen gönderen adresinin veya ileti içeriğinin güvenilir olduğunu tek başına göstermez.

Doğru bir SPF kaydı bütün meşru gönderim kaynaklarını kapsamalı, artık kullanılmayan kaynakları dışarıda bırakmalı ve değerlendirme sınırlarını aşmamalıdır. Politika yalnız e-posta sağlayıcısından alınan bir metni DNS’e yapıştırmakla tamamlanmaz; gönderim envanteri, tek kayıt kuralı, mekanizma sırası, yönlendirme etkisi ve gerçek ileti başlıkları birlikte sınanmalıdır.

SPF Hangi E-posta Kimliklerini Denetler?

MAIL FROM dönüş yolu boş (<>) olduğunda standart, değerlendirme kimliğini HELO alanından türetilen postmaster@helo-alani biçiminde ele alır. Bu nedenle yalnız kullanıcıların kullandığı gönderen alanını değil, posta çıkış sunucularının geçerli HELO/EHLO adlarını da envantere katın.

SPF Kaydı DNS’te Nasıl Yayımlanır?

SPF politikası, TXT kayıt türünde ve yetkilendirdiği alan adının kendisinde yayımlanır. Kayıt v=spf1 sürüm bölümüyle başlar; ardından boşluklarla ayrılmış mekanizmalar ve varsa değiştiriciler gelir. Eski SPF kayıt türü kullanılmaz. Aynı ad altında başka amaçlarla TXT kayıtları bulunabilir, fakat SPF değerlendirmesine yalnız v=spf1 ile başlayan politika katılır.

Aynı alan adı için iki ayrı v=spf1 kaydı yayımlamak yedeklilik sağlamaz; permerror (kalıcı hata) üretir. Farklı e-posta hizmetlerinin yetkileri tek SPF politikasında birleştirilmelidir. Bir TXT kaydı, DNS’te tek bir metin dizesinin boyut sınırı nedeniyle birden fazla dizeye bölünüyorsa bu dizeler tek kayıt içinde, doğru sırada ve araya istenmeyen karakter eklenmeden sunulmalıdır.

Basit bir örnek v=spf1 ip4:192.0.2.0/24 include:_spf.example.net -all biçimindedir. Buradaki 192.0.2.0/24 belge amaçlı örnek ağdır; gerçek kayda yalnız size veya hizmetinize ait doğrulanmış kaynakları yazın. Adres aralığını göstermek için CIDR (Classless Inter-Domain Routing) gösterimindeki prefix kullanılır.

SPF Mekanizmalarının Çalışma Sırası

Mekanizmalar soldan sağa işlenir ve ilk eşleşmede sonuç belirlenir. Bu nedenle geniş bir ağın dar bir istisnadan önce yazılması, sonraki terimi etkisiz bırakabilir. redirect değiştiricisi, hiçbir mekanizma sonuç vermediğinde değerlendirmeyi başka bir politikanın alanına yöneltir; include ile aynı işlev değildir.

Niteleyiciler ve SPF Sonuçları

~all ile -all aynı değildir. ~all yetkisiz görünen kaynak için softfail, -all ise kesin fail bildirir; ancak alıcının iletiye uygulayacağı işlem yine kendi yerel politikasına bağlıdır. Envanter tamamlanmadan sert sonuca geçmek meşru sistemleri etkileyebilir. Değerlendirme +all terimine ulaşırsa kaynak IP adresine bakılmadan pass sonucu verilir; bu nedenle +all kullanılmamalıdır.

SPF’de DNS Sorgusu Gerektiren Terimler Nasıl Sayılır?

Değerlendirme sırasında DNS sorgusu başlatabilen include, a, mx, ptr ve exists mekanizmaları ile redirect değiştiricisinin toplamı 10’u aşamaz. Sınır yalnız üst kayıttaki sözcük sayısı değildir; include ve redirect ile ulaşılan politikalar da aynı küresel hesaba katılır. Aşım permerror üretir. Bu sınır, ağ üzerinde yalnız 10 ayrı DNS sorgusu yapılacağı anlamına gelmez; sayılan unsur, sorgu başlatabilen terimlerdir.

all, ip4 ve ip6 bu on terim sınırına girmez. Ayrıca her mx mekanizmasının değerlendirilmesinde yapılan A veya AAAA adres sorgularının sayısı 10’u aşmamalıdır; bu ayrı sınır aşılırsa permerror oluşur. Yanıt alındığı halde adın bulunmadığı veya yanıt bölümünün boş olduğu sorgular için uygulamaların iki sorguluk sınır koyması önerilir; bunlar yanıt alınamayan zaman aşımı durumlarıyla aynı değildir.

E-posta sağlayıcısı yeni bir include verdiğinde yalnız ana kaydı saymayın; sağlayıcının çağırdığı alt politikaları da çözerek toplamı hesaplayın. SPF flattening (SPF düzleştirme), DNS sorgusu gerektiren mekanizmaların yerine ip4 veya ip6 ile IP adreslerini yazmaktır. Sorgu yükünü azaltabilir, fakat e-posta sağlayıcısının IP adresi değişiklikleri izlenmezse listedeki adresler güncelliğini kaybedebilir. Sağlayıcının desteklediği resmi yöntemi ve değişiklik izleme sürecini tercih edin.

Üçüncü Taraf Gönderim Kaynakları Nasıl Eklenir?

Kurumsal posta, destek masası, müşteri ilişkileri yönetimi, bülten, fatura, izleme ve web uygulaması hizmetleri farklı çıkış kaynakları kullanabilir. Her hizmet için görünen From alanını değil, gerçek MAIL FROM alan adını, çıkış IP adreslerini ve e-posta sağlayıcısının verdiği SPF talimatını kaydedin. Bir hizmet, iletiyi DKIM (DomainKeys Identified Mail) ile imzalayarak DMARC hizalaması sağlıyor olsa bile kullandığı zarf alanını ayrıca bilin.

include, e-posta sağlayıcısının adres değişikliklerini kendi politikasından yönetmesini sağlar; aynı zamanda sağlayıcının o politikada yetkilendirdiği bütün kaynaklara güvenirsiniz. Alan adını yazım hatası ve hesaplar arası karışıklık açısından doğrulayın. Hizmet kapatıldığında eski include veya IP adresi aralığını kayıttan çıkarın.

Gönderim yapmayan alan ve sunucu adlarında v=spf1 -all yayımlamak açık bir “hiçbir kaynak yetkili değil” bildirimi sağlar. Alt alanlar ana alanın SPF politikasını otomatik devralmaz; posta için kullanılan veya kullanılmaması istenen her alt alanı kendi amacıyla değerlendirin.

Yönlendirme ve DMARC Hizalaması

Bir ileti başka sunucuya yönlendirildiğinde son alıcı bağlantıyı özgün çıkış IP adresinden değil, yönlendiren sunucudan görür. Yönlendiren sunucunun IP adresi özgün MAIL FROM alan adının SPF politikasında yer almıyorsa meşru ileti SPF denetiminde fail sonucu alabilir. Yönlendirme hizmetinin zarf gönderenini kendi alanına uyumlu biçimde yeniden yazması veya alıcının güvenilir aracı politikasını uygulaması bu sorunu azaltabilir; davranış hizmete göre sınanmalıdır.

DMARC, SPF tarafında yalnız MAIL FROM kimliğinin başarılı sonucunu kullanır ve bu alan adının görünen From alan adıyla hizalanmasını ister. HELO için alınan başarılı SPF sonucu tek başına başarılı DMARC sonucu sağlamaz. Gevşek hizalama kuruluş alanı ilişkisini, katı hizalama ise tam alan eşleşmesini arar.

Yönlendirme SPF’yi bozsa bile ileti değiştirilmemişse geçerli ve hizalı bir DKIM imzası başarılı DMARC sonucu sağlayabilir. Bu nedenle üretim alanlarında SPF ve DKIM’i birlikte yapılandırın; DMARC raporlarıyla gerçek kaynakları ve hizalama sonuçlarını gözleyin.

SPF Kaydı Nasıl Yayına Alınır?

1. Bütün posta çıkışlarını, üçüncü taraf hizmetleri, uygulamaları, MAIL FROM alanlarını ve HELO/EHLO adlarını envantere alın.
2. Yetkili DNS sunucularında mevcut TXT kayıtlarını okuyun; başka panelde görünen veriyi kanıt saymayın.
3. Mevcut SPF politikasını koruyarak yeni kaynağı tek v=spf1 kaydında birleştirin.
4. Her mekanizmanın gerçekten gereken en dar kaynağı yetkilendirdiğini ve sırasını kontrol edin.
5. İç içe değerlendirmeler dahil 10 terim sınırını, kayıt bulunmayan DNS yanıtları için önerilen sınırı ve adres kaydı sınırlarını kontrol edin.
6. DNS kaydının önbellekte tutulma süresini belirleyen TTL’yi, değişiklikten en az mevcut TTL kadar önce düşürün.
7. Eski ve yeni önbellekler varken bütün meşru kaynakların iki politika görünümünde de yetkili kalmasını sağlayın.
8. Kaydı yayımlayın; her gerçek gönderim kaynağından kontrollü ileti gönderin.
9. İleti üstbilgilerini, alıcı günlüklerini ve DMARC raporlarını inceleyin; eski kaynakları ancak kullanım bittiğinde çıkarın.
10. Geçiş tamamlanınca normal TTL değerine dönün ve envanteri değişiklik sürecine bağlayın.

Üretimde doğrudan ~all veya -all değişikliğine geçmeden önce hatalı olumsuz sonuçların hangi iş akışlarını etkileyeceğini belirleyin. DNS önbellekleri farklı sürelerde eski ve yeni politikayı gösterebilir; geri dönüş planı önceki kaydın doğrulanmış kopyasını ve yayın sırasını içermelidir.

SPF Sonucu Nasıl Doğrulanır?

Web tabanlı bir SPF denetleyicisi kaydın o anda DNS’te görünen yapısını inceleyebilir; gerçek alıcının gördüğü kaynak IP adresini, kullandığı önbelleği ve yerel teslim politikasını bütünüyle taklit edemez. Son kanıt, her yetkili kaynaktan gönderilen iletinin Authentication-Results veya güvenilir alıcı günlüğündeki kimlik ve sonuç eşleşmesidir. Authentication-Results üstbilgisini yalnız alıcı sistemin kendi güven sınırı içinde eklediği biliniyorsa kanıt sayın; iletiyle dışarıdan taşınan aynı adlı alan sahte olabilir.

Sık Hatalar ve SPF’nin Sağlamadığı Güvenceler

• Aynı alan adında birden fazla v=spf1 kaydı yayımlamak.
• Görünen From alanını yetkilendirdiğini sanıp gerçek MAIL FROM alanını incelememek.
• include zincirlerinin 10 terim sınırına etkisini hesaplamamak.
• Web sunucusunu gereksiz a veya mx mekanizmasıyla yetkilendirmek.
• ptr veya değerlendirme kendisine ulaştığında her kaynağı yetkili sayan +all kullanmak.
• Alt alanların ana alan politikasını devraldığını varsaymak.
• Hizmet kapandıktan sonra eski IP adreslerini ve include terimlerini tutmak.
• Yalnız DNS kaydına bakıp gerçek ileti ve DMARC hizalamasını sınamamak.

SPF iletiyi şifrelemez, içeriğin değişmediğini kanıtlamaz, kullanıcı hesabının ele geçirilmediğini göstermez ve teslimatı garanti etmez. Başarılı sonuç yalnız kaynak IP adresinin değerlendirilen SMTP kimliği için yetkili olduğunu bildirir.