Cara Membaca Hasil SPF, DKIM dan DMARC di Header Email

Header email sering kali berisi hasil SPF, DKIM, dan DMARC. Mekanisme ini memberikan bukti tentang domain dan sistem yang terlibat dalam penyampaiannya. Mereka tidak memeriksa segala jenis penipuan dan tidak membuktikan bahwa pesan, pengirim, atau tautan aman.

Panduan ini menjelaskan ringkasan hasil yang dihasilkan oleh Once Email penganalisis header email. Penganalisis membaca teks yang ditempelkan secara lokal di browser. Ia tidak melakukan pencarian DNS, reputasi, malware, atau kebijakan langsung.

SPF: apakah sistem ini diotorisasi untuk domain amplop?

Kerangka Kebijakan Pengirim memungkinkan domain mempublikasikan sistem mana yang diizinkan untuk mengirim menggunakan identitas SPF. Sistem penerima membandingkan pengirim yang terhubung dengan kebijakan yang dipublikasikan dan mencatat hasil seperti pass, fail, softfail, neutral, atau none.

SPF bukan sekadar memeriksa alamat yang dilihat seseorang di bidang Dari yang terlihat. DMARC menggunakan hasil SPF untuk identitas SMTP MAIL FROM dan kemudian mengevaluasi apakah domainnya selaras dengan domain penulis yang terlihat.

Penerusan dapat mempersulit SPF karena server penerusan menjadi sistem yang menghubungkan ke penerima akhir. Oleh karena itu, hasil SPF yang gagal memerlukan konteks; hal ini tidak dengan sendirinya merupakan penilaian lengkap mengenai pesan tersebut.

DKIM: apakah bagian pesan yang ditandatangani divalidasi?

DomainKeys Identified Mail menambahkan tanda tangan kriptografi yang terkait dengan domain penandatanganan. Penerima mengambil kunci publik dari DNS dan memeriksa apakah kolom header dan isi yang ditandatangani masih divalidasi.

Izin DKIM adalah bukti bahwa materi yang ditandatangani telah divalidasi untuk domain penandatanganan. Ini tidak menetapkan bahwa nama tampilan itu jujur, bahwa setiap elemen yang terlihat telah ditandatangani, atau bahwa situs web yang ditautkan aman. Sistem surat juga dapat secara sah mengubah pesan dengan cara yang merusak tanda tangan.

DMARC: apakah identitas yang diautentikasi selaras dengan domain penulis yang terlihat?

DMARC dibangun berdasarkan SPF dan DKIM. Ini membandingkan domain SPF atau DKIM yang diautentikasi dengan domain di alamat Dari yang terlihat dan menerapkan kebijakan publikasi pemilik domain dan kebijakan penerima.

Spesifikasi IETF saat ini, RFC 9989, menjelaskan bahwa DMARC mengautentikasi pengidentifikasi tingkat domain dan tidak mengatasi serangan nama tampilan atau menganalisis konten pesan. Ini menggantikan RFC 7489 yang lebih lama pada Mei 2026.

Apa yang berubah dalam revisi DMARC 2026

RFC 9989 bukanlah bukti bahwa setiap sistem pesan tiba-tiba berubah perilaku pada tahun 2026. RFC 9989 menggabungkan definisi protokol saat ini, secara eksplisit menghapus RFC 7489 dan RFC 9091, dan memisahkan format agregat dan laporan kegagalan ke dalam spesifikasi pendamping. Aturan pembacaan praktisnya tetap stabil: izin DMARC berarti identitas SPF atau DKIM yang selaras dan mengizinkan penggunaan domain penulis yang terlihat. Ini bukan skor reputasi, pemeriksaan identitas orang yang menulis pesan, atau pemindaian tautan dan lampiran.

Perbedaan ini penting ketika menafsirkan “persyaratan DMARC baru” dalam pengumuman produk. Penyedia dapat mengubah kebijakan pengiriman atau persyaratan pengirim massal secara independen dari protokol dasar. Misalnya, panduan pengirim Gmail menerapkan persyaratan autentikasi yang berbeda berdasarkan volume pengiriman. Perlakukan kebijakan penyedia, validasi protokol, dan keamanan pesan sebagai tiga lapisan terpisah.

Lulus DMARC berarti setidaknya satu jalur autentikasi yang didukung diteruskan dengan penyelarasan yang diperlukan. Ini tidak berarti penulisnya terverifikasi secara pribadi, akunnya belum disusupi, atau pesannya tidak berbahaya.

Membaca Hasil Otentikasi

Header yang disederhanakan mungkin terlihat seperti ini:

Authentication-Results: mx.example;
  spf=pass smtp.mailfrom=mailer.example;
  dkim=pass header.d=mailer.example;
  dmarc=pass header.from=mailer.example

Tinjau nilai-nilai ini bersama-sama:

1. Server mana yang menulis kolom Authentication-Results?
2. Domain manakah yang lolos SPF?
3. Domain manakah yang ditandatangani dengan DKIM?
4. Domain manakah yang muncul di alamat Dari yang terlihat?
5. Apakah DMARC melaporkan keselarasan, kegagalan atau tidak ada kebijakan?
6. Apakah rute pengiriman masuk akal bagi pengirim yang Anda harapkan?

Header dapat berisi beberapa bidang hasil karena beberapa sistem memproses pesan tersebut. Hasil penerima tepercaya terbaru sering kali paling relevan, namun menentukan perantara mana yang tepercaya memerlukan pengetahuan tentang penyedia kotak surat dan jalur pengiriman.

Mengapa izin masuk bukan jaminan keamanan

Penyerang dapat mengautentikasi domain yang mereka kendalikan. Akun pengirim yang sah dapat disusupi. Pesan yang diautentikasi dengan benar masih dapat berisi permintaan yang menyesatkan, lampiran berbahaya, atau tautan berbahaya.

Pedoman pengirim Gmail memerlukan kontrol autentikasi yang berbeda bergantung pada volume pengiriman dan menjelaskan autentikasi sebagai upaya pengiriman dan anti-penyalahgunaan. Mereka tidak mengubah autentikasi menjadi keputusan umum tentang keamanan konten.

Jika sebuah pesan meminta kredensial, uang, tindakan mendesak, atau file sensitif, verifikasi permintaan tersebut melalui saluran kontak yang dikenal. Jangan hanya mengandalkan nama Dari atau hasil autentikasi berwarna hijau.

Gunakan penganalisis secara konservatif

Tempelkan kolom header saja, bukan isi pesan atau lampiran. Bandingkan ringkasan penganalisis dengan konteks pesan yang diterima. Perlakukan bukti yang hilang, cacat, atau bertentangan sebagai alasan untuk verifikasi tambahan, bukan sebagai bukti penipuan otomatis.

Untuk respons insiden, konfigurasi domain, atau keputusan berdampak besar, gunakan tampilan pesan asli penyedia kotak surat Anda dan konsultasikan dengan administrator email atau profesional keamanan yang berkualifikasi.