Anda telah memeriksa catatan SPF dan DKIM, memastikan bahwa domain pengirim terlihat bersih, dan meluncurkan kampanye. Kemudian aplikasi mengembalikan kesalahan autentikasi sebelum pesan pertama meninggalkan sistem Anda. Konfigurasi DNS belum tentu salah. Aplikasi pengiriman Anda mungkin gagal melakukan login klien yang diwajibkan oleh server SMTP keluar.
Perbedaan ini menjawab pertanyaan praktis di balik apa itu autentikasi SMTP. SMTP AUTH membuktikan bahwa klien, aplikasi, atau pengguna diizinkan mengirimkan email melalui server. SPF, DKIM, dan DMARC menangani masalah identitas yang berbeda, yaitu apakah penyedia penerima seharusnya mempercayai domain yang terkait dengan pesan tersebut. Deliverability yang andal bergantung pada kedua lapisan ini, ditambah kebersihan daftar yang terjaga sebelum pengiriman.
Penjaga Gerbang Tersembunyi Pengiriman Email
Tim pemasaran dapat menghabiskan berhari-hari meninjau reputasi pengirim, keselarasan domain, dan isi pesan, hanya untuk mengetahui bahwa CRM mereka tidak dapat melakukan autentikasi ke mail server keluar. Kampanye tidak pernah mencapai infrastruktur penerima karena server pengiriman terlebih dahulu menolak koneksi tersebut.
Itulah peran autentikasi SMTP. Ini adalah penjaga gerbang antara aplikasi dan mail server yang menerima pesan keluar. Klien mengidentifikasi mekanisme autentikasi, menyelesaikan pertukaran dengan server, lalu menerima izin untuk mengirimkan email. Tanpa izin tersebut, pesan yang ditulis dengan benar dan catatan domain yang dipublikasikan dengan benar belum berarti apa-apa.
Dua pemeriksaan identitas, bukan satu
Pengiriman email melibatkan dua pertanyaan terpisah:
- Bisakah klien ini mengirimkan email melalui server ini?
- Haruskah penerima memercayai identitas pengirim yang direpresentasikan oleh pesan ini?
SMTP AUTH menjawab pertanyaan pertama. SPF, DKIM, dan DMARC menjawab pertanyaan kedua. CRM mungkin memiliki kredensial yang valid, tetapi mengirim dari domain yang tidak memiliki catatan autentikasi yang selaras. Sebaliknya, domain dapat memublikasikan catatan yang kuat, sementara aplikasi menggunakan kata sandi yang sudah kedaluwarsa, metode yang dinonaktifkan, atau server yang menolak relay untuk akun tersebut.
Aturan operasional: Debug jalur pengiriman secara berurutan. Pertama, pastikan klien dapat membuat sesi pengiriman yang aman dan terautentikasi. Kemudian, verifikasi autentikasi tingkat domain dan kebijakan di sisi penerima.
Standar di balik SMTP AUTH adalah RFC 4954, yang memformalkan autentikasi SMTP sebagai ekstensi layanan yang dibangun di atas SASL. Standar ini memungkinkan server mengiklankan mekanisme yang didukung dan klien memilih salah satunya tanpa mengubah perintah inti transfer pesan SMTP. Desain tersebut masih menjadi dasar pengiriman terautentikasi dalam sistem email perusahaan dan platform pengiriman.
Mengapa pemasar mengalami kegagalan ini
Kesalahan tersebut sering muncul setelah perubahan infrastruktur, bukan setelah perubahan salinan atau penargetan. Penyedia layanan mungkin menonaktifkan metode autentikasi lama. Administrator mungkin mematikan SMTP AUTH untuk sebuah akun. Kebijakan keamanan mungkin mewajibkan pengiriman terenkripsi. Firewall mungkin mengizinkan lalu lintas antarsserver, tetapi memblokir port yang digunakan aplikasi pemasaran.
Inilah alasan ākata sandinya benarā bukanlah diagnosis yang memadai. Server mungkin menolak metode autentikasi, keamanan koneksi, izin relay akun, atau konfigurasi klien pengirim. Perlakukan SMTP AUTH sebagai kontrol tingkat protokol, bukan sekadar kolom formulir.
Memahami Handshake SMTP AUTH
SMTP AUTH adalah pertukaran yang dinegosiasikan. Klien tidak mengirim nama pengguna lalu berharap server menerimanya. Server terlebih dahulu mengidentifikasi apa yang didukungnya, kemudian klien memilih mekanisme yang kompatibel dan memulai rangkaian autentikasi.
Urutan protokol
Pertukaran ini umumnya mengikuti urutan berikut:
- Klien membuka koneksi. Untuk pengiriman terautentikasi, aplikasi biasanya terhubung melalui layanan submission yang ditentukan dan menegosiasikan keamanan transport sebelum kredensial dikirim.
- Klien mengirim EHLO. Sapaan yang diperluas ini memberi tahu server fitur SMTP yang dipahami klien.
- Server mengumumkan kapabilitas. Respons dapat menyertakan baris
250-AUTHyang mencantumkan mekanisme SASL yang didukung. Klien harus memilih salah satu yang ditawarkan server. - Klien mengirim AUTH. Perintah ini menggunakan mekanisme yang dipilih sebagai parameter pertamanya, sebagaimana ditetapkan dalam spesifikasi perintah AUTH RFC 4954.
- Kedua pihak menyelesaikan pertukaran. Bergantung pada mekanismenya, server dapat mengirim tantangan dan klien merespons dengan data autentikasi yang diperlukan. Encoding Base64 dapat merepresentasikan kredensial selama pertukaran, tetapi encoding bukan enkripsi. TLS harus melindungi sesi.
- Server menerima atau menolak sesi. Autentikasi yang berhasil biasanya mengembalikan
235. Upaya yang gagal biasanya mengembalikan535, meskipun detail diagnostiknya berbeda-beda menurut penyedia.
Hal pentingnya adalah SMTP AUTH berlangsung sebelum klien mengirim envelope dan isi pesan. Setelah autentikasi, aplikasi dapat melanjutkan dengan perintah seperti MAIL FROM, RCPT TO, dan DATA, bergantung pada kontrol relay dan kebijakan server.
Apa yang diberitahukan oleh respons
Kapabilitas AUTH yang tidak tersedia dapat menunjukkan bahwa klien terhubung ke layanan yang salah, menggunakan port yang tidak didukung, atau menghubungi server yang tidak menawarkan submission terautentikasi. Respons 535 dapat mencerminkan kredensial yang tidak valid, akun yang diblokir, metode autentikasi yang dinonaktifkan, atau penolakan penyedia terhadap perilaku login lama.
Log aplikasi sebaiknya merekam kode respons server dan status keamanan yang dinegosiasikan, sekaligus menghindari kata sandi dan token. Saat menyelidiki pesan yang diterima tetapi kemudian difilter, tim juga dapat menganalisis header email secara gratis untuk memeriksa hasil autentikasi yang dicatat oleh sistem penerima.
SMTP AUTH juga tidak menggantikan keamanan akun. Jika kotak surat atau akun layanan menggunakan autentikasi multifaktor, tinjau alur yang didukung penyedia, bukan berasumsi bahwa kata sandi biasa akan berfungsi. Panduan Finchum Fixes IT tentang 2FA memberikan latar belakang yang berguna tentang alasan faktor kedua mengubah model login.
Bagi tim yang membersihkan data penerima yang memasok sistem ini, BillionVerify adalah layanan verifikasi email profesional yang dibuat untuk menyelesaikan satu masalah: data email yang buruk membuat bisnis kehilangan uang. Layanan ini menangani kualitas daftar, bukan login SMTP itu sendiri.
Autentikasi SMTP vs Autentikasi Pengirim
Analogi yang paling tepat adalah lencana karyawan dibandingkan dengan kop surat perusahaan.
SMTP AUTH adalah lencananya. Ini memberi tahu server email keluar bahwa klien atau akun ini memiliki izin untuk mengirimkan pesan. SPF, DKIM, dan DMARC adalah kop surat dan tanda verifikasinya. Semuanya membantu penyedia penerima mengevaluasi apakah pesan tersebut mewakili domain yang ditampilkan kepada penerima.
Pemeriksaan lencana yang berhasil tidak membuat kop surat yang meragukan menjadi tepercaya. Begitu pula, catatan domain yang sudah dikonfigurasi dengan baik tidak memberikan otorisasi kepada aplikasi untuk memasukkan email ke dalam antrean server.
| Fitur | Pengiriman Klien (SMTP AUTH) | Verifikasi Domain (SPF/DKIM/DMARC) |
|---|---|---|
| Pertanyaan utama | Apakah klien ini diizinkan mengirim email? | Haruskah penerima mempercayai identitas domain ini? |
| Tempat beroperasi | Antara klien pengirim dan server keluar | Antara pesan, catatan DNS, dan penyedia penerima |
| Komponen utama | EHLO, mekanisme AUTH yang ditawarkan, pertukaran SASL, izin relay | Otorisasi SPF, validasi tanda tangan DKIM, keselarasan dan kebijakan DMARC |
| Kegagalan umum | Penolakan autentikasi, akun dinonaktifkan, metode tidak didukung | Kegagalan spoofing, ketidakselarasan, pemfilteran berbasis kebijakan |
| Dampak keberhasilan | Server dapat menerima pesan untuk dikirimkan lebih lanjut | Penerima dapat menggunakan sinyal identitas domain dalam keputusan pemfilteran |
Apa yang dibuktikan setiap lapisan
SPF mengotorisasi alamat IP pengirim yang ditetapkan untuk suatu domain. DKIM menambahkan tanda tangan kriptografis yang memungkinkan sistem penerima memeriksa apakah konten pesan yang ditandatangani dan tanda tangan domain tervalidasi. DMARC menghubungkan hasil tersebut dengan domain From yang terlihat dan menyediakan kebijakan untuk menangani pesan yang gagal memenuhi keselarasan. Perbedaannya dirangkum dengan jelas dalam perbandingan SPF, DKIM, dan DMARC ini.
SMTP AUTH tidak memublikasikan instruksi domain tersebut. SMTP AUTH juga tidak menjamin bahwa penerima akan menempatkan pesan di kotak masuk. SMTP AUTH hanya menetapkan bahwa layanan pengirim menerima klien sebagai pengirim yang diotorisasi.
Publikasi bukan penegakan
Perbedaan antara memiliki catatan dan menegakkan kebijakan penting secara operasional. Pengukuran pada tahun 2026 terhadap 5,5 juta domain menemukan bahwa SPF dipublikasikan oleh 56,0%, DMARC oleh 30,4%, dan DKIM oleh 22,7%, menurut penelitian autentikasi email DMARC Guard. Dalam tolok ukur terpisah yang mencakup 10.000 domain teratas, publikasi SPF mencapai 84,5%, publikasi DMARC 76,6%, dan penegakan DMARC dengan kebijakan quarantine atau reject 54,0%, berdasarkan sumber yang sama.
Pelajaran praktisnya sederhana. Sebuah domain dapat terlihat telah dikonfigurasi, tetapi masih beroperasi dalam mode pemantauan saja. Gunakan alat pemeriksa DMARC untuk memeriksa kebijakan dan keselarasan, tetapi lakukan pemecahan masalah kredensial SMTP secara terpisah. Tidak satu pun alat tersebut menggantikan yang lainnya.
Port dan Protokol untuk Pengiriman yang Aman
Kredensial tidak boleh dikirim melalui sesi pengiriman klien yang tidak terlindungi. Karena itu, SMTP AUTH harus digunakan bersama enkripsi transport dan port yang ditujukan untuk pengiriman pesan, bukan jalur relay tanpa pembatasan.
Port pengiriman yang ditetapkan oleh standar adalah 587, yang umumnya dipasangkan dengan STARTTLS, sebagaimana dijelaskan dalam ikhtisar port autentikasi SMTP ini. Klien membuat sesi SMTP, menerima kapabilitas server, meminta peningkatan ke TLS, lalu melakukan autentikasi di dalam koneksi yang terlindungi.
Memilih endpoint yang tepat
Port 25 terutama digunakan untuk relay antarserver. Port ini bukan pilihan normal bagi aplikasi, CRM, atau platform pemasaran yang mengirimkan email dengan kredensial pengguna. Banyak jaringan membatasi port ini karena penyalahgunaan open relay dan host yang disusupi telah menjadikan SMTP keluar tanpa pembatasan sebagai masalah keamanan.
Port 465 menggunakan TLS implisit, artinya koneksi dienkripsi sejak awal. Beberapa penyedia dan aplikasi masih memerlukannya, tetapi konfigurasi harus sesuai dengan ekspektasi server. Klien yang mengasumsikan STARTTLS pada endpoint TLS implisit, atau mengasumsikan TLS implisit ketika server mengharapkan sapaan plaintext yang kemudian ditingkatkan, akan gagal sebelum autentikasi.
| Jenis koneksi | Peran umum | Ekspektasi keamanan |
|---|---|---|
| Port 25 | Relay antarserver | Bukan jalur pengiriman klien terautentikasi yang normal |
| Port 587 | Pengiriman pesan | STARTTLS biasanya dinegosiasikan sebelum SMTP AUTH |
| Port 465 | Pengiriman jika diperlukan | TLS implisit dimulai saat koneksi dibuat |
Pemeriksaan konfigurasi untuk mencegah kebocoran
Sebelum menguji kredensial, pastikan endpoint aplikasi, port, mode enkripsi, dan mekanisme autentikasi sesuai dengan dokumentasi penyedia. Sebuah port dapat dijangkau meskipun negosiasi TLS tetap gagal. Demikian pula, server dapat mengiklankan AUTH tetapi menolak akun tersebut karena izin relay atau kebijakan tenant melarang pengiriman.
Alat verifikasi data MX membantu mengidentifikasi server email yang bertanggung jawab menerima email untuk suatu domain, tetapi data MX bukan pengganti endpoint pengiriman yang disediakan oleh penyedia outbound Anda. Infrastruktur penerimaan dan infrastruktur pengiriman terautentikasi dapat berupa layanan yang terpisah.
Batas keamanan: Jangan āmemperbaikiā kegagalan autentikasi dengan menonaktifkan TLS. Tindakan tersebut dapat mengekspos kredensial dan lalu lintas pesan, sementara masalah kompatibilitas atau kebijakan yang mendasarinya tetap belum terselesaikan.
Untuk sistem bervolume tinggi, API dapat lebih sederhana secara operasional dibandingkan mempertahankan sesi SMTP yang banyak berkomunikasi, tetapi SMTP tetap berguna ketika aplikasi sudah mendukungnya dan penyedia menyediakan layanan pengiriman yang stabil. Pilihan tersebut harus mengikuti kebutuhan integrasi, observabilitas, dan kontrol keamanan, bukan kebiasaan.
Dampak Penghentian Auth Legacy
Alur pengiriman dapat berhenti melakukan autentikasi meskipun kata sandinya tidak berubah. Penyedia layanan mengganti Autentikasi Dasar, yang mengirimkan nama pengguna dan kata sandi secara langsung, dengan OAuth dan alur otorisasi lainnya yang memungkinkan administrator mengontrol token, cakupan, persetujuan, dan pencabutan akses.
Rencana yang diumumkan Microsoft menyatakan bahwa perilaku Autentikasi Dasar diproyeksikan tetap tidak berubah hingga Desember 2026. Setelah itu, fitur tersebut direncanakan dinonaktifkan secara default untuk tenant yang sudah ada, sementara tenant baru yang dibuat setelahnya diperkirakan akan menggunakan OAuth sebagai metode yang didukung. Microsoft berencana mengumumkan tanggal penghapusan final pada paruh kedua 2027. Tonggak yang diproyeksikan ini tercantum dalam linimasa penghentian SMTP AUTH Exchange Online Microsoft.
Mengapa kata sandi yang valid tetap gagal
Penyedia layanan dapat menolak metode autentikasi sebelum memeriksa kata sandi. Administrator tenant juga mungkin telah menonaktifkan SMTP AUTH untuk kotak surat tersebut, atau aplikasi mungkin hanya menawarkan LOGIN atau PLAIN sementara layanan memerlukan alur berbasis token. Oleh karena itu, pengujian login yang berhasil dari satu kotak surat tidak memastikan bahwa setiap integrasi pengiriman akan terus berfungsi.
Komunikasi Microsoft sebelumnya menjelaskan penolakan bertahap yang dimulai 1 Maret 2026, dengan penghentian penuh pada 30 April 2026, untuk jalur Autentikasi Dasar yang terdampak, sebagaimana dilaporkan dalam panduan migrasi SMTP AUTH ini. Jadwal penyedia layanan dan kebijakan tenant dapat berubah, jadi verifikasi status terkini setiap lingkungan alih-alih menganggap tanggal implementasi lama sebagai jaminan.
Rencana migrasi praktis
Inventarisasi setiap sistem yang mengirimkan email melalui tenant, termasuk alur kerja CRM, aplikasi penagihan, alat pemantauan, formulir, dan skrip. Untuk setiap sistem, catat akun, endpoint, port, mode enkripsi, mekanisme autentikasi, dan pemiliknya. Pisahkan integrasi yang mendukung OAuth dari integrasi yang memerlukan penggantian atau pendekatan kata sandi aplikasi yang disetujui.
Uji alur baru di lingkungan terkendali sebelum mengubah urutan produksi. Periksa masa berlaku token, persyaratan persetujuan, penanganan kesalahan, dan pencabutan akses. Pastikan juga alur kerja tetap menangani respons penyedia layanan dengan benar setelah autentikasi berhasil. Konektor tanpa dukungan OAuth dapat gagal selama kampanye meskipun kata sandi yang tersimpan tetap valid.
Memverifikasi Deliverability di Luar Login
Autentikasi ke server outbound Anda membuktikan otoritas pengiriman. Namun, hal itu tidak membuktikan bahwa kotak surat penerima benar-benar ada, bahwa domain penerima menerima email untuk alamat tersebut, atau bahwa pesan akan terhindar dari penyaringan.
Pipeline verifikasi sebelum pengiriman dimulai dengan pencarian MX. Record MX mengidentifikasi server email yang bertanggung jawab menerima email suatu domain, dan domain tanpa record MX tidak dapat menerima email, seperti dijelaskan dalam ikhtisar cara kerja verifikasi email. Layanan verifikasi kemudian dapat menyelidiki server penerima menggunakan percakapan SMTP untuk menilai apakah alamat tersebut tampaknya dapat menerima email.
Hal yang sebenarnya diperiksa pipeline verifikasi
Layanan tersebut tidak perlu mengirim pesan kampanye untuk mendapatkan informasi yang berguna. Layanan dapat mengidentifikasi host MX domain penerima, membuka sesi SMTP, dan menanyakan apakah server akan menerima penerima yang dituju. Respons positif masih dapat bersifat ambigu, karena beberapa server menerima email untuk setiap alamat di domain tersebut.
Di sinilah deteksi catch-all menjadi penting. Verifikator mengirim alamat pengujian kedua ke host MX yang sama. Jika server juga menerima alamat acak, domain tersebut diklasifikasikan sebagai catch-all, bukan dianggap sebagai bukti bahwa kotak surat asli benar-benar ada, seperti dijelaskan dalam alur kerja deteksi catch-all ini.
Perbedaan penting: āDiterima oleh serverā dan ādikonfirmasi sebagai kotak surat tertentuā tidak selalu merupakan hasil yang sama.
Karena itu, verifikasi paling efektif digunakan sebagai sistem klasifikasi risiko, bukan tombol sederhana valid atau tidak valid. Operasi pemasaran dapat memisahkan alamat yang kemungkinan dapat menerima email dari data yang tidak diketahui, catch-all, sekali pakai, berbasis peran, atau berisiko dengan cara lain sebelum kampanye menimbulkan hard bounce.
BillionVerify deliverability checker dapat digunakan dalam peninjauan sebelum pengiriman sebagai salah satu alat yang dievaluasi tim untuk pemeriksaan alamat dan jalur pengiriman. Tujuan operasionalnya lebih luas daripada sekadar keberhasilan login: mengurangi penerima yang buruk, mempertahankan reputasi pengirim, dan memberikan audiens yang lebih bersih bagi kampanye.
Membangun Infrastruktur Pengiriman yang Tangguh
Sistem pengiriman yang tangguh memperlakukan autentikasi sebagai kontrol berlapis, bukan sekadar satu kotak centang. Klien harus melakukan autentikasi secara aman ke layanan keluar. Domain pengirim yang terlihat harus lulus pemeriksaan identitas yang selaras. Data penerima harus cukup mutakhir agar kampanye tidak menghasilkan bounce yang sebenarnya dapat dihindari.
Mulai dengan audit infrastruktur
Petakan seluruh rute dari aplikasi hingga penerima. Untuk setiap alur pengiriman, dokumentasikan penyedia pengiriman, metode autentikasi, persyaratan enkripsi, pemilik akun, dan perilaku fallback. Inventarisasi ini biasanya mengungkap integrasi terbengkalai yang masih bergantung pada kata sandi atau pengaturan SMTP lama.
Kemudian uji mode kegagalan secara sengaja:
- Kegagalan pengiriman: Pastikan klien mencapai endpoint yang dimaksud, menegosiasikan TLS, melihat kemampuan AUTH yang diharapkan, dan menerima respons autentikasi yang berhasil.
- Kegagalan domain: Validasi otorisasi SPF, penandatanganan DKIM, dan keselarasan DMARC untuk domain yang ditampilkan dalam alamat From.
- Kegagalan data: Verifikasi alamat baru dan alamat impor sebelum alamat tersebut masuk ke kampanye atau rangkaian penjualan.
- Kegagalan reputasi: Pantau bounce, keluhan, sinyal blocklist, dan perubahan mendadak dalam perilaku penerimaan dengan alat pemeriksa reputasi IP.
Standar RFC 4954 menyediakan dasar protokol, tetapi kepatuhan terhadap standar saja tidak menjamin ketangguhan operasional. Penyedia dapat menerapkan aturan tenant, menonaktifkan mekanisme, atau mengubah persyaratan autentikasi.
Jadikan kebersihan data bagian dari alur kerja
Jangan menunggu hingga daftar menjadi besar atau kampanye dijadwalkan. Tambahkan verifikasi saat pendaftaran, impor, sinkronisasi CRM, dan sebelum pengiriman besar. Pemeriksaan waktu nyata dapat menghentikan alamat yang jelas berisiko agar tidak masuk ke basis data, sementara peninjauan massal dapat mengidentifikasi catatan usang yang terakumulasi oleh tim penjualan dan pemasaran.
Alur kerja terbaik juga menyimpan hasil dan alasannya. āTidak diketahui karena catch-allā memerlukan penanganan yang berbeda dari ākotak surat ditolakā atau ādomain tidak memiliki server penerima.ā Segmentasi memungkinkan tim memutuskan apakah akan menekan, meninjau, atau menguji alamat secara hati-hati, alih-alih menganggap setiap catatan yang tidak pasti sebagai aman.
Program berlapis juga membutuhkan kepemilikan yang jelas. Tim infrastruktur harus mengelola migrasi OAuth dan kebijakan TLS. Operasional pemasaran harus menjaga keselarasan domain pengiriman dan aturan penekanan. Tim data harus menetapkan penanganan status verifikasi. Tanpa kepemilikan yang jelas, setiap kelompok menganggap tim lain sedang melindungi jalur pengiriman.
Video ini memberikan penjelasan visual tentang konsep infrastruktur yang terlibat:
Pelajaran utamanya bersifat praktis: SMTP AUTH memasukkan pesan ke antrean keluar, sementara autentikasi domain dan verifikasi penerima menentukan apakah sistem pengiriman yang lebih luas memiliki alasan untuk mempercayainya. Pisahkan kontrol-kontrol tersebut dalam pemantauan Anda, tetapi hubungkan semuanya dalam proses operasional.
BillionVerify menyediakan verifikasi email untuk memeriksa data penerima sebelum data tersebut mencapai kampanye, alur kerja, dan rangkaian pengiriman keluar. Gunakan untuk menghubungkan verifikasi tingkat SMTP, sinyal MX dan catch-all, serta peninjauan deliverability dalam proses prapengiriman Anda, lalu kunjungi BillionVerify untuk mengevaluasi alur kerja bagi tim Anda.