SPF 10 DNS Sorgu Sınırı: PermError Hatası ve Çözümü

Bir SPF kaydı değerlendirilirken DNS sorgusu gerektiren en fazla on terim işlenebilir. include, a, mx, exists, redirect ve ptr sayılır; iç içe include'ların içindekiler de aynı hesaba yazılır. ip4, ip6 ve all hiçbir şeye mal olmaz. On birinci sorguda değerlendirme permerror ile biter ve permerror bir "pass" değildir: DMARC açısından SPF geçmemiş sayılır. Kalıcı çözüm, kayıttaki hizmetleri daha ustaca saklamak değil, sayılarını azaltmaktır.

Kuralın kaynağı RFC 7208, bölüm 4.6.4. Amaç basit: gelen tek bir ileti, alıcı sunucuya tanımadığı birinin kaydı yüzünden sınırsız sayıda DNS sorgusu yaptıramasın.

Hangi mekanizmalar sayılır, hangileri sayılmaz

Terim	10 sınırına dahil mi?	Not
include:	Evet	Dahil edilen kaydın içindeki sayılan terimler de eklenir, iç içe devam eder
a	Evet	a:host.example.com biçimi de
mx	Evet	Ayrıca kendi iç sınırı var, aşağıda
exists:	Evet	Çoğunlukla makrolarla kullanılır
redirect=	Evet	Niteleyici (modifier) olsa da sorgu doğurur
ptr	Evet	RFC'nin kendisi kullanılmamasını söyler; kaldırın
ip4:, ip6:	Hayır	Adres doğrudan yazılıdır, DNS gerekmez
all	Hayır
exp=	Hayır	Yalnızca fail sonrasında açıklama metni için okunur

Sınır, tek bir SPF değerlendirmesinin bütünü için geçerlidir. Kendi TXT kaydınızın ilk okunması sayılmaz; o kaydın tetiklediği her şey sayılır.

Aynı bölümdeki iki sınır daha

• mx ve ptr için ek sınır. Tek bir mx mekanizması değerlendirilirken dönen MX adları için ondan fazla adres sorgusu yapılamaz (ptr ile bulunan adlar için de aynı tavan geçerlidir). Ondan fazla MX sunucusu olan bir alan adı, toplam terim sayısı düşük olsa bile bu kapıdan permerror üretir.
• Boş sorgular (void lookup). NXDOMAIN ya da boş yanıt dönen sorguya "void lookup" denir. RFC, alıcıların bir değerlendirmede bunlardan en fazla ikisine izin vermesini (SHOULD) ve fazlasında permerror dönmesini söyler. İptal edilmiş hizmetlerden kalan iki ölü include bunun için yeter.

Saymakla ilgisi olmayan klasik hata

Aynı ad üzerinde v=spf1 ile başlayan iki TXT kaydı da permerror demektir. Yeni bir hizmetin kurulum yönergesi "şu SPF kaydını ekleyin" der, biri de aynen ekler. Mekanizmaları tek kayıtta birleştirin.

Hata neden "bazen oluyor, bazen olmuyor" gibi görünür

Permerror, "bu kayıt yorumlanamıyor" anlamına gelir. Alıcının bununla ne yapacağı kendi yerel politikasıdır: kimi fail gibi, kimi nötr gibi davranır. DMARC ise yalnızca SPF'in hizalanmış bir pass üretip üretmediğine bakar; permerror pass değildir. İletilerinizde hizalanmış bir DKIM imzası varsa DMARC yine geçer ve bozuk SPF kaydını aylarca kimse fark etmez. Sonra DKIM imzası olmayan bir kaynak (unutulmuş bir uygulama sunucusu, ofisteki tarayıcı) bir sağlayıcıda reddedilmeye, diğerinde teslim edilmeye başlar.

Mekanizma sırası da kafa karıştırır. SPF soldan sağa değerlendirilir ve ilk eşleşmede durur. İkinci mekanizmayla eşleşen gönderen on birinci sorguya hiç ulaşmaz; kaydın sonunda yer alan gönderen ulaşır. Yani aynı kayıt posta kutusu sağlayıcınız için "pass", e-fatura aracınız için "permerror" verebilir.

Kaydınızı elle sayın

Önce kaydın kendisi:

$ dig +short TXT example.com | grep spf1
"v=spf1 mx a include:_spf.mailprovider.example include:spf.newsletter.example include:spf.crm.example include:spf.helpdesk.example ip4:192.0.2.10 -all"

Sonra her include'u, onların içindeki include'ları da izleyin:

$ dig +short TXT _spf.mailprovider.example
"v=spf1 include:_netblocks1.mailprovider.example include:_netblocks2.mailprovider.example include:_netblocks3.mailprovider.example ~all"

$ dig +short TXT _netblocks1.mailprovider.example
"v=spf1 ip4:198.51.100.0/24 ip6:2001:db8:10::/48 ~all"

Sayılan her terim için bir satır yazın:

example.com kaydındaki terim	Kendi maliyeti	İçindekiler	Ara toplam
mx	1	0	1
a	1	0	1
include:_spf.mailprovider.example	1	3 include	4
include:spf.newsletter.example	1	1 include	2
include:spf.crm.example	1	1 include + 1 a	3
include:spf.helpdesk.example	1	0	1
ip4:192.0.2.10	0	0	0
Toplam			12

On iki: erken eşleşmeyen her gönderen için permerror. Bir not: dahil edilen kaydın sonundaki all, sizin değerlendirmenizi bitirmez; include yalnızca "pass" ürettiğinde eşleşmiş sayılır.

OrbitProbe SPF sorgulama bu sayımı sizin yerinize yapar; yine de bir kez elle saymak, hangi hizmetin pahalı olduğunu görmenin en hızlı yoludur.

SPF permerror çözümü: denenecek sırayla

1. Artık kullanmadığınız hizmetleri çıkarın

Sınırı aşan kayıtların çoğunda yıllar önce iptal edilmiş en az bir hizmet durur. Include'ları, faturaları ödeyen kişiyle birlikte gözden geçirin. Çıkarılan her hizmet genellikle bir ila dört sorgu kazandırır. Ayrıca bir açığı kapatır: include, o platformun gönderim adreslerini alan adınız için yetkilendirir ve paylaşımlı altyapıda aynı adreslerden başka müşterilerin postası da çıkar.

2. a ve mx yerine adres yazın

mx ve a, birçok oluşturucunun varsayılan olarak eklediği kolaylıklardır. Web sunucunuz posta göndermiyorsa a gereksizdir. MX kayıtlarınızdaki sunucular giden postanızı göndermiyorsa (barındırılan e-postada olağan durum budur; gönderimi sağlayıcının include'u karşılar) mx de gereksizdir. Gerçekten gönderen ve adresi sabit olan bir sunucu için ip4:192.0.2.10 ya da ip6:2001:db8::25 yazın: sıfır sorgu.

3. Hizmet, zarf göndericisinde alan adınızı kullanıyor mu?

SPF, kullanıcının gördüğü From başlığını değil, zarf göndericisindeki (MAIL FROM; iletide Return-Path olarak görünür) alan adını denetler. Birçok e-posta gönderim hizmeti burada kendi bounce alan adını kullanır. O durumda alıcı sizin değil onların SPF kaydına bakar; kaydınızdaki include sorgu harcar ve hiçbir işe yaramaz.

Hizmetin gerçekten gönderdiği bir iletiyi açıp başlıklara bakın:

Return-Path: <bounce-7f3a@bounces.newsletter.example>
From: Example Shop <news@example.com>

Return-Path, example.com altında değil; öyleyse ana kayıttaki include:spf.newsletter.example silinebilir. Bu postanın DMARC'tan geçmesini sağlayan şey d=example.com ile atılmış DKIM imzası ya da özel return-path tanımıdır (sonraki adım).

4. Her gönderim hizmetine kendi alt alan adını verin

Sınır değerlendirme başınadır ve her değerlendirme zarf alan adından başlar. Bülteni news.example.com, işlem e-postalarını billing.example.com üzerinden gönderirseniz her adın kendi kaydı ve kendi on sorguluk bütçesi olur:

news.example.com.     TXT  "v=spf1 include:spf.newsletter.example -all"
billing.example.com.  TXT  "v=spf1 include:spf.invoicing.example -all"

Platformların çoğu bunu "custom return-path" ya da "özel bounce alan adı" adıyla sunar: bounce.news.example.com gibi bir CNAME'i sağlayıcıya yönlendirirsiniz, SPF kaydı tümüyle onların tarafında durur. DMARC'ın varsayılanı olan gevşek hizalamada bounce.news.example.com, example.com adresli bir From ile hizalanır. SPF miras alınmaz: kendi kaydı olmayan alt alan adının SPF kaydı yoktur.

5. Hizalanmış DKIM'e yaslanın

DMARC için hizalanmış tek bir geçiş yeter: SPF ya da DKIM. d= alanında sizin alan adınızla imza atabilen her hizmette DKIM tek başına yeterlidir; üstelik SPF'in dayanamadığı yönlendirmeye dayanır (e-posta yönlendirme SPF'i neden bozar). 3. adımı güvenli kılan da budur.

6. Flattening: yalnızca otomasyonla

"Flattening", her include'u o an çözümlendiği IP aralıklarıyla değiştirmektir. Sorgu sayısı sıfıra iner ve kayıt bugün çalışır. Sorun yarındır: sağlayıcılar aralık ekler, aralık bırakır ve size haber vermez. O gün meşru postanızın bir bölümü, görünüşte kusursuz bir kayıtla SPF'ten kalmaya başlar. Flattening yapacaksanız bu, include'ları düzenli aralıklarla yeniden çözümleyip kaydı yeniden yayınlayan bir süreç olmalı ve o sürecin kendisi de izlenmelidir. Elle bir kez düzleştirilmiş kayıt, ertelenmiş bir kesintidir.

Düzleştirilmiş kayıtlar uzar. Tek bir TXT karakter dizgisi en fazla 255 bayt taşır; daha uzun kayıtlar birden fazla dizgiye bölünür ve alıcılar bunları araya boşluk koymadan birleştirir. Yanlış yerden bölünen kayıtta iki mekanizma birbirine yapışır. Yanıtın bütününü de küçük tutun: geleneksel 512 baytlık UDP boyutunu aşan yanıtlar EDNS0'a ya da TCP'ye geçişe bağımlıdır; RFC de bu sınırın altında kalmayı önerir.

7. Makrolar

SPF makroları (exists:%{i}._spf.example.com) çok sayıda göndereni tek sorguya indirebilir. Buna göre kurulmuş bir DNS altyapısı ister, hata ayıklaması zordur. Vardır, bazı büyük işletmeciler kullanır; ilk başvurulacak çözüm değildir.

~all ile -all farkının bu konuyla ilgisi yok: all üzerindeki niteleyici, eşleşmeyen gönderenlere ne olacağını belirler ve iki durumda da sorgu harcamaz.

Sık yapılan hatalar

• Yalnızca ana kayıtta görünen include'ları sayıp iç içe olanları unutmak.
• Return-Path'i kendi alan adında olan bir hizmet için include: eklemek.
• mx ve a mekanizmalarını "ne olur ne olmaz" diye tutmak.
• İptal edilen hizmetlerin include'larını bırakmak: önce sorgu harcarlar, sağlayıcı adı silince de boş sorguya dönüşürler.
• Mevcut kaydı düzenlemek yerine ikinci bir v=spf1 kaydı yayınlamak.
• Elle bir kez flattening yapıp bir daha bakmamak.
• Uzun kaydı 255 baytlık dizgilere bölerken birleşim yerindeki boşluğu kaybetmek.
• Yalnızca kayıttaki ilk hizmetten gelen postayla test etmek; o, sınıra ulaşılmadan eşleşir.

Kaydı sıfırdan kuruyorsanız SPF oluşturucu söz dizimini hazırlar; sayımın yine canlı include'lar üzerinden yapılması gerekir.

OrbitProbe ile kontrol edin

OrbitProbe SPF sorgulama aracı bir alan adının SPF kaydını bulur ve kaydı en sık bozan sorunları işaretler: birden fazla kayıt, +all, eksik all mekanizması ve sınırı aşan DNS sorgusu sayısı. Önce ana alan adı için, ardından posta gönderen her alt alan adı için ayrıca çalıştırın; her ad kendi başına değerlendirilir. DNS sorgusu o anda yayınlanmış olanı gösterir, postanızın kabul edilip edilmediğini gösteremez; DMARC raporlarını okumaya devam edin. Dört posta kaydının birbirine nasıl bağlı olduğunu MX, SPF, DKIM ve DMARC yazısında, teslimatın tamamını kapsayan taramayı mailler spam'e düşüyor: DNS kontrol listesi yazısında bulabilirsiniz.