PanduanAutentikasi

DMARC gagal padahal SPF dan DKIM lolos

Kedua pemeriksaan berbunyi pass, tetapi DMARC tetap berbunyi fail. Penyebabnya adalah domain yang tidak cocok dengan alamat From Anda. Satu email uji menunjukkan domain yang mana, dan perbaikannya adalah sebuah pengaturan di pihak yang mengirim email itu.

Diperbarui 5 Oktober 20269 menit baca

Singkatnya

DMARC hanya lolos jika SPF atau DKIM lolos untuk domain di alamat From Anda. Lolos untuk domain penyedia Anda tidak dihitung.
Buka pesan terkirim di Gmail lewat Show original (tampilkan versi asli), lalu bandingkan smtp.mailfrom, header.i, dan header.from di header Authentication-Results.
Perbaiki DKIM lebih dulu: aktifkan penandatanganan dengan domain Anda sendiri di setiap layanan yang mengirim atas nama Anda. Tanda tangan DKIM bertahan saat email diteruskan, SPF tidak.
Secara bawaan, subdomain sudah cukup dekat. Jika catatan DMARC Anda memuat adkim=s atau aspf=s, subdomain tidak cukup.
Pemanasan tidak memperbaiki keselarasan. Email pemanasan dikirim melalui kotak masuk Anda dan ikut gagal bersamanya.

DMARC tidak menanyakan apakah SPF dan DKIM lolos. DMARC menanyakan apakah salah satunya lolos untuk domain di alamat From Anda. Jika SPF lolos untuk domain bounce penyedia Anda dan DKIM lolos untuk domain penanda tangan penyedia Anda, kedua baris berbunyi “pass” dan DMARC tetap berbunyi “fail”. Perbaikannya ada di pihak pengirim: atur agar pengirim itu menandatangani dengan domain Anda, atau gunakan alamat bounce (alamat tujuan email terpental) di domain Anda. Salah satu dari keduanya sudah cukup.

Kecocokan ini disebut keselarasan (alignment). Inilah bagian DMARC yang tidak bisa dilihat alat pemeriksa DNS. Selaras atau tidaknya email Anda hanya terlihat pada pesan yang benar-benar dikirim. Halaman ini menunjukkan cara membaca pesan seperti itu.

Tiga domain ikut dalam setiap email

Sebuah email memuat domain Anda di paling banyak tiga tempat. Setiap pemeriksaan melihat tempat yang berbeda.

Panji biru tua berlambang amplop, karung surat dengan label kuningan, dan surat bersegel lilin, berjajar di dermaga; segelnya mengulang lambang panji, labelnya tidak — Panji adalah baris From, label pada karung surat adalah Return-Path, segel lilin adalah tanda tangan DKIM. DMARC menghendaki label atau segel cocok dengan panji.

Di mana	Disebut juga	Siapa yang memeriksanya
Baris From yang dilihat pembaca Anda	Header From, `header.from`	DMARC. Inilah tolok ukur bagi dua lainnya.
Return-Path	Pengirim amplop (envelope sender), MAIL FROM, alamat bounce, `smtp.mailfrom`	SPF. SPF memeriksa apakah server pengirim boleh memakai domain ini.
Nilai `d=` di header DKIM-Signature	Domain penanda tangan, `header.d` atau `header.i`	DKIM. DKIM memeriksa apakah tanda tangan domain ini valid.

SPF (RFC 7208) dan DKIM (RFC 6376) masing-masing menjawab satu pertanyaan sempit, dan tidak satu pun dari pertanyaan itu menyinggung baris From Anda. Sebuah layanan newsletter bisa lolos SPF untuk domain bounce miliknya dan menandatangani dengan kuncinya sendiri, sementara pesannya tetap bisa mengaku berasal dari Anda. DMARC menutup celah itu. RFC 9989, standar DMARC sejak Mei 2026, hanya menerima suatu hasil jika domain di baliknya cocok dengan domain From, dan menjelaskan alasannya untuk DKIM dalam satu kalimat:

DMARC mengharuskan Identifier Alignment diterapkan pada DKIM-Authenticated Identifier karena sebuah pesan bisa memuat tanda tangan yang valid dari domain mana pun, termasuk domain yang dipakai pihak berniat jahat.

Hal yang sama berlaku untuk SPF, karena siapa pun bisa menerbitkan catatan SPF untuk domain miliknya. Jadi aturannya: DMARC lolos jika SPF lolos dan domainnya selaras, atau jika DKIM lolos dan domainnya selaras.

Temukan ketidakcocokan dalam satu pesan nyata

Anda memerlukan satu email yang dikirim dengan cara yang sama seperti email Anda sehari-hari, dan satu alamat Gmail untuk menerimanya.

Kirim pesan dari kotak masuk atau alat yang bersangkutan ke alamat Gmail yang bisa Anda buka.
Buka pesan itu di Gmail lewat komputer. Di samping Reply (balas), klik More (lainnya), lalu Show original (tampilkan versi asli). Google menjelaskan langkah yang sama di Trace an email with its full header.
Cari header Authentication-Results, tempat server penerima mencatat hasil pemeriksaannya (RFC 8601). Bandingkan tiga nilai: domain setelah smtp.mailfrom=, domain setelah header.i=@ (sebagian penerima menulis header.d=), dan domain setelah header.from=. Cara membaca header email membahas baris itu langkah demi langkah.

Inilah pola pesan yang lolos SPF dan DKIM tetapi gagal DMARC. Header ini dipersingkat dan memakai domain contoh:

From: anna@example.com
Return-Path: <bounces@send.vendor-mail.example>

Authentication-Results: mx.google.com;
       dkim=pass header.i=@vendor-mail.example header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=fail header.from=example.com

Bacalah dari bawah. Domain From adalah example.com. SPF lolos, tetapi untuk send.vendor-mail.example. DKIM lolos, tetapi tanda tangannya milik vendor-mail.example. Keduanya bukan example.com, jadi tidak ada yang menjamin nama di baris From.

Setelah layanan itu diatur agar menandatangani dengan domain Anda, pesan yang sama terlihat seperti ini:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=pass header.from=example.com

SPF masih menunjuk ke vendor. Itu tidak masalah. DKIM kini cocok, dan satu hasil lolos yang selaras sudah cukup bagi DMARC.

Seberapa dekat yang cukup dekat: relaxed dan strict

Kedua domain tidak harus identik. Secara bawaan, keselarasan bersifat longgar (relaxed): cukup bila keduanya termasuk dalam domain terdaftar yang sama, yang oleh standar disebut domain organisasi (organizational domain). Keselarasan ketat (strict) menuntut kecocokan persis. Anda memilihnya dengan tag adkim untuk DKIM dan aspf untuk SPF di catatan DMARC Anda.

SPF atau DKIM lolos untuk	Domain From	Relaxed (bawaan)	Strict
`example.com`	`example.com`	Selaras	Selaras
`mail.example.com`	`example.com`	Selaras	Tidak selaras
`example.com`	`news.example.com`	Selaras	Tidak selaras
`vendor-mail.example`	`example.com`	Tidak selaras	Tidak selaras

Standar itu mencatat bahwa “hampir semua pemilik domain mendapati keselarasan relaxed sudah memadai untuk kebutuhan mereka”. Meski begitu, periksa catatan Anda sendiri. Contoh catatan di bagian atas halaman Set up DMARC dari Google berakhir dengan adkim=s; aspf=s, jadi catatan yang disalin dari sana bersifat strict. Jika catatan Anda memuat kedua tag itu dan ada alat yang mengirim dari subdomain, hapus keduanya. Google sendiri memperingatkan di halaman itu bahwa keselarasan strict “dapat menyebabkan pesan dari subdomain terkait ditolak atau dikirim ke spam”.

Dari mana ketidakcocokan biasanya berasal

Layanan yang mengirim dari servernya sendiri

Platform newsletter, CRM, alat faktur, dan layanan bantuan pelanggan mengirim email Anda dari infrastruktur mereka. Sebelum Anda menghubungkan domain, mereka biasanya memakai alamat bounce di domain mereka dan menandatangani dengan kunci mereka sendiri. Dokumentasi Amazon menyebut terus terang mengapa keselarasan SPF jarang terjadi di sini: Return-Path “digunakan untuk pentalan dan keluhan yang dilacak penyedia (SES) dengan alamat miliknya” (Amazon SES). Pengaturan yang memperbaikinya punya nama berbeda di setiap layanan, dan ujungnya adalah beberapa catatan DNS di sisi Anda.

Layanan	Sebelum Anda menghubungkan domain	Pengaturan yang perlu dicari
Twilio SendGrid	Email ditampilkan sebagai dikirim “via sendgrid.net”.	Domain authentication: catatan CNAME untuk subdomain bounce dan dua kunci DKIM.
Amazon SES	Return-Path adalah subdomain dari `amazonses.com`.	Easy DKIM untuk tanda tangan, dan custom MAIL FROM domain untuk SPF.
Mailchimp	Domain sudah diverifikasi tetapi belum diautentikasi.	Email domain authentication: dua catatan CNAME untuk DKIM.

Ini uraian dari para vendor sendiri per Oktober 2026. Layanan lain bekerja dengan cara serupa. Cari di halaman bantuan mereka dengan kata kunci “authenticate domain”, “custom DKIM”, atau “branded sending domain”.

Penyedia email Anda menandatangani dengan domainnya sendiri, atau tidak sama sekali

Pada kotak masuk di domain Anda sendiri, Return-Path biasanya alamat Anda sendiri, jadi SPF selaras begitu catatan SPF Anda mencantumkan penyedia itu. Nilai setelah smtp.mailfrom= menunjukkannya. DKIM adalah bagian yang perlu diaktifkan.

Google Workspace. Sebelum Anda mengaktifkan DKIM untuk domain Anda, Google menandatangani dengan salah satu domainnya sendiri. Versi lama halaman bantuan Google menyebutkan bahwa Gmail lalu menandatangani “dengan kunci domain DKIM bawaan ini: d=*.gappssmtp.com”. Halaman yang sekarang tidak lagi menyebut domain itu, jadi periksa header Anda sendiri: header.i yang berakhiran gappssmtp.com berarti kunci Anda belum aktif. Buat kuncinya di konsol Admin lewat Apps, Google Workspace, Gmail, Authenticate email, tambahkan catatan TXT yang ditampilkan, lalu klik Start authentication (Set up DKIM).
Microsoft 365. Dokumentasi Microsoft, yang diperbarui pada Agustus 2026, menyatakan: “Saat ini, tidak ada penandatanganan DKIM untuk email keluar dari domain kustom”. Anda menerbitkan dua catatan CNAME dan mengaktifkan penandatanganan di portal Defender (How to use DKIM for email in your custom domain).

Catatan yang Anda tambahkan untuk kunci DKIM selalu berada di bawah _domainkey, dengan nama yang dipilih penyedia. Untuk Google Workspace bentuknya seperti ini, dengan kunci yang dipersingkat:

google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Alat yang terhubung ke kotak masuk Anda dan mengirim melaluinya tidak menambahkan tanda tangan sendiri. Email dari alat semacam itu terlihat persis seperti email yang Anda tulis sendiri, jadi perbaikannya ada di penyedia email, bukan di alat itu.

Pesan diteruskan

Ketika penerima meneruskan email Anda secara otomatis, email itu tiba dari server yang tidak tercantum di catatan SPF Anda. SPF gagal, atau lolos untuk domain pihak yang meneruskan. Tanda tangan DKIM bertahan sepanjang perjalanan selama tidak ada yang mengubah pesannya. Milis yang menambahkan footer atau tanda di subjek juga merusak tanda tangan itu. Anda tidak bisa memperbaikinya dari sisi Anda. FAQ pengirim Google menyatakan bahwa bagi Gmail “keselarasan DMARC tidak diwajibkan untuk pesan yang diteruskan atau pesan milis”. Itulah alasan untuk menyelaraskan DKIM dan tidak mengandalkan SPF saja.

Sebuah surat bersegel berpindah dari satu perahu pos ke perahu pos lain; tiap perahu punya karung surat dan labelnya sendiri, dan segel lilin pada surat itu utuh — Penerusan menukar karung surat beserta labelnya. Segel pada surat tetap utuh.

Itu bukan email Anda

Jika laporan DMARC Anda menunjukkan kegagalan dari server yang tidak pernah Anda pakai, mungkin ada orang lain yang mengirim dengan alamat Anda. Pesan seperti itu memang seharusnya gagal. Tidak ada yang perlu diperbaiki, dan pesan itulah alasan untuk kebijakan yang lebih ketat nanti.

Perbaiki DKIM lebih dulu, lalu SPF

Salah satu dari keduanya sudah memberi Anda hasil lolos. DKIM lebih baik untuk dimiliki, karena ikut bersama pesan. Praktik terbaik M3AAWG merumuskannya sebagai aturan: “Tanda tangani semua email keluar dengan kunci DKIM yang selaras dengan domain di header RFC5322.From.” RFC 9989 menganjurkan pemakaian keduanya.

Daftar semua yang mengirim atas nama domain Anda. Kotak masuk, alat newsletter, CRM, faktur, formulir kontak di situs Anda. Laporan DMARC Anda menyebut yang terlupa.
Uji masing-masing dengan pemeriksaan header di atas dan catat mana dari kedua domain itu yang bukan milik Anda.
Aktifkan penandatanganan dengan domain Anda di mana pun header.i menunjukkan nama lain, dan terbitkan catatan yang diberikan layanan itu. Pilih kunci 2048 bit jika penyedia DNS Anda menerimanya. Gmail mewajibkan minimal 1024 bit dan menganjurkan 2048.
Atur domain bounce kustom bila layanan itu menyediakannya, pada subdomain seperti bounce.example.com. Dengan begitu SPF ikut selaras.
Kirim ulang email uji dan cari dmarc=pass. Perubahan DNS bisa memakan waktu. Google memberi waktu hingga 48 jam sampai kunci DKIM baru mulai berfungsi.

Yang tidak berhasil adalah menambahkan vendor ke catatan Anda sendiri. include: untuk vendor di catatan SPF Anda tidak mengubah apa pun jika Return-Path berada di domain vendor, karena SPF mencari catatan domain itu, bukan catatan Anda. Catatan DMARC juga tidak bisa mencantumkan pihak ketiga tepercaya. Standar menyatakan “tidak ada mekanisme yang diterima secara umum” untuk itu.

Jika header menunjukkan dmarc=pass dan pesan tetap masuk spam, penyebabnya bukan lagi autentikasi. SPF, DKIM, dan DMARC lolos, tetapi email tetap masuk spam melanjutkan dari titik itu.

Kerugian akibat DMARC yang gagal selama kebijakan Anda p=none

Dengan p=none Anda meminta penerima tidak mengambil tindakan atas kegagalan, jadi tidak ada yang ditolak karena kebijakan Anda. Kegagalan itu tetap merugikan Anda dalam dua hal.

Aturan pengirim massal. Gmail, Yahoo, dan Outlook.com mewajibkan email yang selaras dari pengirim massal, yang bagi Gmail dan Outlook.com berarti mulai 5.000 pesan sehari. FAQ pengirim Google mencantumkan kesalahan sementara 4.7.32 untuk email yang header From-nya “tidak selaras dengan domain organisasi SPF atau DKIM yang diautentikasi”, dan menyebut “kode kegagalan sementara atau permanen, atau penempatan di folder spam” sebagai akibatnya.
Langkah berikutnya terhalang. Begitu Anda beralih ke p=quarantine atau p=reject, setiap pesan Anda sendiri yang tidak selaras akan diperlakukan sebagai spam atau ditolak. Di Gmail, pesan pentalannya berbunyi “Unauthenticated email from domain-name is not accepted due to domain's DMARC policy”, kesalahan 5.7.26 (Troubleshoot DMARC issues).

Jika Anda sama sekali belum punya catatan DMARC, mulailah dengan catatan yang perlu ditambahkan. Catatan itu juga mengaktifkan laporan yang menunjukkan keselarasan semua pengirim Anda sekaligus.

Yang bisa dan tidak bisa dilakukan pemanasan di sini

Pemanasan tidak memperbaiki keselarasan. WarmupBay terhubung ke kotak masuk Anda dan mengirim dari sana, jadi email pemanasannya dikirim dan ditandatangani oleh penyedia Anda persis seperti email yang Anda tulis sendiri. Jika kotak masuk Anda gagal DMARC, email pemanasan ikut gagal. Perbaiki catatannya lebih dulu.

WarmupBay membantu pada bagian sebelum dan sesudahnya. Saat Anda menghubungkan kotak masuk, WarmupBay memeriksa SPF, DKIM, dan DMARC untuk domainnya, dan menghentikan pemanasan jika catatan itu masih belum ada setelah 72 jam. Begitu semuanya terpasang, kotak masuk Anda bertukar beberapa email sehari dengan kotak masuk lain dalam jaringan bersama, dan dasbor menunjukkan ke mana email itu masuk: kotak masuk, tab Gmail, atau spam, terpisah untuk Google dan untuk penyedia lain. WarmupBay tidak menguji email dari alat newsletter atau CRM Anda, karena email itu tidak pernah melewati kotak masuk Anda, dan belum bisa menghubungkan kotak masuk Microsoft 365 atau Outlook.com. Layanan ini gratis untuk 10 email pemanasan sehari. Hubungkan kotak masuk Anda setelah header menunjukkan dmarc=pass.

Pertanyaan yang sering diajukan

SPF lolos dan selaras, DKIM tidak selaras. Apakah itu cukup?

Untuk DMARC, ya. Satu hasil lolos yang selaras sudah cukup. Itu tidak lagi cukup ketika penerima meneruskan email Anda, karena SPF lalu tidak cocok lagi. Google juga menulis di FAQ pengirimnya bahwa keselarasan dengan SPF dan DKIM sekaligus kemungkinan akan menjadi persyaratan, jadi tetap siapkan DKIM untuk domain Anda.

Mengapa DMARC gagal pada sebagian penerima dan lolos pada yang lain?

Karena email sampai ke mereka lewat jalur yang berbeda atau dari pengirim yang berbeda. Penerima yang meneruskan ke kotak masuk lain, atau sebuah milis, mengubah apa yang dilihat SPF dan kadang juga DKIM. Bisa juga salah satu dari beberapa layanan pengirim Anda belum disiapkan. Laporan agregat mencantumkan hasil per server pengirim dan menunjukkan kasus mana yang terjadi.

Apakah alamat Reply-To berperan dalam DMARC?

Tidak. DMARC hanya memakai domain di header From. Alamat Reply-To, nama tampilan, dan header Sender tidak termasuk dalam pemeriksaan.

Bagaimana cara melihat masalah keselarasan tanpa membuka header?

Lewat laporan agregat DMARC. Setiap entri memiliki blok policy_evaluated dengan hasil dkim dan spf, yaitu hasil setelah uji keselarasan. Blok auth_results di bawahnya menunjukkan hasil mentah beserta domain yang diperiksa. Hasil mentah pass di samping hasil evaluasi fail adalah persis kasus di halaman ini. Anda menerima laporan itu dengan menambahkan alamat rua ke catatan DMARC Anda.

Header berbunyi dkim=fail atau dkim=neutral. Apakah itu masalah yang sama?

Tidak. Dalam kasus itu tanda tangannya sendiri yang tidak terverifikasi, dan itu kesalahan yang berbeda. Jika teksnya berbunyi body hash did not verify, halaman pemecahan masalah Google menyebut penyebabnya: pesan diubah setelah ditandatangani, misalnya oleh gateway yang menambahkan footer. Keselarasan menyangkut tanda tangan yang valid tetapi milik domain lain.

Apakah saya perlu kunci DKIM terpisah untuk setiap layanan yang mengirim atas nama saya?

Dalam praktiknya, ya. Setiap layanan menandatangani dengan kuncinya sendiri dan menerbitkannya dengan nama selector sendiri di bawah _domainkey pada domain Anda, sehingga beberapa kunci bisa berdampingan tanpa bentrok. Ini berbeda dari SPF, karena satu domain hanya boleh memiliki satu catatan SPF.