DNS untuk email: catatan, pengaturan, dan kemampuan pengiriman.

Beranda » Ular sanca » DNS untuk email: catatan, pengaturan, dan kemampuan pengiriman.

Email sangat bergantung pada DNS, jauh lebih daripada yang disadari kebanyakan orang.Setiap kali Anda menekan tombol Kirim, serangkaian pencarian DNS akan secara diam-diam menentukan apakah pesan Anda sampai ke kotak masuk, masuk ke spam, atau diblokir sepenuhnya. Jika DNS untuk email Anda salah konfigurasi, bahkan kampanye terbaik atau pesan transaksional terpenting pun dapat hilang begitu saja.

Jika DNS terasa misterius atau terlalu teknis, Anda tidak sendirian.Banyak profesional TI berpengalaman masih berpikir bahwa hosting situs web dan email harus berada di server yang sama, padahal DNS sebenarnya memungkinkan Anda untuk memisahkan layanan dengan cara apa pun yang Anda inginkan. Kabar baiknya: setelah Anda memahami catatan DNS inti untuk email—MX, SPF, DKIM, DMARC, dan beberapa lainnya—Anda dapat membangun pengaturan email yang solid, aman, dan memiliki tingkat pengiriman yang tinggi yang sebagian besar berjalan dengan sendirinya.

Apa itu DNS dan mengapa penting untuk email?

DNS (Domain Name System) adalah buku alamat internet.Manusia menyukai nama-nama seperti itu. perusahaananda.com, tetapi komputer berkomunikasi menggunakan alamat IP seperti 203.0.113.10 or 2001: db8 :: 1DNS mengubah domain menjadi alamat numerik sehingga browser, aplikasi, dan server email tahu ke mana harus terhubung.

Saat Anda mengetikkan domain ke dalam browser, pencarian DNS memulai perjalanan kecil.Perangkat Anda meminta penyelesai rekursif (biasanya dijalankan oleh ISP Anda atau DNS publik seperti Google atau Cloudflare), yang mungkin sudah menyimpan jawabannya dalam cache. Jika tidak, resolver akan menelusuri serangkaian server: server nama root, lalu server nama TLD (untuk .com, .net, .org, dll.), dan akhirnya server nama otoritatif untuk domain tertentu itu. Server terakhir tersebut menyimpan catatan DNS yang memberi tahu internet cara menangani lalu lintas untuk domain tersebut.

Hal yang persis sama terjadi ketika email terlibat.Server pengirim meminta informasi dari DNS untuk mengetahui tiga hal penting: ke mana harus mengirimkan email untuk suatu domain, server mana yang diizinkan untuk mengirim dari domain tersebut, dan apakah pesan tersebut asli atau palsu. Jika catatan DNS tersebut hilang, salah, atau tidak lengkap, Anda akan melihat pesan yang dipantulkan, penempatan di folder spam, atau reputasi pengirim yang rusak.

Bagaimana alur email melalui DNS

Setiap email keluar memicu setidaknya satu pencarian DNS.Ketika seseorang mengirim pesan ke user@yourcompany.comKemudian, server email pengirim bertanya kepada DNS: “Server mana yang menangani email untuk domain ini?” Server tersebut mencari catatan MX Pertama. Jika ada, catatan MX tersebut mengarah ke nama domain server email penerima. Jika catatan MX tidak ada, sebagian besar sistem akan menggunakan nama domain sebagai gantinya. Rekaman A atau AAAANamun, hal itu tidak disarankan untuk pengaturan profesional.

Keterpastian pengiriman dan keamanan membutuhkan lebih dari sekadar mengetahui ke mana harus mengirim surat.Server penerima modern juga melakukan kueri DNS untuk SPF (Kerangka Kebijakan Pengirim), ekstensi dkim (DomainKeys Identified Mail), dan secara opsional ekstensi DMARC (Otentikasi Pesan Berbasis Domain, Pelaporan & Kepatuhan). Catatan ini memberi tahu penerima apakah pesan tersebut benar-benar berasal dari sumber yang berwenang dan bagaimana menangani pesan yang mencurigakan.

Di balik layar, beberapa jenis server yang berbeda bekerja sama untuk memindahkan pesan.Surat keluar biasanya dikirim melalui Server SMTP (Simple Mail Transfer Protocol), yang bekerja dengan Mail Transfer Agent (MTA) untuk mengirim pesan melalui internet. Di sisi penerima, pengguna mengambil surat menggunakan salah satu cara berikut: POP3 (yang biasanya mengunduh dan menghapus email dari server) atau IMAP (yang menyimpan pesan di server dan melakukan sinkronisasi di seluruh perangkat). Semua komponen ini bergantung pada catatan DNS untuk mengetahui nama host dan IP mana yang harus dihubungi.

Jenis-jenis record DNS inti yang wajib Anda ketahui untuk email.

Tidak semua catatan DNS memengaruhi email secara langsung, tetapi beberapa di antaranya sangat penting. untuk perutean, otentikasi, dan penyaringan spam. Lainnya berperan sebagai pendukung dalam hal keandalan dan kepercayaan.

Catatan A dan AAAA: memetakan domain Anda ke alamat IP

Record A menghubungkan sebuah domain dengan alamat IPv4. (sebagai contoh, 93.184.216.34Tanpa setidaknya satu record A yang valid, domain Anda pada dasarnya tidak ada di internet. Banyak layanan juga bergantung padanya ketika record MX hilang atau salah konfigurasi—sesuatu yang ingin Anda hindari dengan menerbitkan record MX yang benar.

Record AAAA adalah padanan IPv6 dari record A.Ini memetakan domain ke alamat IPv6, yang semakin penting karena ruang IPv4 semakin menipis. Meskipun A dan AAAA tidak menentukan ke mana email harus dikirim, keduanya mengaitkan domain Anda dengan infrastruktur nyata dan dapat digunakan untuk perutean email cadangan jika catatan MX tidak ada.

MX records: memberi tahu dunia ke mana harus mengirimkan surat.

Catatan MX (Mail Exchange) adalah landasan DNS untuk email.Mereka menyatakan server mana yang menerima pesan masuk untuk domain Anda. Setiap catatan MX berisi sebuah prioritas (angka di mana angka yang lebih rendah lebih disukai) dan sebuah hostname (bukan IP mentah) dari server email. Server penerima mengurutkan catatan MX berdasarkan prioritas dan mencobanya secara berurutan, sehingga memberikan redundansi bawaan.

Suatu domain dapat menggunakan hanya satu record MX, tetapi penggunaan beberapa record sangat disarankan. untuk ketahanan. Banyak solusi email yang dihosting, seperti Microsoft 365 atau Google Workspace, menyediakan nilai MX utama tunggal, tetapi infrastruktur besar sering menerbitkan beberapa entri MX dengan prioritas berbeda sehingga jika satu server mati, server lain masih dapat menerima email.

Saat Anda mengkonfigurasi catatan MX, penyedia DNS Anda tidak akan menentukan nilainya secara otomatis.Penyedia layanan email Anda memberi Anda nama host, prioritas, dan persyaratan khusus yang tepat. Di panel kontrol DNS Anda, biasanya Anda mengatur: host atau nama (seringkali @ untuk domain akar), nomor prioritas, nama host server email (seperti smtp.provider.com), dan TTL (time to live), yang mengontrol caching.

Catatan TXT: wadah untuk keamanan email modern.

Catatan TXT menyimpan teks sembarang yang terlampir pada domain Anda.Sistem email sangat bergantung pada hal tersebut untuk kebijakan dan data otentikasi. SPF dan DMARC berada di dalam catatan TXT, dan DKIM seringkali juga demikian (meskipun beberapa penyedia mengekspos DKIM melalui CNAME).

Karena catatan TXT dapat menyimpan apa saja, catatan ini juga digunakan untuk pengecekan kepemilikan domain. (misalnya oleh ESP, layanan web, atau penyedia SSL), serta untuk fitur-fitur canggih seperti petunjuk enkripsi oportunistik dan indikator merek BIMI. Bagi pengirim email, tiga mekanisme berbasis TXT utama adalah SPF, DKIM, dan DMARC.

SPF: mengotorisasi server yang dapat mengirim email untuk domain Anda.

SPF adalah kerangka kerja otentikasi email yang menjawab satu pertanyaan.: “Apakah IP atau server ini diizinkan untuk mengirim email menggunakan domain ini di alamat Pengirim?” Anda mempublikasikan kebijakan Anda sebagai catatan TXT yang biasanya dimulai dengan v=spf1 dan diakhiri dengan kata keterangan seperti -semua, ~semua, atau ?semua.

Kebijakan SPF sederhana mungkin hanya mengizinkan email dari host MX domain Anda sendiri.Contohnya seperti ini: “v=spf1 mx -all”Baris tersebut memberi tahu penerima untuk menerima email dari IP yang digunakan oleh catatan MX Anda dan memperlakukan semua sumber lain sebagai tidak sah. Jika Anda juga mengirim melalui alat buletin, CRM, atau layanan cloud, Anda memperluas kebijakan tersebut dengan memasukkan pernyataan untuk setiap domain SPF penyedia.

Kebijakan SPF multi-layanan tipikal menggabungkan beberapa include menjadi satu catatan.Sebagai contoh, jika Anda mengirim email dari penyedia utama Anda ditambah platform helpdesk dan layanan email transaksional, Anda mungkin akan mendapatkan hasil seperti ini: v=spf1 a mx include:service1.com include:service2.com ~allPlatform email Anda biasanya akan menyediakan string dan sintaks yang tepat yang harus Anda tambahkan.

Penting untuk mempertahankan satu catatan SPF TXT per domain.Menumpuk beberapa catatan SPF pada nama DNS yang sama dapat merusak validasi. Sebagai gantinya, gabungkan semua mekanisme yang diperlukan ke dalam satu kebijakan yang dikelola dengan cermat, dan perbarui setiap kali Anda menambah atau menghapus layanan pengirim.

DKIM: menandatangani pesan dengan sidik jari kriptografis

DKIM (DomainKeys Identified Mail) menyediakan tanda tangan yang tidak dapat dipalsukan. Pada pesan keluar, sistem pengirim Anda menggunakan kunci kriptografi pribadi untuk membuat hash berdasarkan header tertentu dan terkadang isi pesan. Tanda tangan ini masuk ke dalam kolom header email khusus.

Kunci publik yang bersangkutan tersimpan di DNS.. Selektor DKIM (label kecil seperti surat or mlsend2) ditambah domain membentuk nama host untuk catatan kunci publik, seringkali seperti ini: selector._domainkey.yourcompany.comKetika sistem penerima menerima email, sistem tersebut melihat header DKIM, melakukan kueri DNS untuk selektor tersebut, mengambil kunci publik, dan memeriksa apakah tanda tangan valid dan konten belum diubah.

DKIM dapat dipublikasikan sebagai catatan TXT atau CNAME.Banyak penyedia layanan memberi Anda nilai TXT besar yang dimulai dengan v=DKIM1 dan panjang p= Kolom yang berisi kunci publik yang dikodekan base64. Yang lain meminta Anda untuk membuat CNAME yang mengarah dari nama host pemilih Anda ke nama host yang mereka host, yang memungkinkan mereka untuk merotasi kunci secara terpusat tanpa Anda perlu mengedit DNS setiap saat.

Setiap domain pengirim biasanya memiliki setidaknya satu pemilih DKIM.Dan layanan yang berbeda mungkin masing-masing menggunakan milik mereka sendiri. Itu tidak masalah; Anda dapat memiliki beberapa catatan DKIM selama pemilihnya berbeda. Penyedia email Anda akan menunjukkan kepada Anda persis apa yang perlu ditambahkan, dan implementasinya biasanya hanya salin-tempel ke panel DNS Anda.

DMARC: menghubungkan SPF dan DKIM dengan sebuah kebijakan.

DMARC (Domain-based Message Authentication, Reporting & Conformance) berada di atas SPF dan DKIM.Sistem ini tidak mengautentikasi pesan secara langsung; sebaliknya, sistem ini memeriksa apakah pesan tersebut lolos SPF dan/atau DKIM dan apakah hasilnya sesuai dengan domain Pengirim yang terlihat. Kemudian, sistem ini menerapkan kebijakan yang Anda tentukan untuk menentukan apa yang harus terjadi jika pemeriksaan gagal.

Kebijakan DMARC tersimpan dalam catatan TXT pada nama host khusus. _dmarc.yourcompany.comRekaman dimulai dengan v=DMARC1 dan mencakup tag seperti p= (kebijakan: tidak ada, karantina, atau tolak) dan opsi untuk melaporkan alamat. Dengan DMARC, Anda dapat menginstruksikan penerima untuk sekadar memantau (tanpa penegakan), mengirim kegagalan ke spam, atau memblokirnya sepenuhnya.

Fitur pelaporan DMARC adalah permata tersembunyi untuk keamanan dan kemampuan pengiriman email.Dengan menentukan alamat di jalan ke ruf Dengan menggunakan tag, Anda meminta penyedia penerima untuk mengirimkan laporan agregat atau forensik tentang hasil autentikasi. Laporan ini membantu Anda menemukan pengirim yang tidak sah, layanan yang salah konfigurasi, atau domain yang disalahgunakan untuk phishing.

Catatan DNS lain yang memengaruhi email

Selain MX, SPF, DKIM, dan DMARC, beberapa jenis catatan DNS lainnya memengaruhi apakah email Anda tepercaya dan berhasil terkirim.Meskipun mungkin tidak sepenuhnya wajib, informasi ini sering muncul dalam daftar periksa pengiriman email dan logika anti-spam.

PTR (DNS terbalik): memvalidasi IP pengirim

Catatan PTR melakukan kebalikan dari pencarian DNS normal.Alih-alih memetakan nama domain ke alamat IP, ia memetakan alamat IP kembali ke nama host. Pemetaan terbalik ini disebut... DNS terbalik atau rDNS.

Server penerima email secara rutin memeriksa DNS terbalik dari alamat IP pengirim.Jika tidak ada catatan PTR, atau nama host yang dikembalikan tidak sesuai dengan domain di header email, beberapa penyedia menganggap pesan tersebut mencurigakan. Hal itu dapat memicu kesalahan seperti "Reverse DNS gagal" atau menyebabkan email ditolak dengan kode yang merujuk pada PTR yang hilang.

Dalam praktiknya, Anda jarang mengelola catatan PTR di zona DNS reguler Anda.IP tersebut dikendalikan oleh siapa pun yang memiliki rentang IP tersebut—seringkali ISP, penyedia hosting, atau platform email Anda. Untuk server email khusus, Anda biasanya meminta penyedia untuk menyiapkan PTR yang mengarah ke nama host yang Anda pilih, dan kemudian memastikan bahwa nama host tersebut juga memiliki catatan A atau AAAA yang sesuai.

SRV, NS, dan SOA: infrastruktur pendukung untuk penyampaian yang konsisten.

Catatan SRV (Service) menjelaskan host dan port untuk protokol tertentu.Untuk email, mereka dapat mengarahkan klien ke server dan port SMTP, IMAP, atau POP yang benar. Meskipun mereka tidak mengontrol pengiriman secara langsung, catatan SRV membantu alat konfigurasi otomatis menemukan titik akhir yang benar.

Catatan NS (Name Server) menentukan nameserver mana yang berwenang untuk domain Anda.Server-server ini menyimpan dan menjawab dengan data DNS Anda. Jika catatan NS salah, ketidakkonsistenan antara penyedia DNS dapat menyebabkan perilaku email yang tidak dapat diprediksi, karena beberapa pengirim mungkin melihat catatan yang usang atau tidak lengkap.

Catatan SOA (Start of Authority) mengidentifikasi nameserver utama. untuk zona tersebut dan memberikan detail seperti nomor seri file zona dan nilai waktu yang digunakan untuk caching dan refresh. Ini tidak mengontrol logika email secara langsung, tetapi konfigurasi SOA yang benar sangat penting untuk replikasi dan propagasi perubahan terkait email Anda yang andal.

BIMI dan TLSA: sinyal kepercayaan dan enkripsi tingkat lanjut

BIMI (Brand Indicators for Message Identification) memungkinkan Anda menampilkan logo Anda di kotak masuk yang kompatibel.Secara teknis, ia menggunakan catatan TXT yang mengarah ke gambar SVG logo Anda dan, dalam banyak kasus, bergantung pada sertifikat merek yang terverifikasi dan kebijakan DMARC yang diterapkan. Meskipun BIMI sendiri tidak akan memperbaiki masalah pengiriman email, ini adalah sinyal kepercayaan visual dan dapat meningkatkan keterlibatan setelah otentikasi Anda sudah solid.

Catatan TLSA mendukung DANE (Autentikasi Entitas Bernama berbasis DNS)TLSA mengikat sertifikat TLS ke nama DNS melalui DNSSEC. Untuk email, TLSA dapat memperkuat koneksi STARTTLS antar server email dengan menentukan sertifikat mana yang valid. Ini membantu mencegah serangan man-in-the-middle pada SMTP, meskipun dalam praktiknya memerlukan DNSSEC dan masih kurang umum dibandingkan SPF/DKIM/DMARC.

Mengonfigurasi DNS untuk penyedia email Anda

Sebagian besar pekerjaan berat dilakukan oleh penyedia layanan email Anda., yang menyediakan entri DNS persis yang harus Anda tambahkan. Tugas Anda adalah menyalin nilai-nilai tersebut ke tipe catatan yang tepat di registrar domain atau penyedia DNS Anda dan memeriksa kembali kesalahan pengetikan.

Langkah demi langkah: menambahkan dan memverifikasi catatan MX

Untuk mengarahkan email domain Anda ke penyedia tertentu, mulailah dengan catatan MX.Setelah mendaftar untuk layanan email atau platform cloud, carilah dokumentasi mereka tentang “pengaturan DNS” atau “catatan penukar surat”. Di sana akan tercantum nama host dan prioritas yang harus Anda gunakan.

Di konsol manajemen DNS Anda, temukan opsi untuk menambahkan catatan baru. dan pilih tipe MXUntuk host atau nama, domain biasanya menggunakan @ untuk mewakili akar (misalnya, perusahaananda.com). Tempelkan nama host server email sebagai nilainya, atur prioritas yang mereka butuhkan, pertahankan TTL default kecuali jika disarankan sebaliknya, lalu simpan. Ulangi untuk setiap catatan MX tambahan yang mereka berikan.

Setelah catatan MX disimpan, akan ada periode propagasi.Cache DNS di seluruh internet membutuhkan waktu untuk menghapus data lama. Harapkan waktu mulai dari beberapa menit hingga beberapa jam—kadang-kadang hingga 24-48 jam—agar perutean email baru terlihat di mana-mana. Selama jangka waktu ini, beberapa pengirim mungkin masih mengirim ke tujuan lama.

Publikasikan SPF di DNS Anda

Setelah pengaturan routing email selesai, publikasikan SPF untuk menentukan siapa yang diizinkan mengirim email atas nama domain Anda.Layanan email utama Anda, platform pemasaran, dan semua sistem transaksional harus diwakili dalam satu catatan SPF TXT.

Sebagian besar penyedia akan menampilkan cuplikan SPF yang tepat yang Anda butuhkan.Sebagai contoh, platform pengirim mungkin mengatakan: “Tambahkan catatan TXT dengan nama @ dan nilai v=spf1 sertakan:_spf.example.com ~semuaJika Anda sudah memiliki catatan SPF, gabungkan include baru ke dalamnya daripada membuat catatan kedua dengan nama yang sama.

Memilih antara -all dan ~all memengaruhi seberapa ketat penerima memperlakukan kegagalan.. Gagal total (-semua) menyatakan bahwa sumber pengirim apa pun yang tidak tercantum secara eksplisit harus ditolak, sedangkan kegagalan lunak (~semuaBiasanya, sistem tersebut mengizinkan pesan masuk tetapi dapat menandainya sebagai spam. Banyak organisasi memulai dengan kebijakan "soft fail" (kegagalan sementara) saat mereka mengaudit semua sistem pengiriman mereka, kemudian beralih ke kebijakan yang lebih ketat seiring waktu.

Menambahkan kunci DKIM dari penyedia Anda

Pengaturan DKIM biasanya mudah setelah Anda menemukan layar yang tepat di dasbor penyedia layanan Anda.Carilah bagian yang berlabel “autentikasi domain,” “DKIM,” atau “penandatanganan email.” Anda akan melihat satu atau lebih pemilih dan nilai TXT atau target CNAME.

Jika penyedia layanan Anda memberikan catatan TXT, buat entri DNS pada nama host pemilih. (sebagai contoh, selector._domainkey.yourcompany.com) dan tempelkan string DKIM panjang yang mereka berikan. Jika mereka meminta CNAME, Anda akan mengarahkan nama host pemilih Anda ke nama host mereka, yang secara efektif memberi tahu dunia untuk mengambil kunci langsung dari DNS penyedia Anda.

Banyak layanan mengharuskan Anda untuk mengklik tombol “Verifikasi” atau “Periksa DNS”. Setelah Anda menambahkan DKIM, ini akan memicu pencarian dari pihak mereka; begitu mereka melihat kunci yang benar, mereka akan mulai menandatangani email keluar. Hingga verifikasi tersebut berhasil, pesan mungkin dikirim tanpa DKIM, sehingga melemahkan klaim otentikasi Anda.

Menerapkan kebijakan DMARC dengan aman.

Penerapan DMARC sebaiknya dilakukan secara bertahap.Mulailah dengan kebijakan tak satupun, yang meminta penerima untuk melaporkan kegagalan tetapi tidak memblokir apa pun. Ini memungkinkan Anda untuk melihat siapa yang mengirim atas nama domain Anda dan apakah SPF dan DKIM telah selaras dengan benar.

Contoh catatan DMARC dasar mungkin terlihat seperti file TXT di _dmarc.yourcompany.com dengan nilai seperti v=DMARC1; p=none; rua=mailto:reports@yourcompany.comSetelah menganalisis laporan dan memperbaiki kekurangan apa pun, Anda dapat meningkatkan kebijakan tersebut ke tingkat yang lebih tinggi. karantina (mengirim email mencurigakan ke spam) dan akhirnya ke menolak Jika Anda menginginkan perlindungan maksimal terhadap pemalsuan identitas.

Banyak klien email, terutama penyedia besar, sekarang mengharapkan domain yang mengirimkan volume email signifikan untuk mengaktifkan DMARC.Dipadukan dengan SPF dan DKIM yang dikonfigurasi dengan benar, kebijakan DMARC yang kuat adalah salah satu sinyal paling jelas bahwa domain Anda dikelola dengan baik dan bukan sumber penyalahgunaan.

Pencegahan spam berbasis DNS dan reputasi pengirim

Filter spam modern sangat bergantung pada data DNS untuk menilai apakah suatu email dapat dipercaya atau tidak.Mereka mempertimbangkan MX, SPF, DKIM, DMARC, PTR, dan bahkan konsistensi catatan A dan NS saat memutuskan apa yang harus dilakukan dengan setiap pesan.

Ketika SPF, DKIM, dan DMARC semuanya selaras dengan benar, domain Anda akan membangun reputasi positif.Seiring waktu, ISP melihat bahwa email terautentikasi dari Anda menghasilkan tingkat keluhan yang rendah dan keterlibatan yang konsisten. Sebaliknya, catatan DNS yang hilang atau rusak merupakan tanda bahaya: email mungkin masih sampai, tetapi kemungkinan besar akan masuk ke folder spam atau diblokir sepenuhnya.

DNS juga membantu melindungi penerima Anda dari phishing dan spoofing.Penyerang senang berpura-pura menjadi merek terkenal atau staf internal dengan memalsukan alamat pengirim. Dengan SPF, DKIM, dan DMARC, Anda mempersulit hal itu. Penerima dapat dengan aman membuang atau mengkarantina pesan yang berpura-pura berasal dari domain Anda tetapi gagal memenuhi kebijakan yang dipublikasikan.

Tentu saja, kemampuan pengiriman email bukan hanya tentang DNS.Kualitas konten, volume pengiriman, kebersihan daftar, tingkat keluhan, dan keterlibatan semuanya penting. Tetapi tanpa fondasi DNS yang solid, bahkan konten yang sempurna pun tidak dapat mengatasi kecurigaan yang disebabkan oleh email yang tidak terautentikasi atau salah konfigurasi.

Memecahkan masalah umum email yang disebabkan oleh DNS

Ketika pengiriman email gagal, DNS seringkali menjadi penyebabnya.Gejalanya bervariasi—mulai dari hard bounce dengan kode SMTP numerik hingga pesan yang hilang tanpa pemberitahuan ke spam—tetapi dalam banyak kasus, akar penyebabnya terletak pada catatan DNS yang hilang atau tidak valid.

Email mental atau ditolak mentah-mentah.

Pesan kesalahan "hard bounce" dengan kode seperti 550, 554, atau kesalahan yang menyebutkan domain tidak valid biasanya menunjukkan masalah konfigurasi DNS.Dua kesalahan yang sering terjadi adalah hilangnya catatan MX dan kebijakan SPF yang tidak menyertakan IP pengirim atau layanan yang sebenarnya.

Jika pesan kesalahan menyebutkan “tidak ada catatan A atau MX” atau “domain pengirim email tidak valid,” periksa zona Anda.Konfirmasikan bahwa domain pada alamat "Dari" memiliki catatan A yang berfungsi, setidaknya satu catatan MX yang mengarah ke nama host yang dapat diresolusi, dan bahwa nama host tersebut sendiri memiliki catatan A atau AAAA yang valid. Kesalahan pengetikan pada nama host dapat merusak rantai tersebut.

Penolakan yang merujuk pada kegagalan DNS terbalik atau IP yang masuk daftar hitam sering kali dapat ditelusuri kembali ke catatan PTR.Periksa apakah IP pengirim Anda memiliki PTR yang mengarah ke nama host yang Anda kendalikan, dan apakah nama host tersebut memiliki catatan A yang sesuai. Jika tidak, buka tiket dengan penyedia email atau hosting Anda dan minta mereka untuk memperbaiki DNS terbalik.

Pesan terus-menerus masuk ke folder spam

Jika pesan Anda terkirim tetapi selalu masuk ke folder spam, periksa dulu sistem otentikasi Anda.Gunakan alat daring untuk memverifikasi SPF, DKIM, dan DMARC untuk domain Anda. Kegagalan atau peringatan apa pun merupakan petunjuk bahwa sistem penerima email tidak sepenuhnya mempercayai lalu lintas Anda.

Pastikan domain pada alamat "Dari" yang terlihat sesuai dengan SPF dan DKIM Anda.Untuk SPF, domain pengirim amplop (Return-Path) harus diotorisasi. Untuk DKIM, nilai d= di header DKIM harus berupa domain yang Anda miliki dan, idealnya, cocok atau selaras dengan domain From. DMARC kemudian mengevaluasi keselarasan tersebut saat memutuskan cara memberi skor pada pesan.

Perilaku pengguna juga menjadi masukan bagi algoritma spam.Jika banyak penerima menghapus pesan tanpa membacanya, tidak pernah membukanya, atau menandainya sebagai spam, reputasi Anda akan menurun, tidak peduli seberapa sempurna DNS Anda. Menggabungkan otentikasi DNS yang kuat dengan praktik pengiriman yang baik adalah formula kemenangan.

Formulir web atau aplikasi yang mengirim email yang tidak pernah sampai

Ketika formulir kontak situs web atau aplikasi tampak "mengirim" email tetapi tidak ada yang sampai, SPF sering kali salah konfigurasi.Alamat IP server web atau pengirim email platform mungkin tidak termasuk dalam catatan SPF Anda, sehingga penerima menganggap pesan tersebut mencurigakan atau langsung menolaknya.

Jika situs Anda mengirim email menggunakan domain penyedia kotak surat utama AndaPastikan server pengirim sebenarnya (misalnya, penyedia hosting web Anda atau ESP transaksional) muncul dalam kebijakan SPF. Dalam beberapa kasus, lebih baik menggunakan subdomain khusus dan ESP yang dikonfigurasi daripada mengandalkan fungsi email default dari penyedia hosting web.

Mengatasi penundaan propagasi DNS

Setiap kali Anda mengubah catatan MX, SPF, DKIM, atau DMARC, beri waktu internet untuk menyesuaikan diri.DNS bekerja dengan menggunakan caching: resolver mengingat jawaban selama jangka waktu TTL, yang bisa berupa menit atau jam. Selama periode ini, beberapa pengirim melihat konfigurasi baru sementara yang lain masih menggunakan konfigurasi lama.

Jika Anda berencana melakukan migrasi email besar-besaran, turunkan TTL satu atau dua hari sebelumnya.Mengurangi TTL menjadi sekitar 300 detik pada record-record penting akan mempercepat penyebaran perubahan di masa mendatang. Setelah transisi stabil, Anda dapat menaikkan TTL kembali untuk meningkatkan performa dan mengurangi jumlah query.

Pengujian dari berbagai jaringan dan penggunaan alat pencarian DNS eksternal membantu memastikan kapan propagasi benar-benar selesai.Jangan hanya mengandalkan resolver lokal Anda, yang mungkin melakukan caching secara agresif atau dikonfigurasi dengan cara yang tidak biasa.

Secara keseluruhan, DNS untuk email bukan tentang keajaiban, melainkan tentang catatan yang dikoordinasikan dengan cermat.Ketika MX, SPF, DKIM, DMARC, PTR, dan entri pendukungnya akurat dan konsisten, domain Anda menjadi pengirim yang tepercaya di mata penyedia email. Kepercayaan tersebut, dipadukan dengan daftar yang bersih dan konten yang dipikirkan dengan matang, adalah kunci agar pesan Anda tetap berada di kotak masuk dan merek Anda terhindar dari folder spam.