Header email: cara membacanya, dan apa yang dibuktikannya

Apa sebenarnya blok header itu

Setiap pesan adalah dua hal yang dipisahkan oleh satu baris kosong: sebuah blok baris Name: value, dan teks yang Anda baca. RFC 5322 menyebut bagian pertama ini header, dan setiap barisnya sebuah field, dan RFC ini tidak menetapkan batas berapa banyak field yang boleh ada. Aplikasi email Anda biasanya cuma menampilkan empat atau lima. Sebuah pesan yang sudah melewati tiga server biasanya membawa antara tiga puluh sampai enam puluh baris.

Return-Path: <bounces+2841@mail.example.com>
Delivered-To: signup-2026@example.org
Received: by mx.example.org (Postfix) with LMTP id 4c8f21
        for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:22 +0000 (UTC)
Received: from out-17.mail.example.com (out-17.mail.example.com [198.51.100.17])
        by mx.example.org (Postfix) with ESMTPS id 9a31b0
        for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:21 +0000 (UTC)
Authentication-Results: mx.example.org;
        spf=pass smtp.mailfrom=mail.example.com;
        dkim=pass header.d=example.com;
        dmarc=pass header.from=example.com
From: "Example Support" <support@example.com>
To: signup-2026@example.org
Subject: Confirm your email address
Date: Fri, 5 Sep 2026 09:14:19 +0000
Message-ID: <20260905091419.9a31b0@mail.example.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_4c8f21"

Dibaca dari atas ke bawah, ini terlihat seperti noise mesin, dan sebagian besar memang begitu. Empat field membawa hampir semua informasinya, dan itulah keempat field yang menjadi topik panduan ini: Received, From, Return-Path, dan Authentication-Results.

Di mana header lengkapnya bersembunyi

Tidak satu pun di bawah ini butuh tool, ekstensi, atau akun. Setiap aplikasi email menyimpan pesan mentahnya di balik satu item menu, dan kata yang harus dicari selalu berupa salah satu bentuk dari sumber, asli, atau mentah.

Jalur-jalur menu itu berlaku seperti itu pada 5 September 2026, dan biasanya berubah kira-kira setahun sekali — itulah sebabnya kalimat di atas lebih penting daripada tabelnya sendiri: apa pun nama item itu musim ini, di dalamnya akan selalu ada kata sumber, asli, atau mentah.

Rantai Received, dibaca dari bawah

Setiap server yang menerima pesan itu menulis satu baris Received: dan meletakkannya di atas blok itu, di atas semua yang sudah ada di sana. Kebiasaan tunggal ini menghasilkan fakta paling berguna yang ada soal header: hop terakhir adalah baris pertama yang Anda lihat, dan perjalanan pesan itu tertulis terbalik.

Received: by mx.example.org (Postfix) with LMTP id 4c8f21
        for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:22 +0000 (UTC)
Received: from out-17.mail.example.com (out-17.mail.example.com [198.51.100.17])
        by mx.example.org (Postfix) with ESMTPS id 9a31b0
        for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:21 +0000 (UTC)
Received: from app-3.internal (app-3.internal [192.0.2.53])
        by out-17.mail.example.com (Postfix) with ESMTP id 771c4e
        for <signup-2026@example.org>; Fri, 5 Sep 2026 09:11:58 +0000 (UTC)

Setiap baris dibangun dari segenggam kata yang sama, dan begitu Anda bisa menyebut nama masing-masing, rantai itu berhenti menjadi sekadar hiasan latar.

from

Nama yang dipakai mesin yang terhubung untuk menyebut dirinya sendiri, diikuti dalam kurung oleh apa yang sebenarnya — nama reverse-DNS dan alamat IP yang dilihat server penerima pada koneksi itu. Nama sebelum kurungnya adalah sebuah klaim. Alamat di dalam kurungnya adalah yang benar-benar diamati.

by

Server yang menulis baris ini. Inilah satu-satunya pihak dalam baris itu yang bisa Anda mintai tanggung jawab atas apa pun di dalamnya.

with

Bagaimana hop itu dilakukan: ESMTP, ESMTPS kalau koneksinya terenkripsi, LMTP untuk penyerahan terakhir ke sebuah kotak surat. Sebuah hop yang bertuliskan ESMTP tanpa S membawa pesan itu dalam bentuk polos tanpa enkripsi.

for

Penerima envelope pada hop itu — alamat Anda yang mana yang sebenarnya dituju pesan itu, sebelum aturan penerusan mana pun menuliskannya ulang. Pada sebuah domain catch-all atau sebuah tag plus, inilah field yang menyebutkan nama alamat yang bocor.

stempel waktu di bagian akhir

Kapan server itu selesai menerima pesan tersebut. Kurangi waktu satu baris dengan waktu baris di atasnya, dan Anda mendapatkan jeda pada hop itu — begitulah cara mengetahui di mana sebuah pesan yang lambat sebenarnya tertahan, alih-alih sekadar menebak-nebak.

Pada contoh di atas, pesan itu meninggalkan aplikasinya pada pukul 09:11:58 dan mencapai server outbound provider pengirim dua menit dua puluh tiga detik kemudian; kedua hop sesudahnya cuma butuh satu detik di antara keduanya. Sebuah pesan yang tiba terlambat satu jam hampir selalu punya satu baris yang di dalamnya ada jeda satu jam, dan itu jarang sekali baris yang terakhir.

Empat field yang sama-sama mengaku sebagai pengirim

“Siapa yang mengirim ini” punya empat jawaban dalam sebuah header, dan keempatnya boleh saja tidak sepakat. Kebanyakan mereka tidak sepakat karena alasan yang membosankan — sebuah mailing list, sebuah platform pemasaran, sebuah aturan penerusan yang Anda buat sendiri. Sebuah ketidakcocokan bukan bukti apa pun. Yang justru berguna adalah mengetahui, dari keempatnya, mana yang sedang Anda lihat.

From:

Alamat yang ingin ditampilkan pengirim, ditambah sebuah nama tampilan yang berupa teks bebas. Tidak ada satu pun dari keduanya yang diverifikasi. Inilah field yang ditaruh aplikasi email Anda di daftar pesan, dan di ponsel, alamatnya biasanya tersembunyi sepenuhnya di balik namanya.

Return-Path:

Pengirim envelope, dituliskan ke dalam header oleh server yang menerima pesan itu, berdasarkan apa yang benar-benar diucapkan selama percakapan SMTP. Di sinilah sebuah bounce dikirim, dan inilah alamat yang diperiksa oleh SPF — dan itulah persis sebabnya sebuah pesan bisa lolos SPF sambil membawa From: yang sama sekali tidak ada hubungannya.

Reply-To:

Ke mana balasan Anda akan dialamatkan, dan itu tidak harus sama dengan dari mana pesan itu berasal. Pengirim biasa memakainya untuk meja bantuan dan alamat no-reply. Ini juga trik tertua dalam bisnis ini, karena seorang pembaca yang hati-hati memeriksa pengirimnya, memutuskan semuanya aman, lalu menekan Balas.

Delivered-To: dan X-Original-To:

Alamat Anda yang mana yang dipakai. Pada sebuah domain catch-all atau dengan sebuah tag plus, inilah field yang menyebutkan nama alamat yang benar-benar Anda bagikan — yang mengidentifikasi siapa yang membocorkannya.

From: "Example Support <support@example.com>" <billing@example.net>
         ^-- the display name, which is free text and is all a phone shows
                                              ^-- the address, which is not

Nama tampilan adalah teks bebas apa saja, jadi ia bisa memuat sebuah alamat lengkap milik orang lain. Setiap aplikasi email di dunia akan menampilkan bagian dalam tanda kutip dan menyembunyikan bagian dalam kurung siku — dan itulah keseluruhan seranganya: tidak ada biaya untuk menuliskannya, dan itu bekerja pada satu-satunya field yang dijamin akan dilihat pembaca.

SPF, DKIM, dan DMARC, dalam satu baris

Ada satu field yang berbeda dari semua field lain di blok itu. Authentication-Results: ditulis oleh server yang menerima pesan itu — milik Anda — dan apa pun yang datang dengan nama yang sama akan dihapus atau diganti namanya sebelum Anda melihatnya. Inilah satu-satunya baris dalam sebuah header yang tidak bisa ditulis oleh seorang pemalsu.

Authentication-Results: mx.example.org;
        spf=pass (sender IP is 198.51.100.17) smtp.mailfrom=mail.example.com;
        dkim=pass header.d=example.com header.s=s1 header.b=Qk3vR2mA;
        dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

Tiga pemeriksaan ada di baris itu, dan masing-masing menjawab pertanyaan yang berbeda. Kolom keempat adalah yang layak dibaca dua kali.

Kolom terakhir itulah inti keseluruhannya, dan di situlah kebanyakan pembacaan header jadi salah arah. dmarc=pass membuktikan bahwa domain yang tercetak di From: mengizinkan pesan itu. Itu sama sekali tidak bilang apa-apa soal apakah domain itu pantas mendapatkan sesuatu dari Anda — dan menerbitkan sendiri record-recordnya cuma butuh waktu sekitar sepuluh menit, bagi siapa saja.

Lima hal yang tidak bisa diberitahukan sebuah header

• Di mana pengirimnya berada. Alamat mesin tempat seseorang mengetik pesannya biasanya sama sekali tidak ada di dalam blok itu. Provider webmail besar sudah berhenti menerbitkannya sejak bertahun-tahun lalu, dan yang tersisa cuma server outbound mereka sendiri, yang berada di sebuah data center dan cuma memberi tahu Anda nama sebuah perusahaan hosting.
• Siapa pengirimnya. Sebuah domain bukan seseorang. dmarc=pass untuk sebuah domain yang dibeli empat puluh menit lalu adalah sebuah lolos yang sepenuhnya asli.
• Apakah semuanya itu benar. Autentikasi itu soal envelope-nya, dan tidak pernah soal klaim di dalamnya. Sebuah invoice bisa ditandatangani dengan benar, diselaraskan dengan benar, dan sepenuhnya karangan.
• Apakah pesan itu dibaca seseorang. Tidak ada apa pun di header yang mencatat itu. Yang mencoba melakukannya adalah sebuah pixel pelacak di badan pesan, dan itu mekanisme yang berbeda dengan pertahanan yang berbeda pula.
• Kapan pesan itu ditulis. Date: berasal dari mesin pengirim sendiri dan jam pengirim sendiri. Sebuah pesan yang tercap tiga jam di masa depan jauh lebih sering berarti komputer yang salah konfigurasi daripada sesuatu yang menarik; stempel waktu yang bisa Anda andalkan ada di baris-baris Received yang ditulis provider Anda.

Dan ada satu keluarga field lain yang secara konstruksi memang tidak membuktikan apa pun. Apa pun yang diawali X- adalah sebuah ekstensi privat yang dikarang oleh siapa pun yang menuliskannya, dan seorang pengirim boleh menuliskan apa saja yang mereka mau: X-Spam-Status: No dalam sebuah pesan cuma berarti pesan itu sendiri yang bilang dirinya bukan spam.

Ketika pesan itu mendarat di sebuah alamat sekali pakai

Perlu jelas soal apa yang dikembalikan layanan ini dan apa yang tidak. Sebuah pesan yang dibaca di sini tiba dalam bentuk yang sudah di-parse, bukan mentah: pengirim, subjek, tanggal, teks, HTML, dan daftar lampiran — field-field yang memang dicari sebuah script — dan bukan blok headernya. Pembacaan seperti di atas adalah sesuatu yang Anda lakukan di kotak surat yang menyimpan email asli Anda.

{
  "id":           "m_7Kq2fV3xTn",
  "from":         "support@example.com",
  "from_name":    "Example Support",
  "to":           "signup-2026@grabmail.io",
  "subject":      "Confirm your email address",
  "date":         "2026-09-05T09:14:22+00:00",
  "expires_at":   "2026-09-10T09:14:22+00:00",
  "text":         "Confirm your address: <https://example.com/confirm/9a31b0>",
  "text_derived": true,
  "html":         "<!doctype html><html>…",
  "attachments":  []
}

Yang justru diberikan sebuah alamat sekali pakai adalah sebuah sinyal yang tidak bisa disamai field header mana pun, dan itu berlaku bahkan sebelum Anda membaca satu baris pun: Anda memberikan alamat itu ke tepat satu pihak. Sebuah pesan yang tiba di situ dan mengaku berasal dari orang lain, entah diteruskan oleh pihak yang Anda beri alamat itu, atau dikirim oleh siapa pun yang alamat itu mereka bagikan lagi. Tidak ada penjelasan ketiga, dan tidak ada apa pun yang perlu diverifikasi.

Itulah argumen yang sama yang dibuat sebuah tag plus, minus bagian di mana tag itu bisa dipotong dalam satu baris kode — di sini alamatnya sendiri yang berbeda, jadi tidak ada apa pun yang bisa dipotong. Ini juga sebabnya sebuah catch-all pada domain milik Anda sendiri adalah versi terkuatnya: satu alamat per pendaftaran, disimpan selama Anda tetap memegang domainnya, dan Delivered-To: di kotak surat Anda sendiri menyebutkan nama alamat yang bocor.

Pemeriksaan yang masih bisa Anda lakukan

Lihat ke mana tautannya menuju, bukan apa bunyi teksnya. Field text berisi entah bagian plain-text asli dari pengirim, atau sebuah rendering dari HTML-nya — text_derived memberi tahu yang mana — dan rendering itu menyimpan setiap tujuan tautan dalam kurung siku. Jadi alamat yang seharusnya dituju sebuah tombol sudah ada begitu saja di dalam respons itu, terlihat jelas, tanpa perlu memuat halamannya, gambar-gambarnya, atau pixel-nya.

Confirm your address: <https://example.com/confirm/9a31b0>

Not you? Ignore this message. <https://example.com/help>

Versi enam puluh detik

1. Buka sumbernya. Tampilkan asli, Lihat sumber pesan, atau Raw Source, tergantung aplikasi email mana yang Anda pakai.
2. Cari Authentication-Results lebih dulu. Satu baris, ditulis oleh provider Anda sendiri, dan satu-satunya yang tidak bisa dipalsukan siapa pun yang lain. dmarc=pass dan domain di From: benar-benar mengizinkan pesan itu; dmarc=fail dan domain itu tidak mengizinkannya.
3. Bandingkan From: dengan Return-Path: dan Reply-To:. Ketiganya tidak sepakat karena alasan yang membosankan, sepanjang hari. Ketiganya juga tidak sepakat karena satu alasan yang menarik.
4. Baca baris-baris Received dari bawah ke atas, dan berhenti mempercayainya begitu sampai di mesin pertama yang bukan milik provider Anda.
5. Lalu lihat ke mana tautan-tautannya menuju, karena itulah bagian yang menentukan apa yang sebenarnya terjadi pada Anda.

Semua yang di atas menjawab satu pertanyaan sempit: apakah domain di From: mengizinkan pesan ini? Itu pertanyaan yang lebih kecil daripada “apakah ini aman”, dan tetap layak dijawab — itulah satu-satunya pertanyaan yang bisa dijawab sebuah header sama sekali.

Pertanyaan