Mengira SPF Pass Cukup untuk DMARC, Padahal Domain Return-Path Tidak Selaras

Banyak yang membuka header email, melihat tulisan spf=pass, lalu menyimpulkan urusan autentikasi sudah beres. Tapi di baris yang sama ada dmarc=fail, dan email newsletter atau notifikasi transaksi tetap masuk folder spam. Kelihatannya kontradiktif. Sebenarnya tidak: SPF yang lolos belum tentu dihitung oleh DMARC, karena DMARC punya syarat tambahan yang namanya alignment. Pola ini paling sering muncul saat domain mengirim lewat layanan pihak ketiga, misalnya platform newsletter, CRM, sistem tiket, atau SMTP relay. Di support, keluhannya biasanya mirip: record SPF sudah ditambah include dari vendor, tapi Gmail tetap menandai email sebagai mencurigakan. Mari kita telusuri dari gejala sampai akar masalahnya.

Gejala yang terlihat di header

Langkah pertama selalu sama: ambil header asli dari email yang bermasalah. Di Gmail, buka email lalu pilih menu Show original (labelnya bisa berbeda tergantung bahasa antarmuka). Cari header Authentication-Results yang ditulis oleh server penerima. Header ini adalah catatan penerima tentang hasil pengecekan SPF, DKIM, dan DMARC. Bentuknya kurang lebih seperti ini. Ini contoh format output, bukan dari kejadian nyata, dan formatnya bisa sedikit berbeda antar penerima:

TEXT

Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=s1 header.b=AbCdEf12;
       spf=pass (google.com: domain of [email protected] designates 192.0.2.10 as permitted sender) [email protected];
       dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) header.from=tokoku.example

Perhatikan tiga domain yang muncul. smtp.mailfrom berisi mail.vendor.example. DKIM ditandatangani oleh mail.vendor.example. Sementara header.from, yaitu alamat yang dilihat penerima di kolom From, adalah tokoku.example. SPF lolos, DKIM lolos, tapi keduanya lolos untuk domain milik vendor, bukan untuk domain kita. Di sinilah DMARC gagal.

SPF sebenarnya memeriksa domain yang mana

Sumber kebingungannya ada di sini. SPF tidak memeriksa alamat From yang terlihat di aplikasi email. SPF memeriksa envelope sender, yaitu alamat yang dikirim di perintah MAIL FROM saat sesi SMTP. Setelah email diterima, alamat ini biasanya dicatat sebagai header Return-Path. Di header Authentication-Results, nilainya muncul sebagai smtp.mailfrom. Envelope sender ini adalah alamat tujuan bounce. Kalau email gagal terkirim, pesan penolakannya dikirim ke alamat tersebut. Karena itu layanan pengirim massal hampir selalu memakai domain mereka sendiri untuk Return-Path: mereka perlu menampung bounce, menghitungnya, dan otomatis menonaktifkan alamat yang mati. Dari sisi operasional itu masuk akal, tapi efeknya SPF dicek terhadap record SPF milik vendor, bukan milik kita. Jadi spf=pass pada contoh di atas artinya kurang lebih: IP 192.0.2.10 memang diizinkan mengirim atas nama mail.vendor.example. Itu benar, tapi tidak menjelaskan apa pun tentang hak IP tersebut memakai nama tokoku.example di kolom From.

Alignment: syarat tambahan yang diminta DMARC

DMARC dibuat untuk menutup celah itu. DMARC tidak cukup dengan SPF atau DKIM yang lolos. Hasil yang lolos harus terkait dengan domain di header From. Kaitan inilah yang disebut alignment (keselarasan). Aturannya:

SPF dianggap selaras jika SPF pass dan domain smtp.mailfrom cocok dengan domain header.from.
DKIM dianggap selaras jika DKIM pass dan domain pada tag d= di tanda tangan (muncul sebagai header.d atau header.i) cocok dengan domain header.from.
DMARC lolos jika minimal satu dari keduanya lolos dan selaras. Tidak harus dua-duanya.

Arti cocok bergantung pada mode alignment. Di record DMARC ada tag aspf untuk SPF dan adkim untuk DKIM. Nilainya r (relaxed) atau s (strict). Kalau tidak ditulis, default-nya relaxed. Pada mode relaxed, cukup organizational domain-nya yang sama, jadi bounce.tokoku.example dianggap selaras dengan tokoku.example. Pada mode strict, domainnya harus persis sama. Dengan aturan ini, contoh di atas jelas gagal. mail.vendor.example dan tokoku.example adalah organisasi yang berbeda. Mode relaxed pun tidak menolong. SPF pass tapi tidak selaras, DKIM pass tapi juga tidak selaras, jadi hasil akhirnya dmarc=fail. Kalau policy domain p=quarantine, email ke spam. Kalau p=reject, email ditolak. Penjelasan lebih panjang tentang cara membaca setiap bagian header ini ada di artikel Reading Authentication-Results Headers to Fix DMARC Alignment.

Hal yang sering dikira penyebab, padahal bukan

Sebelum mengubah apa pun, ada beberapa langkah yang sering dicoba tapi tidak menyentuh akar masalah. Menambahkan include vendor ke record SPF domain sendiri. Ini langkah yang paling sering dilakukan, dan biasanya tetap berguna kalau suatu saat vendor memakai domain kita sebagai Return-Path. Tapi selama envelope sender masih mail.vendor.example, penerima tidak pernah membaca record SPF tokoku.example untuk email tersebut. Record kita bisa sempurna dan tetap tidak berpengaruh. Mengira record SPF rusak. Kalau di header tertulis spf=pass, record SPF yang dicek memang valid. Masalahnya bukan di sintaks, melainkan domain mana yang dicek. Menganggap DKIM pass sudah cukup. Banyak vendor menandatangani email dengan domain mereka sendiri secara default. Hasilnya dkim=pass, tapi header.d bukan domain kita, sehingga tidak dihitung oleh DMARC. Menyalahkan konten atau reputasi IP. Konten dan reputasi memang memengaruhi filter spam, tapi kalau header jelas menulis dmarc=fail dan domain punya policy quarantine atau reject, penyebab utamanya sudah terlihat. Bereskan alignment dulu, baru evaluasi faktor lain. Ada satu kasus yang perlu dibedakan: email yang diforward. Saat email diteruskan oleh server lain, SPF sering gagal karena IP pengirimnya berubah. Gejalanya berbeda karena di situ SPF-nya fail, bukan pass. Ini juga alasan kenapa DKIM yang selaras biasanya lebih tahan banting daripada SPF.

Cara memperbaiki dan memastikan sudah selaras

Ada dua jalur perbaikan, dan idealnya keduanya dipasang. Pertama, custom Return-Path atau bounce domain. Banyak layanan pengirim menyediakan opsi agar envelope sender memakai subdomain milik kita, misalnya bounce.tokoku.example. Biasanya caranya dengan membuat record CNAME atau MX dan TXT di DNS yang mengarah ke infrastruktur vendor. Nama fiturnya dan record yang diminta berbeda per provider, jadi cek dokumentasi atau pengaturan domain di dashboard layanan tersebut. Setelah aktif, smtp.mailfrom menjadi subdomain kita dan SPF selaras dalam mode relaxed. Kedua, DKIM dengan domain sendiri. Ini biasanya disebut custom DKIM atau domain authentication. Vendor memberi selector dan public key yang dipasang di DNS kita, lalu email ditandatangani dengan d=tokoku.example. Jalur ini lebih awet karena tetap selaras walaupun email diforward. Untuk SMTP relay dari server sendiri, misalnya Exim atau Postfix yang meneruskan email lewat relay, perhatikan apakah relay menulis ulang envelope sender ke domain mereka. Kalau ya, solusinya sama: cari opsi custom bounce domain atau pastikan DKIM ditandatangani dengan domain kita, entah oleh server asal atau oleh relay. Konfigurasi DKIM di sisi server sendiri dibahas di Arsitektur Email Deliverability 2026: Konfigurasi SPF, DKIM, dan DMARC pada Exim cPanel. Setelah record dipasang, cek dulu dari sisi DNS sebelum mengirim email uji. Perintah ini hanya membaca, jadi aman dijalankan. Ganti nama domain dan selector sesuai milikmu:

BASH

# Policy DMARC dan mode alignment (cari tag p, aspf, adkim)
dig +short TXT _dmarc.tokoku.example

# Subdomain bounce yang diminta vendor (bisa CNAME, bisa TXT, tergantung provider)
dig +short CNAME bounce.tokoku.example
dig +short TXT bounce.tokoku.example

# Public key DKIM untuk selector yang diberikan vendor
dig +short TXT s1._domainkey.tokoku.example

Lalu kirim email uji dari layanan tersebut ke kotak masuk Gmail atau penerima lain yang menampilkan header lengkap. Yang dicari adalah kondisi seperti ini (contoh format output):

TEXT

dkim=pass [email protected] header.s=s1;
spf=pass [email protected];
dmarc=pass (p=QUARANTINE) header.from=tokoku.example

Cara membacanya sederhana: bandingkan domain di smtp.mailfrom dan header.i atau header.d dengan domain di header.from. Kalau minimal satu berada di organisasi yang sama dan statusnya pass, DMARC akan lolos. Kalau domain kamu memakai aspf=s atau adkim=s, subdomain seperti bounce.tokoku.example tidak lagi dianggap selaras. Mode strict memang lebih ketat, tapi sering membuat layanan pihak ketiga gagal tanpa disadari. Kalau domain sudah mengirim laporan agregat DMARC lewat tag rua, laporan itu juga bisa dipakai untuk memastikan perbaikan berlaku untuk semua email, bukan hanya email uji. Setiap baris laporan mencatat domain SPF dan DKIM yang dievaluasi beserta header From-nya, jadi sumber pengirim yang masih belum selaras akan terlihat. Ini penting sebelum menaikkan policy ke reject, seperti dibahas di artikel tentang audit sebelum mengganti policy DMARC. Intinya, saat melihat spf=pass bersamaan dengan dmarc=fail, jangan langsung mengutak-atik record SPF. Lihat domain di smtp.mailfrom, lalu bandingkan dengan header.from. Kalau berbeda organisasi, SPF-nya lolos untuk orang lain, bukan untuk domainmu. Perbaikannya ada di custom Return-Path dan DKIM dengan domain sendiri, lalu verifikasi lewat header email uji dan laporan DMARC.