Defaults.Exposed › Perbaikan › Guides

Outlook Menolak Email Anda: 550 5.7.515, 550 5.7.509 dan compauth=fail, Dijelaskan dan Diperbaiki (2026)

Diterbitkan 2026-07-08

Angka per 2026-06-29 · metodologi v7. Data sensus agregat dari 261 juta domain yang dinilai. Lihat cara kami menilai.

Dua sistem Microsoft yang berbeda menolak email. Consumer Outlook.com/Hotmail memantul pengirim volume tinggi yang gagal autentikasi (550 5.7.515, diberlakukan sejak Mei 2025); Exchange Online memantul email yang gagal kebijakan DMARC reject Anda sendiri (550 5.7.509). Dari 10,205,070 domain yang mengotorisasi spf.protection.outlook.com, 85.0% memiliki SPF ketat tetapi hanya 21.7% yang menegakkan DMARC, menurut sensus Defaults.Exposed dari 261,086,232 domain.

Sebagian besar masalah “Outlook menolak email saya” sebenarnya bukan penolakan sama sekali — itu adalah email yang diam-diam mendarat di Junk dengan compauth=fail di header. Panduan ini mendekode kode Microsoft, menunjukkan cara membaca header Authentication-Results, dan memandu perbaikan secara berurutan: konfirmasi SPF, aktifkan DKIM untuk domain kustom, terbitkan dan tegakkan DMARC, uji ulang.

Error Microsoft mana yang sebenarnya Anda miliki?

Microsoft menjalankan dua permukaan penerima yang terpisah, dan mereka menolak dengan alasan yang berbeda. Cocokkan gejala Anda terlebih dahulu — diagnosis yang salah membuang satu hari.

Kata-kata tepat NDR berubah; verifikasi string yang Anda kutip terhadap bounce langsung sebelum mengandalkannya.

Apa arti 550 5.7.515?

Ini adalah persyaratan Outlook.com/Hotmail konsumer, bukan error tenant Microsoft 365. Sejak Mei 2025, pengirim lebih dari 5.000 pesan per hari ke alamat Outlook konsumer harus lulus SPF, lulus DKIM, dan menerbitkan record DMARC (setidaknya p=none) yang selaras dengan domain From. Gagal persyaratan itu dan Outlook konsumer menolak dengan kata-kata seperti:

550 5.7.515 Access denied, sending domain [yourdomain.com] does not meet the required authentication level.

Dua hal yang ini bukan: bukan mandat 2026 (jika email Anda baru saja mulai memantul, volume atau DNS Anda yang berubah, bukan aturannya), dan bukan tentang pengaturan tenant M365 penerima. Perbaikannya adalah tangga autentikasi di bawah — dan hari kampanye sesekali yang melewati 5.000/hari ikut dihitung.

Apa arti 550 5.7.509?

Yang satu ini berasal dari Exchange Online Protection pada tenant bisnis, dan berarti kebijakan DMARC Anda sendiri sedang dihormati:

550 5.7.509: Access denied, sending domain [yourdomain.com] does not pass DMARC verification and has a DMARC policy of reject.

Baca itu dengan saksama — ini bukan Microsoft yang sulit. Domain Anda menerbitkan p=reject, pesan ini gagal DMARC, dan penerima melakukan persis apa yang Anda minta. Jika email yang dipantulkan itu sah, beberapa sumber pengiriman (alat newsletter, CRM, perangkat scan-to-email) tidak terautentikasi dengan cara yang selaras. Jangan melemahkan kebijakan; beri sumber itu SPF atau DKIM yang selaras — lihat perbaiki DMARC dan dari p=none ke p=reject.

Mengapa Outlook memasukkan email saya ke Junk dengan compauth=fail alih-alih memantulnya?

Sebagian besar rasa sakit deliverability Microsoft tidak pernah menghasilkan bounce. Pesan diterima, dinilai, dan disimpan di Junk — satu-satunya bukti adalah header Authentication-Results. Di kotak surat penerima (atau kotak surat uji outlook.com Anda sendiri), buka pesan, pilih View message source, dan temukan baris:

Authentication-Results: spf=pass ... dkim=fail ... dmarc=fail action=none ... compauth=fail reason=001

compauth adalah verdict autentikasi komposit Microsoft: bahkan ketika domain tidak menerbitkan record DMARC, Microsoft menerapkan pemeriksaan implisit seperti DMARC. Nilai yang biasa terlihat:

• compauth=fail reason=000 — pesan gagal autentikasi eksplisit: kebijakan DMARC domain Anda adalah quarantine/reject dan pesan gagal memenuhinya.
• compauth=fail reason=001 — pesan gagal autentikasi implisit: domain Anda tidak menerbitkan record auth yang cukup, dan pesan tidak terlihat seperti berasal dari Anda. Tanda tangan klasik “kami tidak pernah mengatur DKIM/DMARC”.
• compauth=fail reason=6xx — varian kegagalan autentikasi implisit; 601 secara spesifik berarti domain pengirim adalah salah satu domain diterima organisasi Anda sendiri (spoofing intra-org, diri-ke-diri).

Pelajarannya: di Microsoft, baca headernya, bukan hanya NDR. Verdict spf=, dkim= dan dmarc= pada baris yang sama memberi tahu Anda persis leg mana yang harus diperbaiki.

Bagaimana cara memperbaiki penolakan dan masuk Junk Outlook?

1. Jalankan pemindaian gratis terlebih dahulu. Ini menilai SPF, DKIM dan DMARC Anda dalam satu pass dan menampilkan leg mana yang gagal sebelum Anda menyentuh DNS.
2. Konfirmasi SPF — biasanya sudah baik-baik saja di Microsoft 365. Record standar adalah v=spf1 include:spf.protection.outlook.com -all, dan setup M365 menempatkannya di sana: 85.0% dari 10,205,070 domain yang mengotorisasi spf.protection.outlook.com sudah berakhir dengan ketat -all (data per 2026-06-29). Satu peringatan: penerima mengevaluasi SPF terhadap domain Return-Path (RFC5321.MailFrom), bukan header From — sehingga alat newsletter bisa lulus SPF pada bounce domain-nya sementara tidak melakukan apapun untuk Anda. Itulah mengapa langkah 3 dan 4 lebih penting.
3. Aktifkan DKIM untuk domain kustom Anda — dua CNAME selector. M365 menandatangani dengan default onmicrosoft.com yang tidak selaras sampai Anda mengaktifkan penandatanganan domain kustom: terbitkan CNAME selector1._domainkey dan selector2._domainkey yang menunjuk ke kunci tenant Anda, kemudian aktifkan penandatanganan di portal Defender. Jalur klik lengkap: siapkan DKIM di Microsoft 365. Jika DKIM menampilkan “pass” tetapi DMARC masih gagal, Anda berada di jebakan tanda tangan default.
4. Terbitkan DMARC, kemudian tegakkan. Mulai dengan v=DMARC1; p=none; rua=mailto:... untuk mendapatkan laporan, perbaiki setiap sumber yang sah yang diungkapkannya, kemudian tingkatkan ke p=quarantine dan p=reject — jalur bertahap ada di perbaiki DMARC. Ini adalah langkah yang paling banyak dilewati toko Microsoft: hanya 21.7% dari domain yang mengirim M365 yang menegakkan DMARC.
5. Uji ulang dengan membaca header. Kirim ke kotak surat outlook.com konsumer, buka sumber pesan, dan konfirmasi spf=pass, dkim=pass, dmarc=pass dan compauth=pass.
6. Pengirim volume tinggi: penuhi persyaratan Outlook konsumer. Lebih dari 5.000/hari Anda juga membutuhkan From/reply-to yang valid dan dipantau, unsubscribe yang berfungsi, dan daftar yang bersih — autentikasi membersihkan 5.7.515; tingkat keluhan membuat Anda keluar dari blok IP S3140/S3150. Jika Anda sudah diblokir IP, memperbaiki SPF/DKIM/DMARC tidak mengangkat blok: minta penghapusan daftar melalui dukungan pengirim Microsoft, dan perlakukan autentikasi sebagai alasan Anda tidak akan kembali.

Mengapa begitu banyak domain Microsoft 365 masih gagal?

Karena default melakukan langkah pertama untuk Anda dan tidak satu pun dari sisanya. Di antara 10,205,070 domain yang mengotorisasi spf.protection.outlook.com, 85.0% membawa SPF ketat — record yang diberikan M365 kepada Anda saat setup — tetapi hanya 21.7% yang menegakkan DMARC, menurut sensus Defaults.Exposed dari 261,086,232 domain. M365 memberi Anda SPF ketat secara default, kemudian sebagian besar tenant berhenti di sana — populasi tepat yang dibangun compauth untuk menangkap (meskipun masih di depan 10.59% penegakan DMARC di semua domain yang dinilai). Perbandingan provider lengkap: tabel liga SPF provider email kami.

Pertanyaan yang Sering Diajukan

Apakah 550 5.7.515 adalah error Microsoft 365? Tidak. Ini berasal dari Outlook.com/Hotmail konsumer dan menarget pengirim >5.000 pesan/hari, diberlakukan sejak Mei 2025. Penolakan Exchange Online bisnis menggunakan kode berbeda — paling umum 550 5.7.509 (kebijakan DMARC reject Anda) atau 5.7.511 (pengirim terlarang).

Kami mendapat 550 5.7.509 tetapi emailnya sah — haruskah kami menurunkan p=reject? Tidak — kebijakan Anda menangkap sumber yang tidak terautentikasi, itulah cara kerjanya. Temukan sumber di header atau laporan DMARC Anda dan beri DKIM yang selaras (atau SPF yang selaras). Melemahkan ke p=none membuka kembali pemalsuan domain-tepat untuk semua orang.

Apakah compauth=fail berarti seseorang memalsukan kami? Belum tentu. reason=001 biasanya berarti email Anda sendiri tidak bisa membuktikan dirinya — tidak ada DKIM yang selaras, tidak ada DMARC. Hanya 21.7% dari 10,205,070 domain yang mengirim M365 yang menegakkan DMARC (data per 2026-06-29), sehingga Microsoft menerapkan pemeriksaan implisit kepada semua orang lain, dan email sah yang tidak terautentikasi juga gagal.

Saya mengirim kurang dari 5.000 email sehari — bisakah saya mengabaikan ini? Anda akan menghindari 550 5.7.515, tetapi tidak folder Junk: compauth berlaku pada volume berapa pun. Gmail menerapkan permainan yang sama — lihat panduan Gmail 550 5.7.26. Perbaikannya gratis; hambatannya adalah kesadaran, bukan biaya.

Kirimkan laporan kepada pemilik

Jika Anda memperbaiki email untuk orang lain — klien, atasan Anda, perusahaan yang fakturnya memantul — selesaikan pekerjaan dengan bukti. Jalankan ulang pemindaian gratis setelah DNS menetap dan teruskan laporan yang dinilai. Ini menampilkan SPF, DKIM dan DMARC menjadi hijau dalam bahasa yang dapat dibaca pemilik bisnis, dan itulah artefak yang mereka butuhkan lain kali perpanjangan asuransi siber atau kuesioner keamanan pelanggan menanyakan apakah email mereka terautentikasi. Diperbaiki itu bagus; diperbaiki yang terbukti adalah yang membuat Anda dibayar dan mereka terlindungi.

Periksa domain Anda gratis

Lihat leg mana yang membuat Microsoft gagal — SPF, DKIM, DMARC — secara privat dan hanya untuk pemilik.

Periksa domain Anda → · Perbaiki DMARC → · DKIM lulus tapi DMARC gagal → · Cara kami menilai → · Hanya data agregat. Data disimpan dan diproses di EU.