Mail Yönlendirme SPF'i Neden Bozar

Şirket adresine gelen mesajları kişisel Gmail hesabına yönlendiren bir kural kurdun, aylarca sorunsuz çalıştı, sonra bir gün mesajlar spam klasörüne düşmeye başladı ya da tamamen reddedildi. Yaptığın bir şey yok, DNS kayıtların da yerinde. Mail yönlendirme SPF'i tam da bu şekilde bozar: yönlendirme, SPF'in tasarımıyla temelde uyumsuzdur ve bu uyumsuzluk, alıcı taraf kuralları sıkılaştırdığı anda görünür hale gelir.

Bu yazıda SPF'in neyi kontrol ettiğini, yönlendirmenin bu kontrolü neden kaçınılmaz olarak düşürdüğünü, DKIM'in neden yönlendirmeden sağ çıkabildiğini ve DMARC hizalamasının bu tabloda nerede durduğunu somut bir SMTP oturumu üzerinden anlatacağım. Ardından gerçekten işe yarayan çözümleri — SRS, ARC, mesajı değiştirmemek ve yönlendirme yerine çekme — tek tek karşılaştıracağım.

SPF Neyi Kontrol Eder: Zarf Gönderen ile Görünen Gönderen#

Bir e-posta mesajının iki ayrı gönderen adresi vardır ve bunları karıştırmak, konunun tamamını anlaşılmaz kılar. Birincisi zarf göndereni (MAIL FROM, geri dönüş adresi anlamında Return-Path); SMTP oturumunda söylenir, kullanıcı arayüzünde asla görünmez ve teslimat hatalarının döneceği adrestir. İkincisi başlık göndereni (From:); mesajın içinde durur ve kullanıcının ekranda gördüğü adres budur.

SPF yalnızca zarf göndereni kontrol eder. Alıcı sunucu şu soruyu sorar: "Bana bağlanan bu IP adresi, MAIL FROM içindeki alan adı adına posta göndermeye yetkili mi?" Cevabı o alan adının SPF TXT kaydından okur.

; firmaniz.com alan adının SPF kaydı
firmaniz.com.   3600   IN   TXT   "v=spf1 ip4:185.12.34.56 include:_spf.saglayici.com -all"

Bu kayıt "yalnızca 185.12.34.56 ve _spf.saglayici.com altındaki IP'ler benim adıma posta gönderebilir, geri kalan her şey reddedilsin" der. -all sert bir reddir; ~all ise yumuşak başarısızlıktır ve genellikle spam puanı olarak işlenir.

Yönlendirme Zinciri Adım Adım Nerede Kopuyor#

Şimdi somut bir senaryoya bakalım. Gönderen [email protected], alıcı [email protected], ve firmaniz.com sunucusu bu mesajı [email protected] adresine yönlendiriyor. İlk teslimat aşamasında her şey yolunda:

# 1. adım: ornek.com sunucusundan firmaniz.com sunucusuna
# Bağlanan IP: 203.0.113.10 (ornek.com'un SPF kaydında yetkili)
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
# SPF sonucu: PASS

Yönlendirme adımında klasik davranış, zarf göndereni olduğu gibi korumaktır — çünkü mesaj teslim edilemezse hata orijinal gönderene dönmelidir. Ama bu sefer bağlanan IP artık senin sunucundur:

# 2. adım: firmaniz.com sunucusundan gmail.com sunucusuna
# Bağlanan IP: 185.12.34.56 (senin sunucun)
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
# Gmail SPF kontrolü: ornek.com kaydında 185.12.34.56 var mı? -> HAYIR
# SPF sonucu: FAIL

Kopma tam olarak burada. Gmail, ornek.com alan adının SPF kaydına bakar, orada senin IP'ni bulamaz ve SPF başarısız der. Sen ornek.com alan adının sahibi olmadığın için o kayda kendi IP'ni ekleyemezsin; ekleyebilseydin bile yönlendirdiğin her gönderen alan adı için aynısını yapman gerekirdi. Yani sorun bir yapılandırma hatası değil, mimarinin doğal sonucudur.

Gmail'in mesajı nasıl değerlendirdiğini Authentication-Results başlığında görebilirsin:

Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of [email protected] does not designate
           185.12.34.56 as permitted sender) [email protected];
       dkim=pass [email protected];
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=ornek.com

Bu örnekte SPF düşmüş ama DKIM ayakta kaldığı için DMARC geçmiş. Mesaj teslim edilir. İşte yönlendirmenin hayatta kalmasını sağlayan mekanizma budur ve bir sonraki bölümün konusu.

DKIM Neden Yönlendirmeden Sağ Çıkar, Ne Zaman Çıkmaz#

DKIM, SPF'ten tamamen farklı bir mantıkla çalışır: bağlanan IP'yi hiç umursamaz. Gönderen sunucu, mesajın belirli başlıklarını ve gövdesini kendi özel anahtarıyla imzalar; alıcı da bu imzayı DNS'teki genel anahtarla doğrular. Mesaj kaç sunucudan geçerse geçsin, içeriği değişmediği sürece imza geçerli kalır.

Sorun şu ki pek çok yönlendirme yolu mesajı sessizce değiştirir. İmzayı bozan tipik müdahaleler:

Yönlendirme yaparken mesajı hiç değiştirmiyorsan DKIM sağ kalır ve DMARC bu sayede geçer. Ama gövdeye tek bir satır alt bilgi eklediğin anda hem SPF hem DKIM düşer; p=reject politikası olan bir alan adından gelen mesaj artık reddedilir. Yönlendirmenin panel tarafındaki kurulumu ve kısıtları için cPanel e-posta iletme yazısına bakabilirsin.

DMARC Hizalaması: Asıl Karar Mercii#

DMARC, SPF ve DKIM sonuçlarını tek bir karara indirir ama bunu yaparken hizalama (alignment) şartı koyar. Hizalama, doğrulanan alan adının kullanıcının gördüğü From: alan adıyla eşleşmesi demektir. DMARC'ın geçmesi için şunlardan en az biri gerekir: hizalı bir SPF geçişi veya hizalı bir DKIM geçişi.

Yönlendirilmiş bir mesajda SPF hemen hemen her zaman düşer, dolayısıyla DMARC'ın tek dayanağı DKIM olur. Denklem bu kadar basit:

1. DKIM sağlam → DMARC geçer → mesaj teslim edilir.
2. DKIM kırık ve gönderen p=none kullanıyor → mesaj muhtemelen teslim edilir ama raporlara "fail" olarak düşer.
3. DKIM kırık ve gönderen p=quarantine kullanıyor → mesaj spam klasörüne gider.
4. DKIM kırık ve gönderen p=reject kullanıyor → mesaj reddedilir, gönderen bounce alır.

Burada kritik ve çok yanlış bilinen bir ayrıntı var: SRS, SPF'i geçirir ama DMARC'ı hizalamaz. SRS zarf gönderenini senin alan adına çevirdiği için SPF firmaniz.com üzerinden geçer, ancak From: başlığı hâlâ ornek.com olduğundan hizalama sağlanmaz. Yani SRS'in görevi DMARC'ı kurtarmak değil, sert SPF reddini ve bounce yönetimi sorunlarını çözmektir. Bu ayrımın ayrıntısını SRS nedir yazısında ele aldım. Kendi alan adına gelen DMARC raporlarını okumayı öğrenmek istersen DMARC raporu nasıl okunur yazısı iyi bir başlangıç.

Çözümler ve Hangisinin Ne Zaman İşe Yaradığı#

Yönlendirmeyi tamamen sorunsuz hale getiren tek bir ayar yok; elindeki seçenekler farklı sorunları çözer ve genellikle birden fazlasını birlikte uygulaman gerekir.

1. Mesajı hiç değiştirme. En ucuz ve en etkili adım budur. Yönlendirme yolundan geçen mesajlara alt bilgi ekleme, konu etiketi koyma, bağlantı yeniden yazma. Böylece DKIM sağ kalır ve DMARC geçer. Postfix'te yönlendirmeyi basit bir alias üzerinden yaparsan mesaj zaten değişmeden aktarılır:

# /etc/postfix/virtual — mesajı olduğu gibi aktarır
[email protected]    [email protected]

2. SRS uygula. Zarf gönderenini kendi alan adına çevirir. Bu, SPF'i sert reddeden alıcıların mesajı kapıda kesmesini önler ve teslim edilemeyen mesajların bounce'unu senin sunucuna getirir. DMARC hizalamasını çözmez.

3. ARC uygula. ARC (Authenticated Received Chain), ilk teslimattaki doğrulama sonuçlarını mühürleyerek zincire ekler. Alıcı, ARC zincirine güveniyorsa "bu mesaj sana ulaşmadan önce SPF ve DKIM geçmişti" bilgisini dikkate alabilir. Büyük sağlayıcılar bunu değerlendiriyor, ancak ARC bir garanti değil, güvenilirlik sinyalidir.

4. Yönlendirme yerine çekme. En sağlam çözüm, mesajı itmek yerine çekmektir. Gmail'in "diğer hesaplardan posta al" özelliği ya da bir istemcinin ikinci IMAP hesabı olarak eklenmesi, aradaki SMTP hopunu tamamen ortadan kaldırır — dolayısıyla SPF de DKIM de hiç sorgulanmaz. Uzun vadede kalıcı bir yönlendirme kuruyorsan bu yöntemi tercih et.

5. From başlığını yeniden yaz. E-posta listelerinin yaptığı budur: From: başlığı senin alan adına çevrilir, orijinal gönderen Reply-To içine taşınır. DMARC tamamen çözülür ama kullanıcı deneyimi bozulur; kurumsal yönlendirmelerde nadiren tercih edilir.

Sık Yapılan Hatalar ve Tuzaklar#

SPF kaydına yönlendirilen alan adlarını eklemeye çalışmak. Kendi SPF kaydına include:gmail.com gibi satırlar eklemek hiçbir işe yaramaz; SPF, MAIL FROM içindeki alan adının kaydına bakar, seninkine değil. Üstelik SPF'in 10 DNS sorgusu sınırı vardır ve gereksiz include satırları kaydı tamamen geçersiz kılabilir.

Yönlendirme yaparken alt bilgi eklemek. "Bu mesaj otomatik olarak yönlendirilmiştir" satırı iyi niyetlidir ama DKIM imzasını kırar ve mesajı reddedilebilir hale getirir. Ek bilgi vermek istiyorsan gövdeye değil, yeni bir başlığa yaz.

Catch-all adresi topluca dışarı yönlendirmek. Yakalanan her adresi Gmail'e yönlendirdiğinde spam'i de yönlendirmiş olursun. Gmail bu trafiği senin IP'nden geliyor kabul eder ve sunucunun itibarı düşer. Sonuç: yalnızca yönlendirmeler değil, normal giden mesajların da spam'e düşmeye başlar.

Bounce yönetimini düşünmemek. SRS kullanmadan yönlendirme yaptığında ve hedef mesajı reddettiğinde, bounce orijinal gönderene gider — yani başkasının alan adına. Bu, sunucunun geri saçılma (backscatter) kaynağı olarak işaretlenmesine yol açabilir.

Sorunun kaynağını yanlış yerde aramak. Yönlendirilen mesajlar spam'e düşüyorsa ve sen kendi DKIM ile SPF kayıtlarını kontrol edip "her şey doğru" diyorsan, doğru yere bakmıyorsun demektir. Kontrol etmen gereken şey, hedef tarafın Authentication-Results başlığında ne yazdığıdır. Büyük sağlayıcıların güncel gönderici kurallarının bu tabloyu nasıl sıkılaştırdığını Gmail ve Yahoo yeni gönderici kuralları yazısında bulabilirsin.

Sıkça Sorulan Sorular#

Yönlendirme yaparken SPF'i tamamen düzeltmenin bir yolu var mı#

Zarf gönderenini değiştirmeden SPF'i geçirmenin bir yolu yok; çünkü SPF tanımı gereği bağlanan IP ile zarf alan adını eşleştirir ve sen üçüncü bir tarafın alan adına yetki ekleyemezsin. SRS ile zarf gönderenini kendi alan adına çevirerek SPF'i geçirebilirsin ama bu sefer DMARC hizalaması sağlanmaz. Pratikte doğru hedef SPF'i kurtarmak değil, DKIM'i bozmadan aktarmaktır.

Yönlendirilen mesajlar neden bazen gidiyor bazen gitmiyor#

Çünkü sonuç, gönderen alan adının DMARC politikasına bağlı olarak değişir. p=none kullanan bir alan adından gelen mesaj SPF düşse bile teslim edilir; p=reject kullanan bir alan adından gelen aynı mesaj DKIM de kırıksa reddedilir. Aynı yönlendirme kuralı, farklı göndericiler için farklı sonuçlar verir ve bu da sorunu rastgele görünmeye iter.

cPanel üzerinden yaptığım yönlendirme SPF'i bozar mı#

Evet, mekanizma aynıdır; panelden kurulan yönlendirme de mesajı senin sunucundan yeniden gönderir ve alıcı SPF kontrolünü senin IP'n üzerinden yapar. cPanel yönlendirmesi mesaj gövdesine dokunmadığı için DKIM genellikle sağ kalır ve DMARC geçer. Yine de hedefte Authentication-Results başlığını okuyarak doğrulamanı öneririm.

SRS kurarsam sorun tamamen çözülür mü#

Hayır, SRS sorunun yalnızca bir bölümünü çözer. SPF kontrolünü geçirir, sert -all politikası olan alan adlarından gelen mesajların kapıda kesilmesini önler ve bounce mesajlarının doğru yere dönmesini sağlar. Ancak From: başlığı değişmediği için DMARC hizalaması hâlâ DKIM'e bağlıdır; DKIM kırıksa DMARC yine düşer.

Yönlendirme yerine ne kullanmalıyım#

Kalıcı bir aktarım kuruyorsan yönlendirme yerine çekme yöntemini tercih et: hedef hesabı, kaynak kutuya IMAP ile bağla. Böylece mesaj hiçbir zaman ikinci kez SMTP üzerinden gönderilmez ve SPF ile DKIM devreye girmez. Ekip içi paylaşım gerekiyorsa ortak bir kutu ya da dağıtım listesi, yönlendirmeden hem daha güvenilir hem de daha yönetilebilir bir çözümdür.

Yönlendirmenin çalışıp çalışmadığını nasıl kontrol ederim#

En doğrudan yöntem, hedef kutudaki mesajın tam başlıklarını açıp Authentication-Results satırını okumaktır; orada spf, dkim ve dmarc sonuçlarını tek tek görürsün. Sunucu tarafında ise mail loglarında mesajın kuyruk kimliğini takip ederek teslimatın kabul mi edildiğini yoksa hata mı aldığını görebilirsin. Test için kendi kontrolündeki iki farklı sağlayıcı hesabı arasında deneme mesajı göndermek en temiz yaklaşımdır.

Kapanış#

Yönlendirmenin SPF'i bozması bir hata değil, SPF'in tasarımının doğal sonucudur — ve bunu kabul ettiğinde çözüm de netleşir. Aklında tutman gereken dört şey var: SPF zarf göndereni kontrol eder, From: başlığını değil; yönlendirmede SPF kaçınılmaz olarak düşer, o yüzden hedefin DKIM'i sağ tutmaktır; mesaj gövdesine alt bilgi, konuya etiket ekleyen her müdahale DKIM'i kırar; ve SRS SPF'i geçirir ama DMARC'ı hizalamaz. Kalıcı aktarımlarda yönlendirme yerine IMAP ile çekmeyi tercih et.

Yönlendirme ve kimlik doğrulama katmanını kendin kurmak yerine hazır çalışan bir yapı istiyorsan kurumsal e-posta çözümlerimizde SPF, DKIM ve DMARC kayıtları kurulumda tanımlanır. Kendi mail sunucunu işletiyor ve SRS ile DKIM tarafını doğru kurmak istiyorsan SMTP sunucu paketlerimiz bu yapılandırmayla teslim edilir; toplu gönderim yapıyorsan itibar yönetimi için e-posta pazarlama tarafına da bakmanı öneririm.