E‑posta Yönlendirmede SPF/DMARC Neden Kırılıyor? SRS ve ARC ile Nasıl Tatlı Tatlı Onarırsın?

Giriş: Forward Tuzağına Düşen İlk E‑posta

Hiç şöyle oldu mu: Alan adını yeni bir sağlayıcıya taşıdın, e‑postaları eski kutundan yenisine yönlendirdin, her şey yolunda derken bir gün önemli bir mesaj karşı tarafa düşmedi. Gelen kutularında spama saplanmış, hatta kiminde tamamen kaybolmuş. O gün ofiste aynen bunu yaşadım. Basit görünen bir yönlendirme ayarı, aslında e‑posta dünyasının kural kitabıyla çatışıyormuş. O an fark ettim ki, meseleyi “bir tıkla forward” sanmakla, onu SPF, DKIM ve DMARC üçlüsünün gözünden görmek arasında dağlar kadar fark var.

Bu yazıda seni şu yolculuğa çıkaracağım: Önce SPF/DMARC neden yönlendirmede patlar, basit bir dille anlatacağım. Ardından sahneye iki kurtarıcı giriyor: SRS (Sender Rewriting Scheme) ve ARC (Authenticated Received Chain). SRS zarfı yani teknik anlamda posta zarfındaki göndereni güvenli biçimde yeniden yazar, ARC ise mesajın geçmişteki doğrulama izlerini saklayarak yeni sunuculara “bu mesaj yol boyunca bozmadı niyetini” der. İşin sonunda “Mesajlarım taraf değiştirdikçe kırılmasın” diyecek pratik bir akışın olacak. Kod göstermeden, ama adımları kafada şıp diye oturtacak örneklerle gideceğiz.

SPF ve DMARC Neden Yönlendirmede Dert Çıkarır?

Mesela şöyle düşün: [email protected] sana yazıyor, mesajını senin alan adına bağlı bir sunucu alıyor ve sen bu mesajı otomatik olarak başka bir yere yönlendiriyorsun. Karşı taraf mesajı aldığında, “Bu e‑postayı gönderen domainin yetkili IP’si bu mu?” diye SPF kontrolü yapıyor. SPF kontrolünde bakılan şey, gönderenin zarf göndereni (MAIL FROM) ile IP’nin o domain için yetkili olup olmadığı. Yönlendirme yaptığında, mesajı gönderen IP artık senin yönlendirme sunucun. Gönderenin SPF kaydı ise “Benim adıma şu IP’ler mail gönderebilir” diyordu. Bu denklem bir anda bozuluyor. SPF “fail” dedi mi, alıcı sistemin ciddiyetine göre mesaj spam’e düşer, bazen de tamamen reddedilir.

DMARC da farklı bir noktaya bakar: Kimlik doğrulama sonuçlarının, gönderen görünen From alanı ile uyumlu olup olmadığı. DMARC, SPF veya DKIM’den en az birinin geçmesini ve bu geçen kimliğin From ile aynı kökten (veya birebir) gelmesini ister. Yönlendirmede sık olan iki sorun var: Birincisi SPF kırılıyor; ikincisi liste yazılımlarının ya da ufak filtrelerin mesajın gövdesini değiştirmesi yüzünden DKIM imzası bozuluyor. O an DMARC “Ben bu mesajın gerçek niyetini anlayamıyorum” diye masadan kalkıyor.

Günlük hayatta bunun karşılığı şu: “Ben sadece yönlendirdim, niye gönderemiyorum?” sorusu. Cevap basit değil ama çözümü var. Burada devreye sırasıyla SRS ve ARC giriyor.

SRS: Zarfı Doğru Yazmadan Postacı İkna Olmaz

SRS tam olarak ne yapar?

SRS, yani Sender Rewriting Scheme, yönlendirme yapan sunucunun, zarf gönderen adresini güvenli bir biçimde kendi alan adına çevirme yöntemidir. Düşün ki postanın üstündeki geri dönüş adresini “Bu mektup artık benden çıkıyor, biri geri döndürecekse bana dönsün” diye düzenliyorsun. Teknikte bu, MAIL FROM adresinin SRS0=… gibi bir yapıya çevrilmesi ve senin domaininle imzalanması demek. Böylece SPF kontrolü yapıldığında, alıcı sunucu “Bu IP bu domain için yetkili mi?” diye bakar ve doğru yapılandırdıysan “Evet” cevabı çıkar.

SRS neden kritik?

Çünkü yönlendirme yaparken, orijinal gönderenin SPF’ini aynen taşımaya çalışırsan kaybedersin. O IP sende değil, o domainin SPF’i de seni kapsamıyor. SRS ile, “Bu mesaj benim üzerimden yeniden çıkıyor” demiş oluyorsun. Bu sayede geri dönüşler (bounce) da doğru yere gelir. Yoksa bounceler orijinal gönderene, hatta bazen boşluğa düşer; iz sürmek çileye döner.

Uygulamada SRS nasıl hayata geçer?

Çok kabaca üç adım var: Bir, alan adının SPF kaydına yönlendirme yapan MTA’nı dahil edersin. İki, MTA üzerinde bir SRS bileşeni çalıştırırsın. Üç, sadece ileri yönlendirmede SRS uygular, normal gönderimlerde dokunmazsın. Postfix tarafında sık kullanılan bir bileşen, Postfix için postsrsd ile pratik SRS kullanımı. Exim ve diğer MTA’larda da benzeri mekanizmalar var. Önemli olan, “Kim yeniden gönderiyor?” sorusunun net bir cevabını SPF’e göstermek.

ARC: Mesajın Yolculuk Günlüğünü Güvenle Taşımak

ARC neyin ilacı?

ARC, yani Authenticated Received Chain, mesaj bir veya birkaç ara sunucudan geçerken, her uğrakta yapılan kimlik kontrollerinin özetini mesajın üzerine damgalıyor. Düşün, bir pasaport gibi; giriş çıkışlarda damga basılıyor. Alıcı sunucu mektup geldiğinde, “Başlangıçta bu mesaj DKIM/ SPF/ DMARC nasıl görünüyordu, arada kim ne yaptı?” sorusunun izini sürebiliyor. Böylece, yönlendirme sırasında gövde ufak değişti ve DKIM bozulduysa bile, alıcı “Ama bak, ilk noktada DKIM geçiyordu” diyebiliyor.

ARC nereye oturur?

ARC bir tamamlayıcıdır. SPF’i düzeltmez, DKIM’i sihirli biçimde onarmaz. Onun görev kartı şudur: Zinciri belgelemek. Birçok büyük alıcı, ARC’yi yorumlamayı öğrendi; bu sayede forward edilen ama niyeti temiz olan mesajlar daha az darbe yiyor. Ayrıntıları merak edersen, ARC standardının RFC 8617 metnini inceleyebilirsin. Detaya boğulmana gerek yok; aklında şu kalsın: ARC, “ben yolda bozulmadım” demenin yazılı yolu.

ARC ile neleri beklemelisin?

ARC tek başına bilet değildir; bir destekleyici referans gibidir. Eksiksiz SRS olmadan sadece ARC’ye güvenirsen, SPF yine patlar. Tersi de doğru: SRS varken ARC yoksa, alıcı yine şüpheye düşebilir. En iyi sonuç, ikisini birlikte düşününce gelir. Kısaca, SRS ile teknik kurala uyarsın, ARC ile iyi niyetini ispatlarsın.

Gerçek Hayattan Dört Senaryo: SRS ve ARC’yi Nereye Koymalı?

1) Klasik “tüm e‑postaları X’ten Y’ye yönlendir”

Bir alan adındaki kutuları başka bir hizmete taşırken, geçiş döneminde “hepsini yeni kutuya akıt” dersin. Burada ilk iş SRS. Yönlendiren tarafta zarf göndereni SRS’lemeni öneririm. SPF hemen hizaya gelir. Ek olarak ARC eklediğinde, alıcı “mesaj ilk geldiğinde imzaları geçiyordu, bu forward masum” diye görür. Bu ikili genelde spam klasörüne saplanmayı engeller. Burada küçük bir not: Eğer orijinal gönderende DKIM zaten güçlü ise, ARC’nin etkisi daha da artar.

2) Catch‑all ile yakala, sonra kurala göre ileri gönder

Özellikle küçük takımlarda “bize gelen her şeyi yakala, sonra dağıt” yaklaşımı var. Catch‑all kullandığında, spam yükün artar ve bunu başka bir hizmete yönlendirirken kolay hedef olursun. SRS şart, çünkü en fazla SPF burada bozulur. Ayrıca ARC eklemek, spam filtrelerinin seni daha az cezalandırmasını sağlar; “yolda bozmadan sadece aktardı” izlenimi taşır. Bu senaryoda, rate limiting ve basit bir içerik filtresi kullanmak iyi olur. Yakalanan toplu spam akışı yüzünden itibarın yara almasın; bunun ipuçlarını e‑posta itibarını toparlama rehberimizde ayrıca detaylandırdım.

3) Şirket içi liste veya alias: Konu etiketleri, imza ekleyen kapılar

Herkese giden bir alias var ve sunucu konu başına etiket ekliyor, bazen altına uyarı bandı iliştiriyor. Bu minik dokunuşlar, DKIM’i kırabilir. Bu durumda SRS yine ilk sırada. Üstüne ARC eklersen, zincirin başında DKIM’in geçer göründüğünü taşırsın. Bu, alıcının “tamam, listede bir şeyler eklenmiş ama orijinal temizmiş” diye düşünmesini sağlar. Etiketlerin ölçülü olmasına dikkat, aşırı müdahale ARC’ye rağmen şüphe uyandırır.

4) Farklı sağlayıcılar arasında akış: MX sende, posta kutusu başka yerde

Alan adının MX’i sende, ama bazı kutular üçüncü bir sağlayıcıda. Posta önce sana geliyor, sonra karşı tarafa gidiyor. Burası forward’ın en çok görüldüğü yer. SRS ile zarf adresini kendi alanına al, SPF düzelsin. ARC ile, ilk doğrulama sonuçlarını paketle. Bu çift, güvenilirliği bir anda yükseltir. Ekstra bir dokunuş olarak, taşıma yolundaki şifrelemeyi de iyileştirmek istersen, MTA‑STS, TLS‑RPT ve DANE üzerine anlattığım yazıya göz at; aktarım katmanında da düzen kurmak, alıcıların sana bakışını yumuşatır.

Adım Adım Zihinsel Model: “Forward”’ı Kurarken Nelere Dokunuyorum?

Önce kim konuşuyor, onu netleştir

Alıcı taraf, kimin adına konuştuğuna bakar. Yönlendirme yapan sunucu, teknik olarak mesajı yeniden gönderir. Bu yüzden “Benim adına konuştuğum domain hangisi?” sorusuna net cevap ver. SPF kaydında bu MTA’yı yetkilendir. SRS ile zarf göndereni kendi domainine çevir. Böylece “Bu mesaj benden çıktı” demeyi resmi hale getirirsin.

From alanı ve DMARC uyumu

DMARC, From’taki domaini esas alır. SPF’in geçmesi yetmez; geçen kimlik From ile uyumlu olmalı. Yönlendirmede From’ı dokunmadan bırakmak normaldir. Bu durumda DMARC uyumu, genellikle orijinal DKIM imzasının ayakta kalmasına yaslanır. İmza bozuluyorsa, ARC’nin kıymeti burada çıkar. “Başlangıçta DKIM sağlamdı” bilgisini ARC taşıyınca, DMARC politikası katı olsa bile alıcılar daha yumuşak davranır.

İmza bozulmasın diye küçük incelikler

Liste etiketleri, dipnotlar, HTML’ye ufak ekler… Hepsi DKIM’i kırabilir. Bunları en aza indir. Posta üstyapısına yapılacak zorunlu ekleri başlıklara (header) taşımak, gövdeyi oynatmaktan daha zararsızdır. Gönderici kimliğine dokunmadan uyarı eklemen gerekiyorsa, kısa ve sabit metinlerle git; dengesiz boşluklar bile imzayı bozabilir.

İleri yönlendirme zincirinde güven

Birden fazla hop varsa, her birinin görevi açık olsun: SRS’yi sadece yönlendiren kapıda uygula, ilk çıkış sunucunda normal gönderimleri SRS’leme. ARC ise zincirin her halkasında yapılabilir; ama pratikte en anlamlı olan, mesajın karar verdiğin kapıda ARC’lenmesidir. “Bu kapıdan geçerken inceledim ve kaydettim” demek, alıcı için en çok şey ifade eder.

Operasyonel İnce İşçilik: DNS, MTA ve İzleme

DNS tarafı: SPF ve arkadaşları

SPF kaydın net olmalı. “include” zincirlerini abartma, hatayı aramak işkence olur. Yönlendirme yapan IP aralığı açıkça kayda girsin. Ayrıca, sertifika altyapını düzenlerken de tutarlılık iyidir; eğer çoklu sertifika otoritesi kullanıyorsan, CAA kayıtlarını doğru kurmak işini kolaylaştırır. Bu detaylar doğrudan SPF/DMARC değil, ama posta altyapısının genel sağlığına iyi gelir.

MTA’daki SRS bileşeni

Postfix, Exim, Haraka… Hangi MTA’yı kullanırsan kullan, SRS’i bir ek yetenek gibi düşün. Adres yeniden yazma, imzalama ve geri dönüşlerin doğru yere düşmesini sağlama üçlüsünü test etmeden canlıya alma. Testte, farklı gönderen domainleri ve farklı alıcılarla deneme yap. “Boş MAIL FROM” bouncelerini de unutma; SRS burada da doğru davranmalı.

ARC anahtarları ve kimlik döngüsü

ARC kendi imzasını atar; bunun için anahtar yönetimine ihtiyaç duyar. DKIM’de alışık olduğun disiplinin aynısı. Döngüsel aralıklarla anahtar yenilemek mantıklı. ARC’nin yazdığı kayıtlar büyüktür; mesaj boyutunu ve bazı sınırları aşmamaya dikkat et. Yine de endişe etme, günlük e‑posta trafiğinde bu sınırlar genelde rahat karşılanır.

Raporlama ve ayarları iyileştirme

DMARC raporları, nerede patladığını gösterir. “Aggregate” raporlar büyük resmi, “forensic” raporlar ise detay vakaları anlatır. DMARC’e ısındıkça, DMARC’in özüne dair kısa bir özet işini kolaylaştırır. Raporları okuyup SRS/ARC akışını ufak dokunuşlarla iyileştirirsin. Bazı alıcılar ARC’ye daha çok değer verir, kimisi daha az; o yüzden gözlem şart.

Kırılma Noktaları: “Neden Hâlâ Spam?” Dediğinde Bakacağın Yerler

Orijinal DKIM yoksa

Forward eden tarafta elinden geleni yaparsın, ama gönderici domain DKIM imzalamıyorsa, DMARC uyumu çoğu zaman sadece SPF’e kalır. SPF’yi SRS ile kurtarsan bile, From ile uyumu yakalamak zor. Bu durumda mesaj bazı alıcılarda hâlâ sert karşılanabilir. Göndericiye “DKIM’i açar mısın?” demek bazen en basit çözümdür.

Yol üstünde gövdeye ağır dokunuş

HTML’i yeniden yazan filtreler, link izleme ekleyen sistemler veya konu satırını sürekli değiştiren listeler, DKIM’i dakikada beş kez kırar. ARC’nin izi faydalıdır ama mucize bekleme. Bu müdahaleleri azaltmak, gövdeyi mümkün olduğunca olduğu gibi taşımak en akıllı yoldur.

İtibar ve altyapı uyumu

Gerçek şu: Bazı IP’ler ve domainler, daha yola çıkmadan gözlerden düşmüştür. Forward akışın kusursuz olsa da alıcı senden geleni istemeyebilir. Böyle anlarda itibar toparlama rehberindeki ipuçları işe yarar. Bir de aktarım katmanını güçlendirmek, örneğin MTA‑STS ve DANE ile şifreli taşıma politikalarını netleştirmek, genel puanını artırır; bunun detaylarını şu yazıda uzun uzun anlattım.

Ufak Bir Rehber: Yönlendirmeyi Kurarken Kafanda Şu Sırayı Tut

1) SPF’yi kendi adına konuşacak şekilde hazırla

Yönlendirme yapan MTA’nın IP’lerini veya kapsayıcı bir include’u SPF’e ekle. Abartmadan, açık ve kısa tut. “-all” ile net bir çerçeve çiz. Böylece SRS sonrası su sızdırmaz bir SPF’in olur.

2) SRS’i sadece forward akışında uygula

Normal gönderimlerde SRS gereksizdir; ileri yönlendirme tanındığı anda zarf gönderene SRS uygula. Geri dönüşlerin doğru tarafa gelip gelmediğini test etmeyi unutma. Bounceler hayat kurtarır; kaybolursa teşhis zorlaşır.

3) ARC’yi zincire dahil et

ARC için anahtarlarını hazırla, imza ve mühür döngüsünü oturt. Mesajı alıp doğruladıktan sonra ARC kayıtlarını ekle. Bu “Mesajı kontrol ettim ve raporu üstüne iliştirdim” demektir.

4) DMARC raporlarını düzenli izle

İlk haftalarda raporlar gürültülü olabilir. Önce büyük resme bak: Hangi alıcıda ne oranda SPF/ DKIM geçiyor? Nerede düşüş var? Sonra sorunlu domainleri tek tek elle dene. Alıcı tarafın davranışı sende dönüşler yaratacaktır; küçük ayarlarla çok yol alırsın.

Hangi Araçlar İşini Kolaylaştırır?

SRS için hafif ve güvenilir çözümler

Postfix ekosisteminde postsrsd hızlı kurulur, hafiftir. Exim tarafında dahili SRS desteği veya ufak eklentiler işini görür. Önemli olan, SRS anahtarının gizli tutulması ve adreslerin belirli bir süre sonra geçersizleşmesi. Böylece sahtekarlığa kapı aralamazsın.

ARC için yaygın uygulamalar

Birçok modern e‑posta geçidi ve MTA, ARC’yi entegre sunar. Bazıları sonradan eklenti ile kazanır. “Ben hangi kombinasyonu seçerim?” sorusunun cevabı, mevcut mimarina bağlı. Küçük bir tüyo: ARC’nin doğru çalıştığını anlamanın en kolay yolu, birkaç alıcıya test mesajları atıp ham başlıklarda ARC‑Seal ve ARC‑Message‑Signature alanlarını görmek ve alıcı yorumuna bakmaktır.

Aktarım güvenliği: Şifreli yol, temiz itibar

İleri yönlendirme ne kadar pürüzsüz olursa olsun, taşıma sırasında kopmalar can sıkar. Şifreli aktarım politikalarını netleştirmek hem güven hem de teslime yardımcı olur. Bu kısım için MTA‑STS ve DANE rehberini okumanı öneririm; orada raporlama ve sorun çözümü için tatlı ipuçları var.

Sık Yapılan Hatalar ve Küçük Kaçış Yolları

“SPF’im zaten var” deyip SRS’i atlamak

SPF kaydın mükemmel olsa da, yönlendirme sırasında konuşan taraf sensin; orijinal gönderen değil. SRS olmadan SPF, karşı tarafa tam olarak “kim konuşuyor” bilgisini vermez. Bu hatayı bir kez yaparsın, ikinci kez SRS’siz forward açmazsın.

Mesajı gereğinden fazla süslemek

Konu satırına etiketler, gövdeye bannerlar, footerlar… Azı karar, çoğu zarar. DKIM imzasını bozmamak için dokunuşları minimize et. Zorunlu uyarıları mümkünse başlıklara taşı, gövdeyi olduğu gibi bırak.

Raporları görmezden gelmek

DMARC raporları sıkıcı görünebilir ama orada hazine var. Hangi alıcı SPF’ye, hangisi DKIM’e daha çok ağırlık veriyor; nerede hatların düğümlendiği; hepsi o raporlarda. Bir rutin oluştur ve haftalık bak. Küçük bir düzeltme, büyük bir deliverability sıçraması demek olabilir.

Kapanış: Yönlendirme, Kurallarla Barışınca Akıyor

Şu tabloyu birlikte çizdik: Yönlendirme basit görünür, ama posta dünyasının kuralları katıdır. SPF “Bu IP bu domain adına konuşabilir mi?” diye sorar. DMARC “From’taki domainle uyum var mı?” diye peşine düşer. DKIM, gövde ve başlıklara dokunulmadığını ispatlar. Yönlendirme bu çizgileri kolayca taşır. SRS, zarfı senin adına yeniden yazarak SPF’i kurtarır. ARC, yol boyunca masum kaldığını belgeleyerek alıcıyı ikna eder. İkisi birlikte, taş gibi bir akış kurar.

Pratik tavsiye olarak şunları cebine koy: Yönlendirme açmadan önce SPF’ini güncelle, SRS’i sadece forward akışında etkinleştir, ARC’yi zincire dahil et. Gövdeye dokunuşları azalt, raporları düzenli izle. Bir de altyapı bütünlüğünü unutma; sertifika ve taşıma politikalarını derli toplu tutarsan, alıcıların gözüne daha güvenilir görünürsün. İstersen buna başlarken MTA‑STS ve DANE yazısından başlayıp, itibar konusunda da şu rehberle destek alabilirsin.

Umarım bu yazı, “Forward açtım ama mail gitmiyor” sorusunu bir daha duymayacağın şekilde aklını aydınlatmıştır. Takıldığın yerde küçük testler yap, başlıklara göz at, raporları takip et. Bir sonraki yazıda belki de DMARC politikalarını kademe kademe sıkılaştırmanın tatlı yollarını konuşuruz. Şimdilik burada noktalayalım; e‑postaların güvenle aksın, sen de kafanı yastığa rahat koy.