# Microsoft 451 4.7.500: playbook pengirim saat email ditunda

URL kanonis: https://brew.new/id/blog/microsoft-451-4-7-500-deferrals-playbook
Penulis: Thomas Park
Dipublikasikan: 2026-10-05
Diperbarui: 2026-10-05

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.

## Poin penting

- Baca nama host lebih dulu. `*.olc.protection.outlook.com` adalah email konsumen Outlook.com, sedangkan `*.mail.protection.outlook.com` adalah tenant Microsoft 365. Dokumentasinya berbeda, jalur eskalasinya pun berbeda.
- Kode 4xx berarti masukkan ke antrean dan coba lagi: RFC 5321 menyebut jeda minimal 30 menit, selama minimal 4 hingga 5 hari. Kode 5xx berarti berhenti. Kebijakan Microsoft melarang percobaan ulang untuk kode ini.
- Jika setiap IP menerima kode Microsoft yang sama pada menit yang sama sementara Gmail dan Yahoo baik-baik saja, curigai Microsoft dan periksa mailop sebelum mengubah apa pun.
- Sejak 5 Mei 2025, Outlook.com menegakkan persyaratan SPF, DKIM, dan DMARC untuk domain yang mengirim lebih dari 5.000 pesan per hari. `550 5.7.515` selalu menjadi tanggung jawab Anda untuk diperbaiki.
- Daftarkan IP pengirim di SNDS dan JMRP sekarang. Akses SNDS berakhir setelah 10 bulan kecuali Anda melakukan atestasi ulang.
- Jangan memperbanyak percobaan ulang, berpindah ke IP baru, atau mengecualikan kontak yang ditunda.

## Pertama, cari tahu Microsoft mana yang Anda hadapi

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](https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting), 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](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online), 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](https://www.mail-archive.com/mailop@mailop.org/msg27209.html) pada 4 September ini, host `relay=` adalah tenant Microsoft 365:

```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))
```

## Uraikan responsnya

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](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online) dari Microsoft, [artikel ASxxx](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/fix-error-code-451-4-7-500-699-asxxx-in-exchange-online), tabel kode Postmaster, dan [artikel 550 5.7.515](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com); Al Iverson tentang [S775](https://www.spamresource.com/2026/02/microsoft-rate-limiting-issues.html) dan [S3115](https://www.spamresource.com/2025/07/microsoft-says-too-many-connections.html); Twilio SendGrid tentang [pemblokiran S3140/S3150](https://support.sendgrid.com/hc/en-us/articles/38465017420955-Troubleshooting-Microsoft-Delivery-Issues-With-Error-550-5-7-1-S3140-S3150-Blocks).

### Angka 4 atau 5, itulah instruksinya

[Sender Best Common Practices dari M3AAWG](https://www.m3aawg.org/sites/default/files/document/M3AAWG_Senders_BCP_Ver3-2015-02.pdf) 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](https://substrate.office.com/ip-domain-management-snds/Postmaster/Policies) 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.

## Insiden Microsoft atau reputasi Anda

Panduan Microsoft untuk 4.7.500 mengarahkan Anda ke pengiriman Anda sendiri. Biasanya itu benar, tetapi tidak selalu.

### Seperti apa kejadian 4 September 2026

Qboxmail [melaporkan ke mailop](https://www.mail-archive.com/mailop@mailop.org/msg27208.html) bahwa masalahnya “dimulai pukul 09.47 CEST di semua IP kami sekaligus”, dengan subkode S77714, S77717, dan S77719. [Halaman status Poppulo](https://poppulo1.statuspage.io/incidents/w0671ycn23fw) mengutip ID insiden Microsoft, EX1467029, yang dimulai pukul 11.19 BST.

Menurut [ulasan emailexpert tertanggal 10 September](https://emailexpert.com/microsofts-ten-days-three-exchange-online-incidents-three-causes/), 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](/id/blog/state-of-email-september-2026) kami membahas sepuluh hari tersebut.

### Lima pemeriksaan sebelum bertindak

1. **Cakupan masalah di pihak Anda.** Masalah platform melanda setiap IP, domain, dan aliran email dalam hitungan menit. Masalah reputasi biasanya bermula pada salah satunya.
2. **Penyedia lain.** Jika Gmail, Yahoo, dan Apple menerima seperti biasa, dan pengirim lain melaporkan kode Microsoft yang sama, kemungkinan besar penyebabnya ada di Microsoft.
3. **72 jam terakhir Anda.** Lonjakan volume, IP baru, daftar kontak yang diimpor, perubahan DNS, atau pengiriman reaktivasi tetap perlu dibenahi, apa pun penyebab penundaannya.
4. **Tanyakan ke sesama pengirim.** Periksa arsip mailop dan halaman status. Admin Microsoft 365 bisa membuka **Health > Service health** (Kesehatan > Kesehatan layanan), dan bagian [Issue history](https://learn.microsoft.com/en-us/microsoft-365/enterprise/view-service-health) (riwayat masalah) di sana mencakup insiden 7 atau 30 hari terakhir yang diposting ke tenant Anda. Di situlah Poppulo menemukan EX1467029.
5. **SNDS.** Status hijau tanpa pemblokiran, sementara penundaan terus menumpuk, menandakan bahwa masalahnya bukan di pihak Anda.

| 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 |

![Diagram alur keputusan untuk respons Microsoft: kode 5xx mengarah ke perbaikan autentikasi, portal penghapusan dari daftar blokir, atau tiket dukungan; kode 4xx mengarah ke pemeriksaan insiden, lalu menunggu hingga reda atau menerapkan throttling dan memeriksa SNDS.](/images/blog/microsoft-451-4-7-500-deferrals-playbook-flowchart.png)

*Cara menindaklanjuti respons Microsoft, berdasarkan dokumentasi Microsoft dan laporan insiden September 2026.*

## SNDS dan JMRP: siapkan sebelum Anda membutuhkannya

[Smart Network Data Services](https://substrate.office.com/ip-domain-management-snds/snds) (SNDS) adalah portal reputasi per IP yang gratis dari Microsoft untuk Outlook.com. [FAQ SNDS](https://substrate.office.com/ip-domain-management-snds/SNDS/FAQ) mencantumkan data yang ditampilkan untuk setiap IP yang diotorisasi:

- **Hasil filter (Filter result).** Hijau berarti kurang dari 10% pesan dinilai spam, kuning 10% hingga 90%, dan merah lebih dari 90%.
- **Tingkat keluhan (Complaint rate)**, yaitu jumlah keluhan dibagi jumlah penerima. Lebih dari 30% IP berada di bawah 0,3%, “patokan yang baik untuk dicapai.”
- **Perintah RCPT vs. penerima pesan.** Selisih yang besar menandakan daftar kontak yang sudah usang.
- **Status IP**: Blocked, Bot, atau Junked.

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](https://www.spamresource.com/2026/06/snds-and-jmrp-in-transition.html) 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](https://substrate.office.com/ip-domain-management-snds/Postmaster/Services) (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.

## Dukungan pengirim dan penghapusan dari daftar blokir

**Outlook.com.** Formulir dukungan di [halaman pemecahan masalah Postmaster](https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting) 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](https://learn.microsoft.com/en-us/defender-office-365/external-senders-use-the-delist-portal-to-unblock-yourself) 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.

## Percobaan ulang, throttling, dan peningkatan volume

**Coba ulang sesuai jadwal.** [RFC 5321, bagian 4.5.4.1](https://www.rfc-editor.org/rfc/rfc5321.html#section-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.

## Yang tidak boleh dilakukan

- **Memperbanyak percobaan ulang.** Mengosongkan antrean setiap beberapa menit menumpuk koneksi pada IP yang ingin diperlambat Microsoft, dan malah membuat Anda mendapat 4.7.652.
- **Berganti IP untuk menghindarinya.** IP baru belum punya reputasi dan lebih rentan bermasalah, dan menyebar email ke banyak IP baru adalah taktik spammer snowshoe.
- **Mencoba ulang kode 5xx.** Microsoft melarangnya, dan setelah “beberapa respons kegagalan pengiriman” Anda harus berhenti mengirim ke penerima tersebut.
- **Mengecualikan kontak yang ditunda.** Alamatnya masih valid.
- **Mengirim ulang ke penerima yang ditunda.** Pesan mereka masih dalam antrean. Anda akan mengirim duplikat.
- **Mengubah DNS karena panik.** Mengubah SPF atau DKIM di tengah insiden justru menambah masalah kedua, kecuali Anda menerima `5.7.515`.

Untuk alignment DMARC dan peralihan dari `p=none` ke penegakan, lihat [panduan keterkiriman](/id/blog/email-deliverability) kami. Agar email reset kata sandi dan bukti pembayaran tetap mengalir, [panduan email transaksional](/id/blog/transactional-emails) kami membahas cara mengirimnya dari domain tersendiri.

## Tampilannya di Brew

Brew menjalankan infrastruktur pengiriman dan mencoba ulang kegagalan sementara, jadi Anda tidak perlu mengatur antrean atau batas koneksi. Yang Anda lihat:

- **Peristiwa Tertunda.** Penundaan dicatat sebagai peristiwa Tertunda (`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.
- **Detail pentalan.** Bagian Metadata pada peristiwa terpental berisi jenis pentalan dan pesan dari penyedia.
- **Jumlah lewat API.** Endpoint [ringkasan analitik](https://docs.brew.new/api-reference/public-v1/analytics/brand-overview-totals-rates-timeseries) mengembalikan `deliveryDelayed` dan `pending` di samping jumlah email yang diterima dan terpental. Alat `get_email_analytics` melakukan hal yang sama lewat MCP.
- **Pengecualian yang menghormati 4xx.** Pentalan permanen dan keluhan langsung membuat kontak dikecualikan. Pentalan sementara baru membuat kontak dikecualikan setelah terjadi tiga kali dalam 30 hari.
- **Peningkatan bertahap.** [Pengiriman bertahap](https://docs.brew.new/create-emails/send-options#gradual-send) membagi pengiriman besar menjadi batch berdasarkan persentase per jam atau per hari, yang bisa Anda jeda jika Outlook.com mulai menunda.
- **Kesehatan domain.** Kartu Keterkiriman di setiap domain memberi skor 0 hingga 100 untuk penempatan kotak masuk, reputasi, autentikasi, konten, dan penyiapan pengiriman, yang juga tersedia lewat alat 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.

## Pertanyaan yang sering diajukan

### Apa arti 451 4.7.500 Server busy dari Outlook atau Microsoft 365?

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.

### Berapa lama Microsoft akan terus menunda email saya?

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.

### Apa itu 550 5.7.515 dan bagaimana cara memperbaikinya?

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.

### Haruskah saya memakai alamat IP baru jika Microsoft memblokir IP saya?

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.

### Apakah penundaan dari Microsoft dihitung sebagai pentalan?

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.