Pahami respons Microsoft 451 4.7.500, 4.7.650, RP-001, dan 550 5.7.515, bedakan insiden Outlook dari masalah reputasi, dan ketahui apa yang harus dihindari.
Penundaan (deferral) dari Microsoft adalah penolakan SMTP sementara, yaitu respons yang diawali angka 4, yang dikirim server Outlook.com atau Microsoft 365 saat server itu belum mau menerima pesan Anda. Server Anda seharusnya menyimpan pesan tersebut dan mencoba lagi. Yang paling dikenal adalah 451 4.7.500 Server busy. Please try again later, dan kode yang sama bisa berarti “pengiriman Anda terlihat mencurigakan” atau “Microsoft sedang bermasalah”.
Pada 4 September 2026, artinya adalah yang kedua, dan setidaknya satu praktisi berpengalaman menghabiskan paginya untuk mengejar kemungkinan pertama. Berikut cara membedakan keduanya.
*.olc.protection.outlook.com adalah email konsumen Outlook.com, sedangkan *.mail.protection.outlook.com adalah tenant Microsoft 365. Dokumentasinya berbeda, jalur eskalasinya pun berbeda.550 5.7.515 selalu menjadi tanggung jawab Anda untuk diperbaiki.Microsoft menjalankan dua sistem penerima email.
Outlook.com adalah layanan email konsumen: outlook.com, hotmail.com, live.com, dan msn.com, dengan host MX seperti hotmail-com.olc.protection.outlook.com. Outlook.com memiliki situs Postmaster Outlook.com, SNDS untuk reputasi, dan formulir dukungan pengirimnya sendiri.
Microsoft 365 (Exchange Online) meng-hosting kotak surat bisnis. Email untuk acme.com dikirim ke acme-com.mail.protection.outlook.com. Error-nya didokumentasikan di Microsoft Learn, pemblokiran ditangani lewat sender.office.com, dan admin di pihak penerima mengendalikan cara tenant mereka memperlakukan Anda.
Nama domain tidak akan memberi tahu sistem mana yang Anda tuju. Responsnyalah yang akan memberi tahu. Pada baris log yang diposting ke mailop pada 4 September ini, host relay= adalah tenant Microsoft 365:
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))Baca kode dasar (451), kode status yang diperluas (4.7.500), dan subkode dalam kurung seperti (S77714). Microsoft tidak memublikasikan daftar subkode S, tetapi jika banyak pengirim melaporkan subkode yang sama secara bersamaan, itu adalah sebuah sinyal.
| Respons | Di mana | Menurut dokumentasi Microsoft | Langkah pertama |
|---|---|---|---|
451 4.7.500 Server busy. Please try again later from [IP]. (S77714) |
Microsoft 365 | Learn mencantumkan 4.7.500-699 sebagai “Access denied, please try again later”: aktivitas mencurigakan, pengiriman dibatasi sementara. | Biarkan antrean mencoba ulang. Periksa cakupannya lebih dulu. |
451 4.7.500-699 (ASxxx) |
Microsoft 365 | Throttling IP saat IP yang terhubung “mengubah pola pengiriman email sebelumnya dengan mengirim volume yang jauh lebih tinggi”. | Perlambat peningkatan volume. Throttling ini hilang “dalam beberapa hari”. |
451 4.7.650 ... temporarily rate limited due to IP reputation (S775) |
Outlook.com | Tidak ada di tabel yang dipublikasikan Microsoft. | Kurangi volume dan jumlah koneksi bersamaan, lalu periksa SNDS. |
451 4.7.652 ... exceeded the maximum number of connections (S3115) |
Outlook.com | Tidak ada di tabel. Teks responsnya menyebutkan penyebabnya. | Kurangi jumlah koneksi yang dibuka. |
421 RP-001, RP-002, RP-003 |
Outlook.com | Batas laju, batas laju per koneksi, dan batas jumlah koneksi terlampaui, “terkait reputasi IP/domain”. | Terapkan throttling, lalu periksa SNDS. |
550 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level. |
Outlook.com | Domain mengirim lebih dari 5.000 email per hari dan tidak memenuhi persyaratan SPF, DKIM, dan DMARC. | Perbaiki autentikasi dan alignment. |
550 5.7.1 ... part of their network is on our block list (S3150) |
Outlook.com | Pemblokiran pada IP atau rentang IP Anda. | Hentikan pengiriman dari IP tersebut dan buka tiket. |
550 SC-001, SC-004, OU-002, dan sejenisnya |
Outlook.com | Penolakan berdasarkan kebijakan karena konten, reputasi, atau keluhan. SC-004 merujuk ke JMRP. | Temukan penyebabnya sebelum melanjutkan pengiriman. |
550 5.7.606-649 Access denied, banned sending IP [IP] |
Microsoft 365 | IP ada di daftar pengirim yang diblokir. | Minta penghapusan dari daftar di sender.office.com. |
550 5.7.511 Access denied, banned sender |
Microsoft 365 | Perlu investigasi manual. | Teruskan NDR ke delist@microsoft.com. |
Sumber: referensi NDR Exchange Online dari Microsoft, artikel ASxxx, tabel kode Postmaster, dan artikel 550 5.7.515; Al Iverson tentang S775 dan S3115; Twilio SendGrid tentang pemblokiran S3140/S3150.
Sender Best Common Practices dari M3AAWG menyatakan bahwa setelah kegagalan sementara, “pengirim sebaiknya menutup koneksi dan membuka koneksi baru nanti”, dan bahwa pengirim tidak boleh memperlakukan kegagalan sementara (tempfail) sebagai kegagalan permanen. Kebijakan pengirim Microsoft tentang 5xx: “pengirim tidak boleh mencoba mengirim ulang pesan itu kepada penerima tersebut.”
Kode 451 bukan pentalan. Jika platform atau skrip Anda memperlakukannya sebagai pentalan, perbaiki itu lebih dulu.
Panduan Microsoft untuk 4.7.500 mengarahkan Anda ke pengiriman Anda sendiri. Biasanya itu benar, tetapi tidak selalu.
Qboxmail melaporkan ke mailop bahwa masalahnya “dimulai pukul 09.47 CEST di semua IP kami sekaligus”, dengan subkode S77714, S77717, dan S77719. Halaman status Poppulo mengutip ID insiden Microsoft, EX1467029, yang dimulai pukul 11.19 BST.
Menurut ulasan emailexpert tertanggal 10 September, seorang praktisi sempat menyalahkan kabel serat optik yang putus, sampai One.com, Qboxmail, Mailjet, dan Poppulo melaporkan kode yang sama di setiap IP pengirim dan wilayah. Microsoft menyalahkan model antispam, lalu aturan throttling yang masih aktif selama pemulihan. emailexpert tidak menemukan laporan pascainsiden yang dipublikasikan. Gangguan autentikasi yang terpisah, MO1465074, berlangsung sekitar 67 jam, dari 31 Agustus hingga 3 September. Laporan September kami membahas sepuluh hari tersebut.
| Sinyal | Mengarah ke Microsoft | Mengarah ke Anda |
|---|---|---|
| Waktu | Semua IP mulai terdampak pada menit yang sama | Satu IP atau domain, atau naik secara bertahap |
| Penyedia lain | Normal | Ikut memburuk, atau keluhan meningkat |
| Pengirim lain | Kode yang sama di mailop dan halaman status | Tidak ada yang membicarakannya |
| Perubahan terbaru di pihak Anda | Tidak ada | Lonjakan volume, IP baru, daftar kontak baru |
| SNDS | Hijau, tidak ada pemblokiran | Kuning atau merah, ada keluhan, “Blocked” |
| Kode | 4.7.500 dengan subkode yang juga dilaporkan pengirim lain | RP-00x, 4.7.650, 5.7.515, S3150 |
Cara menindaklanjuti respons Microsoft, berdasarkan dokumentasi Microsoft dan laporan insiden September 2026.
Smart Network Data Services (SNDS) adalah portal reputasi per IP yang gratis dari Microsoft untuk Outlook.com. FAQ SNDS mencantumkan data yang ditampilkan untuk setiap IP yang diotorisasi:
Data “mungkin tidak tersedia untuk IP yang mengirim kurang dari 100 pesan pada hari tersebut.” Untuk mendapatkan akses, ajukan permintaan untuk IP, rentang IP, atau ASN, lalu SNDS akan mengirim tautan lewat email ke alamat yang ditemukannya melalui reverse DNS (postmaster@, abuse@) atau RDAP. Permintaan manual tidak dilayani.
SNDS diluncurkan ulang pada Juni 2026. Al Iverson mencatat pada 19 Juni bahwa return-path JMRP tidak lagi bisa diandalkan untuk mengidentifikasi kampanye dan penerima, jadi sematkan kedua informasi itu di tempat lain. Menurut halaman beranda SNDS (diperbarui 22 September), akses berakhir 10 bulan setelah persetujuan atau migrasi, dengan tiga kali pengingat. Catat di kalender Anda.
Junk Mail Reporting Program (JMRP), yang pendaftarannya dilakukan di dalam SNDS, mengirimkan kembali setiap pesan yang ditandai sebagai junk oleh pengguna Outlook.com, sering kali “dalam waktu 72 jam saja” setelah pendaftaran. Hapus orang yang mengajukan keluhan dari setiap daftar, dan daftarkan IP baru setiap kali Anda menambahkannya. Untuk IP bersama yang tidak bisa Anda daftarkan, tanyakan kepada penyedia Anda apa yang dipantaunya.
Outlook.com. Formulir dukungan di halaman pemecahan masalah Postmaster memerlukan akun Microsoft, hanya mencakup keempat domain konsumen, dan “tidak menjamin” email Anda akan terkirim. Twilio SendGrid (saran dari vendor) menganjurkan Anda untuk menyertakan domain, IP, deskripsi aliran email, teks pentalan, dan tangkapan layar SNDS; membalas balasan otomatis pertama dengan meminta eskalasi; serta meminta informasi kuota volume Anda dan peninjauan Volume-Based Limit.
Microsoft 365. Untuk 5.7.606-649, gunakan portal delist di sender.office.com: satu alamat dan satu IP per kunjungan, dikonfirmasi lewat email. Penghapusan “bisa memakan waktu hingga 24 jam atau lebih.” Untuk 5.7.511, kirim NDR lewat email ke delist@microsoft.com, dan perkirakan balasan akan datang dalam 48 jam.
Throttling ASxxx tidak bisa dihapus lewat proses delist. Jika perusahaan penerima memfilter email masuk melalui layanan pihak ketiga sebelum sampai ke Microsoft 365, artikel Learn menyebutkan bahwa konektor yang disiapkan admin perusahaan itu akan menghapus throttling tersebut. Jika tidak, throttling akan hilang seiring Anda membangun riwayat pengiriman.
Coba ulang sesuai jadwal. RFC 5321, bagian 4.5.4.1 menyatakan bahwa “interval percobaan ulang SEBAIKNYA minimal 30 menit” dan batas waktu sebelum menyerah “umumnya perlu minimal 4–5 hari,” dengan dua percobaan pada jam pertama, lalu satu kali setiap dua atau tiga jam. Jangan memperpendeknya demi pengiriman yang mendesak.
Terapkan throttling per tujuan. M3AAWG menyatakan bahwa server penerima mengharapkan penyesuaian “sebagai proses menyeluruh untuk semua email yang dikirim kepada mereka dari alamat IP yang sama.” Saat Microsoft menunda, perlambat semua pengiriman ke kelompok MX tersebut (Outlook.com atau Microsoft 365).
Pantau koneksi. Kebijakan Outlook.com menyatakan bahwa pengirim “tidak boleh membuka lebih dari 500 koneksi simultan” tanpa kesepakatan sebelumnya. Itu batas atas, dan 4.7.652 (S3115) berarti Anda sudah melampaui batas Anda.
Naikkan volume IP dan domain baru secara bertahap. Microsoft menyatakan bahwa IP baru “bisa diperkirakan mencapai volume penuh dalam beberapa minggu atau lebih cepat,” tergantung pada volume, akurasi daftar kontak, dan keluhan. IP baru yang tercakup dalam record SPF yang sudah ada mewarisi sebagian reputasi domain. Mulailah dengan kontak yang baru-baru ini aktif berinteraksi.
5.7.515.Untuk alignment DMARC dan peralihan dari p=none ke penegakan, lihat panduan keterkiriman kami. Agar email reset kata sandi dan bukti pembayaran tetap mengalir, panduan email transaksional kami membahas cara mengirimnya dari domain tersendiri.
Brew menjalankan infrastruktur pengiriman dan mencoba ulang kegagalan sementara, jadi Anda tidak perlu mengatur antrean atau batas koneksi. Yang Anda lihat:
delivery_delayed), dan status penerima berpindah dari terkirim ke tertunda, lalu diterima atau terpental. Di Peristiwa, cari “tertunda”, lalu ketik @hotmail.com atau @outlook.com untuk mempersempit ke Outlook.com (filter domain digabungkan dengan OR; penerima Microsoft 365 memakai domain mereka sendiri). Peristiwa ini memberi tahu bahwa pesan sedang menunggu, bukan alasannya.deliveryDelayed dan pending di samping jumlah email yang diterima dan terpental. Alat get_email_analytics melakukan hal yang sama lewat MCP.get_domain_health. Uji penempatan kotak masuk (10 kredit) mengirim ke kotak masuk pengujian di Gmail, Outlook, Yahoo, Apple, dan lainnya.Webhook pengiriman dan data SNDS atau JMRP belum tersedia di Brew (jumlah per penyedia bisa diambil dari API peristiwa dengan groupBy=recipientDomain), jadi gunakan portal Microsoft untuk memantau reputasi. Saat ada dugaan insiden di Microsoft, kami tidak akan mengutak-atik pengiriman dan cukup memantau status Tertunda berubah menjadi Diterima.
Ini adalah penolakan sementara dari Microsoft 365 (Exchange Online), yang tercantum sebagai “Access denied, please try again later” setelah ada aktivitas mencurigakan. Biasanya pola pengiriman Anda berubah, tetapi pada 4 September 2026 penyebabnya adalah insiden Microsoft (EX1467029). Biarkan server Anda mencoba ulang, dan periksa apakah pengirim lain juga mengalaminya.
Menurut Microsoft, throttling berbasis pola akan hilang “dalam beberapa hari” seiring Anda membangun riwayat pengiriman, dan penghapusan dari daftar blokir bisa memakan waktu hingga 24 jam atau lebih. Terus coba ulang selama minimal 4 hingga 5 hari, seperti yang direkomendasikan RFC 5321, dan sebagian besar email yang ditunda pada akhirnya tetap terkirim.
Outlook.com menolak email dari domain yang mengirim lebih dari 5.000 email per hari tetapi tidak memenuhi aturan autentikasinya, yang ditegakkan sejak 5 Mei 2025. SPF dan DKIM harus lolos, domain harus memublikasikan DMARC (p=none sudah cukup), dan SPF atau DKIM harus selaras dengan domain From.
Tidak. Menurut Microsoft, IP baru belum punya reputasi dan lebih rentan bermasalah. Perbaiki penyebabnya, ajukan penghapusan dari daftar blokir, lalu naikkan kembali volume secara bertahap di IP yang Anda miliki.
Tidak. M3AAWG menyatakan bahwa pengirim tidak boleh memperlakukan kode 4xx sebagai kegagalan permanen. Penundaan baru menjadi pentalan jika percobaan ulang sudah habis atau server mengembalikan kode 5xx. Di Brew, penundaan tampil sebagai peristiwa Tertunda, dan kontak baru dikecualikan setelah berulang kali mengalami pentalan sementara.
