Cara Membaca Header Email: Received, SPF, DKIM, DMARC

Header email adalah "catatan perjalanan" sebuah pesan: dari server mana email dikirim, lewat mana saja, dan apakah lolos pemeriksaan SPF, DKIM, serta DMARC. Cara membacanya: baca rangkaian Received dari bawah ke atas untuk melacak rute, lihat Return-Path untuk tahu alamat envelope sender, lalu periksa Authentication-Results yang ditambahkan server penerima untuk melihat hasil spf=, dkim=, dan dmarc=.

Panduan ini menjelaskan cara menampilkan header di Gmail dan Outlook, arti setiap header penting, cara menafsirkan ARC, dan sebuah contoh header lengkap yang dianotasi baris demi baris. Keterampilan ini sangat berguna saat Anda men-debug email yang masuk spam, ditolak, atau dicurigai sebagai phishing.

Cara Menampilkan Header Email

Klien email menyembunyikan header secara default. Berikut cara membukanya di aplikasi yang paling umum.

Gmail (web)

Buka email yang ingin diperiksa.
Klik ikon titik tiga (Lainnya) di samping tombol Balas.
Pilih Tampilkan yang asli (Show original).

Gmail akan membuka tab baru berisi ringkasan hasil SPF, DKIM, dan DMARC di bagian atas, diikuti header dan isi mentah. Ada tombol untuk mengunduh pesan sebagai file .eml atau menyalin ke clipboard.

Outlook di web dan Outlook baru

Buka email.
Klik ikon titik tiga (Tindakan lainnya).
Pilih Tampilan lalu Tampilkan detail pesan (View message details).

Outlook klasik (desktop Windows)

Buka email di jendela terpisah (klik dua kali).
Klik File lalu Properties.
Header ada di kotak Internet headers.

Apple Mail dan Thunderbird

Di Apple Mail, gunakan menu View → Message → All Headers atau Raw Source. Di Thunderbird, gunakan View → Message Source (atau Ctrl+U). Letak menu bisa sedikit berbeda antarversi, tetapi namanya biasanya mirip.

Contoh Header Email yang Dianotasi

Berikut contoh header (disederhanakan, memakai domain dan IP khusus dokumentasi) dari email yang dikirim layanan newsletter atas nama tokocontoh.com ke Gmail:

Delivered-To: pembeli@gmail.com
Received: by 2002:a05:6a10:xxxx with SMTP id abc123;
        Mon, 5 Oct 2026 09:14:07 -0700 (PDT)                       [3]
ARC-Seal: i=1; a=rsa-sha256; t=1791216847; cv=none; d=google.com; s=arc-20240605; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; d=google.com; s=arc-20240605; h=...; b=...
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@tokocontoh.com header.s=s1;
       spf=pass smtp.mailfrom=bounce@mail.tokocontoh.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=tokocontoh.com
Return-Path: <bounce@mail.tokocontoh.com>                          [A]
Received: from o1.mail.penyedia-email.example (o1.mail.penyedia-email.example. [198.51.100.20])
        by mx.google.com with ESMTPS id xyz789
        for <pembeli@gmail.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384);
        Mon, 5 Oct 2026 09:14:06 -0700 (PDT)                       [2]
Received-SPF: pass (google.com: domain of bounce@mail.tokocontoh.com designates 198.51.100.20 as permitted sender) client-ip=198.51.100.20;
Authentication-Results: mx.google.com;                              [B]
       dkim=pass header.i=@tokocontoh.com header.s=s1 header.b=AbCdEf12;
       spf=pass (google.com: domain of bounce@mail.tokocontoh.com designates 198.51.100.20 as permitted sender) smtp.mailfrom=bounce@mail.tokocontoh.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=tokocontoh.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tokocontoh.com; s=s1;
        h=from:subject:to:date:message-id; bh=...; b=AbCdEf12...         [C]
Received: from app-server (unknown [203.0.113.5])
        by o1.mail.penyedia-email.example (Postfix) with ESMTPSA id 4F2A1
        for <pembeli@gmail.com>; Mon, 5 Oct 2026 16:14:05 +0000 (UTC)    [1]
From: Toko Contoh <info@tokocontoh.com>                            [D]
To: pembeli@gmail.com
Subject: Pesanan Anda sudah dikirim
Date: Mon, 05 Oct 2026 16:14:04 +0000
Message-ID: <20261005161404.4F2A1@tokocontoh.com>                  [E]

Angka dan huruf dalam kurung siku bukan bagian dari header asli; itu penanda untuk penjelasan berikut.

Membaca Rangkaian Received

Setiap server yang menangani email menambahkan satu baris Received di paling atas header. Karena itu, header Received paling bawah adalah hop pertama, dan yang paling atas adalah hop terakhir.

[1] Server aplikasi toko (IP 203.0.113.5) mengirim email ke server penyedia newsletter melalui SMTP terautentikasi (ESMTPSA, huruf A berarti authenticated).
[2] Server penyedia (198.51.100.20) mengirim ke mx.google.com menggunakan TLS 1.3. Baris inilah yang paling penting, karena IP di sini adalah IP yang diperiksa SPF oleh Gmail.
[3] Hop internal di infrastruktur Google sebelum masuk ke mailbox.

Beberapa hal yang bisa Anda simpulkan dari rangkaian Received:

Keterlambatan pengiriman: bandingkan cap waktu antar-hop (perhatikan zona waktu). Selisih besar menunjukkan antrean di server tertentu.
Penggunaan TLS: kata ESMTPS dan keterangan version=TLS1_3 menunjukkan koneksi terenkripsi pada hop tersebut.
Server pengirim sebenarnya: pada email phishing, hop terbawah yang bisa dipercaya sering mengungkap IP yang tidak ada hubungannya dengan merek yang dicatut.

Penting: header Received di bagian bawah bisa dipalsukan oleh pengirim, karena pengirim bebas menulis apa saja sebelum pesan sampai ke server Anda. Yang benar-benar bisa dipercaya hanyalah header yang ditambahkan oleh server yang Anda kenal (misalnya server penerima Anda sendiri) dan hop tepat sebelumnya yang dicatat server tersebut.

Return-Path: Alamat Envelope Sender

[A] Return-Path ditambahkan oleh server yang mengantarkan email ke mailbox, berdasarkan perintah MAIL FROM di sesi SMTP. Alamat ini adalah tujuan bounce, dan domain inilah yang diperiksa oleh SPF.

Perhatikan bahwa Return-Path (bounce@mail.tokocontoh.com) berbeda dengan From (info@tokocontoh.com). Ini normal. Banyak layanan pengiriman memakai subdomain khusus untuk bounce (sering disebut custom return-path). Karena mail.tokocontoh.com adalah subdomain dari tokocontoh.com, keduanya tetap aligned dalam mode relaxed DMARC.

Jika Return-Path memakai domain milik penyedia (misalnya bounces.penyedia-email.example), SPF bisa lolos tetapi tidak aligned. Kasus ini dijelaskan lengkap di artikel DMARC gagal padahal SPF lolos.

Authentication-Results: Rapor SPF, DKIM, DMARC

[B] Header Authentication-Results (didefinisikan di RFC 8601) ditulis oleh server penerima untuk mencatat hasil pemeriksaannya. Bagian pertama (mx.google.com) menunjukkan siapa yang melakukan pemeriksaan. Hanya percayai Authentication-Results yang ditambahkan oleh server penerima Anda sendiri; header serupa dari hop sebelumnya bisa saja dipalsukan.

Bagian	Arti
`spf=pass ... smtp.mailfrom=`	IP pengirim diizinkan oleh SPF domain envelope sender.
`dkim=pass header.i=@tokocontoh.com header.s=s1`	Tanda tangan DKIM valid untuk domain `tokocontoh.com` dengan selector `s1`.
`dmarc=pass ... header.from=tokocontoh.com`	Setidaknya satu dari SPF/DKIM lolos dan aligned dengan domain From.
`p=QUARANTINE`	Kebijakan DMARC yang dipublikasikan domain.
`dis=NONE`	Disposisi yang diterapkan Gmail: tidak ada tindakan khusus.

Nilai yang mungkin muncul antara lain pass, fail, softfail, neutral, none, temperror, dan permerror. Jika muncul permerror pada SPF, periksa sintaks record atau jumlah DNS lookup dengan SPF Checker. Jika DKIM gagal, cek record selector dengan DKIM Checker menggunakan selector yang tertera di header.s atau tag s=.

DKIM-Signature, From, dan Message-ID

[C] DKIM-Signature berisi tag penting: d= (domain penanda tangan), s= (selector), h= (daftar header yang ditandatangani), bh= (hash isi), dan b= (tanda tangan). Untuk memverifikasi, penerima mengambil kunci publik di s1._domainkey.tokocontoh.com.

Dapatkan Update Terbaru

Berlangganan gratis. Artikel & tutorial coding terbaru langsung ke email kamu. Tanpa spam.

[D] From adalah alamat yang dilihat pembaca, dan domain inilah yang dijadikan acuan DMARC. Pada email phishing, nama tampilan di From sering dibuat meyakinkan, sementara domain sebenarnya berbeda.

[E] Message-ID adalah pengenal unik pesan. Berguna untuk mencari email yang sama di log server.

Header Lain yang Layak Diperhatikan

Selain header utama di atas, beberapa header berikut sering membantu proses diagnosa:

Received-SPF: catatan hasil SPF versi lama yang masih ditambahkan sebagian server. Isinya biasanya sama dengan bagian spf= di Authentication-Results, ditambah client-ip yang diperiksa.
List-Unsubscribe dan List-Unsubscribe-Post: menunjukkan apakah email massal menyediakan tautan berhenti berlangganan, termasuk versi satu klik (RFC 8058). Email pemasaran tanpa header ini lebih berisiko dikeluhkan penerima.
Reply-To: pada email phishing, Reply-To sering diarahkan ke alamat berbeda dari From agar balasan korban jatuh ke tangan penipu.
Header berawalan X-: header khusus yang ditambahkan penyedia, misalnya ID kampanye, skor spam, atau nama server internal. Header ini tidak standar, jadi artinya bergantung pada penyedia yang menambahkannya.

Jika Anda menemukan header dengan nilai yang di-encode (misalnya subjek berbentuk =?UTF-8?B?...?=), bagian setelah B? adalah teks Base64 yang bisa didekode dengan Base64 decoder.

ARC: Authenticated Received Chain

ARC (RFC 8617) dirancang untuk kasus forwarding dan mailing list, ketika SPF dan kadang DKIM rusak di tengah jalan. Setiap perantara yang mendukung ARC menambahkan tiga header bernomor urut i=1, i=2, dan seterusnya:

ARC-Authentication-Results: salinan hasil autentikasi yang dilihat perantara saat menerima pesan.
ARC-Message-Signature: tanda tangan mirip DKIM atas pesan pada titik itu.
ARC-Seal: tanda tangan atas header ARC sebelumnya; tag cv= berisi status rantai (none untuk set pertama, pass atau fail untuk set berikutnya).

Dalam contoh di atas, Google sendiri menambahkan set ARC i=1. Jika email ini kemudian diteruskan ke penyedia lain yang mempercayai Google sebagai penanda ARC, penerima akhir bisa melihat bahwa saat tiba di Gmail email ini lolos DMARC, walaupun SPF gagal setelah diteruskan. Perlu diingat, apakah penerima mau mempercayai ARC tergantung kebijakan masing-masing.

Alur Diagnosa Cepat

Lihat Authentication-Results teratas milik server penerima Anda. Apakah dmarc=pass?
Jika DMARC gagal, cek SPF: apakah domain di smtp.mailfrom sama atau satu organisasi dengan domain From?
Cek DKIM: apakah header.i atau d= sama atau satu organisasi dengan domain From?
Telusuri Received dari bawah untuk menemukan server keluar terakhir dan IP-nya.
Periksa record SPF, DKIM, dan DMARC domain dengan alat yang sesuai.

Jika Anda sedang mengatasi penolakan Gmail, langkah ini juga dipakai di panduan mengatasi error Gmail 550 5.7.26.

Kesalahan Umum Saat Membaca Header

Membaca Received dari atas ke bawah seolah-olah itu urutan kronologis.
Mempercayai Authentication-Results dari server lain yang muncul di bawah header milik penerima Anda.
Menganggap Return-Path harus sama dengan From. Yang penting adalah alignment domain, bukan kesamaan alamat.
Mengabaikan zona waktu saat menghitung keterlambatan antar-hop.
Membagikan header mentah ke publik tanpa menyamarkan alamat email dan IP internal.

FAQ

Header Received mana yang menunjukkan IP pengirim asli?

Mulailah dari header Received yang ditambahkan oleh server penerima Anda (biasanya dekat bagian atas), lalu lihat bagian from ... [IP]. Itu adalah IP terakhir yang menyerahkan email ke server Anda dan dapat dipercaya. Hop di bawahnya ditulis server lain dan bisa saja dipalsukan.

Apa beda Return-Path dan Reply-To?

Return-Path adalah alamat bounce dari sesi SMTP dan dipakai untuk SPF. Reply-To adalah alamat yang dipakai saat penerima menekan Balas. Keduanya tidak memengaruhi satu sama lain.

Kenapa ada dua header Authentication-Results?

Bisa karena email melewati lebih dari satu sistem yang memeriksa autentikasi, misalnya gateway keamanan lalu server mailbox. Yang paling relevan adalah yang ditambahkan oleh server penerima akhir Anda.

Apakah dkim=pass berarti email pasti aman?

Tidak. DKIM pass hanya membuktikan pesan ditandatangani oleh domain di tag d= dan tidak diubah. Penipu bisa saja menandatangani email dari domain mirip milik mereka sendiri. Selalu periksa domain sebenarnya, bukan hanya status pass.