SPF Kaydı Nedir? Sözdizimi, Sınırlar ve Hata Modları

SPF kaydı nedir? Alan adınızın DNS bölgesinde yayımlanan tek bir TXT kaydıdır ve hangi sunucuların o alan adı üzerinden posta gönderebileceğini listeler. Alıcı sunucu, mesajı gönderen IP adresini bu listeyle karşılaştırır ve sonucu pass, fail, softfail ya da neutral olarak döndürür. SPF, mesajın içeriğini değil gönderim yolunu doğrular. Kullanıcının gördüğü From adresi hakkında ise hiçbir şey söylemez.

Bu ayrım, destek kayıtlarında gördüğümüz SPF sorunlarının çoğunu açıklıyor.

SPF kaydı, DNS'te yayımlanan bir gönderici izin listesidir

SPF, Sender Policy Framework'ün kısaltmasıdır ve RFC 7208 ile tanımlanır. Kayıt, alan adının kökünde bir TXT girdisidir ve v=spf1 ile başlar. En küçük bir örnek şöyle görünür:

example.com.  IN  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.provider.example ~all"

Kaydı soldan sağa okuyun. Alıcı terimleri sırayla kontrol eder ve ilk eşleşmede durur. Sondaki all terimi, önceki terimlerle eşleşmeyen her şeyi yakalar.

Kontrol edilen alan adı From başlığı değildir. SMTP MAIL FROM komutundaki alan adıdır; zarf göndereni ya da Return-Path olarak da bilinir. Bu değer boşsa, örneğin bounce mesajlarında, alıcı HELO adına geri döner.

Mekanizmalar: ip4, ip6, a, mx, include ve exists

Her terim bir mekanizmadır ve isteğe bağlı bir niteleyiciyle başlayabilir. Neredeyse her gerçek kaydı altı mekanizma karşılar:

• ip4: ve ip6: Sabit bir adresi ya da CIDR aralığını eşleştirir. Sorgu maliyeti sıfırdır.

• a Alan adının A ve AAAA kayıtlarını eşleştirir. Bir sorgu harcar.

• mx Alan adının MX kayıtlarındaki sunucuları eşleştirir. Bir sorgu ve her sunucu için bir ek sorgu harcar.

• include: Başka bir alan adının SPF kaydının eşleştirdiği her şeyi eşleştirir. Bir sorgu harcar, içindeki her şey de sayılır.

• exists: Oluşturulmuş bir ad için herhangi bir A kaydını eşleştirir. Bir sorgu harcar.

• ptr Bağlanan IP'nin ters DNS kaydını eşleştirir. Sorgu harcar ve RFC 7208 bu kullanımı önerilmez sayar.

Niteleyiciler, bir terim eşleştiğinde sonucu belirler. + pass anlamına gelir ve varsayılandır, - fail, ~ softfail, ? neutral. Yani -all "listelenmeyen her şeyi reddet" demektir, ~all ise "kabul et ama işaretle".

Adresin sizin kontrolünüzde olduğu durumlarda ip4: ve ip6: tercih edin. Sıfır sorgu harcarlar ve başka birinin DNS'i değiştiğinde bozulmazlar.

10 DNS sorgu sınırı, gerçek kayıtları bozan kısıttır

RFC 7208, tek bir SPF değerlendirmesinde DNS sorgusu tetikleyen en fazla 10 terim tanımlar: include, a, mx, ptr, exists ve redirect değiştiricisi. İç içe include'lar da sayılır. Sınır aşıldığında sonuç permerror olur ve kontrol geri dönüş yapılmadan kalıcı olarak başarısız sayılır.

İkinci bir sınır daha var ve daha az dikkat çekiyor. Boş yanıt ya da NXDOMAIN dönen terimler boş sorgu sayılır ve spec bunları en fazla ikiyle sınırlar. Geçen yıl bıraktığınız bir sağlayıcıya işaret eden eski bir include: kaydı, ödediğiniz ama işe yaramayan bir boş sorgudur.

Ekiplerin bu tavana nasıl dayandığını düşünün. Google Workspace bir include ekler. Bir transactional sağlayıcı bir include ekler. Bir pazarlama platformu bir include ekler ve içine üç tane daha yerleştirir. Bir destek masası, bir CRM ve bir faturalama aracı dört include daha ekler. Hiçbir sıradışı şey yapmadan 11'e ulaşmış olursunuz.

Hata sessizdir. Posta yine gönderilir, bazı alıcılar yine teslim eder, ama SPF artık sizin için hiçbir şeyi doğrulamaz. DMARC hizalamanızı SPF üzerinden kuruyorsanız, kaydı sadeleştirene ya da gönderenleri kaldırana kadar bu yol kapalıdır.

Üç çözüm var, tercih sırasına göre:

1. Artık kullanmadığınız göndericileri kaldırın. Include'ları son 90 günün DMARC toplu raporlarına göre denetleyin.

2. Toplu trafiği mail.example.com gibi bir alt alana taşıyın. Bu alt alanın kendi SPF kaydı ve kendi 10 sorgulık bütçesi olsun.

3. Include'ları sabit ip4: aralıklarına açın, ama yalnızca otomasyonla. Sağlayıcılar IP'lerini değiştirir ve elle açılmış bir kayıt, hiçbir uyarı vermeden eskir.

Alan adı başına tek bir SPF kaydı yayımlayın

Bir alan adı iki SPF kaydı yayımlamamalıdır. Bir alıcı iki v=spf1 TXT girdisi bulursa sonuç permerror olur, tıpkı sorgu sınırında olduğu gibi. Bu genellikle biri yeni bir araç için kayıt eklerken, diğerinin zaten bir kayıt koyduğunu bilmediğinde olur.

Düzeltme mekaniktir. Terimleri tek bir kayda birleştirin: başta bir v=spf1, sonda bir all. Satıcının dokümantasyonunun eklemenizi istediği her şey mevcut kaydın içine yeni bir include: olarak girsin, asla yeni bir TXT girdisi olarak değil.

İki küçük tuzak daha var. 255 karakterden uzun bir TXT dizgisi aynı kaydın içinde birden fazla tırnaklı dizgiye bölünmelidir; çoğu DNS sağlayıcısı bunu sizin yerinize yapar. Ayrıca mümkünse tüm yanıtı yaklaşık 450 bayt altında tutun, çünkü daha büyük yanıtlar UDP'den TCP'ye geçebilir ve bazı çözümleyiciler bunu kötü yönetir.

Softfail mi hardfail mi: gördüğünüz şeye göre seçin

all terimi bir politika beyanıdır. Sık verilen "-all kullanın" tavsiyesi ise önemli kısmı atlıyor. Sert bir fail, bütün meşru göndericileri bildiğinizde güvenlidir.

Hata ayıklamalarda izlediğimiz pratik kural şu:

• Göndericileri hâlâ envanterlerken ya da yönlendirilen postayı kontrol edemediğinizde ~all kullanın.

• DMARC raporları birkaç hafta boyunca her meşru kaynağın geçtiğini gösterdikten sonra -all kullanın.

• Asla +all kullanmayın, çünkü bu tüm internete yetki verir. Üretim alan adında ?all de kullanmayın.

Pratikte fark, insanların beklediğinden daha küçük. Büyük alıcıların çoğu SPF'yi birçok sinyalden biri olarak değerlendirir ve DMARC politikası varken karar veren DMARC sonucudur. Yine de eksik bir kayıtta -all, faturaların kaybolmasının yollarından biridir.

SPF yönlendirmede bozulur, bu tasarımın bir parçasıdır

SPF, alıcı sunucuya bağlanan IP'yi doğrular. Bir ileti yönlendirildiğinde, bir posta listesi tarafından yeniden dağıtıldığında ya da bir takma ad servisi tarafından aktarıldığında, bağlanan IP yönlendiriciye aittir, size değil. SPF kontrolü, siz hiçbir şey yanlış yapmamışken başarısız olur.

Bunu SPF'nin içinde çözemezsiniz. DKIM'in SPF'nin yanında var olmasının nedeni de budur: imza bu sıçramadan sağ çıkar, IP listesi çıkamaz. Yalnızca SPF'ye bağlı bir alan adı, yönlendirilen her iletide kimlik doğrulama hatası görür.

Bu yüzden SPF tek başına yönlendirilmiş postada DMARC'ı da karşılamaz. Bu iletileri taşıması için DKIM'i planlayın.

SPF hizalaması: geçmek, From alan adınızla eşleşmek demek değildir

Bir ileti SPF'yi geçebilir ve yine de DMARC'ta başarısız olabilir. DMARC, SPF'yi geçen alan adının, yani Return-Path alan adının, görünen From alan adıyla eşleşmesini ister. Birçok paylaşımlı sağlayıcı varsayılan olarak kendi bounce alan adını kullanır. Bu durumda SPF provider-mail.net için geçer ve example.com hakkında hiçbir şey söylemez.

Bunu ham başlıklarda kontrol edin. Authentication-Results satırında smtp.mailfrom= değerine bakın. Bu sizin alan adınız ya da onun bir alt alanı değilse, SPF geçiyor ama sizin için bir işe yaramıyor.

Çözüm, kendi alt alanınızda özel bir Return-Path kullanmaktır. Ciddi göndericilerin çoğu bunu destekler. Postmark, Resend, Mailgun ve SendGrid bu kurulumu belgeler, ama her zaman varsayılan olarak açık gelmez.

Gelen kutusu sağlayıcıları artık her göndericiden kimlik doğrulama bekliyor

Şubat 2024'ten beri Google, tüm göndericilerin SPF ya da DKIM ile kimlik doğrulaması yapmasını istiyor. Gmail'e günde 5.000'den fazla ileti gönderen göndericilerin ise SPF, DKIM ve DMARC'a sahip olması gerekiyor. Ayrıntılar Google'ın e-posta gönderici yönergelerinde yer alıyor. Yahoo da aynı dönemde benzer eşleştirme kuralları getirdi.

Bu değişiklik SPF'yi "olsa iyi olur" olmaktan çıkarıp bir teslimat ön koşulu haline getirdi. Eksik ya da bozuk bir kayıt artık yalnızca düşük bir itibar puanı olarak değil, reddedilme ve spam klasörüne düşme olarak görünüyor.

Birkaç yıllık hata ayıklama deneyimimize göre bu kurallar çoğunlukla hiç kimlik doğrulaması olmayan alan adlarını ve yüksek şikayet oranına sahip göndericileri yakalıyor. Doğru bir SPF kaydı tek başına sizi gelen kutusuna sokmaz, ama eksik bir kayıt sizi dışarıda tutar.

Bir SPF kaydını dört adımda kontrol edip düzeltin

Bu adımları sırayla uygulayın ve her DNS değişikliğinden sonra yeniden kontrol edin.

1. Mevcut kaydı alın. dig +short TXT example.com komutunu çalıştırın ve v=spf1 ile başlayan girdiyi bulun. İki tane varsa birleştirin.

2. Sorguları sayın. include, a, mx, exists, redirect ve include'ların içindeki her şeyi toplayın. Toplam 8 ya da daha fazlaysa temizliği şimdi planlayın, 11. sorguda değil.

3. Gerçek göndericileri listeleyin. DMARC toplu raporlarını ya da test gönderimlerinin Authentication-Results başlıklarını kullanın. Yalnızca görünen kaynakları ekleyin.

4. Bir test gönderin ve başlığı okuyun. Sonuç spf=pass olmalı ve smtp.mailfrom sizin alan adınızda olmalı.

DNS değişiklikleri yayılmak için zaman alır ve mevcut kaydınızın TTL değeri, eski yanıtların ne kadar yaşayacağını belirler. Planlı bir değişiklikten bir gün önce TTL değerini 300 saniyeye indirin.

Üç göndericisi olan bir SaaS şirketi için örnek bir kayıt

Google Workspace, bir transactional sağlayıcı ve bir destek masasıyla gönderim yapan bir ürünü düşünelim. Temiz bir kayıt şöyle görünebilir:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:spf.transactional.example include:spf.helpdesk.example -all"

Bu üç include, her birinin kendi iç sorgularını gizlediği anlamına gelir. Yayımlamadan önce sayın, çünkü görünen uzunluk gerçek bütçe hakkında hiçbir şey söylemez. Üç include'lu bir kayıt bile 7 ya da 8 sorguya ulaşabilir.

Şimdi amaca göre ayırın. İnsan postasını kök alan adında tutun. Ürün bildirimlerini yalnızca transactional sağlayıcıyı listeleyen bir kayıtla notify.example.com üzerine taşıyın. Kök kayıt kısa kalır, alt alan kendi 10 sorgulık bütçesini alır ve bir akıştaki itibar sorunu diğerini sürüklemez.

Bu ayrım DMARC raporlarını da okunur hale getirir. Her akışın kendi Return-Path alan adı olduğu için bir hata, bir yığın gönderici yerine tek bir göndericiye işaret eder.

SPF neyi yapmaz

SPF, From adresinizin taklit edilmesini durdurmaz, çünkü o başlığa hiç bakmaz. Hiçbir şeyi şifrelemez. Bir iletinin neden spam klasörüne düştüğünü söylemez. Sürekli bakım olmadan da 10 sorgulık bütçenin ötesine ölçeklenmez.

Onu birlikte yayımladığınız üç kayıttan biri olarak düşünün: gönderim yolu için SPF, ileti bütünlüğü için DKIM, bu ikisini From alan adınıza bağlayan politika için DMARC. Yalnızca SPF'niz varsa, bir sonraki somut adım p=none politikasıyla bir DMARC kaydı yayımlamak ve iki hafta boyunca raporlarını okumaktır.