Defaults.Exposed › Perbaikan › Guides
Yahoo 554 5.7.9 'Message Not Accepted for Policy Reasons' — Perbaikan untuk Pengirim (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.
Yahoo mengembalikan 554 5.7.9 ketika pesan melanggar kebijakan pengirimnya — biasanya kegagalan autentikasi SPF/DKIM atau kebijakan DMARC yang ditegakkan Yahoo. Perbaiki dengan membuat SPF atau DKIM lulus, selaras dengan domain From Anda. Hanya 10.59% domain yang menegakkan DMARC — 27,640,987 di antaranya — menurut sensus Defaults.Exposed dari 261,086,232 domain (2026-06-29).
Perbaikannya adalah DNS dan higienitas daftar, bukan formulir banding: diagnosis kebijakan mana yang Anda langgar, dapatkan SPF atau DKIM lulus untuk domain yang benar, selaraskan leg yang menang dengan alamat From Anda, terbitkan DMARC jika Anda mengirim dalam volume, dan tambahkan unsubscribe satu klik. Di bawah ini adalah urutan langkah ditambah decoder untuk kode saudara Yahoo — 553 5.7.1, 553 5.7.2 dan penangguhan 421.
Apa arti error Yahoo 554 5.7.9?
Sejak Februari 2024, Yahoo menegakkan keluarga aturan pengirim yang sama dengan Gmail: setiap pengirim harus lulus SPF atau DKIM; pengirim massal harus lulus keduanya, dengan mekanisme yang lulus selaras dengan domain From, menerbitkan kebijakan DMARC, menawarkan unsubscribe satu klik RFC 8058 pada email berlangganan, dan menjaga tingkat keluhan rendah. Yahoo dengan sengaja menolak menerbitkan ambang volume untuk “massal” — aturan paralel Google menetapkan batas pada 5.000 pesan sehari, dan itu adalah tolok ukur praktis yang digunakan sebagian besar pengirim. Kotak surat AOL berjalan pada infrastruktur yang sama, sehingga satu perbaikan mencakup keduanya.
554 5.7.9 adalah penolakan kebijakan permanen Yahoo. Bentuk klasiknya berbunyi: “554 5.7.9 Message not accepted for policy reasons. See https://postmaster.yahooinc.com/error-codes” — sengaja generik, karena mencakup seluruh keluarga kebijakan: kegagalan autentikasi, penegakan DMARC (termasuk p=reject domain pengirim sendiri), dan pelanggaran panduan pengirim. Tidak seperti 550-5.7.26 Gmail, teksnya jarang memberi tahu Anda leg mana yang gagal, sehingga langkah 1 di bawah — pemindaian luar-ke-dalam domain Anda — lebih penting di sini, bukan kurang.
Celah mendasarnya sangat besar: di seluruh sensus 2026-06-29 dari 261,086,232 domain, 46.4% (121,145,609) tidak menerbitkan record SPF sama sekali, dan hanya 10.59% yang menegakkan DMARC. Yahoo tidak meminta sesuatu yang eksotis — ia menolak email dari mayoritas yang tidak terautentikasi.
Kode bounce Yahoo mana yang Anda miliki?
Cocokkan NDR Anda dengan tabel ini — perlakukan setiap entri sebagai “bounce seperti:”, karena Yahoo secara resmi menerbitkan kategori error alih-alih string verbatim, dan kata-kata tepat serta tag alasan dalam kurung (seperti [TSS04]) diamati di lapangan dan berubah dari waktu ke waktu. Periksa fragmen terhadap bounce aktual Anda dan daftar kode error Yahoo Sender Hub.
| Kode | Bounce seperti (fragmen) | Artinya | Di mana perbaikannya |
|---|---|---|---|
| 554 5.7.9 | ”Message not accepted for policy reasons” | Penolakan kebijakan permanen — kegagalan autentikasi, DMARC, atau panduan pengirim | Panduan ini, langkah 2–6 |
| 553 5.7.1 | Teks kebijakan IP- atau konten, sering dengan tag alasan dalam kurung (mis. referensi blocklist) | Yahoo tidak akan menerima dari IP/sumber ini — blokir reputasi atau kebijakan | Langkah 2–3, kemudian pengiriman bersih; auth mencegah kambuhan tetapi tidak mendelist IP |
| 553 5.7.2 | ”will be permanently deferred” / percobaan ulang tidak akan berhasil | Kegagalan reputasi berkelanjutan pada IP pengiriman — versi keras dari penangguhan | Langkah 2–7, warm-up IP baru jika self-hosted |
| 421 4.7.0 | ”temporarily deferred due to unexpected volume or user complaints” (sering tag [TSS]) | Penangguhan sementara — lonjakan rate atau keluhan, bukan blokir permanen | Antrian percobaan ulang akan terkuras; perbaiki langkah 5–7 agar tidak berulang |
Dua catatan jujur tentang tabel tersebut. Penangguhan 421 adalah Yahoo yang memperlambat Anda saat ia memutuskan — hormati percobaan ulang, perlambat, dan perbaiki sisi keluhan; memaksakan antrian mengubah penangguhan menjadi 553. Dan tidak ada record DNS yang mendelist IP yang masuk blocklist: autentikasi menghentikan penolakan kebijakan dan mencegah kambuhan, tetapi reputasi IP hanya pulih melalui pengiriman bersih dari waktu ke waktu.
Bagaimana cara memperbaiki 554 5.7.9, langkah demi langkah?
- Jalankan pemindaian gratis di defaults.exposed terlebih dahulu. Ini membaca record SPF, DKIM dan DMARC langsung Anda dari luar — tampilan yang sama yang didapatkan Yahoo — dan menampilkan leg mana yang gagal sebelum Anda menyentuh DNS.
- Dapatkan SPF lulus untuk domain yang benar-benar diperiksa Yahoo. Pengaman yang menangkap setengah dari semua pengirim: penerima mengevaluasi SPF terhadap domain Return-Path (RFC5321.MailFrom), bukan header From. Jika alat newsletter atau CRM mengirim untuk Anda, SPF biasanya dievaluasi terhadap bounce domain mereka — itulah mengapa record SPF Anda sendiri bisa sempurna dan tidak relevan. Konfirmasi domain mana yang mengembalikan bounce Anda, kemudian pastikan SPF domain tersebut mencakup sumber pengiriman.
- Aktifkan penandatanganan DKIM dengan domain Anda sendiri. Di provider atau ESP Anda, aktifkan DKIM domain kustom (biasanya dua atau tiga record CNAME) agar tanda tangan mengatakan
d=yourdomain.com, bukan default platform. Panduan platform: kegagalan DMARC Mailchimp, Brevo dan Klaviyo. - Buat leg yang lulus selaras dengan domain From Anda. Persyaratan Yahoo — seperti DMARC — peduli tentang keselarasan: SPF atau DKIM lulus untuk domain yang cocok dengan yang ada di alamat From Anda. Jika pemindaian Anda menampilkan SPF dan DKIM hijau tetapi Yahoo masih menolak, Anda berada dalam jebakan keselarasan — lihat DMARC gagal tapi SPF dan DKIM lulus.
- Terbitkan record DMARC jika Anda mengirim dalam volume. Yahoo memerlukan setidaknya
p=nonedengan alamat pelaporan dari pengirim massal — tidak ada angka volume keras yang diterbitkan, jadi perlakukan 5.000/hari Google sebagai tolok ukur praktis. Ini adalah satu record TXT di_dmarc— lihat panduan perbaikan DMARC untuk record dan rencana peningkatan, dan panduan setup DMARC IONOS untuk contoh panel kontrol. Anda akan berada di depan 89.41% domain dengan menegakkannya akhirnya. - Tambahkan unsubscribe satu klik RFC 8058 (header
List-Unsubscribe+List-Unsubscribe-Post) pada email pemasaran dan berlangganan, dan hormati unsubscribe dalam dua hari. ESP yang terkemuka menambahkan ini secara otomatis setelah autentikasi domain aktif — verifikasi di header pesan yang dikirim. - Pertahankan keluhan rendah. Yahoo memberi bobot besar pada tindakan pengguna “tandai sebagai spam” — pertahankan tingkat spam di bawah 0,3% — dan lonjakan keluhan berkelanjutan adalah jalan utama dari penangguhan 421 ke penolakan 553/554. Daftar untuk loop umpan balik keluhan Yahoo melalui Sender Hub-nya, pangkas alamat yang tidak aktif, dan jangan pernah mengirim ke daftar yang dibeli.
Sebagian besar pengirim mengatasi 554 5.7.9 pada langkah 2–4; langkah 5–7 adalah yang membuat Anda keluar dari siklus penangguhan setelahnya. Untuk daftar persyaratan lengkap di kedua provider — ambang batas, header, angka tingkat spam — lihat artikel referensi kami tentang persyaratan pengirim Google dan Yahoo; panduan ini tetap fokus pada memperbaiki bounce.
Apakah aturan Yahoo berlaku untuk pengirim kecil?
Daftar periksa massal — keduanya SPF dan DKIM, keselarasan, DMARC diterbitkan, unsubscribe satu klik — secara formal berlaku untuk pengirim volume signifikan, dan Yahoo secara eksplisit menolak memberikan angka pada “signifikan” (aturan paralel Google menggunakan 5.000 pesan sehari, tolok ukur praktis umum). Tetapi autentikasi dasar diharapkan dari semua orang, dan 554 5.7.9 tidak memeriksa volume Anda sebelum menyala: pengirim kecil terkena melalui infrastruktur bersama ESP mereka, melalui p=reject domain mereka sendiri dengan email yang tidak selaras, atau sekadar dengan mengirim dari domain tanpa autentikasi sama sekali — 46.4% domain tanpa record SPF (sensus 2026-06-29). Perlakukan langkah 1–4 sebagai wajib pada volume berapa pun.
Apakah ini sama dengan 550-5.7.26 Gmail?
Keluarga aturan yang sama, dialek yang berbeda. Google dan Yahoo mengumumkan persyaratan mereka bersama-sama pada akhir 2023 dan keduanya mulai menegakkan pada Februari 2024, sehingga domain yang diperbaiki untuk satu pada dasarnya diperbaiki untuk yang lain. Perbedaan praktis: teks bounce Gmail biasanya menyebutkan mekanisme yang gagal, 554 5.7.9 Yahoo biasanya tidak; dan Yahoo lebih condong pada penangguhan IP yang didorong keluhan. Bounce di keduanya? Perbaiki di sini sekali, kemudian periksa spesifik Gmail dalam panduan 550-5.7.26.
Pertanyaan yang Sering Diajukan
Apakah 554 5.7.9 berarti Yahoo telah memblokir domain saya? Biasanya tidak. Ini adalah penolakan kebijakan — paling sering autentikasi — bukan putusan reputasi, dan sepenuhnya dapat diperbaiki di DNS. Ini juga adalah medan yang sangat umum untuk berdiri: hanya 10.59% dari 261,086,232 domain yang menegakkan kebijakan DMARC per sensus 2026-06-29. Penolakan 553 5.7.2 persisten setelah auth Anda bersih adalah kasus reputasi.
Mengapa newsletter saya bounce di Yahoo ketika alamat From adalah @yahoo.com?
Karena Yahoo menerbitkan p=reject pada domain konsumennya sendiri sejak 2014 — layanan pihak ketiga yang mengirim Dari @yahoo.com gagal DMARC Yahoo sendiri dan ditolak, secara desain. Perbaikannya struktural: kirim dari domain Anda sendiri dengan autentikasinya sendiri, bukan dari alamat email gratis. Setup domain kustom ESP Anda adalah jalannya — lihat panduan platform newsletter.
Berapa lama setelah memperbaiki DNS Yahoo akan menerima email saya? Perbaikan autentikasi berlaku segera setelah record baru Anda terlihat — menit hingga beberapa jam, hingga 48 untuk TTL yang lambat. Pemulihan reputasi lebih lambat: penangguhan 421 memudar selama berhari-hari pengiriman bersih tanpa keluhan, dan penangguhan permanen 553 5.7.2 bisa membutuhkan berminggu-minggu atau warm-up baru.
Kirimkan laporan kepada pemilik
Jika Anda membersihkan bounce ini untuk klien, jangan tutup tiket dengan “Yahoo kini menerima email kami lagi”. Jalankan ulang pemindaian gratis setelah perubahan Anda dan teruskan laporan yang dinilai kepada pemilik bisnis. Ini menampilkan, dalam bahasa yang mudah dipahami, bahwa domain sekarang mengautentikasi emailnya dan di mana masih kurang — bukti yang mereka butuhkan untuk perpanjangan asuransi siber dan kuesioner keamanan pemasok. Anda memperbaiki bounce; laporan membuktikannya.
Periksa domain Anda → · Panduan Gmail 550-5.7.26 → · Perbaiki DMARC → · Cara kami menilai → · Hanya data agregat. Data disimpan dan diproses di EU.