Hotmail ve Outlook.com'a Mail Gitmiyor: SNDS, JMRP ve Delist Başvurusu

Sunucunuzun kara liste durumunu kontrol ediyorsunuz: Spamhaus temiz, Barracuda temiz, SORBS temiz, sorguladığınız on beş RBL'in hepsi yeşil. SPF geçiyor, DKIM imzası doğrulanıyor, DMARC hizalı, PTR kaydı düzgün. Gmail'e attığınız test maili anında geliyor. Sonra bir müşteriye @hotmail.com adresine teklif gönderiyorsunuz ve saniyeler içinde geri dönüyor: 550 5.7.1 Unfortunately, messages from 185.x.x.x weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150).

Bu tablo şaşırtıcı değil, beklenen bir şey. Microsoft dış kara listelere bakmaz; kendi kapalı devre itibar sistemini işletir. Bir IP'nin Spamhaus'ta temiz olması Microsoft'un o IP'yi kabul edeceği anlamına gelmez, çünkü Microsoft kararını kendi kullanıcılarının "önemsiz" düğmesine basma oranı, kendi spam tuzaklarına düşen mesaj sayısı ve kendi SmartScreen filtresinin sınıflandırması üzerinden verir. Dolayısıyla kara liste sorgulama ve listeden çıkma yazısındaki yolların hiçbiri burada işlemez — çıkacağınız bir liste yoktur, ikna etmeniz gereken bir şirket vardır.

Bu yazıda önce ret mesajını doğru okumayı ele alacağız, çünkü Microsoft'un iki ayrı ve birbirine karışan sistemi var: tüketici tarafı (Hotmail, Outlook.com, Live, MSN) ve kurumsal taraf (Microsoft 365 / Exchange Online). Türkiye'de kurumsal alıcıların büyük kısmı ikincisini kullanıyor ve iki tarafın kodları da, başvuru kanalları da tamamen farklı. Sonra Microsoft'a özgü üç aracı kuracağız: SNDS kaydı, JMRP geri bildirim döngüsü ve delist başvurusu — başvuruda ne yazarsanız reddedileceği dahil.

Önce Hangi Microsoft'a Gönderdiğinizi Belirleyin#

Yaptığınız ilk iş, alıcı alan adının MX kaydına bakmak olmalı. Microsoft aynı marka altında iki ayrı filtre altyapısı çalıştırır ve hangisiyle konuştuğunuzu MX kaydının son eki söyler.

# Tüketici tarafı mı, kurumsal taraf mı?
dig +short MX hotmail.com
dig +short MX musterinin-firmasi.com.tr

# Kendi IP'nizin ters kaydını da doğrulayın
dig +short -x 185.0.113.25

Çıktıyı şu tabloyla eşleştirin:

Ayrım önemsiz görünebilir ama pratikte tüm çözüm yolunu değiştirir. SNDS ve JMRP yalnızca tüketici tarafını besler; kurumsal tarafta engellendiyseniz SNDS'ye kaydolmak hiçbir işe yaramaz. Tersine, tüketici tarafında engellenmişken kurumsal delist portalına başvurmak da sonuç vermez — form IP'yi bulamaz ve "engellenmiş görünmüyor" der. Türkiye'deki tipik senaryoda ikisi birden yaşanır: aynı IP hem @hotmail.com adreslerine hem de Exchange Online kullanan kurumsal alıcılara gidemez hâle gelir, ama iki ayrı başvuru gerekir.

Outlook.com Ret Kodlarını Okuma: S3140, S3150 ve 5.7.515#

Tüketici tarafındaki S kodlarının tam listesi Microsoft tarafından yayımlanmaz; bu yüzden kodu ezberlemek yerine yanındaki metni okumak daha güvenilirdir. Yine de sahada karşınıza çıkacakların ezici çoğunluğu şu üç davranıştan birine düşer.

Aradaki fark, harcayacağınız zamanı belirler:

• S3140 komşuluk sorunudur. Aynı /24 bloğundaki başka bir müşteri spam göndermiş, Microsoft aralığı toptan kısıtlamıştır. Kendi sunucunuzda düzeltecek bir şey olmayabilir; başvuruyu IP aralığının sahibi (sağlayıcınız) yapmalıdır. Paylaşımlı hostingteyseniz doğru hamle destek kaydı açmaktır, delist formunu tek başınıza doldurmak değil.
• S3150 doğrudan sizin IP'nizle ilgilidir ve neredeyse her zaman bir davranış izi vardır: bir hesabın şifresi ele geçirilmiş, bir PHP formu kötüye kullanılmış, ya da izinsiz bir listeye toplu gönderim yapılmıştır. Sebebi bulmadan başvuru yaparsanız ya reddedilir ya da birkaç gün içinde geri listelenirsiniz.
• 5.7.515 itibarla ilgili değildir; kimlik doğrulama başarısızlığıdır. Burada SNDS, JMRP ve delist tamamen konu dışıdır — düzelteceğiniz şey DNS kayıtlarınızdır. Microsoft, DMARC politikası reject olan bir alan adından gelen ama hizalanmayan mesajı doğrudan reddeder. SPF, DKIM ve DMARC kayıtlarının kurulumu bu kodun tek çözümüdür.

Ret satırını bulmanın en hızlı yolu geri dönen mesajın ham hâlini açmaktır; sunucuya erişiminiz varsa doğrudan kayıtlardan da okuyabilirsiniz:

# Postfix: son 500 satırda Microsoft retlerini süz
grep -E 'olc\.protection|S31[0-9]{2}|5\.7\.515' /var/log/mail.log | tail -50

# Exim (cPanel sunucuları)
grep -E 'olc\.protection|S31[0-9]{2}' /var/log/exim_mainlog | tail -50

# Hangi alan adlarına kaç ret aldık?
awk '/olc\.protection/ {print $NF}' /var/log/mail.log | sort | uniq -c | sort -rn | head

Geri dönen mesajın yapısını ve 4.x.x ile 5.x.x arasındaki farkı hatırlamak isterseniz bounce mesajlarını okuma ve SMTP hata kodlarının anlamları yazıları bu yazının ön adımıdır.

Microsoft 365 Tarafı: 5.7.606, 5.7.708 ve 5.7.511#

Alıcı bir kurumsal alan adıysa ve MX'i mail.protection.outlook.com ile bitiyorsa Exchange Online Protection ile konuşuyorsunuz demektir. Buradaki kodlar sayısaldır ve her birinin farklı bir çözüm kanalı vardır — en sık yapılan hata, hepsi için aynı delist portalını denemektir.

5.7.606 kodunda delist portalına gidersiniz, engellenen IP'yi ve bir iletişim adresi girersiniz, adrese gelen doğrulama bağlantısına tıklarsınız ve talep genellikle 30 dakika ile birkaç saat içinde işlenir. 5.7.708 ise "düşük itibarlı IP" anlamına gelir ve portal bu kaydı görmez; burada alıcı kurumun Microsoft 365 yöneticisinin destek kaydı açması ya da sizi kendi izin listesine (allow list) eklemesi gerekir. Pratikte kurumsal müşterinizin BT sorumlusuna bir cümlelik açıklama göndermek, portalda saatlerce uğraşmaktan çok daha hızlı sonuç verir.

451 4.7.500 geçici bir koddur ve 4 ile başladığı için sunucunuz mesajı zaten kuyrukta tutup tekrar deneyecektir. Bunu kalıcı bir engel sanıp başvuru yapmak yaygın bir zaman kaybıdır; asıl yapılması gereken, Microsoft'a giden eş zamanlı bağlantı sayısını düşürmektir.

# Postfix: Microsoft hedefleri için ayrı bir taşıma tanımlayıp yavaşlatın
# /etc/postfix/main.cf
transport_maps = hash:/etc/postfix/transport

# /etc/postfix/transport
hotmail.com      msmtp:
outlook.com      msmtp:
live.com         msmtp:

# /etc/postfix/master.cf içine yeni taşıma
# msmtp    unix  -  -  n  -  5  smtp

# main.cf içinde bu taşımaya özel hız sınırı
msmtp_destination_concurrency_limit = 2
msmtp_destination_rate_delay = 2s

Bu ayar, aynı anda en fazla iki bağlantı açıp mesajlar arasına iki saniye koyar. Yeni bir IP ile gönderime başlarken ya da bir engelden yeni çıkmışken Microsoft'un hız kısıtlamasına takılmamanın en pratik yoludur.

SNDS Kaydı: IP Sahipliği Doğrulaması Nasıl Yapılır?#

Smart Network Data Services (SNDS), Microsoft'un size kendi gözünden nasıl göründüğünüzü gösterdiği tek penceredir. Ücretsizdir ve sendersupport.olc.protection.outlook.com üzerinden erişilir. Kayıt sırasında bir Microsoft hesabıyla oturum açar, izlemek istediğiniz IP'yi ya da IP aralığını eklersiniz.

Kritik nokta doğrulama adımıdır: Microsoft, o IP üzerinde gerçekten yetkiniz olduğunu kanıtlamanızı ister. Bunu IP bloğunun WHOIS kaydındaki abuse@ veya teknik iletişim adresine ya da IP'nin ters DNS kaydındaki alan adının postmaster@ / abuse@ adresine otomatik bir doğrulama e-postası göndererek yapar. Doğrulama bağlantısına tıklandığı anda kayıt açılır.

Bu mekanizma, paylaşımlı hostingteki durumu doğrudan belirler:

1. IP'niz size ait (VDS, dedicated, kendi IP bloğunuz): Doğrulama e-postası ya WHOIS'teki adrese ya da rDNS'inizdeki alan adına gider. [email protected] adresinin gerçekten var olduğundan ve okunduğundan emin olun; bu adres yoksa doğrulama sessizce başarısız olur ve neden kaydolamadığınızı anlamazsınız.
2. Paylaşımlı hostingtesiniz: IP sağlayıcıya aittir, WHOIS kaydı sağlayıcının adınadır, doğrulama e-postası da sağlayıcıya gider. Kendi başınıza SNDS kaydı açamazsınız. Yapılacak şey, sağlayıcıdan o IP için SNDS kaydını açmasını ve verileri sizinle paylaşmasını istemektir. Ciddi sağlayıcıların çoğunda bu kayıt zaten açıktır.
3. Aralık ekleme: Tek IP yerine /29, /24 gibi bir aralık eklerseniz komşularınızın davranışını da görürsünüz. S3140 aldıysanız bu, sorunun sizden mi komşudan mı geldiğini kanıtlayan tek veridir.

Kayıt açıldıktan sonra verilere bir otomatik erişim anahtarı da üretebilirsiniz; bu, izlemeyi kendi sisteminize bağlamanızı sağlar:

# SNDS otomatik veri erişimi (anahtarı SNDS arayüzünden üretirsiniz)
curl -s "https://postmaster.live.com/snds/data.aspx?key=SIZIN_ANAHTARINIZ" -o snds.csv

# Kırmızı filtre sonucu veya sıfırdan büyük trap hit var mı?
awk -F, 'tolower($0) ~ /red/ || $8+0 > 0 {print}' snds.csv

SNDS Verisini Okumak: Filtre Rengi, Şikâyet Oranı ve Trap Hit#

SNDS ekranı ilk bakışta kalabalık görünür ama karar vermenizi sağlayan üç sütun vardır.

Renk kodu üç bantlıdır: yeşil trafiğinizin %10'undan azının spam sayıldığını, sarı %10–90 arasını, kırmızı ise %90'ın üzerinde spam sınıflandırması yapıldığını gösterir. Kırmızıya düşmüş bir IP'yle delist başvurusu yapmanın anlamı yoktur; başvuru reddedilir çünkü Microsoft ekranında hâlâ kötü davranışı görüyordur.

En değerli sütun trap hits'tir. Sıfırdan büyük her değer, kimsenin kaydolmadığı bir adrese mail gönderdiğinizi söyler ve bunun tek bir açıklaması vardır: satın alınmış, kazınmış ya da yıllardır temizlenmemiş bir liste. Şikâyet oranı yükseldiyse mesele farklıdır — insanlar gerçekten mailinizi alıyor ama istemiyor demektir; bu, maillerin spama düşmesi sorununun aynısıdır ve içerik/izin tarafında çözülür.

RCPT commands sütununu da göz ardı etmeyin. Kendi trafiğinizden belirgin biçimde yüksekse sunucunuzdan sizin haberiniz olmadan gönderim yapılıyor demektir; bu durumda önce kaynağı kapatmalısınız.

JMRP: Şikâyet Geri Bildirim Döngüsüne Abone Olma#

Junk Mail Reporting Program (JMRP), bir Outlook.com kullanıcısı mailinizi "önemsiz" olarak işaretlediğinde o mesajın bir kopyasını size gönderen geri bildirim döngüsüdür. Değeri şuradan gelir: şikâyet oranınız yükseldiğinde hangi kampanyanın, hangi listenin, hangi gönderen adresinin şikâyet ürettiğini tahmin etmek zorunda kalmazsınız; elinize somut mesaj gelir.

Kurulum sırası önemlidir çünkü JMRP artık SNDS hesabına bağlı çalışır: önce IP'lerinizi SNDS'de kaydettirip doğrulamanız, sonra aynı Microsoft hesabıyla JMRP'ye abone olmanız gerekir. Abonelik sırasında şikâyet kopyalarının gönderileceği bir adres tanımlarsınız.

Bu adresi seçerken üç kurala uyun:

1. Gerçek bir posta kutusu olsun, gönderim yaptığınız alan adında olmasın. [email protected] mantıklı görünür ama bu kutu doluysa ya da spam filtresine takılırsa geri bildirim sessizce kaybolur. Ayrı bir alan adında ya da farklı bir sağlayıcıda tutmak daha sağlamdır.
2. Otomatik işlensin. Gelen her JMRP mesajı bir abonelikten çıkarma işlemi tetiklemeli; elle takip edilen bir kutu birkaç hafta içinde okunmaz hâle gelir.
3. Tek adrese toplayın. Aynı sunucudan farklı alan adları gönderim yapıyorsa hepsini tek JMRP adresine yönlendirin; şikâyet oranını IP bazında göreceksiniz zaten.

JMRP'nin sınırını da bilin: yalnızca tüketici Outlook.com/Hotmail kullanıcılarının şikâyetlerini kapsar. Microsoft 365 kullanan kurumsal alıcıların "önemsiz" işaretlemeleri size ulaşmaz, kendi kiracılarında kalır. Bu yüzden kurumsal tarafta itibar sorunu yaşadığınızda elinizde JMRP verisi olmayacaktır.

Delist Başvurusu: Formu Nasıl Doldurmalı, Neden Reddediliyor#

Tüketici tarafındaki engel için başvuru, sendersupport.olc.protection.outlook.com altındaki Sender Support formuyla yapılır. Form kısa görünür ama reddedilen başvuruların büyük kısmı aynı üç hatadan kaynaklanır.

Başvurmadan önce mutlaka yapılması gerekenler:

1. Sebebi bulun ve kapatın. Kuyrukta bekleyen anormal mail var mı, hangi hesap gönderiyor?
2. Kuyruğu temizleyin. Engelli hâlde kuyrukta biriken binlerce mesaj, engel kalkar kalkmaz aynı anda Microsoft'a gider ve sizi anında geri listeler.
3. rDNS, SPF, DKIM üçlüsünü doğrulayın. Eksik PTR kaydı tek başına başvurunun reddi için yeterlidir.

# Kuyrukta ne var? (Postfix)
mailq | tail -1
qshape deferred | head -20

# Belirli bir gönderene ait mesajları kuyruktan temizle
mailq | awk '/^[A-F0-9]/ && /supheli@alanadiniz\.com/ {print $1}' | tr -d '*!' | postsuper -d -

# Exim (cPanel)
exim -bpc
exiqgrep -f 'supheli@alanadiniz\.com' -i | xargs -r exim -Mrm

Form metninde ne yazmalı? Microsoft'un burada okuduğu şey bir özür değil, bir kök neden analizidir. Şu üç bilgi olmadan başvurunuz otomatik reddedilir: sorunun ne olduğu, nasıl tespit edildiği ve tekrar etmemesi için ne değiştirildiği. Üç cümlelik somut bir metin, üç paragraflık genel bir açıklamadan daha etkilidir.

Neden reddedilir? Sahada en sık görülen gerekçeler:

Başvuru sonucu genelde 24–48 saat içinde e-postayla gelir. Aynı IP için üst üste tekrar başvurmayın; Microsoft tekrarlanan talepleri birleştirir ve bekleme süresi uzar.

Engel Kalktıktan Sonra Aynı Yere Geri Düşmemek#

Delist onayı bir sonuç değil, bir fırsat penceresidir. Microsoft engeli kaldırdığında IP'nizin itibar geçmişi sıfırlanmaz; sadece kapı yeniden aralanır. İlk günlerde yapacağınız hacim, kapının açık kalıp kalmayacağını belirler.

Uygulanacak sıra:

1. Hacmi kademelendirin. İlk gün yalnızca işlem mailleri (şifre sıfırlama, sipariş bildirimi), üçüncü günden itibaren kademeli artış. Pazarlama gönderimini en az bir hafta bekletin.
2. SNDS'yi günlük kontrol edin. Filtre rengi sarıya dönerse hacmi hemen geri çekin; kırmızıya inmesini beklemeyin.
3. JMRP mesajlarını otomatik işleyin. Şikâyet eden adresi 24 saat içinde listeden çıkarın.
4. Sert bounce'ları temizleyin. 5.1.1 alan adresleri listenizden silin; tuzak isabetinin en yaygın kaynağı ölü adreslerdir.
5. Giden gönderimi tek noktadan çıkarın. Sunucudaki her PHP betiğinin doğrudan mail göndermesine izin vermek yerine kimlik doğrulamalı SMTP zorunlu kılın; böylece ele geçirilen bir form tüm IP'yi yakamaz.
6. Ayrı IP kullanın. İşlem mailleri ile pazarlama gönderimini aynı IP'den yapıyorsanız, bir kampanya şikâyeti şifre sıfırlama maillerinizi de düşürür.

Gmail tarafında da benzer bir itibar mantığı işler ama araçlar ve eşikler farklıdır; iki tarafı birlikte yönetiyorsanız Gmail'e mail gitmiyor yazısındaki Postmaster Tools adımlarını bu yazıdaki SNDS adımlarının yanına koyun. İkisi birbirinin yerine geçmez: bir sağlayıcıda temiz görünmek, diğerinde hiçbir şey ifade etmez.

Sıkça Sorulan Sorular#

Spamhaus'ta temiz olduğum hâlde Hotmail neden engelliyor?#

Microsoft dış kara listeleri karar mekanizması olarak kullanmaz. Kendi kullanıcılarının "önemsiz" işaretleme oranı, kendi spam tuzaklarına düşen mesaj sayısı ve SmartScreen filtresinin sınıflandırması üzerinden bağımsız bir itibar puanı tutar. Bu yüzden bir IP tüm RBL'lerde temizken Outlook.com tarafından engellenebilir. Çözüm de RBL'lerden çıkmak değil, Microsoft'un kendi kanallarından geçer: SNDS ile veriyi görmek ve Sender Support formuyla başvurmak.

SNDS kaydını paylaşımlı hostingte kendim açabilir miyim?#

Hayır. Microsoft, IP üzerindeki yetkinizi WHOIS kaydındaki iletişim adresine veya ters DNS kaydınızdaki alan adının postmaster adresine gönderdiği doğrulama e-postasıyla kontrol eder. Paylaşımlı hostingte IP sağlayıcıya aittir, dolayısıyla doğrulama e-postası da sağlayıcıya ulaşır. Yapılması gereken, sağlayıcınızdan o IP için SNDS kaydını açmasını ve filtre rengi ile şikâyet oranı verisini sizinle paylaşmasını istemektir.

S3140 ile S3150 arasındaki fark nedir?#

S3140, IP'nizin içinde bulunduğu ağ bloğunun toptan kısıtlandığını söyler; suçlu çoğu zaman komşu bir IP'dir ve başvuruyu bloğun sahibi yapmalıdır. S3150 ise doğrudan sizin IP'nizin engellendiğini gösterir ve neredeyse her zaman sunucunuzda bulunabilecek bir sebep vardır: ele geçirilmiş hesap, kötüye kullanılan iletişim formu veya izinsiz toplu gönderim. İkisi farklı sahibi olan sorunlardır, bu yüzden çözüm yolları da ayrışır.

Delist başvurum kaç kez reddedilirse ne yapmalıyım?#

Aynı IP için üst üste başvuru yapmayın; Microsoft tekrarlanan talepleri birleştirir ve inceleme süresi uzar. İki ret sonrasında başvuruyu bırakıp iki hafta boyunca IP'yi neredeyse hiç kullanmadan bekletmek, SNDS verisinin doğal olarak düzelmesini sağlar. Bu sürede kök nedeni belgeleyin: hangi hesap, hangi tarih, hangi önlem. Üçüncü başvuruda bu somut zincir genellikle sonuç verir.

Microsoft 365 kullanan kurumsal alıcıya mail gitmiyorsa SNDS işe yarar mı?#

Hayır. SNDS ve JMRP yalnızca tüketici tarafını (Hotmail, Outlook.com, Live, MSN) kapsar. Alıcının MX kaydı mail.protection.outlook.com ile bitiyorsa Exchange Online Protection ile karşı karşıyasınız demektir ve orada 5.7.606 için delist portalı, 5.7.708 için Microsoft 365 destek kaydı gerekir. En hızlı yol genellikle alıcı kurumun BT sorumlusundan sizi izin listesine eklemesini istemektir.

PTR kaydı olmadan delist başvurusu onaylanır mı?#

Pratikte onaylanmaz. Ters DNS kaydı, Microsoft'un gönderici sunucuyu tanımlamak için baktığı ilk şeydir ve eksikliği tek başına ret sebebidir. Başvurudan önce dig -x IP_ADRESINIZ komutunun gönderim yaptığınız hostname'i döndürdüğünü, o hostname'in de aynı IP'ye çözümlendiğini (ileri-geri tutarlılık) doğrulayın. PTR kaydı IP bloğunun sahibinde olduğu için bu değişikliği sağlayıcınız yapar.