E-posta Yönlendirme SPF Hatası: SRS ve ARC Ne İşe Yarar?

E-posta yönlendirme SPF denetimini bozar, çünkü SPF bağlanan IP adresini zarf göndericisinin alan adındaki kayıtla karşılaştırır; düz bir yönlendirici ise birincisini değiştirir, ikincisine dokunmaz. Son alıcı, yönlendiricinin sunucusunun example.com "adına" posta teslim ettiğini görür, o sunucuyu example.com SPF kaydında bulamaz ve fail döner. İki tarafta da yanlış ayar yoktur: SPF böyle tasarlanmıştır. İletinin DMARC denetiminden geçip geçmeyeceği neredeyse tümüyle DKIM imzasına bağlıdır.

Bu yazı tek bir iletiyi yönlendirici üzerinden izliyor ve SRS, DKIM ve ARC'nin her birinin neyi değiştirdiğini gösteriyor.

SPF tam olarak neyi denetler

Bir SMTP tesliminde iki gönderici kimliği vardır:

• zarf göndericisi: MAIL FROM komutunda verilir, sonradan Return-Path başlığına yazılır. Geri dönen (bounce) iletiler buraya gider.
• From başlığı: alıcının posta programında gördüğü adres.

SPF (RFC 7208) yalnızca ilkini bilir. Alıcı, zarf göndericisinin alan adını alır (zarf göndericisi boşsa, örneğin bounce iletilerinde, yedek olarak HELO adını kullanır), o alan adının SPF kaydını okur ve sorar: şu anda bana bağlanan IP adresi bu kayıtta var mı?

Doğrudan teslim:

alice@example.com  ->  example.com posta sunucusu (192.0.2.10)  ->  alıcı
MAIL FROM:<alice@example.com>      bağlanan IP 192.0.2.10        spf=pass

Düz yönlendirici ne yapar

Düz yönlendirici; bir alias, bir .forward dosyası, "tüm postayı şu adrese ilet" kuralı ya da birçok kayıt firmasının alan adıyla birlikte sunduğu e-posta yönlendirme hizmetidir. İletiyi kabul eder ve başka bir adrese yeniden gönderir; bounce iletileri yazarına dönsün diye özgün zarf göndericisini korur.

alice@example.com  ->  yönlendirici (203.0.113.7)  ->  Bob'un asıl posta kutusu
MAIL FROM:<alice@example.com>      bağlanan IP 203.0.113.7       spf=fail

203.0.113.7 yönlendiriciye aittir. example.com bu adresi tanımaz, tanıması da gerekmez: bir gönderen, alıcılarının postayı nereye yönlendirdiğini bilemez.

SRS: SPF'i yönlendirici adına onarmak

Sender Rewriting Scheme (SRS), iletiyi yeniden göndermeden önce zarf göndericisini yönlendiricinin kendi alan adındaki bir adresle değiştirir:

MAIL FROM:<SRS0=HHH=TT=example.com=alice@forwarder.example>

HHH kısa bir özet (hash), TT zaman damgasıdır; özgün alan adı ve kullanıcı adı korunur ki bu adrese gelen bir bounce çözülüp alice@example.com adresine iletilebilsin. Özet, üçüncü kişilerin yönlendiriciyi bounce aktarıcısı olarak kötüye kullanmasını engeller.

Artık alıcı forwarder.example alan adının SPF kaydına bakar; o kayıtta 203.0.113.7 vardır. SPF geçer.

SRS hakkında bilinmesi gereken iki şey:

• IETF standardı değildir. SPF projesinden çıkmış bir topluluk belirtimidir; uygulamalar ayrıntıda birbirinden ayrılır.
• SPF'i düzeltir, DMARC'ı düzeltmez. Yeniden yazımdan sonra SPF ile doğrulanan alan adı forwarder.example olur, From başlığında ise hâlâ example.com yazar. DMARC, doğrulanan alan adının From alan adıyla hizalanmasını ister; dolayısıyla DMARC'ın SPF ayağı yine başarısızdır. Yalnızca gürültülü değil, sessiz biçimde başarısız olur.

DKIM: yolculuğa dayanan kısım

DKIM imzası bağlantının değil, iletinin parçasıdır. Gövdeyi ve seçilmiş başlıkları kapsar; imzalayanın DNS'indeki açık anahtarla doğrulanır. İletiyi değiştirmeden aktaran bir yönlendirici, hangi IP'den bağlanırsa bağlansın imzayı geçerli bırakır. İmzalayan alan adı (d=) From alan adıyla hizalıysa DMARC yalnızca DKIM ayağıyla geçer.

DKIM, imzalanan bir bölüm değiştiğinde bozulur:

• e-posta listesi konuya [liste-adı] etiketi ya da gövdeye alt bilgi ekler
• bir ağ geçidi gövdeyi yeniden yazar; örneğin yasal uyarı ekler ya da bağlantıları değiştirir
• bir sistem iletiyi, imzanın kanonikleştirme yönteminin tolere etmediği biçimde yeniden kodlar

Düz yönlendirme bunların hiçbirini yapmaz. E-posta listeleri ilkini sürekli yapar.

Senaryo tablosu

example.com alan adının SPF yayınladığını, d=example.com ile imzaladığını ve politikasının p=reject olduğunu varsayalım.

Senaryo	SPF sonucu	DKIM sonucu	DMARC sonucu
Doğrudan teslim	pass, hizalı	pass, hizalı	pass
Düz yönlendirme, ileti değişmemiş	fail	pass, hizalı	pass (DKIM sayesinde)
Düz yönlendirme, gönderende DKIM yok	fail	yok	fail
SRS'li yönlendirme, ileti değişmemiş	yönlendirici için pass, hizasız	pass, hizalı	pass (DKIM sayesinde)
SRS'li yönlendirme, gönderende DKIM yok	yönlendirici için pass, hizasız	yok	fail
Konuyu ya da gövdeyi değiştiren e-posta listesi	liste için pass, hizasız	fail (bozulmuş)	fail; liste From'u yeniden yazmıyorsa
Aynısı, alıcının güvendiği bir ARC zinciriyle	yukarıdaki gibi	yukarıdaki gibi	fail; ama alıcı yerel kararla geçirebilir

Pratikte önemli olan ikinci ve beşinci satırlardır: hizalı DKIM imzası olmayan bir göndereni SRS kurtaramaz; hizalı DKIM imzası olan gönderenin ise DMARC için SRS'e ihtiyacı yoktur.

ARC: aracının gördüğünü sonraki alıcıya aktarmak

Authenticated Received Chain (RFC 8617, "Experimental" statüsünde) e-posta listesi satırlarına çözüm arar. İletiyi işleyen aracı, ileti kendisine ulaştığında gördüğü doğrulama sonuçlarını kaydeder ve bu kaydı imzalar. Her durak, örnek numarası taşıyan üç başlık ekler:

ARC-Authentication-Results: i=1; lists.example.org;
   spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com;
   dmarc=pass header.from=example.com
ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.example.org; s=arc1; …
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.org; s=arc1; …

İkinci aracı i=2 ekler ve böyle sürer. Son alıcı zinciri doğrulayıp iletinin lists.example.org sunucusuna ulaştığında, yani liste onu değiştirmeden önce DMARC'tan geçmiş olduğunu görebilir.

Buradaki kilit sözcük "görebilir". ARC, alıcıya bir mühürleyicinin ne gördüğünü iddia ettiğini söyler. O mühürleyiciye inanıp inanmamak yerel politikadır: alıcı güvendiği bir aracının zincirini dikkate alabilir (MAY), yok da sayabilir. ARC teslim garantisi değildir.

Bu belirsizlik yüzünden e-posta listeleri, alan adı DMARC uygulayan gönderenler için genellikle daha kaba bir yol seçer: From başlığını listenin kendi alan adındaki bir adresle yeniden yazar; böylece ileti listenin kendi SPF ve DKIM'iyle hizalanır.

Authentication-Results başlığını okumak

Yönlendirici üzerinden, kendi kontrolünüzdeki bir posta kutusuna ileti gönderin, "orijinali göster" ile açın ve son alıcının eklediği (en üstteki) Authentication-Results başlığını bulun:

Authentication-Results: mx.receiver.example;
   spf=pass smtp.mailfrom=forwarder.example;
   dkim=pass header.d=example.com header.s=s2026;
   dmarc=pass header.from=example.com;
   arc=pass
Return-Path: <SRS0=a1b2=XY=example.com=alice@forwarder.example>

Alan	Ne söyler
smtp.mailfrom=	SPF'in hangi alan adına göre denetlendiği. Yönlendiricinin alan adıysa SRS kullanılıyor demektir.
spf=	O alan adı ve bağlanan IP için sonuç. Özgün alan adıyla birlikte fail, düz yönlendirici demektir.
header.d=	DKIM imzası doğrulanan alan adı. header.from ile karşılaştırın.
dmarc=	Hizalama sonrası hüküm. Belirleyici olan budur.
arc=	Bir ARC zinciri var mıydı, doğrulandı mı.

Başlıkları satır satır okumak yerine yapıştırmak isterseniz e-posta başlık analizi aracı bunları ayrıştırır.

Gönderenler için öneriler

1. Her şeyi, From alan adınızla hizalı DKIM ile imzalayın. Adınıza gönderen her hizmet: posta kutusu sağlayıcısı, bülten aracı, e-fatura, destek yazılımı. Postanızı yönlendirmeye dayanıklı kılan budur. SPF tek başına bunu hiçbir zaman sağlayamaz.
2. Yönlendiricilerin IP adreslerini SPF kaydınıza eklemeyin. Hepsini bilemezsiniz, değişirler ve eklediğiniz her include 10 sorgu sınırından düşer.
3. p=reject politikasına, DMARC raporları tüm meşru kaynaklarınızda DKIM hizalamasını gösterdikten sonra geçin. Yalnızca SPF'e dayanan p=reject politikalı bir alan adının yönlendirilen postası reddedilir.
4. E-posta listelerinden kaynaklanan küçük bir başarısızlık kalıntısı bekleyin. MX, SPF, DKIM ve DMARC yazısındaki geçiş sırası bunu hesaba katar.

Postasını yönlendirenler için öneriler

• SRS uygulayan, mümkünse ARC ile mühürleyen bir yönlendirici kullanın. SRS yoksa -all yayınlayan her alan adından gelen ileti hedefe spf=fail ile ulaşır.
• Yönlendirmek yerine çekmeyi düşünün. Hedef posta kutusu eski hesaptaki postayı POP ya da IMAP ile toplayabiliyorsa yeniden gönderim olmaz, doğrulama da bozulmaz.
• Spam'i yönlendirmeyin. Son alıcı, o postayı yönlendiricinizin IP'sinin teslim ettiğini görür ve hesabı yönlendiriciye yazar. Yönlendirmeden önce filtreleyin. Yönlendirilmiş çöp postada "spam bildir" düğmesine basmak durumu ağırlaştırır.
• Posta kutusunu yönlendirmek yerine barındırmayı düşünün. Kurumsal alan adını ücretsiz bir posta kutusuna yönlendiren kurulum, "maillerim gelmiyor" şikâyetlerinin çoğunda kırılgan halkadır: mailler spam'e düşüyor: DNS kontrol listesi.

Sık yapılan hatalar

• Yönlendirilmiş bir iletideki spf=fail sonucunu sahtecilik kanıtı saymak. Karar vermeden önce dkim= ve dmarc= alanlarına bakın.
• SRS'in DMARC'ı düzelttiğini sanmak. SRS, SPF'i yönlendiricinin alan adı için düzeltir; hizalama yine yoktur.
• Alıcıların yönlendiricileri için kendi SPF kaydınıza include: eklemek.
• "Testlerimizin hepsinde SPF geçiyor" diyerek yalnızca SPF ile p=reject politikasına geçmek. Testlerde yönlendirici nadiren bulunur.
• ARC'nin alıcıyı kabule zorladığını varsaymak. ARC, mühürleyiciye güvenip güvenmemekte serbest olan alıcıya sunulmuş bir kanıttır.
• Giden posta ağ geçidinde yasal uyarıyı DKIM imzasından sonra eklemek. İleti daha yola çıkmadan kendi imzanızı bozarsınız.
• Küçük bir sunucudan spam dahil her şeyi yönlendirip büyük posta sağlayıcısının neden kısıtlama uyguladığına şaşırmak.

OrbitProbe ile kontrol edin

OrbitProbe SPF sorgulama aracı bir alan adının yayınladığı SPF kaydını gösterir ve bilinen yapısal sorunları işaretler: birden fazla kayıt, +all, eksik all mekanizması, sınırı aşan DNS sorgusu sayısı. Yönlendirme sorununda iki adı kontrol edin: özgün gönderenin alan adı (-all ile bitiyor mu; bitiyorsa düz yönlendirme sert biçimde başarısız olur) ve yönlendiricinin alan adı (SRS ile yeniden yazılan postanın geçebilmesi için geçerli bir kaydı var mı). DNS kontrolü yayınlanmış politikayı okur. Belirli bir iletinin başına ne geldiği ise yalnızca o iletinin Authentication-Results başlığında yazar; ikisine birlikte bakın.