# Microsoft 451 4.7.500 ertelemeleri: göndericiler için rehber

Kanonik URL: https://brew.new/tr/blog/microsoft-451-4-7-500-deferrals-playbook
Yazar: Thomas Park
Yayımlandı: 2026-10-05
Güncellendi: 2026-10-05

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](https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting), 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](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online) ü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](https://www.mail-archive.com/mailop@mailop.org/msg27209.html) bu günlük satırında `relay=` sunucusu bir Microsoft 365 kiracısıdır:

```text
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.

| Yanıt | Nerede? | Microsoft’un dokümantasyonu ne diyor? | İlk adım |
|---|---|---|---|
| `451 4.7.500 Server busy. Please try again later from [IP]. (S77714)` | Microsoft 365 | Learn, 4.7.500-699 aralığını “Access denied, please try again later” olarak listeliyor: şüpheli etkinlik, gönderim geçici olarak kısıtlandı. | Kuyruğun yeniden denemesine izin verin. Önce sorunun kapsamını kontrol edin. |
| `451 4.7.500-699 (ASxxx)` | Microsoft 365 | Bağlanan IP “çok daha yüksek hacimde göndererek önceki e-posta gönderim düzenini değiştirdiğinde” uygulanan IP hız sınırlaması. | Hacmi daha yavaş artırın. Kısıtlama “birkaç gün içinde” kalkar. |
| `451 4.7.650 ... temporarily rate limited due to IP reputation (S775)` | Outlook.com | Microsoft’un yayımladığı tabloda yok. | Hacmi ve eş zamanlı bağlantı sayısını azaltın, ardından SNDS’i kontrol edin. |
| `451 4.7.652 ... exceeded the maximum number of connections (S3115)` | Outlook.com | Tabloda yok. Nedeni yanıt metninin kendisi söylüyor. | Daha az bağlantı açın. |
| `421 RP-001`, `RP-002`, `RP-003` | Outlook.com | Gönderim hızı, bağlantı başına gönderim hızı ve bağlantı limitleri aşıldı; “IP/alan adı itibarıyla ilgili”. | Gönderimi yavaşlatın, ardından SNDS’i kontrol edin. |
| `550 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level.` | Outlook.com | Alan adı günde 5.000’den fazla e-posta gönderiyor ve SPF, DKIM ve DMARC gereksinimini karşılamıyor. | Kimlik doğrulamayı ve hizalamayı düzeltin. |
| `550 5.7.1 ... part of their network is on our block list (S3150)` | Outlook.com | IP’nize ya da IP aralığınıza uygulanan bir engel. | O IP’den göndermeyi durdurun ve bir destek talebi açın. |
| `550 SC-001`, `SC-004`, `OU-002` ve benzerleri | Outlook.com | İçerik, itibar ya da şikâyetler nedeniyle verilen politika retleri. SC-004, JMRP’ye işaret eder. | Göndermeye devam etmeden önce nedeni bulun. |
| `550 5.7.606-649 Access denied, banned sending IP [IP]` | Microsoft 365 | IP, engellenen göndericiler listesinde. | `sender.office.com` adresinden listeden çıkarılmayı talep edin. |
| `550 5.7.511 Access denied, banned sender` | Microsoft 365 | Elle inceleme gerektirir. | Teslim edilememe raporunu (NDR) `delist@microsoft.com` adresine iletin. |

Kaynaklar: Microsoft’un [Exchange Online NDR başvuru sayfası](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online), [ASxxx makalesi](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/fix-error-code-451-4-7-500-699-asxxx-in-exchange-online), Postmaster kod tablosu ve [550 5.7.515 makalesi](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com); Al Iverson’ın [S775](https://www.spamresource.com/2026/02/microsoft-rate-limiting-issues.html) ve [S3115](https://www.spamresource.com/2025/07/microsoft-says-too-many-connections.html) yazıları; Twilio SendGrid’in [S3140/S3150 engelleri](https://support.sendgrid.com/hc/en-us/articles/38465017420955-Troubleshooting-Microsoft-Delivery-Issues-With-Error-550-5-7-1-S3140-S3150-Blocks) hakkındaki makalesi.

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

[M3AAWG’nin Sender Best Common Practices belgesine](https://www.m3aawg.org/sites/default/files/document/M3AAWG_Senders_BCP_Ver3-2015-02.pdf) 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ı](https://substrate.office.com/ip-domain-management-snds/Postmaster/Policies) 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](https://www.mail-archive.com/mailop@mailop.org/msg27208.html); S77714, S77717 ve S77719 alt kodları görülüyordu. Poppulo’nun [durum sayfası](https://poppulo1.statuspage.io/incidents/w0671ycn23fw) ise Microsoft’un saat 11:19’da (BST) başlayan EX1467029 numaralı sorun kaydını aktardı.

emailexpert’in [10 Eylül tarihli değerlendirmesine](https://emailexpert.com/microsofts-ten-days-three-exchange-online-incidents-three-causes/) 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](/tr/blog/state-of-email-september-2026) 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](https://learn.microsoft.com/en-us/microsoft-365/enterprise/view-service-health) (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.

| Sinyal | Microsoft’u işaret ediyor | Sizi işaret ediyor |
|---|---|---|
| Zamanlama | Tüm IP’lerde aynı dakika içinde başlıyor | Tek bir IP ya da alan adında başlıyor veya yavaş yavaş artıyor |
| Diğer sağlayıcılar | Normal | Onlarda da bozulma var ya da şikâyetler artıyor |
| Diğer göndericiler | mailop’ta ve durum sayfalarında aynı kod | Başka kimse bundan söz etmiyor |
| Son değişiklikleriniz | Yok | Hacim sıçraması, yeni IP, yeni liste |
| SNDS | Yeşil, engel yok | Sarı ya da kırmızı, şikâyetler, “Blocked” |
| Kod | Başkalarının da bildirdiği bir alt kodla 4.7.500 | RP-00x, 4.7.650, 5.7.515, S3150 |

![Microsoft yanıtları için bir karar akış şeması: 5xx kodları kimlik doğrulamayı düzeltmeye, listeden çıkarma portalına ya da bir destek talebine; 4xx kodları ise bir sorun kontrolüne, ardından ya sorunun geçmesini beklemeye ya da gönderimi yavaşlatıp SNDS’i kontrol etmeye yönlendiriyor.](/images/blog/microsoft-451-4-7-500-deferrals-playbook-flowchart.png)

*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](https://substrate.office.com/ip-domain-management-snds/snds) (SNDS), Microsoft’un Outlook.com için sunduğu, IP bazında itibar bilgisi veren ücretsiz portaldır. [SNDS SSS sayfası](https://substrate.office.com/ip-domain-management-snds/SNDS/FAQ), 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](https://www.spamresource.com/2026/06/snds-and-jmrp-in-transition.html); 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](https://substrate.office.com/ip-domain-management-snds/Postmaster/Services) (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](https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting) 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ı](https://learn.microsoft.com/en-us/defender-office-365/external-senders-use-the-delist-portal-to-unblock-yourself) 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](https://www.rfc-editor.org/rfc/rfc5321.html#section-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](/tr/blog/email-deliverability) 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](/tr/blog/transactional-emails) 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](https://docs.brew.new/api-reference/public-v1/analytics/brand-overview-totals-rates-timeseries) 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](https://docs.brew.new/create-emails/send-options#gradual-send), 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.