Berhenti menebak DNS Anda: tur ramah developer tentang MX, SPF, DKIM, dan DMARC

Mengapa record DNS email penting sekarang

Autentikasi email dulu bersifat opsional. Pada 2026, ini sudah menjadi syarat dasar. Gmail dan Outlook sama-sama memberlakukan SPF dan DKIM untuk pengirim massal, dan DMARC dengan cepat menjadi wajib untuk domain apa pun yang mengirim email transaksional. Jika record DNS Anda salah, email Anda tidak sampai—tanpa bounce, tanpa peringatan, hanya senyap.

Masalahnya, record-record ini didokumentasikan seperti RFC, bukan seperti alat. Kebanyakan developer menyalin-tempel contoh dari panduan penyiapan penyedia email mereka dan berharap semuanya berjalan baik. Itu berhasil sampai Anda perlu memecahkan masalah, menambahkan layanan pengiriman kedua, atau menjelaskan kepada klien mengapa email dari formulir kontak mereka masuk ke spam.

Panduan ini membahas MX, SPF, DKIM, dan DMARC dalam urutan yang kemungkinan besar akan Anda temui, dengan detail yang cukup untuk mengonfigurasinya dengan benar dan konteks yang cukup untuk men-debug-nya saat bermasalah.

Record MX: ke mana email masuk dikirim

Record MX memberi tahu internet server mail mana yang menerima email untuk domain Anda. Ini yang paling sederhana dari keempatnya, tetapi juga yang paling mudah salah dikonfigurasi.

Sebuah record MX memiliki dua bagian: angka prioritas dan hostname. Angka prioritas yang lebih rendah dicoba terlebih dahulu. Jika Anda menggunakan Google Workspace, record MX Anda mungkin terlihat seperti ini:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

Titik di akhir itu penting—titik tersebut menandakan bahwa hostname sudah fully qualified. Sebagian besar penyedia DNS menambahkannya secara otomatis, tetapi tidak semuanya.

Kesalahan umum: mengarahkan record MX ke record A alih-alih hostname, mengatur semua prioritas ke angka yang sama (yang menggagalkan tujuan memiliki cadangan), atau lupa menghapus record MX lama saat Anda migrasi penyedia. Record MX yang usang tidak hanya diam tanpa dampak—record tersebut dapat menyebabkan mail loop atau membagi pengiriman ke dua inbox.

Jika Anda menjalankan formulir kontak sendiri dan ingin menghindari spam tanpa bergantung pada layanan pihak ketiga, memahami bagaimana formulir menjadi vektor spam adalah titik awal yang berguna.

SPF: server mana yang diizinkan mengirim sebagai Anda

SPF (Sender Policy Framework) adalah record TXT yang mencantumkan alamat IP dan domain yang diotorisasi untuk mengirim email atas nama domain Anda. Ini adalah pemeriksaan pertama yang dilakukan sebagian besar server mail saat menerima pesan yang mengaku berasal dari Anda.

Record SPF dasar terlihat seperti ini:

v=spf1 include:_spf.google.com ~all

Rinciannya:

• v=spf1 mendeklarasikan versi SPF
• include:_spf.google.com mendelegasikan ke record SPF Google
• ~all adalah soft fail—tolak email dari sumber yang tidak tercantum, tetapi jangan terlalu ketat

Anda juga dapat menggunakan ip4: atau ip6: untuk memasukkan alamat tertentu ke whitelist, atau a dan mx untuk merujuk ke record A dan MX domain Anda. Mekanisme all di akhir mengontrol apa yang terjadi pada email dari sumber yang tidak Anda cantumkan: -all adalah hard fail (tolak), ~all adalah soft fail (tandai sebagai mencurigakan), ?all adalah netral (tanpa opini), dan +all adalah bebas untuk semua (jangan gunakan ini).

SPF memiliki dua sisi tajam. Pertama, SPF rusak saat email diteruskan, karena server penerusan tidak ada di record SPF Anda. Kedua, record SPF memiliki batas lookup sepuluh kueri DNS. Jika Anda menyertakan terlalu banyak layanan pihak ketiga, Anda akan melampaui batas dan SPF akan berhenti bekerja. Perbaikannya adalah meratakan record SPF Anda—mengganti direktif include: dengan rentang IP sebenarnya—tetapi ini memerlukan pemeliharaan saat penyedia mengubah IP mereka.

DKIM: bukti kriptografis identitas pengirim

DKIM (DomainKeys Identified Mail) menambahkan tanda tangan digital ke email keluar Anda. Server penerima memeriksa tanda tangan tersebut terhadap kunci publik yang dipublikasikan di DNS Anda. Jika tanda tangan valid dan pesan belum diubah, DKIM lolos.

Tidak seperti SPF, DKIM tetap bertahan saat diteruskan, karena tanda tangan ikut berjalan bersama pesan. DKIM juga lebih fleksibel—Anda dapat memiliki beberapa kunci DKIM untuk layanan pengiriman yang berbeda, masing-masing dengan selector-nya sendiri.

Record DNS DKIM terlihat seperti ini:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Selector (default dalam contoh ini) bersifat arbitrer—penyedia email Anda yang memilihnya. Nilai p= adalah kunci publik, biasanya string panjang yang dienkode base64. Penyedia email Anda membuat kunci privat dan menggunakannya untuk menandatangani pesan keluar.

Penyiapan DKIM hampir selalu ditangani oleh penyedia email Anda. Tugas Anda adalah menyalin record TXT yang mereka berikan dan menempelkannya ke DNS Anda. Bagian yang rumit adalah beberapa penyedia DNS tidak menangani record TXT panjang dengan baik—mereka bisa memotongnya atau mengharuskan Anda membagi nilainya menjadi beberapa string bertanda kutip.

Untuk memverifikasi DKIM berfungsi, kirim email uji ke alamat Gmail dan periksa header-nya. Cari dkim=pass di header Authentication-Results.

DMARC: penegakan kebijakan dan pelaporan

DMARC (Domain-based Message Authentication, Reporting and Conformance) menyatukan SPF dan DKIM serta memberi tahu server penerima apa yang harus dilakukan saat autentikasi gagal. DMARC juga mengaktifkan pelaporan, sehingga Anda dapat melihat siapa yang mengirim email sebagai domain Anda—baik yang sah maupun yang dipalsukan.

Record DMARC minimal terlihat seperti ini:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none berarti hanya memantau—jangan menolak atau mengarantina pesan yang gagal
• rua=mailto:[email protected] menentukan ke mana laporan agregat dikirim

Setelah Anda yakin SPF dan DKIM berfungsi, Anda dapat memperketat kebijakan menjadi p=quarantine (kirim kegagalan ke spam) atau p=reject (bounce secara langsung). Anda juga dapat menetapkan kebijakan subdomain dengan sp= dan menentukan persentase pesan yang dikenai kebijakan dengan pct=.

Laporan DMARC adalah file XML yang dikirim setiap hari oleh penerima besar. Laporan ini verbose dan sulit dibaca mentah-mentah, tetapi memberi tahu Anda secara persis pesan mana yang lolos atau gagal autentikasi dan alasannya. Jika Anda melihat email sah ditolak, laporan akan menunjukkan pemeriksaan SPF atau DKIM mana yang gagal.

Satu hal yang perlu diwaspadai: DMARC membutuhkan alignment. Untuk SPF, domain di header Return-Path harus cocok dengan domain di header From (atau merupakan subdomain). Untuk DKIM, domain d= dalam tanda tangan DKIM harus cocok dengan domain From. Jika Anda menggunakan layanan pengiriman pihak ketiga, mereka perlu mendukung custom return path atau penandatanganan DKIM dengan domain Anda, bukan domain mereka.

Cara mengaudit penyiapan Anda saat ini

Sebagian besar masalah DNS tidak terlihat sampai menyebabkan masalah. Berikut cara memeriksa record Anda sebelum sesuatu rusak:

1. Kueri record MX Anda: dig MX example.com seharusnya mengembalikan hostname dan prioritas server mail Anda. Verifikasi bahwa hasilnya cocok dengan dokumentasi penyedia email Anda.

1. Periksa sintaks SPF: dig TXT example.com dan cari record v=spf1. Jalankan melalui validator SPF untuk menangkap kesalahan sintaks dan pelanggaran batas lookup.

1. Verifikasi kunci DKIM: Kirim email uji dan inspeksi header DKIM-Signature. Ekstrak selector dan domain, lalu kueri dig TXT selector._domainkey.example.com untuk mengonfirmasi bahwa kunci publik ada.

1. Validasi kebijakan DMARC: dig TXT _dmarc.example.com seharusnya mengembalikan record DMARC Anda. Pastikan rua= mengarah ke alamat yang benar-benar Anda pantau.

1. Uji end-to-end: Gunakan layanan seperti mail-tester.com atau kirim ke alamat Gmail dan periksa header lengkap. Cari spf=pass, dkim=pass, dan dmarc=pass di header Authentication-Results.

Jika Anda men-debug mengapa email tidak sampai, header adalah alat terbaik Anda. Sebagian besar klien mail memungkinkan Anda melihat header mentah—di Gmail, buka pesan, klik tiga titik, dan pilih 'Show original'. Header Authentication-Results akan memberi tahu Anda secara persis pemeriksaan mana yang gagal dan alasannya.

Kapan menggunakan kebijakan subdomain

Jika Anda mengirim email dari beberapa subdomain—misalnya, newsletter.example.com untuk marketing dan app.example.com untuk email transaksional—Anda dapat menetapkan kebijakan DMARC per subdomain. Ini memungkinkan Anda menerapkan kebijakan ketat pada subdomain yang Anda kendalikan sambil mempertahankan kebijakan yang lebih longgar pada domain utama.

Trade-off-nya adalah kompleksitas. Setiap subdomain membutuhkan record SPF, DKIM, dan DMARC sendiri, dan Anda perlu melacak layanan pengiriman mana yang diotorisasi untuk subdomain mana. Untuk sebagian besar tim kecil, satu domain yang dikonfigurasi dengan baik lebih sederhana dan sama amannya.

Apa yang harus dilakukan saat autentikasi rusak

Mode kegagalan yang paling umum adalah menambahkan layanan pengiriman baru tanpa memperbarui DNS. Jika Anda mulai menggunakan penyedia email transaksional baru, Anda perlu menambahkan include SPF atau rentang IP mereka, mengonfigurasi penandatanganan DKIM dengan domain Anda, dan memverifikasi alignment DMARC.

Masalah paling umum kedua adalah penerusan. Jika pengguna meneruskan email Anda ke alamat lain, SPF akan gagal karena server penerusan tidak ada di record SPF Anda. DKIM biasanya tetap bertahan saat diteruskan, jadi selama DKIM lolos dan kebijakan DMARC Anda mengizinkan alignment parsial, pesan seharusnya tetap terkirim. Jika Anda melihat email yang diteruskan ditolak, periksa kebijakan DMARC Anda—p=reject dengan alignment ketat akan merusak penerusan.

Masalah ketiga adalah propagasi DNS. Perubahan pada record DNS dapat memerlukan waktu berjam-jam untuk tersebar, dan server mail yang berbeda menyimpan cache record untuk durasi yang berbeda. Jika Anda baru saja memperbarui record dan belum bekerja, tunggu beberapa jam dan uji lagi. Anda dapat memeriksa propagasi dengan alat seperti whatsmydns.net.

Poin utama

• Record MX merutekan email masuk; SPF, DKIM, dan DMARC mengautentikasi email keluar. Mereka menyelesaikan masalah yang berbeda dan Anda membutuhkan keempatnya.
• SPF rusak saat penerusan dan memiliki batas sepuluh lookup. DKIM bertahan saat penerusan tetapi memerlukan konfigurasi per layanan. DMARC menyatukannya dan mengaktifkan pelaporan.
• Mulai dengan p=none di DMARC, pantau laporan selama beberapa minggu, lalu perketat menjadi p=quarantine atau p=reject setelah Anda yakin email sah sudah lolos.
• Kesalahan DNS bersifat senyap. Uji konfigurasi Anda dengan email sungguhan dan inspeksi header untuk mengonfirmasi SPF, DKIM, dan DMARC lolos.
• Jika autentikasi rusak setelah menambahkan layanan pengiriman baru, periksa include SPF, selector DKIM, dan alignment DMARC. Header akan memberi tahu Anda pemeriksaan mana yang gagal.

FAQ

Q: Bisakah saya memiliki beberapa record SPF?

A: Tidak. Beberapa record SPF akan menyebabkan semuanya diabaikan. Jika Anda perlu mengotorisasi beberapa layanan, gunakan direktif include: dalam satu record SPF, atau cantumkan rentang IP secara langsung. Perhatikan batas sepuluh lookup.

Q: Apakah saya membutuhkan DMARC jika hanya mengirim beberapa email sehari?

A: Ya. DMARC bukan soal volume—ini soal membuktikan bahwa Anda adalah pihak yang Anda klaim. Bahkan domain kecil mendapatkan manfaat dari DMARC karena mencegah spoofing dan memberi Anda visibilitas atas masalah pengiriman. Mulai dengan p=none dan alamat pelaporan.

Q: Apa yang terjadi jika DKIM dan SPF sama-sama gagal tetapi email terlihat sah?

A: Tergantung kebijakan DMARC Anda. Jika p=none, email dikirim dengan peringatan. Jika p=quarantine, email masuk ke spam. Jika p=reject, email di-bounce. Inilah alasan Anda harus memantau laporan DMARC sebelum menerapkan kebijakan ketat—Anda mungkin memiliki pengirim sah yang belum Anda ketahui.

Q: Bisakah saya menggunakan kunci DKIM yang sama untuk beberapa domain?

A: Secara teknis bisa, tetapi jangan. Setiap domain sebaiknya memiliki pasangan kunci DKIM sendiri. Berbagi kunci membuat rotasi lebih sulit dan memperbesar blast radius jika kunci privat dikompromikan.

Q: Seberapa sering saya harus merotasi kunci DKIM?

A: Tidak ada aturan universal, tetapi setahun sekali wajar untuk sebagian besar domain. Jika Anda mencurigai sebuah kunci telah dikompromikan, rotasi segera. Pastikan untuk memublikasikan kunci publik baru di DNS sebelum Anda mulai menandatangani dengan kunci privat baru, dan biarkan kunci lama tetap di DNS selama beberapa hari setelah rotasi untuk menangani email yang tertunda.

<!-- tool-cta:start -->

💡 Coba ini: Periksa kebijakan yang dipublikasikan dari domain mana pun dengan DMARC Lookup untuk melihat bagaimana catatan MX, SPF, dan DMARC saling berkaitan dalam praktik.

<!-- tool-cta:end -->

Sumber

• RFC 7208: Sender Policy Framework (SPF) — Spesifikasi SPF, termasuk aturan sintaks dan batas sepuluh lookup.
• RFC 6376: DomainKeys Identified Mail (DKIM) — Spesifikasi DKIM, mencakup pembuatan dan verifikasi tanda tangan.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — Spesifikasi DMARC, termasuk sintaks kebijakan dan format pelaporan agregat.
• Google Workspace: Prevent spoofing and spam — Panduan praktis tentang konfigurasi SPF, DKIM, dan DMARC untuk domain Google Workspace.