Ketika formulir kontak mengatakan “Terima kasih” tetapi tidak ada email yang diterima

Bayangkan sebuah praktik fisioterapi kecil. Situs webnya memiliki formulir kontak, dan formulir itu berfungsi – atau setidaknya terlihat demikian. Pengunjung mengisinya, mengeklik “Kirim”, dan melihat pesan ramah “Terima kasih, kami akan segera menghubungi Anda”. Yang tidak dilihat siapa pun: pesan sudah lama tidak sampai ke kotak masuk praktik tersebut. Tidak ada kesalahan, tidak ada pemberitahuan email gagal terkirim di kotak masuk siapa pun, dan tidak ada indikator merah di mana pun. Formulir gagal secara diam-diam.

Mengapa tidak ada yang menyadarinya

Halaman “Terima kasih” pada formulir biasanya hanya berarti satu hal: situs web telah meneruskan pesan. Apakah server email menerimanya, memasukkannya ke spam, atau menolaknya di tengah jalan terjadi kemudian, di luar jangkauan formulir. Fungsi mail() PHP, misalnya, melaporkan keberhasilan segera setelah sistem lokal menerima pesan untuk dikirim – bukan ketika pesan sampai kepada seseorang. Jadi, pengunjung menerima konfirmasi lalu melanjutkan kegiatannya. Sementara itu, pemilik melihat kotak masuk yang kosong dan beranggapan bahwa bulan ini memang sepi. Berkurangnya pertanyaan jarang menimbulkan kekhawatiran dengan sendirinya: liburan, cuaca, perekonomian – selalu ada penjelasan yang terdengar lebih masuk akal daripada “formulirnya rusak”.

Penyebab yang umum

• Kata sandi SMTP atau penyedia email berubah. Formulir terus login dengan kredensial lama dan server email menolaknya – secara diam-diam dari sudut pandang pengunjung.
• PHP mail() tanpa autentikasi. Server web mengirim email secara langsung, tanpa login ke server email yang semestinya. Banyak server penerima menganggap email tersebut mencurigakan: email masuk ke spam atau langsung ditolak.
• SPF, DKIM, dan DMARC tidak selaras. Banyak formulir menempatkan alamat pengunjung di kolom From. Pesan kemudian mengaku berasal, misalnya, dari alamat gmail.com tetapi dikirim oleh server web Anda – persis hal yang dirancang untuk dicegah oleh DMARC.
• Pembaruan plugin atau perubahan tema merusak formulir atau CAPTCHA-nya. Templat yang berubah menghilangkan suatu kolom, skrip tidak lagi dimuat, atau widget CAPTCHA muncul tanpa skripnya – dan setiap pengiriman gagal divalidasi.
• Kotak email penerima penuh. Server email menolak pesan baru, dan pemberitahuan email gagal terkirim masuk ke alamat yang tidak dibaca siapa pun.
• Banner cookie memblokir skrip formulir. Jika alat persetujuan menggolongkan CAPTCHA atau skrip formulir sebagai “pemasaran”, pengunjung yang menolak cookie mungkin mendapatkan formulir yang tidak dapat dikirim, atau yang pengirimannya ditolak karena token tidak ada.
• Sertifikat TLS atau domain kedaluwarsa. Pengunjung melihat peringatan browser lalu pergi, atau server email tidak lagi dapat dijangkau dengan aman. Jika domain kotak email penerima kedaluwarsa, email ke alamat tersebut berhenti begitu saja.
• Lapisan cache menyajikan halaman usang. Cache halaman penuh dapat menyajikan formulir dengan token keamanan yang kedaluwarsa (nonce atau token CSRF). Server menolak pengiriman, dan bergantung pada konfigurasinya, pengunjung tidak melihat kesalahan yang jelas.

Jebakan alamat From

Penyebab ketiga perlu diperhatikan lebih saksama karena sudah menjadi bawaan pada banyak konfigurasi formulir. DMARC memeriksa apakah domain pada alamat From yang terlihat cocok dengan domain yang dijamin oleh SPF atau DKIM. Jika formulir mengirim pesan “dari” alamat pengunjung, server Anda tidak berwenang mengirim untuk domain tersebut, sehingga pemeriksaan gagal. Bergantung pada kebijakan DMARC domain pengunjung dan penyedia email Anda sendiri, pesan masuk ke spam atau ditolak. Perbaikannya sederhana: kirim dari alamat pada domain Anda sendiri dan tempatkan alamat pengunjung di Reply-To. Mengeklik “Balas” tetap akan mengirim balasan kepada pengunjung.

Yang perlu dilakukan

1. 1Kirim pesan uji melalui formulir Anda sendiri secara rutin – setidaknya setiap bulan, dan selalu setelah pembaruan, perubahan tema, atau perubahan pengaturan email. Tandai dengan jelas sebagai pengujian agar tidak ada yang membalasnya.
2. 2Ketahui ritme normal Anda. Jika formulir biasanya menghasilkan beberapa pesan per minggu, dua minggu tanpa pesan merupakan alasan untuk memeriksanya, bukan sekadar bulan yang sepi.
3. 3Kirim melalui SMTP dengan autentikasi – melalui penyedia email Anda atau layanan pengiriman khusus – alih-alih mengandalkan PHP mail().
4. 4Gunakan domain Anda sendiri pada From dan alamat pengunjung pada Reply-To. Kemudian konfigurasikan SPF, DKIM, dan DMARC untuk domain tersebut agar pesan lolos pemeriksaan.
5. 5Simpan salinan setiap pengiriman dalam basis data. Banyak plugin formulir menyediakan fitur ini, terkadang sebagai pengaya. Jika email gagal, pertanyaannya tetap tersimpan.
6. 6Periksa formulir setelah setiap pembaruan plugin – termasuk CAPTCHA, dan juga dengan cookie ditolak.

Pemeriksaan seperti ini mudah terlupakan, sehingga layak diotomatiskan. Dengan akun dan domain terverifikasi, formexposed dapat mengirim pengiriman uji yang ditandai dengan jelas dan memeriksa apakah benar-benar diterima (pemeriksaan pengiriman, hanya dengan persetujuan aktif). Layanan ini juga mendeteksi ketiadaan pesan – formulir yang biasanya menerima pesan tiba-tiba tidak menerima apa pun – serta memeriksa SPF, DKIM, dan DMARC pada email notifikasi, juga masa berlaku sertifikat TLS dan domain. Anda hanya diberi tahu ketika ada perubahan.

Jika Anda hanya ingin melihat gambaran awal: pemeriksaan gratis di formexposed.com tidak memerlukan akun dan tidak mengirim apa pun. Antara lain, pemeriksaan ini menunjukkan apakah CAPTCHA tersedia tetapi rusak – widget tanpa skripnya, kunci uji publik, kesalahan di browser – salah satu cara formulir berhenti berfungsi tanpa banyak tanda. Apakah pesan benar-benar diterima hanya dapat dipastikan melalui pesan uji yang nyata, jadi kirimkan satu hari ini.