Membaca Header Email untuk Membedakan Spoofing dan Akun yang Dibobol

Laporan seperti "domain saya kirim email aneh" biasanya punya dua kemungkinan yang penanganannya beda jauh. Bisa jadi orang lain memalsukan alamat pengirim dari server miliknya sendiri. Bisa juga memang ada akun email di server kita yang password-nya sudah dipegang orang lain. Yang pertama urusan DNS dan kebijakan DMARC, yang kedua urusan reset password, cek queue, dan membersihkan perangkat pelanggan. Catatan ini membahas cara membedakan keduanya dari bukti, bukan dari tebakan.

Dua kejadian yang kelihatan sama dari kotak masuk penerima

Dari sisi penerima, kedua kasus terlihat identik. Ada email dengan From [email protected] berisi tautan phishing atau tagihan palsu. Bedanya baru kelihatan kalau kita tahu jalur yang dilewati email itu. SMTP, protokol pengiriman email, dari awal tidak memverifikasi siapa pengirimnya. Siapa pun yang punya server bisa menulis header From apa saja. Ada juga envelope sender, yaitu alamat di perintah MAIL FROM yang nanti muncul sebagai Return-Path, dan nilainya boleh berbeda dari header From. Spoofing memanfaatkan celah ini. Pengirim memakai server dan IP miliknya sendiri, lalu menulis domain kita di header From. Server kita sama sekali tidak terlibat. Akun yang dibobol berbeda. Penyerang login ke server kita lewat SMTP AUTH dengan username dan password yang sah, lalu mengirim email seperti pengguna biasa. Email keluar dari IP server kita, ditandatangani DKIM domain kita, dan lolos SPF. Jadi kalau email aneh itu lolos semua pemeriksaan autentikasi, justru itu petunjuk kuat bahwa pengirimnya masuk lewat pintu depan. Ada kemungkinan ketiga yang sering terlewat, yaitu script di website yang sudah disusupi lalu mengirim email lewat fungsi mail lokal. Email ini juga keluar dari server kita, tapi tanpa login SMTP. Di log polanya berbeda, dan itu akan dibahas di bagian log.

Membaca Received dari bawah ke atas, dan tahu mana yang bisa dipercaya

Setiap server yang meneruskan email menambahkan satu baris Received di bagian paling atas header. Akibatnya, baris paling atas berasal dari server penerima terakhir, dan baris paling bawah adalah klaim paling awal. Arah bacanya dari bawah ke atas kalau ingin mengikuti perjalanan email. Yang sering disalahpahami, tidak semua baris Received bisa dipercaya. Pengirim spoofing bebas menulis baris Received palsu di bagian bawah supaya email terlihat seperti lewat server kita. Baris yang bisa dipercaya hanya yang ditulis server yang kita percaya. Dalam praktik, itu baris dari server penerima (misalnya mailbox pelanggan di Gmail atau Outlook) yang mencatat IP mana yang terhubung ke dia. IP itu fakta, karena dicatat dari koneksi TCP yang benar-benar terjadi. Pertanyaan pertamanya sederhana: IP yang tercatat di hop penerima itu milik server kita atau bukan? Kalau bukan, dan tidak ada relay resmi lain milik pelanggan, email itu hampir pasti tidak pernah lewat server kita. Berikut contoh potongan header untuk kasus akun yang dibobol. Ini contoh format, bukan kejadian nyata, dan urutan baris bisa sedikit berbeda antar penyedia:

TEXT

Authentication-Results: mx.penerima.test;
       dkim=pass header.d=example.com;
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass header.from=example.com
Received: from mail.example.com (mail.example.com [203.0.113.10])
        by mx.penerima.test with ESMTPS id abc123
Received: from [198.51.100.25] (port=51234 helo=[192.168.1.5])
        by mail.example.com with esmtpsa (TLS1.3)
        (Exim 4.xx)
        (envelope-from <[email protected]>)
        id 1tAbCd-0000Xy-1Z
From: [email protected]

Baca dari bawah. Baris Received kedua ditulis server kita sendiri, jadi bisa dipercaya. Kata esmtpsa di situ berarti koneksi ESMTP yang memakai TLS (s) dan terautentikasi (a). Artinya ada klien dari IP 198.51.100.25 yang login dulu sebelum mengirim. Nilai id adalah message ID Exim yang nanti kita cari di log. Baris di atasnya ditulis server penerima, dan mencatat bahwa yang terhubung memang IP server kita. Pada kasus spoofing, baris yang ditulis server penerima akan menunjukkan IP asing. Baris Received yang menyebut server kita, kalau ada, berada di bawahnya dan tidak didukung bukti lain.

Hasil SPF, DKIM, dan DMARC sebagai petunjuk, bukan vonis

Header Authentication-Results ditulis oleh server penerima dan merangkum hasil tiga pemeriksaan. SPF mengecek apakah IP pengirim diizinkan oleh domain di envelope sender. DKIM mengecek tanda tangan kriptografis. DMARC mengecek apakah salah satu dari keduanya lolos dengan domain yang sejajar (aligned) dengan domain di header From. Pola spoofing biasanya seperti ini: SPF fail atau softfail untuk domain kita, atau SPF pass tapi untuk domain lain milik penyerang. DKIM tidak ada, gagal, atau ditandatangani domain lain. DMARC fail. Kalau kebijakan DMARC domain masih p=none, email tetap bisa masuk inbox meski gagal, dan itu sebabnya pelanggan tetap menerima keluhan. Pola akun dibobol biasanya kebalikannya: semuanya pass dengan domain kita. Dua catatan supaya tidak buru-buru menyimpulkan. Pertama, kegagalan tidak selalu berarti spoofing. Email yang diteruskan (forwarding) sering gagal SPF karena IP-nya berubah. Mailing list yang mengubah subject atau isi bisa merusak DKIM. Record SPF yang rusak juga bisa membuat email sah ikut gagal, seperti dibahas di Kenapa SPF Jadi Permerror Setelah Menambah Record Relay Email Baru. Kedua, perhatikan alamat sebenarnya, bukan nama tampilannya. Email dengan nama tampilan "Admin example.com" tapi alamat aslinya akun webmail gratisan, atau domain mirip seperti examp1e.com, bisa lolos DMARC karena domain di From memang domain si penyerang. Itu bukan spoofing domain kita, dan juga bukan akun yang dibobol.

Mencocokkan dengan log server

Header memberi arah, tapi log server kita yang memastikan. Kalau header menunjukkan email lewat server kita, ambil message ID dari baris Received yang ditulis server kita, lalu cari di log. Di server Exim, field A= pada log mencatat authenticator dan akun yang dipakai login. Di Postfix, informasinya ada di field sasl_username. Perintah di bawah ini read-only. Sesuaikan path log dengan distro dan panel kamu:

BASH

# Exim (umum di cPanel): telusuri satu pesan berdasarkan ID dari header Received
exigrep '1tAbCd-0000Xy-1Z' /var/log/exim_mainlog

# Exim: lihat login SMTP terbaru untuk satu akun beserta IP-nya
# Nama authenticator (dovecot_login/dovecot_plain) tergantung konfigurasi server
grep -E 'A=dovecot_(login|plain):[email protected]' /var/log/exim_mainlog | tail -n 20

# Postfix: login SMTP tercatat di sasl_username
# Debian/Ubuntu biasanya /var/log/mail.log, keluarga RHEL biasanya /var/log/maillog
grep '[email protected]' /var/log/mail.log | tail -n 20

Yang dicari di hasilnya adalah akun mana yang login, dari IP mana, dan seberapa banyak email yang dikirim dalam waktu singkat. Login dari IP yang tidak pernah dipakai pelanggan, ditambah lonjakan jumlah penerima, sudah cukup kuat untuk menyimpulkan akun dibobol. Log login IMAP/POP3 dari Dovecot juga layak dicek, karena penyerang sering membaca mailbox dulu sebelum mengirim. Kalau message ID ditemukan tapi tanpa A= atau sasl_username, kemungkinan email dikirim dari proses lokal, misalnya script PHP. Tergantung panel dan setting PHP, header email bisa memuat penanda seperti X-PHP-Originating-Script yang menunjukkan file pengirimnya. Kasus ini masuk ke ranah pembersihan website, bukan reset password email. Kalau ID dan waktu pengiriman sama sekali tidak ada jejaknya di log, sementara hop penerima mencatat IP asing, kesimpulannya spoofing. Penanganannya ada di sisi DNS: memastikan SPF dan DKIM benar, lalu bertahap mengetatkan DMARC.

Latihan aman di VPS uji

Menurutku, cara paling cepat paham topik ini adalah melihat kedua pola dengan mata sendiri. Siapkan VPS uji dengan domain atau subdomain milik sendiri yang sudah punya SPF, DKIM, dan DMARC p=none. Kirim satu email lewat klien email biasa dengan login SMTP ke mailbox pribadimu. Lalu dari server lain, kirim email dengan From domain uji itu tanpa login, misalnya pakai swaks dengan opsi --from dan --to. Buka header mentah keduanya (di Gmail lewat menu yang menampilkan pesan asli) dan bandingkan baris Received serta Authentication-Results-nya. Kirim hanya ke mailbox milikmu dan pakai domain milikmu. Memalsukan domain orang lain, sekalipun untuk latihan, tetap spoofing. Perlu diingat juga, banyak penyedia VPS memblokir port 25 keluar secara default, jadi cek kebijakannya dulu sebelum mengira server yang salah konfigurasi. Saat ada laporan berikutnya, minta pelanggan mengirim header lengkap, bukan screenshot. Cari hop yang ditulis server penerima dan lihat IP-nya. Baca Authentication-Results, lalu cocokkan message ID dengan log server kita. Tiga langkah itu biasanya cukup untuk menentukan apakah yang perlu diperbaiki record DNS, password akun, atau script di website. Dengan begitu, pelanggan tidak perlu menjalani reset massal yang tidak menyelesaikan masalah.