Di halaman iniOutlook.com dan aturan Mei 2025
"Outlook" terdiri dari tiga filter berbeda, dan cara memperbaikinya bergantung pada filter mana yang memindahkan email Anda ke Junk. Ada Outlook.com, layanan email konsumen Microsoft, yang juga menangani alamat hotmail.com, live.com, dan msn.com. Ada Microsoft 365, yaitu kotak surat bisnis berbayar yang digunakan perusahaan, tempat admin di perusahaan penerima menetapkan kebijakan spam. Lalu ada aplikasi Outlook di komputer seseorang, yang dapat menjalankan filter Junk sendiri di atas keputusan server. Aturan pengirim yang diumumkan Microsoft pada 2025 hanya berlaku untuk yang pertama.
Jadi, sebelum mengubah satu pun catatan DNS, saya melihat alamat penerima. Alamat hotmail.com atau outlook.com berarti aturan konsumen di bawah ini berlaku. Alamat perusahaan yang menjalankan emailnya di Microsoft berarti kebijakan tenant, yang dibuat oleh tim IT perusahaan tersebut.
Outlook.com dan aturan Mei 2025
Pada April 2025, Microsoft mengumumkan persyaratan untuk domain yang mengirim lebih dari 5.000 email per hari ke layanan konsumennya, dan halaman kebijakan Postmaster menyebutkan bahwa aturan tersebut mulai berlaku pada 5 Mei 2025. Di atas volume tersebut:
- SPF harus lolos untuk domain pengirim.
- DKIM harus lolos.
- DMARC harus dipublikasikan dengan "setidaknya p=none" dan selaras dengan SPF atau DKIM, "sebaiknya keduanya". Halaman kebijakan tersebut menambahkan bahwa
p=rejectdirekomendasikan.
Artikel dukungan tentang bounce menjelaskannya dengan sedikit berbeda. Artikel tersebut menghitung 5.000 pesan atau lebih ke layanan konsumen Microsoft yang semuanya menggunakan domain yang sama di alamat From, menyatakan bahwa pemeriksaan SPF dan DKIM harus sama-sama lolos, dan setelah suatu domain mencapai batas tersebut, Microsoft mengharapkan "semua pesan dari pengirim dalam domain tersebut" memenuhi aturan, bukan hanya newsletter yang membuat volumenya melewati batas. Contoh DMARC yang diberikan hampir sesingkat mungkin untuk sebuah record:
Hostname: _dmarc
TXT value: v=DMARC1; p=noneSaya akan menambahkan alamat pelaporan, rua=mailto:dmarc@example.com atau alamat mana pun yang emailnya benar-benar Anda baca. Outlook.com memang mengirim laporan agregat (FAQ Microsoft menyatakan bahwa mereka mengirim RUA dan tidak berencana mengirim RUF), dan pemeriksa DMARC akan menunjukkan apakah alamat yang Anda cantumkan dapat menerimanya.
Google menetapkan batas 5.000 per hari yang sama untuk Gmail pada Februari 2024 dan mulai meningkatkan penerapan aturan, termasuk penolakan, pada November 2025. Yahoo menerapkan daftar persyaratan serupa tanpa menyebutkan ambang batas.
Cara aturan tersebut diterapkan berubah ketika pengumumannya masih baru. Postingan awal menyatakan bahwa email yang tidak mematuhi aturan akan masuk ke Junk terlebih dahulu dan mungkin ditolak kemudian. Pembaruan bertanggal 29 April menyatakan bahwa Microsoft memutuskan untuk langsung menolaknya, tetapi postingan yang sama masih memuat paragraf lama tentang masuk ke Junk terlebih dahulu di bagian bawah. Penafsiran yang paling hati-hati saat ini adalah bahwa sejak 5 Mei 2025, email yang tidak mematuhi aturan masuk ke Junk, dan Outlook.com kini juga menolaknya dengan pesan berikut:
550 5.7.515 Access denied, sending domain example.com does not meet the required authentication level.
Saya belum menemukan tanggal yang dipublikasikan untuk peralihan ke penolakan. Artikel dukungan tersebut hanya menjelaskannya dalam bentuk waktu sekarang.
Penjelasan dari kode bounce
Bounce dari Outlook.com lebih berguna daripada pesan yang hanya masuk ke folder Junk, karena bounce menyebutkan alasannya. Halaman pemecahan masalah Microsoft memiliki tabel kode, dan berikut kode yang biasanya muncul untuk pengirim biasa:
| Kode | Arti menurut Microsoft |
|---|---|
550 5.7.515 | Domain mengirim lebih dari 5.000 email per hari dan tidak diautentikasi dengan SPF, DKIM, serta DMARC |
550 SC-001 | Penolakan berdasarkan kebijakan, "content with spam-like characteristics or IP/domain reputation" |
550 SC-004 | Pemblokiran IP Anda setelah ada keluhan tentang email yang dikirim dari IP tersebut |
421 RP-001 | Pembatasan laju pada IP yang terhubung, juga karena reputasi |
Kode 550 5.7.1 biasa tanpa kode khusus Microsoft merupakan jenis penolakan lain, dan tersedia halaman terpisah untuk memahami kode tersebut.
Pengirim pihak ketiga dan persyaratan SPF
Banyak domain mengirim melalui beberapa layanan sekaligus: platform newsletter, CRM, help desk, dan penagihan. Setiap layanan mengirim dengan domain Anda di baris From, dan semuanya harus tercakup dalam record Anda. Saat ditanya apakah aturan tersebut tetap berlaku ketika penyedia mengirim untuk Anda, FAQ Microsoft menjawab, "Ya. Meskipun Anda menyerahkan pengiriman kepada pihak lain, autentikasi tetap terkait dengan domain Anda." Artikel dukungannya menjelaskan hal yang perlu diverifikasi: DKIM menandatangani dengan domain Anda, dan record SPF Anda "menyertakan alamat IP atau nilai include yang diwajibkan oleh layanan tersebut".
Di sinilah persyaratan agar SPF dan DKIM sama-sama lolos menjadi membingungkan. Banyak platform menggunakan alamat bounce di domain mereka sendiri, dan Return-Path inilah yang sebenarnya diperiksa oleh SPF. SPF kemudian lolos untuk platform tersebut, sehingga memenuhi bagian "harus lolos", sedangkan penyelarasan DMARC harus berasal dari tanda tangan DKIM dengan domain Anda. Jika platform justru menandatangani dengan domainnya sendiri, Anda mendapatkan dua hasil lolos tanpa penyelarasan, dan DMARC fail yang terjadi setelahnya adalah inti masalah 5.7.515. Artikel dukungan tersebut juga meminta Anda memeriksa apakah domain Return-Path selaras dengan domain From.dua hasil lolos, tanpa penyelarasan: keseluruhan masalah 5.7.515
Setiap layanan yang Anda tambahkan ke SPF juga menggunakan kuota lookup DNS. FAQ Microsoft menjelaskannya seperti ini: "Jika Anda melebihi 10 lookup DNS, pemeriksaan SPF Anda mungkin gagal." Pemeriksa SPF menghitungnya untuk Anda, dan jika jumlahnya melebihi batas, berikut cara menurunkannya hingga kurang dari sepuluh. Pemeriksa DKIM melakukan pemeriksaan kecocokan untuk selector setiap platform.
Microsoft 365 difilter oleh kebijakan pihak lain
Organisasi Microsoft 365 memiliki kebijakan anti-spam yang dikonfigurasi oleh adminnya. Secara default, spam, spam dengan tingkat keyakinan tinggi, dan email massal masuk ke folder Junk Email, sedangkan phishing masuk ke karantina dan phishing dengan tingkat keyakinan tinggi selalu dikarantina. Dari sisi pengirim, karantina adalah hasil yang paling merugikan karena penerima tidak akan menemukan pesan tersebut di folder mana pun kecuali mereka mencarinya. Kebijakan default menyimpannya di sana selama 15 hari, sedangkan preset Standard dan Strict selama 30 hari.
Email massal memiliki ukurannya sendiri, yaitu bulk complaint level. BCL 1 hingga 3 menunjukkan pengirim massal dengan sedikit keluhan, sedangkan 8 atau 9 menunjukkan pengirim dengan banyak keluhan. Kebijakan default mengirim email massal ke Junk mulai BCL 7, preset Standard mulai 6, dan Strict mulai 5. Sejak Juli 2026, ada lapisan yang lebih baru: email massal yang bersifat promosi mendapat tag Promotions berapa pun BCL-nya, dan jika admin telah mengaktifkan "Bulk moves enabled", email tersebut masuk ke folder Promotions. Itu bukan spam, tetapi juga bukan Inbox. Fitur ini masih diluncurkan secara bertahap.
Kedua sistem Microsoft tersebut tidak sepenuhnya terpisah. Microsoft menyatakan bahwa pemfilteran spam Microsoft 365 "belajar dari ancaman spam dan phishing yang diketahui serta masukan pengguna dari platform konsumen kami, Outlook.com", sehingga laporan dari pembaca hotmail.com turut memengaruhi filter yang digunakan inbox bisnis.
Admin juga dapat memasukkan pengirim ke daftar yang diizinkan, yang melewati sebagian besar perlindungan kecuali malware dan phishing dengan tingkat keyakinan tinggi. Jika perusahaan mitra terus menerima faktur Anda di Junk, tim IT mereka dapat melihat keputusan filter yang sebenarnya.
Membaca hasil keputusan di header
Jika Anda bisa mendapatkan pesan sebagaimana diterima oleh mailbox Microsoft 365, header anti-spam menyatakan keputusan secara langsung. X-Forefront-Antispam-Report memuat beberapa bidang yang perlu Anda ketahui:
SFV:SPMberarti pemfilteran spam menandainya sebagai spam,SFV:NSPMberarti bukan spam, danSFV:SFEberarti pemfilteran dilewati karena pengirim ada dalam daftar Safe Senders pengguna.CATmenunjukkan kategori kebijakan yang diterapkan:SPM,HSPM(spam dengan tingkat keyakinan tinggi),BULK,PHSH,SPOOF.SCLadalah angka, yaitu -1 atau 0 hingga 9. Panduan lama menganggapnya sebagai keputusan akhir. Halaman SCL Microsoft saat ini menyatakan bahwa nilai tersebut "doesn't determine whether spam filtering identifies a message as Spam or High confidence spam", jadi bacaCATterlebih dahulu.
Header tersebut juga memuat compauth, yaitu hasil gabungan Microsoft yang dibuat berdasarkan SPF, DKIM, DMARC, dan bagian lain dari pesan. Kode alasan 001 berarti autentikasi implisit gagal, biasanya karena domain pengirim tidak menerbitkan catatan autentikasi atau hanya menggunakan kebijakan yang lemah.
SNDS dan JMRP, kini di situs Postmaster
Smart Network Data Services, atau SNDS, kini berada di situs Postmaster baru dan menggantikan situs lama di sendersupport.olc.protection.outlook.com. SNDS melaporkan data per alamat IP, jadi Anda harus membuktikan bahwa Anda memiliki rentang IP sebelum data apa pun ditampilkan. Data tersebut mencakup volume, tingkat keluhan, dan warna yang menunjukkan seberapa banyak lalu lintas Anda dinilai sebagai spam oleh filter: hijau di bawah 10%, kuning antara 10% dan 90%, merah di atas 90%. Akses kini kedaluwarsa 10 bulan setelah persetujuan atau migrasi dan harus diperpanjang.
Untuk pengirim kecil, SNDS mungkin tidak menampilkan data sama sekali karena alamat IP yang mengirim kurang dari 100 pesan pada hari tertentu dapat dilewati. Jika Anda mengirim melalui IP bersama milik suatu platform, Anda tidak memiliki alamat tersebut dan tidak dapat mendaftarkannya.
JMRP, Junk Mail Reporting Program, adalah sistem umpan balik. Daftarkan melalui SNDS, lalu Microsoft akan mengirimkan header tertentu dari pesan yang ditandai sebagai junk oleh pengguna Outlook.com, biasanya mulai dalam waktu 72 jam. Tambahkan IP baru ke JMRP saat Anda menambahkannya.
Microsoft menyebut tingkat keluhan junk sebagai "salah satu faktor utama" dalam reputasi pengirim, dan FAQ SNDS menyebut tingkat keluhan di bawah 0,3% sebagai "target yang baik untuk dicapai". IP baru memerlukan waktu. Microsoft menyatakan bahwa IP baru dapat mencapai kapasitas penuh "dalam beberapa minggu atau lebih cepat, tergantung pada volume dan akurasi daftar". Dan tidak, tidak ada daftar yang dapat Anda beli agar diterima. Halaman pemecahan masalah menanyakan apakah Outlook.com menyediakan allow list yang dapat dimasuki pengirim dan menjawab "Tidak."
Hal yang dapat diubah oleh penerima
Sebagian pengaturan ini berada di sisi penerima, dan wajar jika Anda meminta pembaca untuk membantu. Di Outlook.com (Settings, lalu Mail, lalu Junk email), pengguna dapat menandai pesan sebagai Not junk atau menambahkan pengirim ke Safe senders and domains. Daftar tersebut dapat menampung hingga 10.000 entri, dan Microsoft menyatakan bahwa tautan serta gambar dari pengirim dalam daftar itu biasanya diaktifkan secara default. Pengguna yang menerapkan aturan ketat juga dapat mengaktifkan mode "exclusive", yang hanya menerima email dari Contacts dan Safe Senders.
Tombol Junk bekerja sebaliknya. Microsoft menggunakan laporan tersebut untuk menentukan apakah email berikutnya dari pengirim yang sama harus diblokir. Secara terpisah, rekomendasinya bagi pengirim meminta tautan berhenti berlangganan yang "terlihat jelas". Teks Microsoft tidak menyebutkan header List-Unsubscribe sekali klik yang diwajibkan Gmail dan Yahoo, tetapi karena kampanye yang sama dikirim ke ketiganya, saya akan menambahkan header tersebut di semua email (kedua header tersebut).
Aplikasi desktop memiliki Junk Email Filter tersendiri. Secara default, pengaturannya adalah "No Automatic Filtering", dengan opsi Low, High, dan "Safe Lists Only" di atasnya. Opsi terakhir menganggap semua email dari luar daftar aman pengguna sebagai junk. Daftar aman dan daftar blokirnya disinkronkan ke server dan juga digunakan di sana.
Lalu ada Focused Inbox, yang membagi inbox menjadi Focused dan Other serta, menurut Microsoft, "menyaring sumber yang mengganggu seperti email yang dibuat secara otomatis atau dikirim secara massal". Other adalah tab di inbox, dan menurut pemahaman saya, newsletter yang berada di sana sudah lolos penyaringan spam.
Menguji sebelum pengiriman sebenarnya
Halaman pemecahan masalah Microsoft sendiri menyatakan bahwa mereka "sangat menyarankan Anda melakukan pengujian email sebelum mengirim komunikasi sebenarnya". Langkah tersebut dapat Anda lakukan dengan Email Spam Tester. Anda mengirim pesan yang sebenarnya ke alamat yang dibuat oleh halaman tersebut, dari server atau platform yang memang akan Anda gunakan, lalu laporan akan menampilkan 42 pemeriksaan: SPF, DKIM, dan DMARC beserta alignment, reverse DNS, IP pengirim pada 21 daftar blokir (mengapa hal tersebut penting), header berhenti berlangganan, dan konten. Pemeriksaan yang gagal dilengkapi rencana perbaikan dan catatan DNS yang dapat disalin. Poin untuk setiap perbaikan berasal dari tabel penilaian.
Tambahkan uji penempatan inbox, lalu pesan yang sama juga dikirim ke inbox di Gmail, Outlook, Yahoo, dan penyedia lain. Laporan menunjukkan tempat pesan masuk di setiap penyedia berdasarkan pembacaan langsung dari mailbox, termasuk Focused atau Other jika penyedia menggunakan pengelompokan tersebut. Layanan ini gratis dan tidak memerlukan pendaftaran. Dokumentasi menjelaskan setiap pemeriksaan dan jumlah poinnya.
Jika langkah berikutnya adalah mengirim tiket dukungan, perhatikan bahwa formulir deliverability Microsoft hanya menerima kasus terkait alamat @outlook.com, @hotmail.com, @live.com, dan @msn.com. Halaman kebijakannya memperingatkan bahwa jika Anda tidak mematuhinya, "tim dukungan kami mungkin tidak dapat membantu Anda."