DMARC Gagal Padahal SPF Lolos? Ini Penyebabnya

SPF sudah Anda pasang, sudah dicek berkali-kali, dan semua tes menunjukkan spf=pass. Lalu datang laporan DMARC, atau email dari klien yang masuk folder spam, dan di header-nya tertulis dmarc=fail. Rasanya tidak masuk akal: bagaimana pemeriksaan dasarnya lolos, tapi kebijakan yang dibangun di atasnya justru gagal?

Ini bukan bug, dan biasanya juga bukan salah ketik di DNS. Bagian yang terlewat namanya identifier alignment (keselarasan identitas domain). Begitu Anda paham domain mana yang sebenarnya dicek oleh masing-masing mekanisme, masalah ini berubah dari misteri menjadi perbaikan yang cukup mekanis. Artikel ini membahas konsepnya, cara membaca header email untuk membuktikannya, dan solusi yang bisa diterapkan di layanan email (ESP) yang umum dipakai.

Intinya: SPF lolos saja belum cukup

DMARC, yang didefinisikan di RFC 7489, tidak sekadar bertanya "apakah SPF lolos?" atau "apakah DKIM lolos?". Pertanyaannya lebih ketat: apakah SPF atau DKIM lolos untuk domain yang selaras dengan domain di header From yang terlihat penerima? Sebuah pesan dinyatakan lolos DMARC jika minimal satu dari dua mekanisme itu menghasilkan pass, dan domain yang diautentikasi selaras dengan domain From.

Jadi ada dua syarat. SPF bisa memenuhi syarat pertama tetapi gagal di syarat kedua. Kombinasi itulah yang menghasilkan kondisi "SPF pass, DMARC fail".

SPF ternyata mengecek domain yang berbeda

Setiap email sebenarnya membawa dua alamat pengirim, dan kebanyakan orang hanya melihat salah satunya:

• Envelope sender (RFC5321.MailFrom), yaitu alamat pada perintah SMTP MAIL FROM. Ke alamat inilah bounce dikirim, dan server penerima mencatatnya di header Return-Path. Domain inilah yang dicek SPF.
• Header From (RFC5322.From), yaitu baris From: yang tampil di aplikasi email penerima. Domain inilah yang dilindungi DMARC.

Kalau Anda mengirim dari server sendiri, keduanya sering kali domain yang sama, jadi perbedaannya tidak terasa. Masalah muncul saat Anda memakai ESP, misalnya platform newsletter atau API email transaksional. Penyedia seperti ini sering memakai domain bounce milik mereka sendiri sebagai envelope sender supaya mereka bisa mengelola bounce. Akibatnya SPF mengecek domain milik penyedia, record SPF penyedia mengizinkan server mereka, dan SPF pun lolos. Tetapi domain yang lolos itu tidak ada hubungannya dengan example.com di baris From Anda, sehingga bagi DMARC hasil pass tersebut tidak dihitung.

DKIM punya jebakan serupa. Banyak penyedia secara default menandatangani email dengan domain mereka, sehingga header tanda tangannya berisi d=esp.com. Tanda tangan valid, DKIM lolos, tapi esp.com tidak selaras dengan example.com, jadi DMARC juga tidak bisa memakainya.

Contoh di header email

Berikut potongan header (disederhanakan) dari email yang dikirim lewat ESP dengan pengaturan bawaan:

Return-Path: <bounce-8f3a2c@bounces.esp.com>
From: Toko Contoh <news@example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=esp.com; s=s1; ...
Authentication-Results: mx.receiver.net;
       spf=pass (sender IP is 203.0.113.10) smtp.mailfrom=bounces.esp.com;
       dkim=pass header.d=esp.com;
       dmarc=fail (p=QUARANTINE) header.from=example.com

Cara membacanya:

• spf=pass smtp.mailfrom=bounces.esp.com: SPF lolos, tapi untuk bounces.esp.com.
• dkim=pass header.d=esp.com: DKIM lolos, tapi untuk esp.com.
• dmarc=fail header.from=example.com: DMARC mengevaluasi kebijakan example.com dan tidak menemukan satu pun hasil pass milik domain tersebut.

Dua kali pass, nol yang selaras, hasilnya DMARC gagal. Kuncinya sederhana: bandingkan domain setelah smtp.mailfrom= dan header.d= dengan domain setelah header.from=.

Cara mengeceknya sendiri lewat Gmail

Anda tidak butuh alat khusus untuk diagnosis awal. Kirim email uji ke alamat Gmail, lalu:

1. Buka emailnya, klik ikon titik tiga di samping tombol balas, lalu pilih Tampilkan versi asli (Show original).
2. Di bagian atas, Gmail menampilkan ringkasan hasil SPF, DKIM, dan DMARC. Di baris SPF tercantum domain yang dicek, dan di baris DKIM tercantum domain penanda tangan.
3. Gulir ke header mentah dan cari header Authentication-Results yang ditambahkan Google. Perhatikan nilai smtp.mailfrom=, header.d= (atau header.i=), dan header.from=.
4. Cari juga header Return-Path dan DKIM-Signature. Tag d= di tanda tangan adalah domain penanda tangan.

Aplikasi email lain punya fitur serupa, biasanya bernama "View source" atau "Show headers". Nama header-nya standar, jadi cara membacanya sama. Kalau ada lebih dari satu Authentication-Results, pegang yang ditambahkan oleh server penerima terakhir, biasanya yang paling atas.

Sebelum mengubah apa pun, pastikan dulu sisi DNS Anda beres. Cek kebijakan dan tag alignment dengan DMARC Checker, validasi record SPF dengan SPF Checker, dan pastikan kunci publik selector DKIM sudah terpasang lewat DKIM Checker.

Relaxed vs strict alignment

"Selaras" tidak selalu berarti "sama persis". DMARC punya dua mode alignment yang diatur lewat dua tag di record DMARC:

• aspf untuk alignment SPF.
• adkim untuk alignment DKIM.

Nilainya r (relaxed) atau s (strict). Jika tidak ditulis, keduanya default ke relaxed.

Pada mode relaxed, kedua domain cukup memiliki organizational domain yang sama, yaitu domain yang didaftarkan ke registrar seperti example.com (atau example.co.id, karena public suffix ikut diperhitungkan). Jadi bounces.example.com selaras dengan example.com, dan tanda tangan DKIM d=example.com selaras dengan alamat From di news.example.com.

Pada mode strict, domainnya harus sama persis. bounces.example.com tidak dianggap selaras dengan example.com.

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=r; aspf=r

Perlu dicatat, mode relaxed tidak bisa menjembatani dua organisasi berbeda. esp.com dan example.com punya organizational domain yang berbeda, jadi mode apa pun tidak akan membuatnya selaras. Kalau masalah Anda adalah domain penyedia yang muncul di header, mengganti ke relaxed tidak membantu. Itu hanya berguna jika Anda sudah memakai subdomain sendiri tetapi terlanjur menyetel strict.

Solusi 1: Pasang custom Return-Path (domain bounce) di ESP

Ini perbaikan untuk alignment SPF. Sebagian besar penyedia besar mengizinkan Anda memakai subdomain milik sendiri sebagai envelope sender. Namanya bermacam-macam, misalnya "custom Return-Path", "custom MAIL FROM domain", "custom bounce domain", atau "domain authentication", tapi langkahnya mirip:

1. Di dashboard penyedia, tambahkan subdomain seperti bounce.example.com.
2. Buat record DNS yang diberikan, biasanya CNAME dari bounce.example.com ke hostname milik penyedia. Ada juga penyedia yang meminta record MX dan TXT SPF di subdomain tersebut.
3. Tunggu sampai terverifikasi, lalu pastikan email baru menampilkan smtp.mailfrom=bounce.example.com.

Dengan alignment SPF relaxed, bounce.example.com kini selaras dengan example.com. Bounce tetap diproses oleh penyedia karena CNAME mengarahkan subdomain itu ke infrastruktur mereka.

Solusi 2: Tanda tangani DKIM dengan domain Anda sendiri

Bisa dibilang ini perbaikan yang paling penting, karena alignment DKIM tetap bertahan di situasi ketika SPF rusak (dibahas di bagian forwarding). Aktifkan custom DKIM di penyedia Anda, biasanya ada di menu "domain authentication" atau "sender authentication". Umumnya Anda perlu memasang satu atau beberapa record CNAME atau TXT pada selector, misalnya s1._domainkey.example.com. Setelah aktif, penyedia akan menandatangani dengan d=example.com dan header akan menunjukkan dkim=pass header.d=example.com.

Karena DMARC cukup butuh satu hasil pass yang selaras, DKIM yang selaras sering sudah cukup. Menyelaraskan keduanya memberi lapisan cadangan.

Solusi 3: Rancang subdomain dengan sengaja

Banyak tim memisahkan email marketing di news.example.com dan email transaksional di mail.example.com agar reputasinya terpisah. Ini aman untuk DMARC selama Anda ingat beberapa aturan:

• Dengan alignment relaxed, tanda tangan DKIM untuk example.com atau domain bounce di bawah example.com selaras dengan alamat From mana pun di bawah example.com.
• Kalau memakai strict, setiap aliran pengiriman wajib mengautentikasi subdomain From yang persis sama.
• Subdomain mewarisi kebijakan DMARC domain induk, kecuali record induk memakai tag sp= atau subdomain itu punya record _dmarc sendiri.

Catatan soal forwarding dan mailing list

Walau konfigurasi sudah sempurna, sebagian email sah tetap bisa gagal. Saat email diteruskan (forward), server penerus mengirim ulang dari IP miliknya sendiri. Record SPF Anda tidak mengizinkan IP tersebut sehingga SPF gagal. Kalaupun penerus menulis ulang envelope sender, SPF akan lolos untuk domain penerus, yang tentu tidak selaras dengan domain Anda.

DKIM biasanya bertahan pada forwarding biasa, karena tanda tangannya ikut terbawa bersama pesan dan tidak bergantung pada IP pengirim. DKIM baru rusak jika bagian pesan yang ditandatangani diubah, dan inilah yang sering dilakukan mailing list, misalnya menambahkan tag di subjek atau footer. Ini alasan lain untuk memprioritaskan DKIM yang selaras.

Sebagian perantara menambahkan header ARC (Authenticated Received Chain) yang mencatat hasil autentikasi sebelum pesan diubah. Server penerima boleh mempertimbangkan ARC saat memutuskan nasib email yang gagal DMARC, tapi keputusan itu sepenuhnya di tangan penerima. ARC bukan sesuatu yang Anda atur di record DMARC, dan tidak menjamin email pasti masuk inbox.

Checklist singkat

• Temukan smtp.mailfrom=, header.d=, dan header.from= di header Authentication-Results dari email sungguhan.
• Jika smtp.mailfrom berisi domain penyedia, pasang custom Return-Path atau domain bounce di subdomain Anda.
• Jika header.d berisi domain penyedia, aktifkan custom DKIM agar email ditandatangani dengan d=domainanda.
• Biarkan aspf dan adkim di mode relaxed kecuali ada alasan khusus memakai strict.
• Periksa semua layanan yang mengirim atas nama domain Anda: CRM, helpdesk, sistem tagihan, formulir website.
• Pantau laporan agregat DMARC dengan p=none sebelum naik ke quarantine atau reject.

FAQ

Apakah SPF dan DKIM harus sama-sama selaras agar DMARC lolos?

Tidak. DMARC lolos jika salah satu, SPF atau DKIM, lolos dengan domain yang selaras. Meski begitu, menyelaraskan keduanya tetap disarankan karena SPF mudah rusak saat forwarding, sedangkan DKIM bisa rusak jika pesan diubah di perjalanan.

Apakah mengubah aspf ke relaxed bisa mengatasi kegagalan dari ESP?

Hanya jika domain yang diautentikasi sudah berupa subdomain dari domain Anda. Kalau header menunjukkan domain penyedia seperti bounces.esp.com, mode alignment apa pun tidak akan membuatnya cocok dengan example.com. Solusinya custom Return-Path atau custom DKIM.

Kenapa SPF lolos di tool pengecek, tapi DMARC gagal di Gmail?

Tool pengecek SPF umumnya memeriksa record domain Anda secara langsung. Gmail memeriksa domain yang benar-benar dipakai sebagai envelope sender pada email tersebut, yang bisa saja milik penyedia. Bandingkan smtp.mailfrom= di header asli dengan domain From Anda.

Apakah DMARC gagal pada email yang di-forward bisa diperbaiki?

Tidak sepenuhnya, karena cara pengiriman ulang dikendalikan oleh server penerus. DKIM yang selaras memberi peluang terbaik, sebab umumnya tetap valid selama isi pesan tidak diubah. Beberapa penerus dan mailing list juga menambahkan header ARC yang mungkin dipertimbangkan oleh penerima.

Di mana saya bisa melihat domain yang dipakai DKIM?

Lihat tag d= di header DKIM-Signature, atau nilai header.d= di Authentication-Results. Di ringkasan "Tampilkan versi asli" Gmail, baris DKIM juga menampilkan domain penanda tangan.