SPF Kaydı Nasıl Oluşturulur?

Sesli Dinle — Makale

SPF (Sender Policy Framework) kaydı oluşturmanın amacı, bir alan adını e-posta gönderim kimliği olarak kullanmaya yetkili bütün kaynakları tek politikada tanımlamaktır. Politika, DNS içinde TXT kaydı olarak yayımlanır; alıcı sistem bağlantıyı kuran IP adresini bu politikayla karşılaştırır.

Başlangıç noktası, kullanıcının gördüğü From adresi değil, SMTP MAIL FROM adresinin alan adıdır. Sunucunun HELO/EHLO adı da ayrı değerlendirilebilir. Bu yüzden kaydı ekleyeceğiniz DNS adı ve yetkilendireceğiniz çıkış kaynağı, gerçek bir iletinin teknik kimliklerinden belirlenmelidir.

İyi bir SPF kaydı kısa görünmek zorunda değildir; eksiksiz, dar kapsamlı, tek kayıt kuralına uygun ve değerlendirme sınırları içinde olmalıdır. Yeni bir hizmet eklerken ikinci SPF kaydı açmayın; mevcut politikayı güncelleyin. E-posta sağlayıcısının politikasına başvuran include mekanizmasındaki alan adını tahmin etmek yerine, hizmetin resmi talimatından alın.

1. SPF Kaydı İçin Alan Adını Belirleme

SPF sorgusu, alıcının değerlendirdiği MAIL FROM adresinin alan adında yapılır. İleti teslim edildiğinde bu kimlik çoğu zaman Return-Path (geri dönüş yolu) üstbilgisinde görülebilir. Ana alan adına ait kullanıcı adresi görünürken hizmet bounce.example.com gibi bir alt alanı MAIL FROM adresinin alan adı olarak kullanabilir; bu durumda SPF politikası alt alanda aranır.

Alt alanlar ana alanın SPF politikasını otomatik devralmaz. Kök alan için kayıt adı panelde @, boş alan veya tam alan adı olarak gösterilebilir. Panelin oluşturacağı tam DNS adını kaydetmeden önce önizleyin.

2. Posta Gönderim Kaynaklarını Listeleme

• Kurumsal e-posta ve şirketin yönettiği posta çıkış sunucuları
• Web uygulaması, iletişim formu, üyelik ve parola sıfırlama iletileri
• Fatura, sipariş, destek ve işlem bildirimi sistemleri
• Bülten, toplu gönderim ve CRM hizmetleri
• İzleme sistemi, ağ cihazı, yazıcı ve yerel uygulamaların kullandığı SMTP aktarıcıları
• Satın alınan alan adına bağlı üçüncü taraf güvenlik veya bildirim hizmetleri

Her kaynak için hizmet sahibini, MAIL FROM alan adını, HELO/EHLO adını, gerçek çıkış IP adreslerini, e-posta sağlayıcısının resmi SPF talimatını ve hizmetin kapatılma sorumlusunu kaydedin. Uygulama iletileri bir bulut SMTP aktarıcısına teslim ediyorsa SPF’ye uygulama sunucusunun genel adresi değil, internette alıcıya bağlantı kuran hizmet kaynağı yazılır.

Kendi posta sunucunuz doğrudan gönderiyorsa çıkış adresini sunucu günlüğünden ve ağ geçidinden doğrulayın. Çalışan bir bilgisayarda görülen genel IP adresinin posta hizmetinin çıkış IP adresi olduğunu varsaymayın. IPv6 yolu açıksa yalnız IPv4 envanteriyle yetinmeyin.

3. Kaynağa Uygun SPF Mekanizmasını Seçme

Adres aralığı yazarken CIDR (Classless Inter-Domain Routing) gösterimindeki prefix uzunluğunu kullanın. Tek IPv4 adresinde prefix uzunluğu yazılmazsa /32, tek IPv6 adresinde /128 kabul edilir. Geniş bir ağı kolaylık için yetkilendirmek, o ağdaki gereksiz kaynakların alanınızı kullanabilmesine yol açar.

4. Kaynakları Tek SPF Politikasında Birleştirme

Kayıt v=spf1 sürüm bölümüyle başlar. Mekanizmalar soldan sağa değerlendirilir ve ilk eşleşmede sonuç belirlenir. Aynı DNS adında iki ayrı v=spf1 kaydı yayımlamak yedeklilik sağlamaz; permerror (kalıcı hata) üretir. Başka amaçlı TXT kayıtları aynı adda bulunabilir.

Belge amaçlı IPv4 ve IPv6 adresleri ile örnek e-posta sağlayıcısı kullanan bir politika şöyle olabilir:

v=spf1 ip4:192.0.2.25 ip6:2001:db8::25 include:_spf.example.net -all

Bu adresleri ve alanı gerçek kaydınıza kopyalamayın; kendi doğrulanmış kaynaklarınızla değiştirin. include, başvurulan SPF politikasının ilgili kaynak için başarılı sonuç vermesi halinde eşleşir; metni doğrudan kaydınıza kopyalamaz. redirect ise hiçbir mekanizma eşleşmediğinde değerlendirmeyi başka alanın politikasına devreder. Kayıtta all varsa redirect, kaydın neresinde olursa olsun devreye girmez.

Niteleyicilerde + pass (başarılı), - fail (başarısız), ~ softfail (zayıf olumsuz), ? neutral (tarafsız) sonucu bildirir. İşaret yazılmazsa + varsayılır. ~all ile -all aynı değildir; bütün meşru kaynaklar kanıtlanmadan sert sonuca geçmeyin. Değerlendirme +all terimine ulaşırsa kaynak IP adresine bakılmadan pass sonucu verilir; bu nedenle +all kullanmayın.

5. SPF Terim Sayısını ve TXT Kaydının Yapısını Denetleme

Değerlendirme sırasında DNS sorgusu başlatabilen include, a, mx, ptr ve exists mekanizmaları ile redirect değiştiricisinin küresel toplamı 10’u aşamaz. Yalnız ana kayıttaki sözcükleri saymak yeterli değildir; iç içe include ve redirect politikaları aynı hesaba katılır. Aşım permerror üretir.

ip4, ip6 ve all bu terim sınırına girmez. Yanıt alındığı halde adın bulunmadığı veya yanıt bölümünün boş olduğu sorguların ikiyle sınırlanması önerilir; yanıt alınamayan zaman aşımı durumları bu tanıma girmez. Ayrıca mx adres çözümünde ayrı kayıt sınırları vardır. E-posta sağlayıcısı yeni bir include verdiğinde bütün çağrı zincirini yeniden hesaplayın.

TXT kaydı, DNS’te tek metin dizesi için geçerli boyut sınırı nedeniyle aynı kayıt içinde birden fazla parçaya ayrılabilir. Parçalar birleştirildiğinde mekanizmalar arasındaki boşluklar korunmalı, ortada yeni karakter oluşmamalıdır. Panelin otomatik dize bölmesi ikinci SPF kaydı değildir; uzunluğu çözmek için iki ayrı v=spf1 politikası açmayın.

6. SPF TXT Kaydını Yetkili DNS Paneline Ekleme

1. Alan adının gerçekten kullandığı yetkili ad sunucularını belirleyin.
2. Bu ad sunucularını yöneten panelde hedef alanın mevcut TXT kayıtlarını okuyun.
3. Mevcut v=spf1 politikası varsa yeni kaynağı onunla birleştirin; yeni kayıt açmayın.
4. Kayıt türü olarak TXT, ad olarak doğruladığınız MAIL FROM veya HELO/EHLO alan adını seçin.
5. Hazırladığınız tek dizeyi değer alanına girin.
6. Panelin tırnak, son nokta ve alan adı tamamlama davranışını önizleyin.
7. Kaydı yayımlayın ve doğrudan yetkili DNS yanıtından okuyun.

DNS panelindeki satır yalnız panel verisini gösterir. Kayıt, alan adının yetkili sunucularını yönetmeyen bir DNS sağlayıcısının paneline eklenirse internete yansımaz. Yetkili yanıt içinde hedef adda tam olarak bir SPF politikası, doğru mekanizma sırası ve eksiksiz dize bulunmalıdır.

7. Yeni Kaynağı DNS Önbellekleri Yenilendikten Sonra Devreye Alma

DNS kaydının önbellekte tutulma süresini belirleyen TTL’yi, değişiklikten en az mevcut TTL kadar önce düşürün. Yeni TTL, daha önce önbelleğe alınmış cevabı geriye dönük kısaltmaz. Eski yanıtlar önbellekteyken yeni kaynaktan gönderim başlatmayın. Düşük TTL en az önceki TTL kadar süredir yayındaysa yeni kaynağı mevcut politikaya ekleyin ve düşük TTL süresi dolana kadar bekleyin; eski kaynağın kaldırılmasını da kuyruklar boşaldıktan sonra ayrı bir değişiklik olarak yapın.

1. Yeni kaynağı mevcut politikaya ekleyin, fakat eski kaynağı hemen çıkarmayın.
2. DNS önbellekleri yenilendikten sonra yeni hizmetten kontrollü gönderimi başlatın.
3. Gerçek iletilerde SPF ve DMARC sonucunu izleyin.
4. Eski sistemin kuyrukları boşalıp gönderimi tamamen bittikten sonra eski yetkiyi kaldırın.
5. Değişiklik yeniden doğrulandıktan sonra normal TTL değerine dönün.

Geri dönüş planı, önceki kaydın doğrulanmış kopyasını, hangi kaynağın hangi sırayla yeniden açılacağını ve yetkili DNS’te beklenen sonucu içermelidir. Yalnız panel geçmişine güvenmeyin.

8. SPF Kaydının Söz Dizimini ve Kaynak Kapsamını Doğrulama

Web tabanlı bir SPF denetleyicisi yapıyı ve o anda görülen DNS verisini inceleyebilir; gerçek alıcının gördüğü kaynak IP adresini, kullandığı önbelleği ve yerel politikasını bütünüyle taklit edemez. Yapısal kontrolü gönderim kanıtıyla tamamlayın.

9. Her Gönderim Kaynağını Gerçek İletiyle Sınama

Kurumsal posta, web uygulaması, bülten, fatura, destek ve SMTP aktarıcısı gibi her çıkıştan ayrı kontrollü ileti gönderin. Alıcı tarafında Authentication-Results (kimlik doğrulama sonuçları) veya Received-SPF (SPF sonucu) üstbilgisini ve güvenilir posta günlüğünü inceleyin. Kaynak IP adresi, değerlendirilen smtp.mailfrom ya da smtp.helo kimliği, eşleşen mekanizma ve SPF sonucu envanterle uyumlu olmalıdır.

Authentication-Results ve Received-SPF üstbilgilerini yalnız alıcı sistemin kendi güven sınırı içinde eklediği biliniyorsa kanıt sayın; dışarıdan taşınan aynı adlı üstbilgiler sahte olabilir. Kendi sunucunuz iki IP ailesinden çıkabiliyorsa IPv4 ve IPv6 yollarını ayrı sınayın.

SPF’nin başarılı olması görünen From alanının doğrulandığını veya iletinin teslim edileceğini garanti etmez. DKIM (DomainKeys Identified Mail) imzasını ve DMARC hizalamasını ayrıca doğrulayın. DMARC, SPF tarafında yalnız başarılı sonuçla doğrulanan MAIL FROM alan adını görünen From alan adıyla karşılaştırır; HELO için alınan başarılı SPF sonucu tek başına başarılı DMARC sonucu sağlamaz.

10. SPF Kaydını Güncel Tutma

• Yeni hizmeti üretime almadan önce SPF yetkisini ve DNS geçişini tamamlayın.
• Kapatılan hizmetin ip4, ip6 ve include yetkilerini kuyruklar boşaldıktan sonra SPF politikasından kaldırın; kullanılmayan alt alanların SPF politikalarını ayrıca değerlendirin.
• E-posta sağlayıcısının resmi SPF alanı değişirse DNS sorgusu gerektiren terimlerin sayısını ve gerçek iletileri yeniden sınayın.
• Gönderim envanterine hizmet sahibini, değişiklik tarihini ve sorumlu ekibi ekleyin.
• +all, gereksiz a/mx, ptr ve yinelenen include terimlerini düzenli aralıklarla tarayın.
• Alt alanların, HELO/EHLO adlarının ve gönderim yapmayan adların politikalarını ayrı değerlendirin.