Gmail "550-5.7.1 Message Blocked" — Decode Bounce dan Perbaiki (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.

Gmail mengembalikan 550-5.7.1 ketika memblokir pesan karena alasan kebijakan bukan record yang hilang: kebijakan domain pengirim atau penerima, koneksi IPv6 tanpa reverse DNS, atau dugaan spam. Dari 12,145,313 domain yang mengotorisasi server Google sendiri di SPF, hanya 18.5% yang menegakkan DMARC, menurut sensus Defaults.Exposed dari 261 juta domain.

550-5.7.1 adalah penolakan catch-all tertua Gmail, dan perbaikannya bergantung pada kalimat setelah kode di bounce Anda. Di bawah ini: tabel decoder untuk kata-kata yang tepat, kemudian jalur perbaikan per varian — penolakan kebijakan, server IPv6 tanpa reverse DNS, blokir spam atau konten — ditambah kode mirip yang sering dikacaukan dengannya, termasuk keluarga 5.7.26 yang sekarang digunakan Google untuk penolakan kebijakan DMARC yang referensi lama daftarkan di bawah 5.7.1.

Apa sebenarnya arti 550-5.7.1 Gmail?

Dalam skema enhanced-status SMTP (RFC 3463), setiap kode 5.7.x berarti “kegagalan permanen, alasan kebijakan”. Gmail menggunakan 550-5.7.1 sebagai keluarga kebijakan warisannya: blokir kebijakan pengirim atau penerima, blokir reputasi-spam, dan — varian yang mengejutkan sebagian besar admin — email yang tiba melalui IPv6 dari server tanpa record reverse-DNS (PTR).

Google telah mengkodekan ulang varian dari waktu ke waktu. Penolakan kebijakan DMARC (“not accepted due to domain’s DMARC policy”) sekarang ada di bawah 550-5.7.26 dalam referensi terkini Google, meskipun bounce lama di lapangan masih mungkin menampilkannya sebagai 5.7.1; blokir keamanan konten sekarang dikodekan 552 5.7.0. Dua saudara lain sering dikacaukan dengan 5.7.1: 550-5.7.26, keluarga persyaratan-autentikasi (panduan tersendiri), dan 550-5.7.25, kode PTR hilang pada versi IP apa pun. Apapun kodenya, decode teksnya di bawah.

Varian 550-5.7.1 mana yang Anda miliki?

Cocokkan kata-kata dalam non-delivery report (NDR) Anda. Google menyesuaikan string ini dari tahun ke tahun — cocokkan maksudnya, bukan tanda bacanya.

Bounce Anda berbunyi seperti…	Artinya	Jalur perbaikan Anda
”This message does not meet IPv6 sending guidelines regarding PTR records and authentication.”	Server Anda mengirim melalui IPv6 tanpa reverse DNS yang ada (atau tidak cocok)	Record PTR untuk alamat IPv6, atau relay via smarthost provider Anda (di bawah)
“The user or domain that you are sending to (or from) has a policy that prohibited the email that you sent.”	Blokir kebijakan — milik penerima, atau domain Anda sendiri	Hubungi admin penerima; jika DMARC domain Anda sendiri yang berlaku, lihat di bawah
”This message is likely unsolicited email. To reduce the amount of spam sent to Gmail, this message has been blocked.”	Blokir spam/reputasi pada konten, IP, atau domain Anda	Postmaster Tools + kebersihan daftar + unsubscribe satu klik (di bawah)
“This message is likely suspicious due to the very low reputation of the sending domain” (atau “…sending IP address”)	Blokir reputasi — domain atau IP	Jalur reputasi yang sama (di bawah)
“Unauthenticated email from yourdomain is not accepted due to domain’s DMARC policy.” — dikodekan 550-5.7.26 dalam referensi terkini Google; bounce lama mungkin masih menampilkan 5.7.1	Kebijakan DMARC Anda sendiri meminta Gmail menolak pesan yang tidak terautentikasi	Temukan sumber yang tidak terautentikasi — jangan perlonggar kebijakan terlebih dahulu (di bawah)
“…blocked because its content presents a potential security issue.” — sekarang dikodekan 552 5.7.0	Blokir konten/kebijakan (jenis lampiran, reputasi tautan)	Hapus kelas konten yang ditandai; periksa tautan dan lampiran
Kode adalah 550-5.7.25, “the sending IP address doesn’t have a PTR record”	Reverse DNS hilang pada versi IP apa pun	Perbaikan rDNS yang sama seperti varian IPv6
Kode adalah 550-5.7.26	Keluarga persyaratan-autentikasi, bukan 5.7.1	Lihat panduan 550-5.7.26
Kode adalah 421-4.7.0, “Try again later, closing connection.”	Penundaan sementara — rate atau reputasi, bukan blokir permanen	Perlambat, perbaiki autentikasi dan tingkat spam; biasanya hilang sendiri

Bagaimana cara memperbaiki bounce 550-5.7.1?

Jalankan pemindaian gratis di defaults.exposed — ini menilai SPF, DKIM dan DMARC Anda sebagaimana dunia melihatnya, sebelum Anda menyentuh DNS, dan menampilkan apakah varian DMARC bahkan mungkin terjadi di domain Anda.
Baca teks NDR lengkap terhadap tabel decoder — kalimatnya, bukan kodnya, yang mengidentifikasi penyebabnya.
Varian DMARC: temukan sumber pengiriman mana yang gagal autentikasi dan perbaiki sumber tersebut (bagian berikutnya).
Varian IPv6/PTR: tambahkan reverse DNS yang cocok untuk alamat IPv6 server, atau relay melalui smarthost provider Anda.
Varian spam/kebijakan: Postmaster Tools, tingkat spam di bawah 0,10% (persyaratan langit-langit keras Google adalah 0,30%), kebersihan daftar, unsubscribe satu klik RFC 8058.
Kirim tes ulang ke kotak surat Gmail dan pindai ulang — konfirmasi bounce sudah hilang dan nilai mencerminkannya.

Bounce menyebut kebijakan DMARC Anda — mengapa itu adalah kebijakan Anda yang bekerja

Referensi terkini Google mengkodekan string ini sebagai 550-5.7.26, tetapi bounce lama dan dokumen pihak ketiga masih menampilkannya di bawah 5.7.1 — cara kerja keduanya identik. Bunyinya terbalik sampai Anda melihatnya: Gmail memeriksa pesan yang mengklaim berasal dari domain Anda, menemukan bahwa SPF maupun DKIM tidak lulus dengan keselarasan, mencari record DMARC Anda, dan melakukan persis apa yang Anda minta — tolak. Pagar Anda berfungsi. Pertanyaannya adalah apa yang tertangkap di dalamnya: pengirim sah yang terlupakan (CRM, alat faktur, platform newsletter) atau pemalsuan nyata.

Jadi jangan longgarkan kebijakan sebagai langkah pertama. Temukan sumber yang tidak terautentikasi. Dua jebakan menjelaskan sebagian besar kasus:

SPF lulus, tetapi pada domain yang salah. Penerima mengevaluasi SPF terhadap domain Return-Path (RFC5321.MailFrom), bukan header From. Alat SaaS yang mengirim “dari” Anda biasanya lulus SPF pada bounce domain-nya sendiri, yang tidak selaras dengan domain From Anda — sehingga DMARC tetap gagal. Panduan: DMARC gagal tapi SPF dan DKIM lulus.
DKIM lulus, tetapi dengan tanda tangan default. Default gappssmtp.com Google Workspace dan onmicrosoft.com Microsoft terverifikasi dengan baik dan tidak selaras dengan apapun. Lihat DKIM lulus tapi DMARC tetap gagal.

Varian ini lebih jarang dari yang Anda kira: 27,640,987 dari 261,086,232 domain — 10.59% — menegakkan kebijakan DMARC quarantine atau reject, menurut sensus Defaults.Exposed (2026-06-29). 89.41% lainnya tidak pernah melihat bounce ini karena mereka tidak memiliki pagar untuk dipegang. Memperbaiki sumber, bukan kebijakan, dibahas dari ujung ke ujung di panduan perbaikan DMARC.

Bounce menyebut panduan pengiriman IPv6 — perbaikan reverse-DNS

Server modern sering terhubung ke Gmail melalui IPv6 secara default, dan Google mengharuskan alamat IPv6 yang terhubung memiliki record PTR yang me-resolve ke hostname yang me-resolve kembali ke alamat yang sama (forward-confirmed reverse DNS). Lewatkan itu, dan setiap pesan mendapat 550-5.7.1 terlepas dari betapa bersihnya SPF Anda.

Tiga perbaikan, berurutan berdasarkan preferensi:

Atur record PTR untuk alamat IPv6 server Anda — dilakukan di tempat IP berada (panel VPS atau ISP Anda, bukan zona DNS domain Anda), dengan record AAAA yang cocok yang menunjuk kembali.
Relay melalui smarthost provider Anda. Jika Anda tidak bisa mengontrol rDNS, rutekan email keluar melalui relay provider email atau ISP Anda, yang sudah memiliki rDNS yang benar.
Preferensikan transport IPv4 sebagai solusi sementara. Biasanya menyembunyikan gejala karena alamat IPv4 Anda memiliki PTR — solusi sementara, bukan perbaikan. Atur PTR IPv6 saat Anda bisa.

Bounce mengatakan “likely unsolicited email” — jalur reputasi

Di sini autentikasi mungkin baik-baik saja, tetapi filter Gmail tidak mempercayai emailnya. Autentikasi adalah lantai, bukan langit-langit — di antara 12,145,313 domain yang mengotorisasi _spf.google.com, hanya 8.0% yang mengunci SPF dengan ketat -all, sehingga pemeriksaan yang lulus tidak berarti banyak sendiri. (Perbandingan lengkap: provider email mana yang memberikan default SPF terkuat.)

Daftar periksa reputasi:

Daftarkan di Google Postmaster Tools dan pantau dasbor tingkat spam — pertahankan di bawah 0,10%, dan jangan biarkan mencapai batas 0,30% yang ditetapkan panduan pengirim massal Google sebagai persyaratan keras.
Bersihkan daftar Anda. Hapus yang tidak terlibat dan apapun yang dibeli atau di-scrape; kirim hanya kepada orang yang meminta.
Implementasikan unsubscribe satu klik RFC 8058 pada email massal — diwajibkan oleh aturan Google, dan setiap unsubscribe yang bukan klik “spam” melindungi rate Anda.
Pertahankan autentikasi yang selaras (SPF dan DKIM pada domain Anda sendiri) agar reputasi terakumulasi ke domain yang Anda kendalikan.

Pertanyaan yang Sering Diajukan

Apakah 550-5.7.1 sama dengan 550-5.7.26? Tidak. 550-5.7.26 adalah keluarga persyaratan-autentikasi Gmail (SPF/DKIM hilang atau gagal) — dan referensi terkini Google juga mendaftarkan penolakan kebijakan DMARC di sana. 550-5.7.1 adalah keluarga kebijakan yang lebih lama: blokir kebijakan penerima dan pengirim, IPv6-tanpa-PTR, blokir spam dan reputasi. Teks bounce, bukan nomornya, yang memberi tahu Anda perbaikan mana yang berlaku (per 2026-06-29 dan panduan Google terkini).

Haruskah saya mengatur kebijakan DMARC kembali ke p=none untuk menghentikan bounce? Itu menghentikannya dengan meruntuhkan pagar. Hanya 10.59% dari 261,086,232 domain dalam sensus Defaults.Exposed (2026-06-29) yang menegakkan DMARC sama sekali; jika Anda salah satunya, pertahankan dan perbaiki sumber yang tidak terautentikasi — melonggarkan kebijakan membuka kembali pemalsuan domain tepat.

Mengapa Gmail memblokir email saya padahal record SPF saya lulus setiap pemeriksa? Pemeriksa menguji record; Gmail menguji pesan. SPF dievaluasi terhadap domain Return-Path, bukan alamat From yang terlihat, sehingga lulus pada bounce domain vendor tidak melakukan apapun untuk keselarasan DMARC Anda — dan blokir reputasi mengabaikan SPF sepenuhnya. Pemindaian gratis menampilkan lapisan mana yang sebenarnya gagal.

Apakah 550-5.7.1 berarti IP saya ada dalam daftar hitam? Tidak harus. Gmail menjalankan sistem reputasinya sendiri; Anda bisa diblokir oleh Google sementara tidak ada di daftar hitam publik mana pun. Periksa Postmaster Tools untuk pandangan Google — dan perhatikan bahwa memperbaiki autentikasi mencegah kerusakan di masa depan tetapi tidak dengan sendirinya mereset reputasi pengiriman yang buruk.

Kirimkan laporan kepada pemilik

Setelah bounce diperbaiki, jalankan ulang pemindaian dan teruskan laporan yang dinilai kepada pemilik bisnis atau klien yang emailnya memantul. Ini menampilkan, dalam bahasa mudah dipahami, apa yang rusak, apa yang Anda perbaiki, dan di mana domain saat ini berada terhadap baseline 261 juta domain — tepat apa yang mereka butuhkan untuk perpanjangan asuransi atau kuesioner keamanan klien yang menanyakan “apakah Anda mengautentikasi email Anda?”. Bounce yang diperbaiki diam-diam adalah pekerjaan yang tidak terlihat; laporan sebelum-dan-sesudah adalah buktinya.

Periksa domain Anda → · Gmail 550-5.7.26 — perbaikan sesuai urutan persyaratan → · Perbaiki DMARC → · Cara kami menilai → · Hanya data agregat. Data disimpan dan diproses di EU.