EmailDNSDeliverability

Email DNS: MX, SPF, DKIM, DMARC

Ditulis oleh Harry Osmar Sitohang·Jun 2026·8 mnt

Kami ingin dua hal dari [email protected]: email yang tetap mengalir setelah pindah DNS, dan bisa membaca serta mengirimnya dari Gmail biasa. Mailbox-nya sendiri Hostinger Email; record DNS yang membuat email berfungsi kini ada di Cloudflare (awan abu-abu, dibawa serta saat kami memindahkan domain). Begini cara record itu sebenarnya bekerja — dalam bahasa sederhana.

Dua arah: ingress vs egress

Cara paling jelas untuk memahami record DNS email adalah memilahnya berdasarkan arah perjalanannya — mail yang masuk ke Anda (ingress) versus mail yang keluar dari Anda (egress). Tiap arah diatur oleh record yang berbeda, dan — ini bagian yang sering bikin orang kaget — sebagian justru dicek di server orang lain, bukan server Anda.

Empat aktor, dua arah. INGRESS: [email protected] → Cloudflare (MX) → mail.hostinger.com. EGRESS: sales@ menandatangani dengan kunci privat; [email protected] menjalankan SPF (server pengirim diizinkan?) DAN DKIM (cek tanda tangan via kunci publik?) ke Cloudflare DNS — keduanya bermuara ke DMARC, yang mengantar saat ada yang lolos selaras atau menerapkan kebijakan (p=none memantau) saat keduanya gagal.

Ingress — mail masuk (→ `sales@`), diatur MX

MX singkatan dari Mail eXchange, dan ia menjawab satu pertanyaan: "ke mana mail yang dialamatkan ke @pangaea.id harus diantar?"

Ikuti dari sudut pandang pengirim: ada yang mengirim email ke [email protected] → server mail mereka melakukan lookup MX di DNS → DNS menjawab mx1.hostinger.com (prioritas 5) dan mx2.hostinger.com (prioritas 10) → pengirim menyambung lewat SMTP dan mengantar pesan ke Hostinger, tempat mailbox berada. (Angka prioritas lebih kecil = dicoba lebih dulu; mx2 itu cadangan.)

Egress — mail keluar (dari `@pangaea.id` →), diatur SPF + DKIM + DMARC

Inilah inti idenya: Anda menerbitkan ketiga record ini, tapi yang mengeceknya justru server penerima (Gmail, Outlook…) begitu pesan Anda mendarat di sisi mereka. Jadi ketiganya identitas keluar Anda, yang diverifikasi di ujung penerima.

SPF — Sender Policy Framework. Allow-list yang diterbitkan, berisi server yang boleh mengirim mail "sebagai" domain Anda. Penerima bertanya: apakah ini datang dari server yang diizinkan pangaea.id?
```
v=spf1 include:_spf.mail.hostinger.com ~all
```
(~all itu softfail: apa pun yang bukan dari Hostinger dianggap mencurigakan, bukan ditolak keras.)
DKIM — DomainKeys Identified Mail. Hostinger menandatangani tiap pesan keluar secara kriptografis dengan kunci privat rahasia; Anda menerbitkan kunci publik yang cocok di DNS supaya penerima bisa memverifikasi tanda tangannya. Ini membuktikan mail (a) benar-benar datang dari domain Anda dan (b) tak diubah di perjalanan. Diterbitkan sebagai "selector" CNAME — mis. hostingermail-a._domainkey → hostingermail-a.dkim.mail.hostinger.com (selector -a membawa kunci live; -b, -c cadangan).
DMARC — Domain-based Message Authentication, Reporting & Conformance. Ia mengikat SPF + DKIM, memberi tahu penerima apa yang harus dilakukan saat sebuah pesan gagal (p=none = pantau, p=quarantine = spam, p=reject = tolak), dan mengirimi Anda laporan (rua=). Ia juga menegakkan alignment: domain From: yang terlihat harus cocok dengan yang diverifikasi SPF/DKIM.
```
v=DMARC1; p=none; rua=mailto:[email protected]
```
(Saat ini pantau-saja — mulai lembut, awasi laporannya, perketat ke quarantine/reject nanti.)

MX itu alamat dok bongkar-muat; SPF, DKIM, dan DMARC itu segel lilin, kop surat, dan kebijakan pengembalian yang membuktikan mail keluar Anda memang dari Anda — dan semuanya dicek di ujung penerima.

— model mental satu baris

Record sekilas — dan siapa yang mengecek masing-masing

Kolom yang paling sering terlewat justru yang terakhir:

MX — Mail eXchange · ingress · ke mana mail diantar ke Anda · dibaca server pengirim
SPF — Sender Policy Framework · egress · server mana yang boleh mengirim sebagai Anda · server penerima
DKIM — DomainKeys Identified Mail · egress · tanda tangan anti-utak-atik di tiap mail · server penerima
DMARC — …Authentication, Reporting & Conformance · egress · apa yang harus dilakukan kalau SPF/DKIM gagal (+ laporan) · server penerima

Baca & kirim `sales@` dari Gmail biasa Anda

Terima — entah pasang forwarding (Hostinger → Gmail Anda), atau tarik masuk: Gmail → Settings → Accounts and Import → Check mail from other accounts → POP pop.hostinger.com, port 995, SSL.

Kirim sebagai — Gmail → Accounts and Import → Send mail as → SMTP smtp.hostinger.com, port 465 (SSL), username [email protected], password mailbox-nya. Konfirmasi lewat kode yang dikirim Google. Kini Anda bisa mengirim sebagai [email protected] dari inbox yang biasa Anda pakai.

Membawa record-nya saat DNS pindah ke Cloudflare

Kesalahan migrasi nomor 1

Menambahkan DKIM sebagai record TXT. DKIM Hostinger Email itu CNAME — salah tipe dan mail Anda mulai ditandai. Salin selector dan target persis dari panel Hostinger.

Kami melakukan persis ini saat domain pindah ke Cloudflare — cerita hari migrasinya (dan record CAA yang nyaris merusak gembok berminggu-minggu kemudian) ada di Pindah DNS tanpa kehilangan email →.

Pertanyaan umum

Saat seseorang mengirim email ke [email protected], bagaimana ia sampai ke mailbox kami?

Itu ingress — mail masuk — yang diatur record MX. MX singkatan dari Mail eXchange, dan ia menjawab tepat satu pertanyaan: "ke mana mail untuk @pangaea.id harus diantar?" Server mail pengirim mencari MX kami di DNS, mendapat mx1.hostinger.com (prioritas 5) dan mx2.hostinger.com (prioritas 10), lalu mengantar pesan ke Hostinger, tempat mailbox sebenarnya berada. Angka prioritas lebih kecil dicoba lebih dulu, jadi mx2 cuma cadangan.

Siapa yang membaca record MX — kami atau pengirim?

Server pengirim. Ini yang sering mengejutkan: MX itu catatan publik yang Anda terbitkan, tapi server mail orang lain-lah yang membacanya untuk tahu ke mana mengirim mail yang dialamatkan ke Anda.

Apa itu SPF, DKIM, dan DMARC, dan kenapa perlu tiga-tiganya?

Ketiganya record egress (keluar) — bersama-sama mereka membuktikan bahwa mail yang mengaku dari @pangaea.id memang benar dari Anda. SMTP polos (protokol mail) tak punya cara bawaan untuk membuktikan pengirim, jadi ketiganya menambal itu:

SPF (Sender Policy Framework) adalah allow-list yang diterbitkan, berisi server yang boleh mengirim "sebagai" domain Anda. Punya kami v=spf1 include:_spf.mail.hostinger.com ~all — ~all berarti "anggap apa pun yang bukan dari Hostinger sebagai mencurigakan."
DKIM (DomainKeys Identified Mail) adalah tanda tangan kriptografis di tiap pesan: Hostinger menandatangani dengan kunci privat, dan kunci publik yang cocok di DNS memungkinkan penerima memverifikasi bahwa mail benar-benar dari Anda dan tak diubah.
DMARC (Domain-based Message Authentication, Reporting & Conformance) mengikat SPF dan DKIM, memberi tahu penerima apa yang harus dilakukan saat gagal, dan mengirimi Anda laporan. Punya kami v=DMARC1; p=none; rua=mailto:[email protected] — p=none untuk sekarang pantau-saja, dan rua= tempat laporan dikirim.

Siapa yang mengecek SPF, DKIM, dan DMARC?

Server penerima — Gmail, Outlook, dan seterusnya — tepat saat pesan Anda mendarat di sisi mereka. Jadi ketiganya adalah identitas keluar Anda, tapi diverifikasi di ujung sana. Itu kebalikan dari MX (dibaca pengirim): ingress dicek pengirim, egress dicek penerima.

Kenapa DMARC disetel p=none alih-alih menolak mail buruk?

p=none itu "pantau saja" — ia meminta penerima melaporkan kegagalan tapi belum memblokir apa pun. Ini sikap awal yang aman: Anda mengamati laporan rua= untuk memastikan semua mail sah Anda lolos SPF/DKIM dulu, baru nanti memperketat ke p=quarantine (kirim kegagalan ke spam) atau p=reject (tolak). Memperketat terlalu dini berisiko memantulkan email asli Anda sendiri.

Posisinya di mana

Catatan diary berbahasa sederhananya ada di Email yang membuktikan dirinya →. Untuk sisa jalur go-live, mulai dari Arahkan domain ke Cloudflare.

Sources