Eksik SPF kaydı nasıl düzeltilir?

Eksik SPF kaydı ne anlama gelir?

SPF, bir domain adına hangi e-posta sistemlerinin gönderim yapabileceğini belirten herkese açık bir DNS politikasıdır. Kayıt yoksa alıcı sunucuların o domainden değerlendirebileceği bir SPF politikası da yoktur.

Eksik bir SPF kaydı tek başına her teslim edilebilirlik sorununu ortaya koymaz. E-posta kimlik doğrulama sinyallerinden yalnızca biridir ve DKIM ile DMARC ile birlikte incelenmelidir.

Gönderen envanteriyle başlayın

SPF kaydı oluşturmadan önce, domaini kullanarak e-posta gönderen her servisi listeleyin. Tipik kaynaklar arasında kurumsal e-posta sağlayıcısı, web sitesi formu, faturalama sistemi, destek platformu, pazarlama yazılımı ve uygulama bildirimleri bulunur.

Her gönderenin sorumlusundan belgelenmiş SPF gereksinimini isteyin. Başka bir domainin kaydını kopyalayarak ya da açıklayamadığınız geniş mekanizmalar ekleyerek tahmin yürütmeyin.

Birkaç kayıt değil, tek kayıt yayınlayın

SPF, bir domain için tek bir politika kaydına izin verir. Birden fazla SPF kaydı değerlendirmeyi geçersiz kılar. Bu yüzden onaylı gönderenleri, bu gönderenlerin sağladığı talimatları kullanarak tek bir politikada birleştirin.

Kaydın sonundaki politikayı ancak gönderen listesi tamamlandıktan sonra seçin. Kısıtlayıcı bir politika uygun olabilir, ancak envanter eksikse meşru e-postaları da etkileyebilir.

1. SPF kaydının eksik mi olduğunu, yoksa hâlihazırda birden fazla kayıt mı bulunduğunu kontrol edin.
2. Her meşru gönderen sistemi belgeleyin.
3. Tek bir politika oluşturmak için her sağlayıcının resmî SPF talimatlarını kullanın.
4. Gönderen domainde tek bir TXT kaydı yayınlayın.
5. Herkese açık politikayı yeniden kontrol edin ve daha da sıkılaştırmadan önce teslimat sorunlarını araştırın.

Bu herkese açık kontrol neleri yapmaz?

CloudSpex SPF denetleyicisi, bir SPF kaydının bulunup bulunmadığını, birden fazla kayıt yayınlanıp yayınlanmadığını ve belirlenebildiğinde kaydın sonundaki niteleyiciyi raporlar.

Her include ya da redirect hedefini çözmez ve SPF DNS sorgu sınırının tamamını hesaplamaz. Politikanın tamamı için sağlayıcı belgelerini ve kontrollü bir değişiklik sürecini kullanın.

Doğru bir kayıt nasıl görünür?

SPF kaydı, _spf gibi bir alt domainde değil, domainin kendisinde yayınlanan bir TXT kaydıdır. v=spf1 ile başlar, yetkili gönderenleri tanımlayan mekanizmaları sıralar ve geri kalan her şeye ne yapılacağını söyleyen bir all mekanizmasıyla biter.

Aşağıdaki örnekler, çoğu domainin içinde bulunduğu üç durumu kapsar. Her biri eksiksiz bir kayıttır: bir domain bunlardan tam olarak birini yayınlar, asla ikisini yan yana yayınlamaz.

; One mailbox provider
example.com.  TXT  "v=spf1 include:_spf.google.com ~all"

; Mailbox provider, a transactional service and one fixed server
example.com.  TXT  "v=spf1 include:spf.protection.outlook.com include:sendgrid.net ip4:203.0.113.10 ~all"

; A domain that sends no mail
example.com.  TXT  "v=spf1 -all"

Her bölüm ne anlama gelir?

include mekanizması başka bir domainin SPF kaydını gösterir ve o kaydın yetkilendirdiği her şeyi yetkilendirir. Bir sağlayıcının adres listesini kopyalamadan ona yetki devretmenin yolu budur. ip4 ve ip6 mekanizmaları belirli adresleri ya da aralıkları yetkilendirir. a ve mx mekanizmaları domainin kendi A ve MX kayıtlarının arkasındaki adresleri yetkilendirir. Bu, yalnızca aynı sunucular e-posta gönderiyorsa işe yarar.

Son mekanizma, liste kadar önemlidir. -all ile başka herhangi bir kaynaktan gelen e-posta SPF'ten geçemez. ~all ile softfail sonucu alır. Çoğu alıcı sunucu bunu kabul eder, ancak puanını düşürebilir. ?all ile kayıt hiçbir görüş bildirmez. +all ise tüm interneti yetkilendirir ve bu hiçbir zaman doğru değildir.

Sıra yalnızca şu açıdan önemlidir: değerlendirme ilk eşleşmede durur. all mekanizmasını en sona koyun. Ondan sonra yazılan her şey yok sayılır.

Gönderen envanterini oluşturma

Kayıt, ancak arkasındaki liste kadar iyidir. Olağan hata, e-posta sağlayıcısını listeleyip domain adına gönderim yapan diğer her şeyi unutmaktır.

1. Çalışanların kullandığı e-posta sağlayıcısı: Google Workspace, Microsoft 365 ya da benzeri.
2. Web sitesinden ya da uygulamadan gelen işlemsel e-postalar: parola sıfırlamaları, sipariş onayları, iletişim formları.
3. Pazarlama ve bülten platformları.
4. Müşterilere sizin adresinizden yanıt veren yardım masası ve CRM sistemleri.
5. Belgeleri e-postayla gönderen faturalama, muhasebe ve bordro araçları.
6. Uyarı gönderen cihazlar ve sunucular: yazıcılar, izleme sistemleri, yedekleme işleri.

SPF aslında hangi domaini kontrol eder?

SPF, kişinin gördüğü From adresine bakmaz. Dönüş yolu (return path) ya da geri dönüş adresi olarak da adlandırılan zarf göndereni kontrol eder. Bu adresi gönderen sistem belirler ve çoğunlukla görünmez. Birçok servis burada varsayılan olarak kendi domainini kullanır.

Bunun iki sonucu vardır. Birincisi, kendi dönüş yolunu kullanan bir servisin SPF kaydınızda bulunmasına hiç gerek yoktur, çünkü alıcı sunucular sizin kaydınızı değil, o servisin kaydını kontrol eder. Eklemek bir DNS sorgusunu boşa harcar. İkincisi, bu durumda SPF geçer ama domaininizle hizalı değildir, dolayısıyla DMARC'a katkı sağlamaz. SPF'in DMARC için sayılmasını istiyorsanız serviste özel bir dönüş yolu yapılandırın. Bu genellikle kendi SPF kaydı olan bir alt domaininizdir.

Hangi durumun geçerli olduğunu her sağlayıcının kurulum kılavuzu belirtir. Kılavuz kök domaininize bir include eklemenizi istiyorsa servis, dönüş yolunda sizin domaininizle gönderim yapar. Bir alt domainde CNAME istiyorsa özel bir dönüş yolu kullanıyordur.

Kaydı yayınlama

Kaydı DNS sağlayıcınızda oluşturun. DNS sağlayıcınız, domainin ad sunucularının gösterdiği yerdir ve domainin kaydedildiği yerle aynı olmak zorunda değildir.

1. v=spf1 ile başlayan bir TXT kaydının zaten bulunup bulunmadığını kontrol edin. Varsa o kaydı düzenleyin, ikinci bir kayıt eklemeyin.
2. Host ya da ad alanını domainin kendisi olarak ayarlayın. Çoğu panel bunun için @ kullanır ya da alanı boş bırakır.
3. Türü TXT olarak ayarlayın ve değeri yapıştırın. Panel tırnak işaretlerini sizin yerinize ekliyorsa siz eklemeyin.
4. Kaydedin, sonra kaydı herkese açık DNS'ten geri okuyun. Paneller bazen host alanına domain adını ekler ya da değeri beklenmedik biçimde böler.
5. Kontrol ettiğiniz bir posta kutusuna test iletisi gönderin ve spf=pass sonucunu doğrulamak için Authentication-Results başlığını okuyun.

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

Geçerli görünen bir kaydı bozan sınırlar

İki sınır, doğru görünen kayıtların başarısız olmasına yol açar. Bir SPF değerlendirmesi en fazla on DNS sorgusu tetikleyebilir. Her include, a, mx, exists ve redirect sayılır, include edilen her kaydın içindeki sorgular da sayılır. On aşıldığında alıcı sunucular kalıcı hata (permerror) döndürür ve her ileti için SPF'i başarısız sayar. Dört ya da beş include içeren bir kayıt çoğu zaman sınırı çoktan aşmıştır.

Diğer sınır uzunluktur. Bir TXT kaydının içindeki tek bir dizgi 255 karakteri aşamaz. Daha uzun kayıtlar, tek bir TXT kaydı içinde tırnak içine alınmış birkaç dizgi olarak yayınlanmalıdır. Alıcı sunucular bunları birleştirir. Birçok DNS paneli bunu otomatik yapar, bazıları ise kaydı reddeder ya da keser.

ptr mekanizması hiç kullanılmamalıdır. Yavaştır, güvenilmezdir, SPF belirtimi kullanılmamasını önerir ve bazı alıcı sunucular onu yok sayar.

Alt domainlerin kendi kaydı olmalı

SPF devralınmaz. example.com üzerindeki bir kayıt, mail.example.com ya da news.example.com hakkında hiçbir şey söylemez. Bir dönüş yolunda geçen her alt domainin kendi kaydı olmalıdır. Hiç e-posta göndermeyen her alt domaine de sahte gönderimde kullanılamaması için v=spf1 -all vermek en iyisidir. Bu aynı zamanda bir avantajdır: tek bir servisin kullandığı alt domainin kendi on sorguluk bütçesi vardır ve yalnızca o servisi listeleyebilir.

Kayıt yayınlandıktan sonra

SPF kayıtları zamanla kayar. Bir sağlayıcı include girdisinin arkasındaki kayıtları değiştirir, biri bir araç ekler ve yeni bir include toplamı on sorgunun üzerine çıkarır ya da bir geçiş, eski bir sağlayıcıyı yıllarca yetkili bırakır. Bir gönderim servisi eklendiğinde ya da kaldırıldığında kaydı yeniden kontrol edin ve DMARC toplu raporları hiçbir meşru kaynağın başarısız olmadığını gösterdiğinde ~all değerinden -all değerine geçin. CloudSpex SPF Kayıt Denetleyici yayınlanan kaydı okur, include zincirini izler ve gerçek sorgu sayısını raporlar. SPF Kayıt Üretici ise seçtiğiniz gönderenlerden bir kayıt oluşturur.

Kaydı geçersiz kılan hatalar

Birkaç hata, iyi niyetle hazırlanmış bir kaydı her ileti için başarısız olan bir kayda dönüştürür. Bunları bir DNS panelinde yapmak da, sonradan kontrol etmek de kolaydır.

1. İkisi de v=spf1 ile başlayan iki TXT kaydı. Genellikle biri e-posta sağlayıcısının kurulum sihirbazından gelir, diğeri sonradan elle eklenmiştir.
2. Sürüm etiketinde yazım hatası: örneğin v=spf ya da fazladan noktalı virgülle v=spf1; yazılması. Bu durumda alıcı sunucular kaydı hiç SPF olarak tanımaz.
3. Boşluk yerine virgülle ayrılmış mekanizmalar.
4. Kendi SPF kaydı olmayan bir domaini gösteren include. Bu, kalıcı hata üretir.
5. Bir belgeden yapıştırılan ve değerin parçası hâline gelen kıvrık (akıllı) tırnak işaretleri.