Bu sayfadaOutlook.com ve Mayıs 2025 kuralları
- Outlook.com ve Mayıs 2025 kuralları
- Geri dönme kodu size ne söylüyor
- Üçüncü taraf göndericiler ve SPF gereksinimi
- Microsoft 365 başka birinin politikasına göre filtrelenir
- Başlıklardaki sonucu okuma
- SNDS ve JMRP, artık Postmaster sitesinde
- Karşı taraftaki kişinin değiştirebilecekleri
- Gerçek gönderimden önce test
"Outlook" üç farklı filtre anlamına gelir ve çözüm, e-postanızı hangisinin Önemsiz klasörüne taşıdığına bağlıdır. Bunlardan ilki, Microsoft'un bireysel kullanıcılara yönelik e-posta hizmeti Outlook.com'dur. Bu hizmet hotmail.com, live.com ve msn.com adreslerini de kapsar. İkincisi, şirketlerin ücretli olarak kullandığı kurumsal posta kutusu hizmeti Microsoft 365'tir. Burada spam politikasını alıcının şirketindeki bir yönetici belirler. Üçüncüsü ise bir kişinin bilgisayarındaki Outlook uygulamasıdır. Uygulama, sunucunun kararına ek olarak kendi Önemsiz filtresini çalıştırabilir. Microsoft'un 2025'te duyurduğu gönderen kuralları yalnızca bunlardan ilki için geçerlidir.
Bu nedenle tek bir DNS kaydını bile değiştirmeden önce alıcının adresine bakarım. hotmail.com veya outlook.com adresi, aşağıdaki bireysel kullanıcı kurallarının geçerli olduğu anlamına gelir. E-posta sistemini Microsoft üzerinde çalıştıran bir şirkete ait adres için ise o şirketin BT ekibi tarafından yazılmış kiracı politikası geçerlidir.
Outlook.com ve Mayıs 2025 kuralları
Microsoft, Nisan 2025'te tüketici hizmetine günde 5.000'den fazla e-posta gönderen alan adları için gereksinimleri duyurdu. Postmaster politikaları sayfası, bu gereksinimlerin 5 Mayıs 2025'te yürürlüğe girdiğini belirtiyor. Bu hacmin üzerinde:
- SPF, gönderen alan adı için doğrulamadan geçmelidir.
- DKIM doğrulamadan geçmelidir.
- DMARC, "en az p=none" ilkesiyle yayımlanmalı ve SPF veya DKIM ile, "tercihen her ikisiyle", uyumlu olmalıdır. Politikalar sayfası ayrıca
p=rejectkullanılmasını öneriyor.
Geri dönen iletiyle ilgili destek makalesi bunu biraz farklı ifade ediyor. From adresinde aynı alan adını kullanan ve Microsoft tüketici hizmetlerine gönderilen 5.000 veya daha fazla iletiyi hesaba katıyor, hem SPF hem de DKIM kontrollerinin başarılı olması gerektiğini söylüyor. Bir alan adı bu noktaya ulaştığında Microsoft, yalnızca sınırın aşılmasına neden olan bültenin değil, "alan adındaki gönderenlerden gelen tüm iletilerin" kurallara uymasını bekliyor. Verdiği DMARC örneği, bir kaydın olabileceği kadar kısa:
Hostname: _dmarc
TXT value: v=DMARC1; p=noneBen buna, rua=mailto:dmarc@example.com gibi bir raporlama adresi veya e-postaları gerçekten okuduğunuz başka bir adres eklerdim. Outlook.com toplu raporlar gönderiyor. Microsoft'un SSS sayfasına göre RUA gönderiyor ve RUF gönderme planı bulunmuyor. DMARC denetleyicisi, belirttiğiniz adresin bu raporları kabul edip edemediğini gösterir.
Google, Şubat 2024'te Gmail için de günlük 5.000 sınırını belirledi ve Kasım 2025'te, reddetmeler dahil olmak üzere yaptırımları kademeli olarak artırmaya başladı. Yahoo, herhangi bir eşik belirtmeden benzer bir gereksinim listesini uyguluyor.
Duyuru henüz yeniyken kuralın uygulanma biçimi değişti. İlk gönderide, kurallara uymayan e-postaların önce Junk klasörüne gideceği ve daha sonra reddedilebileceği belirtiliyordu. 29 Nisan tarihli güncellemede Microsoft'un bunun yerine e-postaları reddetmeye karar verdiği yazıyor, ancak aynı gönderinin alt kısmında önce Junk klasörüne gönderileceğini belirten eski paragraf hâlâ yer alıyor. Bugün için temkinli yorum şu: 5 Mayıs 2025'ten bu yana kurallara uymayan e-postalar Junk klasörüne gidiyor ve Outlook.com artık bunları şu iletiyle de reddediyor:
550 5.7.515 Access denied, sending domain example.com does not meet the required authentication level.
Reddetmeye geçiş için yayımlanmış bir tarih bulamadım. Destek makalesi bunu yalnızca şimdiki zaman kullanarak açıklıyor.
Geri dönme kodu size ne söylüyor
Outlook.com'dan gelen bir geri dönme bildirimi, Gereksiz klasöründe sessizce duran bir iletiden daha faydalıdır çünkü nedeni belirtir. Microsoft'un sorun giderme sayfasında kodları içeren bir tablo vardır. Sıradan göndericilerin karşılaştığı kodlar şunlardır:
| Kod | Microsoft'a göre anlamı |
|---|---|
550 5.7.515 | Alan adı günde 5.000'den fazla ileti gönderiyor ve SPF, DKIM ve DMARC ile doğrulanmamış |
550 SC-001 | Politika nedeniyle ret, "content with spam-like characteristics or IP/domain reputation" |
550 SC-004 | IP'nizden gelen e-postalarla ilgili şikâyetler sonrasında IP'nize uygulanan engelleme |
421 RP-001 | Yine itibar nedeniyle, bağlanan IP'ye uygulanan hız sınırı |
Microsoft'a özgü kodlardan biri olmadan gelen düz bir 550 5.7.1, başka bir ret türüdür. Bu yanıtı yorumlamak için ayrı bir sayfa vardır.
Üçüncü taraf göndericiler ve SPF gereksinimi
Birçok alan adı aynı anda birden fazla hizmet üzerinden gönderim yapar: bülten platformu, CRM, destek sistemi, faturalandırma. Bunların her biri From satırında sizin alan adınızı kullanarak gönderim yapar ve her birinin kayıtlarınız tarafından kapsanması gerekir. Microsoft'un SSS bölümü, gönderimi sizin adınıza bir sağlayıcı yaptığında kuralların hâlâ geçerli olup olmadığı sorusuna şu yanıtı verir: "Evet. Gönderimi dışarıdan bir hizmete yaptırsanız bile kimlik doğrulama alan adınıza bağlıdır." Destek makalesi neleri doğrulamanız gerektiğini açıklar: DKIM'in sizin alan adınızla imza attığını ve SPF kaydınızın "hizmetin gerektirdiği IP adresini veya include değerlerini içerdiğini" doğrulayın.
Hem SPF hem de DKIM zorunlu olduğunda kafa karışıklığı burada başlar. Birçok platform geri dönüş adresini kendi alan adına koyar ve SPF'nin gerçekte kontrol ettiği adres bu Return-Path'tir. Böylece SPF platform için başarılı olur ve "başarılı olmalı" kısmını karşılar. DMARC hizalamasının ise sizin alan adınızla atılan DKIM imzasından gelmesi gerekir. Platform bunun yerine kendi alan adıyla imza atarsa iki başarılı kontrolden geçersiniz ancak hizalama sağlanmaz. Ardından oluşan DMARC fail, tam olarak 5.7.515'in konusudur. Destek makalesi ayrıca Return-Path alan adının From alan adıyla hizalanıp hizalanmadığını kontrol etmenizi ister.iki başarılı kontrol, sıfır hizalama: 5.7.515'in bütün hikâyesi
SPF'ye eklediğiniz her hizmet ayrıca DNS sorgulama hakkı tüketir. Microsoft'un SSS bölümü bunu şöyle ifade eder: "10 DNS sorgulamasını aşarsanız SPF kontrolünüz başarısız olabilir." SPF denetleyicisi bunları sizin için sayar. Sınırı aşıyorsanız sayısını yeniden onun altına nasıl indireceğinizi burada bulabilirsiniz. DKIM denetleyicisi her platformun seçicisi için ilgili eşleştirme işlemini yapar.
Microsoft 365 başka birinin politikasına göre filtrelenir
Bir Microsoft 365 kuruluşunda, yöneticilerin yapılandırdığı istenmeyen posta önleme politikaları bulunur. Varsayılan olarak spam, yüksek güvenilirlikli spam ve toplu postalar Junk Email klasörüne giderken kimlik avı iletileri karantinaya alınır, yüksek güvenilirlikli kimlik avı iletileri ise her zaman karantinaya alınır. Gönderen açısından en olumsuz sonuç karantinadır, çünkü alıcı özellikle aramadıkça iletiyi hiçbir klasörde bulamaz. Varsayılan politika iletiyi orada 15 gün, Standard ve Strict ön ayarları ise 30 gün tutar.
Toplu postalar için ayrı bir ölçüm kullanılır: toplu şikâyet düzeyi. 1 ile 3 arasındaki BCL, az sayıda şikâyet alan bir toplu göndericiyi, 8 veya 9 ise çok sayıda şikâyet alan bir göndericiyi ifade eder. Varsayılan politika, BCL 7'den itibaren toplu postaları Junk klasörüne gönderir. Standard ön ayarında bu eşik 6, Strict ön ayarında ise 5'tir. Temmuz 2026'dan beri daha yeni bir katman da vardır: tanıtım niteliğindeki toplu postalar, BCL değerinden bağımsız olarak Promotions etiketi alır ve bir yönetici "Bulk moves enabled" seçeneğini açtıysa Promotions klasörüne gider. Bu spam değildir, ancak Inbox da değildir. Özellik hâlâ kademeli olarak kullanıma sunulmaktadır.
Microsoft'un iki sistemi birbirinden tamamen yalıtılmış değildir. Microsoft, Microsoft 365 spam filtrelemesinin "bilinen spam ve kimlik avı tehditlerinden ve tüketici platformumuz Outlook.com'dan gelen kullanıcı geri bildirimlerinden öğrendiğini" belirtiyor. Bu nedenle hotmail.com kullanıcılarının bildirimleri, kurumsal gelen kutularında kullanılan filtreyi de etkiler.
Yöneticiler ayrıca bir göndericiyi izin verilenler listesine ekleyebilir. Bu işlem, kötü amaçlı yazılım ve yüksek güvenilirlikli kimlik avı korumaları dışındaki çoğu korumayı atlar. İş ortağınız faturalarınızı sürekli Junk klasöründe alıyorsa gerçek kararı görebilecek taraf, o şirketin IT ekibidir.
Başlıklardaki sonucu okuma
İletiyi Microsoft 365 posta kutusunun aldığı hâliyle edinebiliyorsanız, istenmeyen posta önleme başlıkları kararı doğrudan belirtir. X-Forefront-Antispam-Report, bilinmesi yararlı birkaç alan içerir:
SFV:SPM, istenmeyen posta filtresinin iletiyi istenmeyen posta olarak işaretlediği;SFV:NSPM, istenmeyen posta olarak işaretlemediği;SFV:SFEise gönderen kullanıcının Güvenilir Gönderenler listesinde olduğu için filtrelemenin atlandığı anlamına gelir.CAT, uygulanan politika kategorisini belirtir:SPM,HSPM(yüksek güvenilirlikli istenmeyen posta),BULK,PHSH,SPOOF.SCL, -1 veya 0 ile 9 arasında bir sayıdır. Eski kılavuzlar bunu sonuç olarak değerlendirir. Microsoft'un güncel SCL sayfası, değerin "istenmeyen posta filtresinin bir iletiyi istenmeyen posta veya yüksek güvenilirlikli istenmeyen posta olarak tanımlayıp tanımlamadığını belirlemediğini" söylüyor. Bu nedenle önceCATalanına bakın.
Başlıklar ayrıca Microsoft'un SPF, DKIM, DMARC ve iletinin diğer bölümlerinden oluşturduğu bileşik sonuç olan compauth alanını da içerir. 001 neden kodu, örtük kimlik doğrulamanın başarısız olduğu anlamına gelir. Bunun tipik nedeni, gönderen etki alanında yayımlanmış kimlik doğrulama kayıtlarının bulunmaması veya yalnızca zayıf bir politikanın bulunmasıdır.
SNDS ve JMRP, artık Postmaster sitesinde
Smart Network Data Services, yani SNDS, artık yeni Postmaster sitesinde yer alıyor ve sendersupport.olc.protection.outlook.com adresindeki eski sitenin yerini alıyor. Raporları IP adresi bazında sunduğu için size herhangi bir veri göstermeden önce bir IP aralığının sahibi olduğunuzu kanıtlamanız gerekir. Veriler; hacmi, şikayet oranlarını ve filtrenin trafiğinizin ne kadarını spam olarak değerlendirdiğini gösteren bir rengi kapsar: %10'un altında yeşil, %10 ile %90 arasında sarı, %90'ın üzerinde kırmızı. Erişim artık onay veya geçişten 10 ay sonra sona eriyor ve yenilenmesi gerekiyor.
Küçük bir göndericiyseniz SNDS hiçbir veri göstermeyebilir, çünkü belirli bir günde 100'den az ileti gönderen bir IP'yi atlayabilir. Ayrıca bir platformun paylaşılan IP'leri üzerinden gönderim yapıyorsanız bu adresler size ait değildir ve bunları kaydedemezsiniz.
Junk Mail Reporting Program olan JMRP, geri bildirim döngüsüdür. SNDS üzerinden kaydolduğunuzda Microsoft, Outlook.com kullanıcılarının gereksiz olarak işaretlediği iletilerin seçili başlıklarını size gönderir. Bu gönderimler genellikle 72 saat içinde başlar. Yeni IP'ler ekledikçe bunları JMRP'ye de ekleyin.
Microsoft, gereksiz posta şikayet oranını gönderici itibarındaki "başlıca faktörlerden biri" olarak tanımlıyor. SNDS FAQ ise %0,3'ün altındaki şikayet oranını "hedeflemek için iyi bir eşik" olarak belirtiyor. Yeni IP'lerin oturması zaman alır. Microsoft, yeni bir IP'nin "hacme ve liste doğruluğuna bağlı olarak birkaç hafta veya daha kısa süre içinde" tam kapasiteye ulaşmasının beklenebileceğini söylüyor. Ayrıca ücret ödeyerek girebileceğiniz bir liste yoktur. Sorun giderme sayfasında Outlook.com'un göndericilerin katılabileceği bir izin listesi kullanıp kullanmadığı soruluyor ve "Hayır." yanıtı veriliyor.
Karşı taraftaki kişinin değiştirebilecekleri
Bunların bir kısmı alıcının kontrolündedir ve okuyucudan yardım istemek makuldür. Outlook.com'da (Settings, ardından Mail, ardından Junk email) kullanıcı bir iletiyi Not junk olarak işaretleyebilir veya göndereni Safe senders and domains listesine ekleyebilir. Bu liste en fazla 10.000 kayıt tutar ve Microsoft, listedeki gönderenlerin bağlantı ve görsellerinin genellikle varsayılan olarak etkinleştirildiğini belirtir. Daha katı bir kullanıcı, yalnızca Contacts ve Safe Senders kaynaklarından gelen e-postaları kabul eden "exclusive" modunu da açabilir.
Junk düğmesi bunun tersini yapar. Microsoft, aynı gönderenden gelecek e-postaların engellenip engellenmeyeceğine karar vermek için bu bildirimleri kullanır. Ayrıca gönderenlere yönelik önerilerinde, "açıkça görünür" bir abonelikten çıkma bağlantısı ister. Microsoft'un metni, Gmail ve Yahoo'nun zorunlu tuttuğu tek tıklamalı List-Unsubscribe üstbilgilerinden bahsetmez, ancak aynı kampanya üçüne de gönderildiği için bunları her yerde eklerdim (iki üstbilgi).
Masaüstü uygulamasının kendi Junk Email Filter özelliği vardır. Varsayılan olarak "No Automatic Filtering" şeklinde ayarlanmıştır. Bunun üzerinde Low, High ve "Safe Lists Only" seçenekleri bulunur. Sonuncusu, kullanıcının güvenli listelerinde olmayan kaynaklardan gelen her şeyi gereksiz e-posta olarak değerlendirir. Güvenli ve engellenen gönderen listeleri sunucuyla senkronize edilir ve orada da kullanılır.
Bir de gelen kutusunu Focused ve Other olarak ayıran Focused Inbox vardır. Microsoft'un ifadesiyle bu özellik, "otomatik oluşturulan veya toplu e-posta gibi gürültülü kaynakları filtreler". Other, gelen kutusundaki bir sekmedir ve benim yorumuma göre burada yer alan bir bülten, spam filtresinden zaten geçmiştir.
Gerçek gönderimden önce test
Microsoft'un kendi sorun giderme sayfası, "canlı iletişimleri göndermeden önce e-posta testi yapmanızı önemle tavsiye ettiğini" belirtiyor. Email Spam Tester tam olarak bu adımı kapsıyor. Gerçekte kullanacağınız sunucu veya platformdan, sayfanın oluşturduğu bir adrese asıl mesajı gönderirsiniz. Rapor, 42 kontrolü listeler: hizalama dahil SPF, DKIM ve DMARC, ters DNS, gönderen IP'nin 21 engelleme listesindeki durumu (bunların neden önemli olduğu), abonelikten çıkma üstbilgileri ve içerik. Başarısız kontroller için bir düzeltme planı ve kopyalayabileceğiniz DNS kayıtları sunulur. Her düzeltmenin kazandırdığı puan, puanlama tablosuna dayanır.
Gelen kutusu yerleşim testini eklediğinizde aynı mesaj Gmail, Outlook, Yahoo ve diğer sağlayıcılardaki gelen kutularına da gönderilir. Rapor, mesajın her birinde nereye düştüğünü doğrudan posta kutusundan okuyarak gösterir. Sağlayıcının bu şekilde sınıflandırdığı durumlarda Focused veya Other da buna dahildir. Ücretsizdir ve kayıt gerekmez. Belgeler, her kontrolü ve puan karşılığını açıklar.
Bir sonraki adımınız destek talebi açmaksa Microsoft'un teslim edilebilirlik formunun yalnızca @outlook.com, @hotmail.com, @live.com ve @msn.com adresleriyle ilgili vakaları kabul ettiğini unutmayın. Politikalar sayfası, kurallara uymuyorsanız "destek ekibimizin size yardımcı olmasının mümkün olmayabileceği" konusunda uyarıyor.