Yönlendirme neden “basit” görünür ama pratikte sorun çıkarır?
E-posta yönlendirme (forwarding), ilk bakışta çok basit bir işlem gibi görünür: Gelen bir mesajın bir kopyası başka bir adrese iletilir. Ancak kurumsal e-posta altyapısında güvenlik ve kimlik doğrulama kontrolleri devreye girdiğinde yönlendirme; SPF, DMARC ve genel teslim edilebilirlik açısından beklenmedik hatalara yol açabilir. Bunun nedeni, yönlendirme yapan sunucunun çoğu zaman mesajın “göndereni” gibi davranması ve alıcı tarafın bu yeni bağlantıyı kimlik doğrulama açısından değerlendirmesidir.
Bu yazıda, yönlendirme sırasında SPF’in neden bozulduğunu, SRS (Sender Rewriting Scheme) yaklaşımının ne yaptığını, hangi senaryolarda gerekli hale geldiğini ve şirketlerin yönlendirme politikasını nasıl tasarlaması gerektiğini pratik şekilde ele alacağız.
SPF’in kontrol ettiği şey nedir?
SPF (Sender Policy Framework), bir alan adının “bu domain adına mail göndermeye hangi IP’ler/servisler yetkilidir?” sorusuna DNS üzerinden yanıt vermesini sağlar. Alıcı sunucu, SMTP bağlantısını yapan IP’yi alır, zarf gönderen (envelope-from) adresindeki domain için SPF kaydını sorgular ve bu IP yetkili mi diye kontrol eder.
Burada kritik nokta şudur: SPF, mesajın içerik kısmındaki görünen From alanından değil, çoğunlukla zarf gönderen bilgisinden (Return-Path ile ilişkilidir) ve bağlantıyı kuran IP’den hareket eder. Bu, SPF’i yönlendirme senaryolarında kırılgan yapar.
E-posta yönlendirme SPF’i neden başarısız yapar?
Bir kullanıcıya gelen mesajı başka bir adrese yönlendirdiğinizde, yönlendirme sunucusu genellikle yeni bir SMTP oturumu başlatır ve mesajı hedef sunucuya iletir. Bu yeni SMTP oturumunda bağlantıyı kuran IP artık “yönlendiren sunucunun IP’sidir”. Ancak zarf gönderen adresi çoğu zaman orijinal gönderen olarak kalır.
Sonuç: Hedef sunucu, “orijinal gönderen domain”in SPF kaydına bakar ama bağlanan IP “yönlendiren sunucu” olduğu için bu IP genellikle yetkili değildir. SPF bu yüzden fail (veya softfail) olur.
Örnek senaryo
- Orijinal gönderici: kullanici@ornek.com
- İlk alıcı: info@sirket.com
- Yönlendirme hedefi: ad.soyad@baskadomain.com
- Yönlendiren sunucu: sirket.com’un mail sunucusu
baskadomain.com tarafı, ornek.com’un SPF kaydına bakıp “sirket.com sunucusu ornek.com adına mail gönderebilir mi?” diye kontrol eder. Çoğu durumda cevap hayırdır; SPF başarısız olur.
SPF fail her zaman sorun mu? DMARC devreye girince büyür
Tek başına SPF fail bazen tolere edilebilir gibi görünse de, DMARC politikası olan domainlerde durum ciddi hale gelebilir. DMARC, SPF ve/veya DKIM sonuçlarına bakar ve bunların görünen From domainiyle “uyumlu” (alignment) olmasını ister. Yönlendirme SPF’i bozduğunda, DKIM de mesaj üzerinde bozulmuşsa (örneğin mailing list modifikasyonu, bazı geçitler, bazı otomatik eklemeler), DMARC başarısız olabilir.
Orijinal gönderen domain p=quarantine veya p=reject gibi sıkı bir DMARC politikası kullanıyorsa, yönlendirdiğiniz mesajlar hedefte spam/karantina klasörüne düşebilir veya tamamen reddedilebilir. Bu, özellikle rol bazlı adresleri (info@, muhasebe@ gibi) kişisel kutulara yönlendiren şirketlerde yaygın bir problemdir.
SRS (Sender Rewriting Scheme) nedir ve neyi değiştirir?
SRS, yönlendirme sırasında SPF kırılmasını azaltmak için geliştirilmiş bir yöntemdir. Temel fikir şudur: Yönlendiren sunucu, mesajı iletirken zarf gönderen adresini (envelope-from) kendi domainine ait bir adrese “yeniden yazar”. Böylece hedef sunucu SPF kontrolünü artık orijinal domain için değil, yönlendiren sunucunun domaini için yapar.
Bu, yönlendirme sunucusunun bağlantıyı kuran IP olduğu gerçeğiyle uyumludur. Yani SPF açısından “bağlanan IP, kontrol edilen domainin SPF kaydında yetkili mi?” sorusu olumluya dönebilir.
SRS nasıl çalışır (kavramsal)?
Orijinal envelope-from: bounce@ornek.com
Yönlendirme sonrası envelope-from örneği: SRS0=HASH=ZAMAN=ornek.com=bounce@sirket.com
Mesajın görünen From alanı genellikle değişmez; değişen kısım çoğu zaman Return-Path/envelope-from’dur. Bu, SPF doğrulamasını hedef tarafta “sirket.com adına gönderim” gibi gösterir. Ayrıca bounce (geri dönüş) trafiğinin de doğru şekilde yönlendiren sunucuya geri gelmesini sağlar.
SRS ne zaman gereklidir, ne zaman şart değildir?
SRS’nin özellikle gerekli olduğu durumlar
- Şirketiniz bir alan adından gelen mailleri başka bir sağlayıcıya veya farklı bir domain’e otomatik yönlendiriyorsa
- Rol bazlı adresler yoğun şekilde yönlendirme kullanıyorsa (info@ ekip dağıtımı yerine yönlendirme gibi)
- DMARC politikası sıkı (quarantine/reject) domainlerden yoğun mail alıyorsanız
- Yönlendirme hedefi büyük posta sistemleri ve sıkı anti-spam kontrolleri uygulayan kurumsal alıcılarsa
SRS’ye daha az ihtiyaç duyulan durumlar
- Aynı e-posta sistemi içinde sunucu tarafı “deliver to mailbox” yapılıyor, farklı bir dış hedefe SMTP ile yeniden gönderim yapılmıyorsa
- Yönlendirme yerine istemci tarafı kural kullanılıyor (kullanıcının oturumu içinde) ancak bunun da farklı riskleri vardır
- Yönlendirme hedefi aynı domain içindeki bir posta kutusuysa
Yönlendirme tasarımında pratik alternatifler
SRS çoğu zaman doğru çözümdür; ancak her zaman tek seçenek değildir. İşletmeler aşağıdaki seçenekleri de değerlendirmelidir.
1) Yönlendirme yerine dağıtım grubu / paylaşılan posta kutusu
Bir adresin birden fazla kişiye “dağıtılması” gerekiyorsa, gelen mesajın aynı sistem içinde birden fazla kutuya teslim edilmesi, dışa yönlendirmeye göre daha az teslim edilebilirlik riski taşır. Ayrıca denetim, erişim kontrolü ve işten ayrılan çalışan süreçleri daha yönetilebilir olur.
2) Yönlendirmeyi sınırlandırma ve istisna yönetimi
Her hesabın her yere yönlendirme yapabilmesi, veri sızıntısı ve gölge IT riskini artırabilir. Yönlendirmeyi yalnızca onaylı hedeflere izin vererek veya belirli rol adresleriyle sınırlayarak kontrol etmek, hem güvenlik hem teslim edilebilirlik açısından faydalıdır.
3) DKIM’in korunmasına dikkat etmek
Yönlendiren sistem, mesaj içeriğini veya başlıklarını gereksiz yere değiştirdiğinde DKIM imzası bozulabilir. Bu da DMARC başarısızlığını hızlandırır. Yönlendirme yapan altyapıda hangi işlemlerin mesajı modifiye ettiğini anlamak (etiket ekleme, konuya prefix ekleme, bazı şablonlar) önemlidir.
SRS kullanırken dikkat edilmesi gereken operasyonel noktalar
DNS ve teslim edilebilirlik
SRS ile yeniden yazılan envelope-from adresleri sizin domaininizi kullanacağından, bu domainin SPF kaydı yönlendiren çıkış IP’lerinizi kapsamalıdır. Aksi halde SPF yine fail olur; sadece sorunu başka yere taşımış olursunuz.
Bounce yönetimi
SRS’nin bir amacı da geri dönüş (bounce) mesajlarının doğru yere ulaşmasıdır. Yanlış yapılandırılmış SRS, bounce’ların kaybolmasına veya döngü oluşmasına neden olabilir. Bu, özellikle otomatik yanıtlar ve teslim edilemeyen mail raporları açısından operasyonel körlük yaratır.
Loglama ve sorun giderme
Yönlendirme kaynaklı teslim sorunlarını çözmek için SMTP logları, alıcı tarafın verdiği hata kodları ve mümkünse mesaj header analizi gerekir. SRS devredeyse, Return-Path gibi alanlarda görünen yeniden yazım bilgisinin izlenebilir olması önemlidir.
Şirketler için önerilen kontrol listesi
- Hangi adresler yönlendirme yapıyor? Nereye yönlendiriyor?
- Yönlendirme dış bir domaine mi gidiyor? (risk artar)
- Yönlendirme nedeniyle SPF fail görülen örnekler var mı?
- DMARC’ı sıkı domainlerden gelen maillerde kayıp yaşanıyor mu?
- Yönlendirme yerine dağıtım/ortak posta kutusu gibi tasarımlar daha uygun olabilir mi?
- Yönlendirme zorunluysa, SRS destekli sunucu tarafı yönlendirme planlandı mı?
- Değişiklik sonrası test: SPF/DKIM/DMARC sonuçları hedef tarafta nasıl görünüyor?
Sonuç: Yönlendirme bir “kolaylık” değil, mimari karardır
E-posta yönlendirme, doğru tasarlanmadığında SPF kırılması, DMARC başarısızlığı ve teslim edilebilirlik kaybı gibi sonuçlar doğurabilir. SRS, bu problemin temelini hedefleyerek yönlendirme sırasında zarf göndereni yeniden yazar ve SPF kontrolünü tutarlı hale getirir. Bununla birlikte, yönlendirme ihtiyacını baştan azaltan tasarımlar (dağıtım grupları, rol adresi yönetimi) çoğu şirket için daha sürdürülebilir olabilir.
MX1Mail üzerinde e-posta akışlarını planlarken, yönlendirme gereksinimlerini teslim edilebilirlik ve kimlik doğrulama perspektifiyle ele almak; özellikle SPF/DMARC kaynaklı sürprizleri azaltmak için iyi bir başlangıçtır.