SPF kaydınız muhtemelen çalışıyor ve en kötü durum da bu. Bir alıcı permerror döndürmediği sürece kimse ona bakmaz; döndürdüğünde ise işlemsel e-postalar sessizce kuyrukta bekler veya spam'e gider. Buradaysanız, her terimin tam değerini bilmek istiyorsunuz demektir, genel bir açıklama değil. O halde doğrudan sözdizimine geçiyoruz.
Bir SPF kaydının yapısı ve terimlerin zorunlu sırası
SPF kaydı, alan adı üzerinde v=spf1 ile başlayan bir TXT record'dur. Ardından boşlukla ayrılmış bir terim listesi gelir ve sıraları anlamlıdır: mekanizmalar soldan sağa değerlendirilir ve ilk eşleşme kazanır. Eşleşme bulunamazsa, varsayılan niteleyici yani -all uygulanır. Bu "varsayılan olma" durumunu çoğu kişi bilmez ve all'ın yokluğunun nötr anlamına geldiğini düşünür.
example.com. 3600 IN TXT "v=spf1 mx a:mail.example.com include:_spf.google.com ip4:185.10.20.30 -all"Üç terim kategorimiz var. Hangi ana makinelerin yetkili olduğunu belirleyen mekanizmalar, her mekanizmanın sonucunu belirleyen niteleyiciler ve = ile gelen ve mekanizmaların aksine sıraları önemli olmayan modifier'lar.
Mekanizmalar: her biri tam olarak neyle eşleşir
| Mekanizma | Eşleştiği şey | Sorgu maliyeti |
|---|---|---|
all | Tüm göndericiler; her zaman en sonda gelir | Sıfır |
a | Alan adının (veya belirtilen alan adının) A veya AAAA kaydı | 1 |
mx | Alan adının tüm MX'lerinin IP adresleri | 1 + MX sayısı |
ip4 / ip6 | Belirtilen adres veya CIDR | Sıfır |
include | Başka bir alan adının SPF kaydı ve sonucu | 1 + o alan adının sorguları |
exists | Bir alan adının varlığı (herhangi bir kayıt türü) | 1 |
ptr | Göndericinin adresinin reverse DNS'i | Her IP için 1 |
Pratikte sık gördüğüm iki nokta. Birincisi, ptr kullanımdan kaldırılmıştır ve RFC 7208 açıkça kullanılmamasını önerir; bir yerde görüyorsanız, genellikle eski bir panelden kalmıştır. İkincisi, include sonucunu hedef alan adından ödünç alır: include ettiğiniz alan adı -all ile bitiyorsa ve adresiniz o listede yoksa, sonuç neutral değil fail'dir. Bu tek fark, "neden sunucumuzdan işlemsel e-posta reddediliyor" biletlerinin çoğunun kaynağıdır.
Niteleyiciler: dört değer ve bir varsayılan
Her mekanizma dört niteleyiciden biriyle gelebilir: + pass anlamına gelir, - fail, ~ softfail ve ? neutral. Niteleyicinin yokluğu + ile eşdeğerdir. Yani mx ve +mx aynıdır.
-all: katı. Listede olmayan her gönderici reddedilir. Yalnızca belirli bir yoldan e-posta gönderen bir alan adı için en doğru seçimdir.~all: yumuşak. Alıcı kabul edip spam'e koyabilir. Geçiş dönemi için ve tüm göndericileri kapsadığınızdan emin olmadığınızda mantıklıdır.?all: etkisiz. SPF'yi pratikte etkisiz kılar ve yalnızca e-postası olmayan alan adları için anlam taşır.
Benim seçimim: -all. Gönderici listenizi biliyorsanız, softfail yalnızca alıcının kötü bir karar vermesine izin verir. ~all'ı yalnızca geçişin ilk iki haftasında tutun ve sonra katılaştırın.
On DNS sorgu sınırı ve permerror hatası
Sağlam kayıtların çöktüğü yer burasıdır. RFC 7208, her SPF değerlendirmesi için 10 DNS sorgusu sınırı belirlemiştir. include, a, mx, ptr ve exists mekanizmalarının her biri bir sorgu tüketir ve include, içindeki alan adının sorgularını da sizin hesabınıza yazar. ip4, ip6 ve all sıfırdır.
Sınırı aşmanın sonucu permerror hatasıdır ve alıcılar bunu fail gibi ya da daha kötü işler. Belirtisi de tam olarak şudur: kayıt sözdizimsel olarak doğrudur, dig de temiz yanıt verir, ama Gmail e-postayı reddeder. spfquery veya çevrimiçi servisler gibi araçlar nihai sayıyı gösterir:
dig +short TXT example.com | grep spf1
spfquery -i 185.10.20.30 -s mail.example.com -h example.comBir include:_spf.google.com tek bir sorgu değildir; kendisi birkaç tane tüketir. Her biri include'a sahip üç SaaS servisi sizi rahatça 12'ye ulaştırır. Doğru çözüm, tekrarlayan include'ları doğrudan ip4 ile değiştirmektir, çünkü sıfır sorgu tüketir. Maliyeti, o servis IP'lerini değiştirirse kaydı elle güncellemeniz gerektiğidir. Bu maliyeti kabul ediyorum; permerror daha kötüdür.
Burada hata yapıyorlar
En yaygın gerçek hata, all'ı kaydın ortasına koymaktır. Biri kaydı düzenler ve -all include'dan önce gider. O andan itibaren her değerlendirme all'da durur ve kalan terimler asla okunmaz. Belirtisi kafa karıştırıcıdır: kayıt eksiksiz görünür, include da yerindedir, ama yeni servisin e-postaları reddedilir ve eski e-postalar gider. Çünkü all include'dan önce eşleşmiştir.
İkinci hata, her ikisi de v=spf1 ile başlayan iki ayrı TXT kaydıdır. RFC, bu durumda sonucun birini seçmek değil permerror olduğunu söyler. DNS paneli mevcut kaydı düzenlemeye izin vermiyorsa ve ikinci bir kayıt oluşturuyorsanız, tam olarak bu olur. İkisini tek bir TXT'de birleştirmelisiniz.
modifier'lar ve redirect
İki standart modifier'ınız var. redirect= tüm değerlendirmeyi başka bir alan adına devreder ve yalnızca hiçbir mekanizma eşleşmediğinde uygulanır. exp= hata metnini döndüren bir açıklama alan adı belirtir; neredeyse hiçbir alıcı bunu göstermez ve pratik değeri sıfıra yakındır.
"v=spf1 include:_spf.example.net redirect=_spf.example.org -all"Daha az söylenen bir nokta: redirect kendisi bir sorgu tüketir ve hedef alan adı da sınırı aşarsa, permerror size atfedilir. Ana alan adları için açık include kullanın ve redirect'i park edilmiş alan adları için saklayın.
Paylaşımlı hosting'deyseniz ve tam DNS kontrolünüz yoksa, kayda dokunmadan önce gönderim yolunun nereden belirlendiğinden emin olun. İşlemsel e-posta; neden hosting'den göndermiyoruz ve doğru alternatif nedir? rehberi bu ayrımı netleştirir ve birçok yanlış kaydı önler.
Kaydı yayınlamadan önce test etme yöntemi
- Kaydı ana alan adında değil, bir test alan adında oluşturun.
dig +short TXT test.example.comile panelde yazdığınızı değil, gerçekten yayınlanan değeri görün.spfqueryveya çevrimiçi bir araçla birkaç örnek IP için sorgu sayısını ve sonucu kontrol edin.- Gmail ve Outlook'a gerçek bir e-posta gönderin ve
Received-SPFbaşlığını okuyun. - Sonuç
softfailveyaneutralise,-all'a geçmeden önce nedenini bulun.
MX kayıtlarını incelemek ve alma ana makinelerinin de doğru ayarlandığından emin olmak için MX kaydı sorgulama hızlı bir başlangıç noktasıdır. SPF'yi ayarladıktan sonra e-postalar hâlâ spam'e gidiyorsa, sorun genellikle SPF değildir; E-postalarımız neden spam'e gidiyor? Tam sorun giderme rehberi DKIM, DMARC ve reputation yolunu kapsar.
Pratik bir uyarı: SPF yalnızca gönderim yolunu doğrular, içeriği değil. Kusursuz SPF'ye ve kapalı DKIM'e sahip bir alan adı, Gmail'de hâlâ sorun yaşar. Linux hosting üzerinde çalışıyorsanız ve DNS ayarlarına ve DKIM anahtarına erişiminiz varsa, ikisini birlikte ayarlayın; SPF işin yalnızca yarısıdır.
Sık sorulan sorular
Bir SPF kaydındaki maksimum include sayısı kaçtır?
Include sayısı üzerinde sayısal bir sınır yoktur, ancak 10 DNS sorgu sınırı bunu pratikte bulut servislerine bağlı iki veya üç include ile sınırlar. Her include en az bir sorgu tüketir ve kendi iç sorgularını da ekler. Bu sınırı aşarsanız, sonuç permerror olur ve e-posta reddedilir.
SPF'de -all ile ~all arasındaki fark nedir?
-all alıcıya listede olmayan göndericileri kesinlikle reddetmesini söyler, ~all ise kabul edebilirsin ama dikkatli davran der. Pratikte ~all, e-postanın reddedilmek yerine spam'e düşmesine neden olur. Tüm göndericilerini bildiğiniz bir alan adı için -all doğru seçimdir.
SPF kaydım doğru göründüğü halde neden permerror veriyor?
Üç yaygın neden: on DNS sorgu sınırının aşılması, her ikisi de v=spf1 ile başlayan iki ayrı TXT kaydının varlığı ve all'ın diğer mekanizmalardan önce gelmesi. İkinci durumu dig +short TXT example.com ile görün; iki satır dönerse tek bir kayıtta birleştirilmelidir.
ptr SPF'de hâlâ çalışıyor mu?
Çalışıyor ama RFC 7208 kullanımını yasaklamıştır ve bazı alıcılar onu görmezden gelir. Ayrıca her IP bir sorgu tüketir ve sizi hızla on sınırına ulaştırır. Yerine ip4 veya include kullanın.
Başka herhangi bir değişiklikten önce, şimdi alan adınızda bir kez dig +short TXT çalıştırın ve sorgu tüketen terimleri sayın. Ona yakınsa, bir sonraki sorununuz SPF olmayacak; sorun şimdiden başlamış demektir.