DMARC Gagal Tapi SPF dan DKIM Lulus? Perbaikan Keselarasan (2026)

Diterbitkan 2026-07-08

Angka per 2026-06-29 · metodologi v7. Data sensus agregat dari 261 juta domain yang dinilai. Lihat cara kami menilai.

DMARC membutuhkan lebih dari sekadar lulus — domain yang lulus SPF atau DKIM harus cocok dengan domain From Anda. Sebagian besar email “SPF lulus, DMARC gagal” lulus SPF di bounce domain vendor, bukan domain Anda. Hanya 7.4% dari 261,086,232 domain yang dinilai lulus SPF dengan keselarasan di bawah kebijakan DMARC yang menegakkan, menurut sensus Defaults.Exposed (2026-06-29).

Perbaikannya lebih cepat dari yang disarankan kebingungannya. Baca header Authentication-Results untuk melihat leg mana — SPF atau DKIM — yang lulus di domain yang salah; kemudian aktifkan penandatanganan DKIM domain kustom layanan pengiriman Anda (biasanya beberapa CNAME, dan perbaikan yang bertahan saat email diteruskan), atau atur return-path kustomnya agar SPF lulus di domain Anda. Satu leg yang selaras sudah cukup untuk DMARC.

Bagaimana DMARC bisa gagal ketika SPF dan DKIM keduanya lulus?

Karena DMARC tidak pernah bertanya “apakah SPF lulus?” Ia bertanya: apakah SPF atau DKIM lulus untuk domain yang cocok dengan alamat From yang dilihat penerima Anda? Syarat tambahan itu disebut keselarasan, dan itulah seluruh tujuan DMARC — tanpanya, siapapun bisa lulus SPF di domain yang mereka miliki sambil menampilkan domain Anda di header From.

Setiap pemeriksaan mengautentikasi domain yang berbeda:

Pemeriksaan	Domain yang benar-benar dievaluasi	Tempat melihatnya
SPF	Return-Path (RFC5321.MailFrom, alamat bounce/envelope-from) — bukan header From	`smtp.mailfrom=` di Authentication-Results
DKIM	Domain di tag `d=` tanda tangan — apapun yang dipilih penandatangan	`header.d=` di Authentication-Results
DMARC	*Domain header From Anda — dan memerlukan domain SPF atau* `d=` DKIM untuk cocok**	`header.from=` di Authentication-Results

Beginilah potongan-potongan biasanya salah: platform newsletter atau CRM Anda mengirim dengan Return-Path seperti [email protected], SPF diperiksa terhadap vendor.com dan lulus, DKIM lulus dengan d=vendor.com — dan DMARC gagal, karena tidak ada domain yang lulus cocok dengan yourcompany.com. Setiap pemeriksaan mengatakan kebenaran; tidak ada yang mengautentikasi Anda. Mengedit record SPF Anda sendiri tidak dapat memperbaiki ini — ia tidak pernah dikonsultasikan. Ini adalah jebakan yang sama yang dibahas di SPF gagal untuk alat SaaS Anda.

Sensus menunjukkan betapa sedikitnya pengirim yang menyelesaikan langkah terakhir ini: 27,640,987 dari 261,086,232 domain yang dinilai (10.59%) memiliki kebijakan DMARC yang menegakkan sama sekali, dan hanya 7.4% lulus SPF dengan keselarasan di bawah satu. Di antara 77.5 juta domain yang SPF-nya berakhir dengan softfail (~all), hanya 9.2% berada di bawah kebijakan DMARC yang menegakkan; di antara penerbit hardfail (-all), 12,142,351 ditegakkan sementara 42,514,532 tidak. Sebagian besar domain berhenti di “SPF lulus” — yang tanpa DMARC yang bertindak atasnya, hampir tidak melindungi apapun.

Bagaimana cara membaca Authentication-Results untuk melihat leg mana yang tidak selaras?

Kirim pesan kepada diri sendiri melalui layanan yang gagal, buka sumber mentah, dan temukan header Authentication-Results. Hasil yang tidak selaras biasanya terlihat seperti ini:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounces.espmail.net;
       dkim=pass header.d=espmail.net;
       dmarc=fail (p=NONE) header.from=yourcompany.com

Baca dalam tiga perbandingan:

Leg SPF: apakah smtp.mailfrom= berakhir dengan domain Anda? Di sini ini bounces.espmail.net — tidak selaras.
Leg DKIM: apakah header.d= berakhir dengan domain Anda? Di sini ini espmail.net — tidak selaras.
Verdict DMARC: header.from= adalah domain yang dipertahankan DMARC. Tidak ada leg yang cocok, jadi dmarc=fail — meskipun kedua pemeriksaan individual mengatakan pass.

Leg mana pun yang sudah melibatkan domain Anda sendiri (atau dapat dibuat) adalah yang perlu diperbaiki. Anda hanya membutuhkan satu.

Apa perbedaan antara keselarasan relaxed dan strict?

DMARC menawarkan dua mode pencocokan, diatur dengan tag aspf (SPF) dan adkim (DKIM) di record DMARC Anda:

Relaxed (r, default): dua domain harus berbagi domain organisasi yang sama — domain yang dapat didaftarkan per Public Suffix List. bounce.yourcompany.com selaras dengan yourcompany.com; begitu pula DKIM d=mail.yourcompany.com. Inilah mengapa return-path kustom dan DKIM kustom vendor, yang berada di subdomain, berhasil.
Strict (s): domain harus cocok persis, karakter demi karakter. bounce.yourcompany.com tidak lagi selaras dengan yourcompany.com.

Jika record Anda tidak menyebutkan aspf atau adkim, Anda dalam mode relaxed — dan Anda hampir pasti ingin tetap di sana. Mode strict tidak menambahkan keamanan bermakna untuk sebagian besar pengirim dan secara diam-diam merusak setiap pengirim subdomain yang sah yang Anda atur. Jika DMARC gagal dan record Anda mengandung aspf=s atau adkim=s, itu sendiri bisa menjadi bug.

Bagaimana cara memperbaiki keselarasan DMARC?

Jalankan pemindaian gratis di defaults.exposed sebelum menyentuh DNS. Ini menampilkan record dan kebijakan DMARC Anda, apakah SPF dan DKIM dikonfigurasi untuk selaras, dan apa lagi yang rusak — sehingga Anda memperbaiki leg yang benar terlebih dahulu.
Uji setiap layanan pengiriman dan baca Authentication-Results-nya (seperti di atas). Daftarkan setiap sumber — provider kotak surat, alat newsletter, CRM, aplikasi faktur — dan catat per sumber apakah smtp.mailfrom dan header.d adalah domain Anda atau domain vendor.
Aktifkan penandatanganan DKIM domain kustom untuk setiap vendor — perbaikan yang bertahan. Setiap layanan pengiriman serius menawarkan “autentikasi domain”: beberapa record CNAME yang memungkinkannya menandatangani sebagai d=yourcompany.com (atau subdomain, yang selaras dalam mode relaxed). DKIM yang selaras biasanya merupakan perbaikan yang lebih mudah dan satu-satunya yang bertahan saat diteruskan, karena penerusan memutus SPF secara desain.
Untuk keselarasan SPF, aktifkan return-path kustom vendor (sering disebut bounce domain kustom) — biasanya satu CNAME seperti bounce.yourcompany.com yang menunjuk ke vendor. SPF kemudian lulus di domain organisasi Anda dan selaras. Lakukan ini di mana tersedia, tetapi perlakukan sebagai leg kedua, bukan pengganti DKIM yang selaras.
Biarkan keselarasan dalam mode relaxed kecuali Anda memiliki alasan spesifik yang dipahami untuk aspf=s/adkim=s.
Pindai ulang dan konfirmasi kedua leg, kemudian menuju penegakan. Kebijakan DMARC p=none melaporkan tetapi tidak memblokir apapun; setelah pengirim nyata Anda selaras, jalur penuh ke kebijakan yang melindungi Anda ada di halaman perbaiki DMARC, dan panduan provider seperti DMARC di IONOS mencakup klik panel DNS.

Haruskah saya memperbaiki keselarasan SPF atau DKIM?

Anda membutuhkan satu leg yang selaras per sumber pengiriman. Jika Anda hanya bisa melakukan satu, pilihannya tidak sulit:

Perbaikan	Yang diperlukan	Bertahan saat diteruskan?
DKIM selaras (penandatanganan domain kustom)	Beberapa CNAME di panel “autentikasi domain” vendor	Ya — tanda tangan berjalan bersama pesan
SPF selaras (return-path/bounce domain kustom)	Satu CNAME, di mana vendor menawarkannya	Tidak — IP forwarder menggantikan IP vendor

Kasus khusus yang perlu diketahui: Google Workspace dan Microsoft 365 akan DKIM-sign email Anda secara default dengan domain fallback mereka (gappssmtp.com, onmicrosoft.com) — sehingga DKIM menampilkan pass sementara DMARC masih gagal. Ini adalah contoh spesifik paling umum dari seluruh masalah ini, dan memiliki panduan tersendiri: DKIM lulus tetapi DMARC masih gagal: jebakan tanda tangan default.

Pertanyaan yang Sering Diajukan

Apakah SPF dan DKIM keduanya harus selaras agar DMARC lulus? Tidak — satu leg yang lulus dan selaras sudah cukup. Praktik terbaik adalah menyelaraskan keduanya, sehingga ketika penerusan memutus leg SPF, leg DKIM masih membawa DMARC lulus. Dari 261,086,232 domain yang dinilai dalam sensus 2026-06-29, hanya 3.87% yang menyelesaikan triad penuh SPF + DMARC + DKIM.

Dashboard ESP saya mengatakan SPF dan DKIM “terverifikasi” — mengapa DMARC masih gagal? “Terverifikasi” biasanya berarti pengiriman vendor sendiri lulus di domain vendor. Kecuali Anda menyelesaikan langkah domain kustom mereka (DKIM CNAME, return-path kustom), email mengautentikasi sebagai vendor, bukan sebagai Anda — dan DMARC membandingkan terhadap domain From Anda.

Apakah record SPF -all yang ketat sudah cukup tanpa keselarasan? Tidak. Qualifier yang ketat memperkuat verdict SPF di domain Return-Path, tetapi DMARC masih membutuhkan domain itu untuk menjadi milik Anda. Per sensus 2026-06-29, hanya 12,142,351 dari domain yang menerbitkan -all berada di bawah kebijakan DMARC yang menegakkan — 42,514,532 lainnya memiliki record yang ketat tetapi tidak ada kebijakan yang bertindak atasnya.

Haruskah saya beralih ke keselarasan strict (aspf=s/adkim=s) untuk keamanan lebih? Hampir tidak pernah. Keselarasan relaxed sudah memerlukan domain yang dapat didaftarkan yang sama, yang tidak dikendalikan spoofer. Mode strict kebanyakan merusak pengirim subdomain Anda sendiri — periksa kapanpun keselarasan gagal secara tidak terduga.

DMARC gagal hanya pada email yang diteruskan penerima — perbaikan yang sama? Itulah leg SPF yang mati dalam perjalanan: server forwarder tidak ada di record SPF siapapun untuk return-path Anda. Anda tidak dapat memperbaiki SPF untuk email yang diteruskan; DKIM yang selaras adalah jawabannya, karena tanda tangan bertahan saat diteruskan dengan utuh. Detail di email yang diteruskan gagal SPF.

Kirimkan laporan kepada pemilik

Jika Anda memperbaiki ini untuk klien atau perusahaan, tutup dengan bukti. Jalankan ulang pemindaian gratis setelah CNAME aktif dan teruskan laporan yang dinilai kepada pemilik bisnis: bertanggal, bahasa mudah dipahami, menunjukkan SPF, DKIM dan DMARC selaras dan lulus. Itulah artefak yang mereka butuhkan untuk perpanjangan asuransi siber dan kuesioner keamanan pemasok berikutnya — bukti konfigurasi yang berfungsi, bukan hanya “saya menambahkan beberapa record DNS”.

Periksa domain Anda → · DKIM lulus tapi DMARC masih gagal → · Perbaiki DMARC → · Cara kami menilai → · Hanya data agregat. Data disimpan dan diproses di EU.