Email yang terpental memberi tahu Anda sesuatu yang sering kali bisa Anda ketahui sebelum mengirim: bahwa alamat itu tidak ada. Untuk cold outreach, di mana alamat berasal dari situs web, direktori, dan kartu nama, bukan dari formulir pendaftaran, sebagian dari daftar mana pun akan sudah usang.
Panduan ini ditujukan bagi siapa pun yang akan mengirim email ke daftar yang tidak mereka bangun lewat opt-in — tim penjualan, pendiri, agensi. Kami (Outreach) menjelaskan tiga pemeriksaan yang memberi tahu Anda apakah sebuah alamat dapat menerima email, di mana pemeriksaan itu berhenti berfungsi, dan cara membaca kode email terpental yang Anda terima ketika sebuah pesan tetap gagal.
Jawaban singkatnya di awal: Anda biasanya dapat memastikan bahwa sebuah alamat ada tanpa mengirim email ke alamat itu, tetapi tidak selalu — dan mengetahui kapan Anda tidak bisa tahu sama bergunanya dengan jawabannya sendiri.
Mengapa Anda harus memverifikasi alamat email sebelum mengirim?
Karena penyedia layanan email meminta pengirim menghapus alamat yang tidak valid, dan setiap email terpental adalah pesan yang tidak sampai ke siapa pun. Praktik terbaik Sender Hub Yahoo menyatakan: "Hapus penerima yang tidak valid dari daftar Anda dengan segera." Pedoman pengirim email Google menyatakan agar "Berhentikan langganan secara otomatis bagi penerima yang memiliki beberapa pesan terpental," dan, "Jika pesan mulai terpental atau mulai ditunda, kurangi volume pengiriman sampai tingkat kesalahan SMTP menurun."
Singkatnya: penyedia layanan memperhatikan bagaimana Anda menangani alamat yang buruk. Memeriksa sebelum mengirim berarti lebih sedikit email terpental yang harus ditangani sesudahnya, dan gambaran yang lebih bersih tentang berapa banyak orang nyata yang dijangkau kampanye Anda.
Apa saja langkah untuk memverifikasi alamat email?
Tiga pemeriksaan, berurutan: apakah format alamat benar, apakah domainnya memiliki server email, dan apakah server itu menyatakan kotak surat tersebut ada? Setiap langkah menangkap masalah yang tidak bisa ditangkap langkah sebelumnya.
| Langkah | Yang diperiksa | Yang tertangkap |
|---|---|---|
| 1. Sintaks | Alamat mengikuti aturan format email | Salah ketik, @ yang hilang, karakter tidak valid |
| 2. Pencarian MX | Domain mempublikasikan server email di DNS | Domain mati, domain yang tidak menerima email |
| 3. Pemeriksaan kotak surat SMTP | Server email menerima penerima spesifik itu | Kotak surat yang tidak ada atau sudah ditutup |
Lolos di langkah 3 adalah sinyal terkuat yang bisa Anda peroleh tanpa mengirim. Tetapi seperti yang akan kita lihat, sebagian server memberikan jawaban yang sama untuk setiap alamat, nyata atau tidak.
Bagaimana cara memeriksa sintaks email?
Pastikan hanya ada satu @, bagian di depannya yang tampak valid, dan domain yang nyata di belakangnya — dalam batas panjang yang ditetapkan standar SMTP. RFC 5321 menetapkan "Panjang total maksimum nama pengguna atau local-part lainnya" (bagian sebelum @) sebesar 64 oktet, dan panjang domain maksimum sebesar 255 oktet.
Pemeriksaan sintaks menangkap hal-hal yang jelas: sales@@example.com, info@example, spasi di akhir yang tersalin dari halaman web, atau koma yang diketik sebagai ganti titik. Pemeriksaan ini murah dan instan, jadi selalu jalankan lebih dulu. Yang tidak bisa diberitahukannya adalah apakah ada orang di balik alamat itu. jane.doe@example.com berformat sempurna terlepas dari apakah Jane bekerja di sana.
Bagaimana cara kerja pencarian MX?
Pencarian itu menanyakan ke DNS server mana yang menerima email untuk domain tersebut; jika tidak ada, tidak ada alamat di domain itu yang bisa menerima email. Catatan MX (mail exchanger) menunjuk ke server yang menerima email untuk sebuah domain. Mencarinya memberi tahu Anda apakah domain itu diatur untuk menerima email sama sekali.
Tiga hasil yang mungkin, menurut standar:
- Catatan MX ditemukan. Domain memiliki server email — lanjut ke langkah 3.
- Domain tidak ada. RFC 5321 menyatakan "Jika kesalahan domain yang tidak ada dikembalikan, situasi ini HARUS dilaporkan sebagai kesalahan." Alamat itu mati.
- Tidak ada catatan MX, tetapi domainnya ada. RFC 5321 menyatakan bahwa alamat itu "diperlakukan seolah-olah terkait dengan MX implisit" — email dikirim ke catatan alamat milik domain itu sendiri. Jadi MX yang hilang tidak otomatis berarti jalan buntu.
Ada juga sinyal "kami tidak menerima email" yang eksplisit. RFC 7505 mendefinisikan "null MX" — satu catatan MX dengan preferensi 0 dan tanda "." sebagai nama server — yang "akan menyebabkan semua upaya pengiriman email ke sebuah domain gagal seketika." Jika Anda melihatnya, berhenti: domain itu telah menyatakan bahwa ia tidak menerima email.
Bagaimana pemeriksaan kotak surat SMTP bekerja tanpa mengirim email?
Pemeriksa terhubung ke server email domain itu dan memulai pengiriman, menyebutkan penerima, membaca balasan server, lalu memutus koneksi sebelum mengirim isi pesan apa pun. Dalam istilah SMTP: terhubung, EHLO, MAIL FROM, RCPT TO:<address>, membaca kode balasan, lalu QUIT — langkah DATA, tempat pesan sebenarnya akan dikirim, tidak pernah terjadi.
Balasan terhadap RCPT TO adalah yang terpenting. RFC 5321 mendefinisikan kode-kodenya:
| Balasan | Arti menurut RFC 5321 | Yang biasanya diberitahukannya kepada Anda |
|---|---|---|
| 250 | Tindakan email yang diminta berhasil, selesai | Server menerima penerima ini |
| 550 | "Tindakan yang diminta tidak dilakukan: kotak surat tidak tersedia (misalnya, kotak surat tidak ditemukan, tidak ada akses, atau perintah ditolak karena alasan kebijakan)" | Sering berarti "tidak ada kotak surat seperti itu" — tetapi bacalah teksnya, bisa juga berupa penolakan karena kebijakan |
| 553 | "nama kotak surat tidak diizinkan (misalnya, sintaks kotak surat salah)" | Format alamat ditolak |
| 450 | "kotak surat tidak tersedia (misalnya, kotak surat sibuk atau diblokir sementara karena alasan kebijakan)" | Sementara — coba lagi nanti |
| 452 | "penyimpanan sistem tidak mencukupi" | Sementara |
Mengapa tidak langsung bertanya ke server dengan perintah VRFY? Karena server boleh mematikannya. RFC 5321 bagian 7.3 mengizinkan situs menonaktifkan VRFY demi alasan keamanan, dan menyatakan bahwa server yang melakukannya "HARUS mengembalikan respons 252" — balasan yang berarti bukan ya dan bukan tidak. Itulah sebabnya pemeriksa memakai jalur RCPT TO sebagai gantinya.
Dalam pengujian kami sendiri pada September 2026, metode RCPT mengidentifikasi dengan benar semua 6 alamat dalam sebuah kumpulan kecil yang sudah diketahui: 3 alamat yang kami tahu pernah terpental, 2 alamat yang berfungsi, dan 1 alamat pada domain catch-all yang kami tandai dengan benar sebagai tidak dapat dipastikan.
Apa itu domain catch-all, dan mengapa tidak bisa diverifikasi?
Domain catch-all menerima email untuk alamat apa pun — nyata atau karangan — sehingga servernya menjawab "250 OK" untuk setiap penerima, dan pemeriksaan sebelum pengiriman tidak mendapatkan informasi apa pun. Sebagian perusahaan mengonfigurasi emailnya dengan cara ini agar alamat yang salah eja tetap sampai ke seseorang. Yang lain memakai gateway yang menerima semuanya lebih dulu dan memilahnya kemudian.
Anda mendeteksi catch-all dengan menanyakan ke server tentang alamat yang hampir pasti tidak ada, seperti rangkaian acak yang panjang pada domain yang sama. Jika server menerima alamat itu juga, setiap "ya" darinya tidak bermakna.
Seberapa umum hal ini? Dalam pengujian pada September 2026, kami (Outreach) mengirim pemeriksaan RCPT dengan alamat karangan ke 25 domain email yang diambil dari 200 kontak bisnis yang telah kami kumpulkan (sebagian besar perusahaan Korea). Sekitar 74% domain menjawab dengan jujur dan menolak alamat palsu itu; sekitar 25% menerimanya — itulah catch-all. Anggap itu sebagai satu sampel dari satu pasar, bukan tingkat yang berlaku universal. Intinya adalah bahwa hal itu tidak jarang.
Untuk alamat catch-all, hasil yang jujur adalah "tidak dapat diverifikasi." Mengirim adalah satu-satunya cara untuk mengetahuinya, dan itu soal penilaian: alamat yang dipublikasikan di situs web perusahaan itu sendiri adalah taruhan yang lebih baik daripada alamat yang ditebak dari pola nama.
Mengapa sebagian server email menolak pemeriksaan verifikasi?
Sebagian server email membatasi siapa yang boleh bertanya tentang penerima, sehingga alih-alih menjawab, server itu menunda, menolak sementara, atau memutus koneksi. Penolakan biasanya tampak seperti:
- Balasan 4xx sementara untuk setiap penerima, yang meminta Anda mencoba lagi nanti.
- Balasan 5xx yang merujuk pada kebijakan atau reputasi, bukan pada kotak surat — misalnya kode lanjutan 5.7.1, yang oleh RFC 3463 dijelaskan sebagai "Pengiriman tidak diotorisasi, pesan ditolak."
- Tidak ada jawaban sama sekali, atau koneksi yang terputus.
Tidak satu pun dari ini memberi tahu Anda apakah kotak surat itu ada. Pemeriksa yang baik melaporkannya sebagai "tidak diketahui," bukan "tidak valid" — menandai alamat yang nyata sebagai mati hanya karena servernya berhati-hati akan membuang kontak yang baik.
Sebagian penyedia hosting juga memblokir koneksi keluar pada port 25, port SMTP, yang berarti pemeriksa yang berjalan di sana tidak dapat menjangkau server email sama sekali. Sekali lagi, jawaban yang tepat dalam kasus itu adalah "tidak dapat diverifikasi," bukan "tidak ada."
Bagaimana cara membaca kode email terpental setelah pengiriman?
Lihat digit pertama kode status lanjutan: 5 berarti permanen, 4 berarti sementara. Lalu digit tengah menunjukkan jenis masalahnya. RFC 3463 mendefinisikan kode dalam bentuk class.subject.detail:
- 5.x.x — Kegagalan permanen: "kecil kemungkinan teratasi dengan mengirim ulang pesan dalam bentuknya saat ini."
- 4.x.x — Kegagalan sementara yang berkelanjutan: "pengiriman di masa depan mungkin berhasil."
Kode yang paling sering Anda lihat ketika alamat menjadi masalahnya:
| Kode | Nama menurut RFC 3463 | Yang harus dilakukan |
|---|---|---|
| 5.1.1 | Alamat kotak surat tujuan salah — "Kotak surat yang ditentukan dalam alamat tidak ada" | Hapus alamat itu |
| 5.1.2 | Alamat sistem tujuan salah | Periksa domainnya; hapus jika sudah mati |
| 5.1.3 | Sintaks alamat kotak surat tujuan salah | Perbaiki salah ketiknya atau hapus |
| 5.1.6 | Kotak surat tujuan sudah pindah, tidak ada alamat penerusan | Hapus; cari kontak baru |
| 5.2.1 / 4.2.1 | Kotak surat dinonaktifkan, tidak menerima pesan | Hapus jika permanen (5), tunggu jika sementara (4) |
| 4.2.2 | Kotak surat penuh ("sebaiknya diperlakukan sebagai kegagalan sementara yang berkelanjutan") | Coba lagi nanti |
| 4.4.1 | Tidak ada jawaban dari host | Sementara — coba lagi nanti |
| 4.4.7 | Waktu pengiriman habis | Pesan terlalu lama untuk dikirim; periksa alamat dan coba lagi nanti |
| 5.7.1 | Pengiriman tidak diotorisasi, pesan ditolak | Bukan masalah alamat — masalah kebijakan atau autentikasi |
Baris terakhir itu penting. Kode 5.7.x biasanya berarti server penerima menolak Anda, bukan berarti kotak surat itu tidak ada. Periksa pengaturan SPF, DKIM, dan DMARC Anda sebelum menghapus kontak itu.
Bagaimana cara memeriksa satu alamat secara gratis?
Masukkan alamat itu ke pemeriksa alamat email gratis kami; pemeriksa itu menjalankan pemeriksaan sintaks, MX, dan kotak surat, lalu memberi tahu Anda satu dari tiga hal. Tidak perlu mendaftar. Pemeriksa ini tersedia dalam bahasa Inggris dan Korea; masukkan alamat yang ingin Anda periksa. Hasilnya adalah salah satu dari:
- Alamat ini dapat menerima email — server email menerima penerima itu.
- Alamat ini tidak ada — alamat tidak berformat benar, domain tidak memiliki server email, atau server menyatakan tidak ada kotak surat seperti itu.
- Kami tidak dapat memverifikasi alamat ini — domain itu catch-all, server menolak pemeriksaan, atau tidak ada pemeriksaan yang memungkinkan. Alat itu memberi tahu Anda alasan mana yang berlaku.
Agar alat ini tidak disalahgunakan untuk pemeriksaan massal, jumlah pemeriksaan per hari dibatasi. Untuk seluruh daftar, lakukan verifikasi di dalam alur pengiriman Anda, bukan satu alamat per satu.
Apa yang harus dilakukan dengan alamat yang tidak dapat diverifikasi?
Pisahkan alamat itu, kirim ke alamat itu dalam kelompok yang lebih kecil, dan hapus yang terpental dengan kode 5.x.x. Urutan yang praktis:
- Buang apa pun yang gagal pada sintaks atau tidak memiliki server email.
- Hapus alamat yang dinyatakan server tidak ada.
- Kirim ke alamat yang sudah terkonfirmasi lebih dulu.
- Kirim ke alamat "tidak dapat diverifikasi" dengan lebih hati-hati, dan hapus yang kembali dengan email terpental permanen — seperti yang disarankan Yahoo dan Google.
Ingat juga bahwa alamat yang valid tidak berarti penerima yang bersedia. Keluhan spam tetap merugikan Anda terlepas dari apakah alamat itu ada; kami membahas angkanya di mengapa cold email masuk ke folder spam.
Versi singkatnya
- Verifikasi dalam tiga langkah: sintaks → pencarian MX → pemeriksaan kotak surat SMTP (RCPT, tanpa mengirim isi).
- Bagian sebelum @ paling banyak 64 karakter (RFC 5321); null MX berarti domain itu tidak menerima email (RFC 7505).
- Domain catch-all menerima setiap alamat — dalam pengujian 25 domain kami, sekitar 25% melakukannya — sehingga sebagian alamat hanya bisa ditandai "tidak dapat diverifikasi."
- Pada email terpental, 5.x.x berarti permanen dan 4.x.x sementara; 5.1.1 berarti kotak surat tidak ada; 5.7.x menunjuk ke masalah kebijakan, bukan alamat yang buruk.
- Coba satu alamat dengan pemeriksa email gratis kami.
