Microsoft ertelemesi, Outlook.com’un ya da bir Microsoft 365 sunucusunun mesajınızı o an kabul etmediğinde gönderdiği, 4 ile başlayan geçici bir SMTP reddidir. Sunucunuz mesajı saklamalı ve yeniden denemelidir. En bilineni 451 4.7.500 Server busy. Please try again later yanıtıdır ve aynı kod hem “gönderimleriniz şüpheli görünüyor” hem de “Microsoft kötü bir gün geçiriyor” anlamına gelebilir.

4 Eylül 2026’da ikinci anlama geliyordu; en az bir deneyimli e-posta sistemi yöneticisi ise sabahı birinci olasılığın peşinde geçirdi. İkisini nasıl ayırt edeceğinizi aşağıda anlatıyoruz.

Öne çıkan noktalar

• Önce sunucu adını okuyun. *.olc.protection.outlook.com Outlook.com’un bireysel e-posta hizmetidir, *.mail.protection.outlook.com ise bir Microsoft 365 kiracısıdır. Dokümantasyon da, sorunu üst seviyeye taşıma yolu da farklıdır.
• 4xx, “kuyrukta tut ve yeniden dene” demektir: RFC 5321’e göre denemeler arasında en az 30 dakika olmalı ve denemeler en az 4 ila 5 gün sürmelidir. 5xx ise “dur” demektir; Microsoft’un politikaları bu yanıtları yeniden denemeyi yasaklar.
• Gmail ve Yahoo sorunsuzken tüm IP’leriniz aynı dakika içinde aynı Microsoft kodunu alıyorsa sorunun Microsoft’ta olduğundan şüphelenin ve herhangi bir şeyi değiştirmeden önce mailop’a bakın.
• Outlook.com, 5 Mayıs 2025’ten beri günde 5.000’den fazla mesaj gönderen alan adları için SPF, DKIM ve DMARC zorunluluğu uyguluyor. 550 5.7.515 yanıtını düzeltmek her zaman size düşer.
• Gönderim IP’lerinizi SNDS ve JMRP’ye hemen şimdi kaydedin. SNDS erişimi, yeniden onaylamazsanız 10 ay sonra sona erer.
• Daha sık yeniden denemeyin, yeni IP’lere geçmeyin ve ertelenen kişileri gönderim engeline almayın.

Önce hangi Microsoft ile muhatap olduğunuzu bulun

Microsoft, gelen e-postalar için iki ayrı sistem işletir.

Outlook.com bireysel kullanıcılara yönelik e-posta hizmetidir: outlook.com, hotmail.com, live.com ve msn.com; MX sunucuları da hotmail-com.olc.protection.outlook.com gibi adlar taşır. Bu sistemin Outlook.com Postmaster sitesi, itibar için SNDS hizmeti ve kendine ait bir gönderici destek formu vardır.

Microsoft 365 (Exchange Online) kurumsal posta kutularını barındırır. acme.com adresine giden e-postalar acme-com.mail.protection.outlook.com sunucusuna gider. Hata kodları Microsoft Learn üzerinde belgelenmiştir, engeller sender.office.com üzerinden çözülür ve kiracının e-postalarınıza nasıl davranacağını alıcının yöneticileri belirler.

Alan adı, hangisiyle muhatap olduğunuzu söylemez; yanıt söyler. 4 Eylül’de mailop listesine gönderilen bu günlük satırında relay= sunucusu bir Microsoft 365 kiracısıdır:

relay=xxxx-com.mail.protection.outlook.com[52.101.10.16]:25, dsn=4.7.500,
status=deferred (host xxx-com.mail.protection.outlook.com[52.101.10.16] said:
451 4.7.500 Server busy. Please try again later from [199.89.3.6]. (S77714)
[BN2PEPF000055E1.namprd21.prod.outlook.com 2026-09-04T10:28:53.346Z ...]
(in reply to end of DATA command))

Yanıtı çözümleyin

Temel kodu (451), gelişmiş durum kodunu (4.7.500) ve (S77714) gibi parantez içindeki alt kodu okuyun. Microsoft, S ile başlayan alt kodları yayımlamaz; ancak çok sayıda göndericinin aynı anda aynı alt kodu bildirmesi önemli bir işarettir.

Kaynaklar: Microsoft’un Exchange Online NDR başvuru sayfası, ASxxx makalesi, Postmaster kod tablosu ve 550 5.7.515 makalesi; Al Iverson’ın S775 ve S3115 yazıları; Twilio SendGrid’in S3140/S3150 engelleri hakkındaki makalesi.

Ne yapacağınızı baştaki 4 ya da 5 söyler

M3AAWG’nin Sender Best Common Practices belgesine göre geçici bir hatadan sonra “gönderici bağlantıyı kapatmalı ve daha sonra yeni bir bağlantı açmalıdır”; göndericiler geçici bir hatayı (tempfail) asla kalıcı saymamalıdır. Microsoft’un gönderici politikaları 5xx yanıtları için şöyle diyor: “Gönderici o mesajı o alıcıya yeniden iletmeye çalışmamalıdır.”

451 bir geri dönme değildir. Platformunuz ya da bir betik onu geri dönme olarak işliyorsa önce bunu düzeltin.

Microsoft kaynaklı bir sorun mu, itibarınız mı?

Microsoft’un 4.7.500 için verdiği yönergeler sizi kendi gönderimlerinize yönlendirir. Bu genellikle doğrudur, ama her zaman değil.

4 Eylül 2026’da neler yaşandı?

Qboxmail, sorunun “tüm IP’lerimizde aynı anda saat 09:47’de (CEST) başladığını” mailop listesine bildirdi; S77714, S77717 ve S77719 alt kodları görülüyordu. Poppulo’nun durum sayfası ise Microsoft’un saat 11:19’da (BST) başlayan EX1467029 numaralı sorun kaydını aktardı.

emailexpert’in 10 Eylül tarihli değerlendirmesine göre bir e-posta sistemi yöneticisi, One.com, Qboxmail, Mailjet ve Poppulo tüm gönderim IP’lerinde ve bölgelerde aynı kodları bildirene kadar sorunu fiber kablo kesintilerine bağladı. Microsoft ise sorunu önce bir spam önleme modeline, ardından kurtarma sırasında devreye girmeye devam eden bir hız sınırlama kuralına bağladı. emailexpert, kamuya açık bir olay sonrası rapor bulamadı. Ayrı bir kimlik doğrulama arızası olan MO1465074 ise 31 Ağustos’tan 3 Eylül’e kadar yaklaşık 67 saat sürdü. Bu on günü eylül raporumuz ele alıyor.

Harekete geçmeden önce beş kontrol

1. Sorunun sizdeki kapsamı. Platform kaynaklı sorunlar birkaç dakika içinde tüm IP’leri, alan adlarını ve e-posta trafiklerini etkiler. İtibar sorunları ise genellikle bunlardan birinde başlar.
2. Diğer sağlayıcılar. Gmail, Yahoo ve Apple e-postaları normal şekilde kabul ediyorsa ve başka göndericiler de aynı Microsoft kodunu bildiriyorsa sorunun kaynağı büyük olasılıkla Microsoft’tur.
3. Son 72 saatiniz. Ani bir hacim artışı, yeni bir IP, içe aktarılmış bir liste, bir DNS değişikliği ya da uzun süredir e-posta almayan kişilere yapılan bir gönderim varsa sorunun kaynağı ne olursa olsun bunların düzeltilmesi gerekir.
4. Etrafa sorun. Durum sayfalarına ve mailop arşivine bakın. Bir Microsoft 365 yöneticisi Health > Service health (hizmet durumu) sayfasını açabilir; bu sayfadaki Issue history (sorun geçmişi) bölümü, kiracınıza bildirilen son 7 ya da 30 günlük sorunları kapsar. Poppulo da EX1467029 kaydını orada buldu.
5. SNDS. Ertelemeler birikirken SNDS yeşil görünüyor ve hiçbir engel yoksa sorun büyük olasılıkla sizde değildir.

Bir Microsoft yanıtı karşısında izlenecek yol; Microsoft’un dokümantasyonu ve Eylül 2026’daki sorun raporları temel alınarak hazırlandı.

SNDS ve JMRP: ihtiyaç duymadan önce kurun

Smart Network Data Services (SNDS), Microsoft’un Outlook.com için sunduğu, IP bazında itibar bilgisi veren ücretsiz portaldır. SNDS SSS sayfası, yetkilendirilmiş her IP için şunların gösterildiğini belirtiyor:

• Filtre sonucu. Spam değerlendirmelerinin payı %10’un altındaysa yeşil, %10 ile %90 arasındaysa sarı, %90’ın üzerindeyse kırmızı.
• Şikâyet oranı, yani şikâyetlerin alıcı sayısına oranı. IP’lerin %30’undan fazlası %0,3’ün altında kalıyor; bu da “hedeflemek için iyi bir eşik”.
• RCPT komutları ve mesaj alıcıları. İkisi arasında büyük bir fark varsa listeleriniz eskimiş demektir.
• IP durumu: Blocked, Bot ya da Junked.

Veriler, “ilgili gün 100’den az mesaj gönderen IP’ler için bulunmayabilir.” Erişim için bir IP, IP aralığı ya da ASN talep edersiniz; SNDS de ters DNS (postmaster@, abuse@) ya da RDAP üzerinden bulduğu adreslere bir bağlantı gönderir. Elle yapılan talepler kabul edilmez.

SNDS, Haziran 2026’da yenilenerek yeniden kullanıma sunuldu. Al Iverson, JMRP’nin Return-Path adreslerinin artık kampanyayı ve alıcıyı güvenilir biçimde tanımlamadığını 19 Haziran’da belirtti; bu yüzden bu bilgileri başka bir yerde kodlayın. SNDS ana sayfasına göre (22 Eylül’de güncellendi) erişim, onaydan ya da taşımadan 10 ay sonra sona eriyor ve öncesinde üç hatırlatma gönderiliyor. Bu tarihi takviminize ekleyin.

SNDS içinden kaydolunan Junk Mail Reporting Program (JMRP), bir Outlook.com kullanıcısının gereksiz olarak işaretlediği her mesajı size geri gönderir; bu çoğu zaman kayıttan sonra “72 saat gibi kısa bir süre içinde” başlar. Şikâyet edenleri tüm listelerden çıkarın ve yeni IP’ler ekledikçe onları da programa kaydedin. Kaydedemediğiniz paylaşılan IP’lerde gönderim sağlayıcınıza neleri izlediğini sorun.

Gönderici desteği ve listeden çıkarılma

Outlook.com. Postmaster sorun giderme sayfasındaki destek formu bir Microsoft hesabı gerektirir, yalnızca dört bireysel e-posta alan adını kapsar ve teslimi “garanti etmez”. Bir firma tavsiyesi olarak Twilio SendGrid; talebe alan adınızı, IP’lerinizi, e-posta trafiğinizin açıklamasını, geri dönme metnini ve SNDS ekran görüntülerini eklemenizi, ilk otomatik yanıta talebin üst seviyeye taşınmasını isteyerek cevap vermenizi, hacim kotanızı sormanızı ve bir Volume-Based Limit incelemesi talep etmenizi öneriyor.

Microsoft 365. 5.7.606-649 için sender.office.com adresindeki listeden çıkarma portalını kullanın: her ziyarette bir e-posta adresi ve bir IP girilir, talep e-postayla onaylanır. Listeden çıkarılma “24 saat ya da daha uzun sürebilir.” 5.7.511 için teslim edilememe raporunu (NDR) delist@microsoft.com adresine gönderin; 48 saat içinde yanıt bekleyebilirsiniz.

ASxxx hız sınırlamasının bir listeden çıkarma süreci yoktur. Alıcı şirket gelen e-postaları Microsoft 365’ten önce üçüncü taraf bir hizmetten geçiriyorsa, Learn makalesine göre şirketin yöneticisinin kuracağı bir bağlayıcı (connector) sınırlamayı kaldırır. Aksi hâlde sınırlama, gönderim geçmişiniz oluştukça kalkar.

Yeniden deneyin, yavaşlatın, kademeli artırın

Belirli bir takvime göre yeniden deneyin. RFC 5321, bölüm 4.5.4.1, “yeniden deneme aralığı en az 30 dakika olmalıdır (SHOULD)” der ve vazgeçme süresinin “genellikle en az 4-5 gün olması gerektiğini” belirtir; ilk saatte iki deneme, sonrasında da iki ya da üç saatte bir deneme önerir. Acil bir gönderim için bu süreyi kısaltmayın.

Hedefe göre yavaşlatın. M3AAWG’ye göre alıcı sunucular, ayarlamanın “aynı IP adresinden kendilerine gönderilen tüm e-postalar için toptan bir süreç olarak” yapılmasını bekler. Microsoft ertelemeye başladığında o MX ailesine (Outlook.com ya da Microsoft 365) giden tüm gönderimleri yavaşlatın.

Bağlantıları izleyin. Outlook.com politikasına göre göndericiler, önceden bir düzenleme yapılmadıkça “aynı anda 500’den fazla bağlantı açmamalıdır”. Bu bir tavan değeridir; 4.7.652 (S3115) yanıtı ise size tanınan sınırı aştığınızı gösterir.

Yeni IP’leri ve alan adlarını kademeli olarak ısındırın. Microsoft’a göre yeni bir IP, hacme, listenin doğruluğuna ve şikâyetlere bağlı olarak “birkaç hafta içinde ya da daha kısa sürede tamamen ısınmış olmayı bekleyebilir”. Mevcut bir SPF kaydının kapsadığı yeni IP’ler, alan adı itibarının bir kısmını devralır. Isındırmaya yakın zamanda etkileşimde bulunan kişilerle başlayın.

Yapmamanız gerekenler

• Daha sık yeniden denemek. Kuyruğu birkaç dakikada bir boşaltmaya çalışmak, Microsoft’un yavaşlamasını istediği bir IP’ye bağlantı yığar ve size bir 4.7.652 kazandırır.
• Sorundan kaçmak için IP değiştirmek. Yeni IP’lerin itibarı yoktur ve sorun yaşama olasılıkları daha yüksektir; e-postaları yeni IP’lere dağıtmak da tam olarak “snowshoe” spam gönderenlerin yöntemidir.
• Bir 5xx yanıtını yeniden denemek. Microsoft bunu yasaklar; “birden fazla teslim edilememe yanıtından” sonra o alıcıya göndermeyi bırakmanız gerekir.
• Ertelenen kişileri gönderim engeline almak. Adres hâlâ geçerlidir.
• Ertelenen alıcılara yeniden göndermek. Mesajları hâlâ kuyrukta bekliyor. Mükerrer e-posta göndermiş olursunuz.
• Panikle DNS kayıtlarını değiştirmek. Bir 5.7.515 almadıysanız, sorun sürerken SPF ya da DKIM kaydını değiştirmek ikinci bir sorun yaratır.

DMARC hizalaması ve p=none politikasından uygulama moduna geçiş için teslim edilebilirlik rehberimize göz atın. Şifre sıfırlama e-postalarının ve makbuzların aksamadan gitmesi için bunları kendi alan adlarına taşımayı işlemsel e-posta rehberimiz anlatıyor.

Brew içinde bu nasıl görünüyor?

Gönderim altyapısını Brew yönetir ve geçici hataları yeniden dener; bu yüzden kuyrukları ya da bağlantı limitlerini hiçbir zaman sizin ayarlamanız gerekmez. Sizin gördükleriniz:

• Teslim gecikti olayları. Bir erteleme olduğunda bir “Teslim gecikti” olayı (delivery_delayed) kaydedilir; alıcı “kabul edildi” durumundan “gecikti” durumuna, ardından “teslim edildi” ya da “geri döndü” durumuna geçer. Olaylar sayfasında “delayed” diye arayın, ardından Outlook.com alıcılarına daraltmak için @hotmail.com ya da @outlook.com yazın (alan adı filtreleri VEYA ile birleşir; Microsoft 365 alıcıları kendi alan adlarını kullanır). Olay, mesajın beklediğini söyler; neden beklediğini söylemez.
• Geri dönme ayrıntıları. Bir geri dönme olayının Meta veriler bölümünde geri dönme türü ve sağlayıcının mesajı yer alır.
• API üzerinden sayılar. Analiz özeti uç noktası, teslim edilen ve geri dönen e-postaların yanında deliveryDelayed ve pending değerlerini de döndürür. MCP üzerinden get_email_analytics aracı da aynısını yapar.
• 4xx yanıtlarını dikkate alan gönderim engeli. Kalıcı geri dönmeler ve şikâyetler kişiyi hemen gönderim engeline alır. Geçici geri dönmeler ise yalnızca 30 gün içinde üç kez yaşandığında engele yol açar.
• Kademeli artış. Kademeli gönderim, büyük bir gönderimi saatlik ya da günlük yüzdelik partilere böler; Outlook.com ertelemeye başlarsa bu partileri duraklatabilirsiniz.
• Alan adı sağlığı. Her alan adının Teslim edilebilirlik kartı; gelen kutusu yerleşimi, itibar, kimlik doğrulama, içerik ve gönderim ayarları üzerinden 0 ile 100 arasında bir puan verir. Aynı puana get_domain_health MCP aracıyla da ulaşabilirsiniz. Bir gelen kutusu yerleşim testi (10 kredi), Gmail, Outlook, Yahoo, Apple ve diğer sağlayıcılardaki test gelen kutularına e-posta gönderir.

Teslim webhookları ve SNDS ya da JMRP verileri henüz Brew içinde yok (sağlayıcı bazında sayılar, olaylar API’sinden groupBy=recipientDomain ile alınır); itibar için Microsoft’un portallarını kullanın. Microsoft kaynaklı bir sorundan şüphelenilen durumlarda biz olsak gönderime dokunmaz, “Teslim gecikti” olaylarının yerini “Teslim edildi” olaylarının almasını izlerdik.

Sıkça sorulan sorular

Outlook ya da Microsoft 365’ten gelen 451 4.7.500 Server busy yanıtı ne anlama gelir?

Microsoft 365’in (Exchange Online) geçici bir reddidir ve şüpheli etkinlik sonrasında “Access denied, please try again later” olarak listelenir. Genellikle gönderim düzeniniz değişmiştir; ancak 4 Eylül 2026’da bunun nedeni Microsoft kaynaklı bir sorundu (EX1467029). Sunucunuzun yeniden denemesine izin verin ve başka göndericilerin de aynı yanıtı görüp görmediğini kontrol edin.

Microsoft e-postalarımı ne kadar süre ertelemeye devam eder?

Microsoft’a göre gönderim düzenine bağlı hız sınırlaması, gönderim geçmişiniz oluştukça “birkaç gün içinde” ortadan kalkar; listeden çıkarılma ise 24 saat ya da daha uzun sürebilir. RFC 5321’in önerdiği gibi en az 4 ila 5 gün boyunca yeniden denemeye devam edin; ertelenen e-postaların çoğu sonunda yine de teslim edilir.

550 5.7.515 nedir ve nasıl düzeltilir?

Outlook.com, günde 5.000’den fazla e-posta gönderen ve 5 Mayıs 2025’ten beri uygulanan kimlik doğrulama kurallarını karşılamayan alan adlarından gelen e-postaları reddeder. SPF ve DKIM kontrolden geçmeli, alan adı bir DMARC kaydı yayımlamalı (p=none yeterlidir) ve SPF ya da DKIM, From alan adıyla hizalanmalıdır.

Microsoft IP adresimi engellerse yeni bir IP adresi almalı mıyım?

Hayır. Microsoft’a göre yeni IP’lerin itibarı yoktur ve sorun yaşama olasılıkları daha yüksektir. Nedeni düzeltin, listeden çıkarılmayı talep edin ve mevcut IP’nizde hacmi yeniden kademeli olarak artırın.

Microsoft ertelemeleri geri dönme sayılır mı?

Hayır. M3AAWG’ye göre göndericiler bir 4xx yanıtını kalıcı saymamalıdır. Bu yanıt ancak yeniden denemeler tükenirse ya da sunucu bir 5xx yanıtı döndürürse geri dönmeye dönüşür. Brew içinde bir erteleme “Teslim gecikti” olayı olarak görünür ve kişiler yalnızca tekrarlanan geçici geri dönmelerden sonra gönderim engeline alınır.