Microsoft 365 / Catatan DNS email: memeriksa MX, SPF, DKIM, dan DMARC

Untuk email Microsoft 365, catatan DNS (Domain Name System) mengarahkan email masuk dan mendukung otentikasi email keluar. Catatan mail-exchanger (MX) mengidentifikasi server penerima; Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), dan Domain-based Message Authentication, Reporting, and Conformance (DMARC) menyediakan berbagai pemeriksaan otentikasi dan informasi kebijakan. Verifikasi kepemilikan domain dan inventaris layanan pengiriman Microsoft 365 maupun eksternal sebelum mengubah catatan ini.

Peran dari keempat catatan

Panduan penerapan autentikasi email Microsoft menjelaskan konfigurasi SPF, DKIM, dan DMARC untuk domain kustom. Keberhasilan SPF atau DKIM saja belum tentu cukup untuk DMARC; domain yang diautentikasi juga harus selaras dengan domain pengirim yang ditampilkan.

SPF menyatakan sumber pengirim mana yang diizinkan. Dengan DKIM, pengirim menggunakan kunci pribadi untuk menandatangani bagian dari pesan, dan penerima menggunakan kunci publik yang diterbitkan melalui DNS untuk memverifikasi tanda tangan. DMARC memeriksa kesesuaian dengan domain From yang terlihat dan menerbitkan kebijakan kegagalan yang diminta serta tujuan pelaporan. Kemampuan autentikasi ini termasuk dalam perlindungan bawaan untuk kotak surat cloud; fitur Defender lainnya bisa memiliki persyaratan lisensi tambahan.

SPF memeriksa domain yang digunakan dalam MAIL FROM, alamat pengirim amplop yang digunakan antar server email. Ini bisa berbeda dari alamat From yang ditampilkan kepada pembaca. Domain penandatangan DKIM juga bisa milik penyedia layanan. Oleh karena itu, layanan manajemen hubungan pelanggan (CRM) mungkin melewati SPF dan DKIM dengan domain penyedianya tetapi tetap gagal DMARC untuk domain perusahaan yang ditampilkan di From. Persyaratan kunci adalah bahwa setidaknya satu hasil SPF yang selaras atau DKIM yang selaras berhasil.

Penyelarasan bisa longgar (domain organisasi yang sama, memungkinkan subdomain) atau ketat (cocok nama domain secara tepat). Tag opsional aspf dan adkim mengontrol penyelarasan SPF dan DKIM secara terpisah; keduanya default ke longgar (r). Periksa mode ini ketika layanan pengiriman menggunakan subdomain.

Selidiki jalur pengiriman sebelum konfigurasi

• Email yang dikirim oleh karyawan dari Exchange Online
• Email yang dikirim oleh sistem eksternal seperti formulir pertanyaan di website, CRM, layanan pemasaran, dan perangkat multifungsi
• Layanan pengiriman yang menggunakan subdomain secara terpisah
• Jalur melalui gateway keamanan email atau server relay

Jika sumber pengiriman dihilangkan, email yang sah mungkin ditolak setelah memperkuat SPF, DKIM, dan DMARC. Hapus sumber pengiriman yang tidak digunakan, dan autentikasi layanan yang diperlukan sesuai panduan resmi dari penyedia masing-masing.

Urutan verifikasi di Microsoft 365

1. Di pusat admin Microsoft 365, buka domain target di [Pengaturan] → [Domain] dan periksa status konfigurasi DNS. Gunakan nilai MX yang ditampilkan di wizard domain untuk domain tersebut.

2. Periksa catatan SPF TXT saat ini dengan penyedia hosting DNS Anda. Jika sumber pengiriman di luar Microsoft 365 perlu disertakan, integrasikan mereka ke nilai yang sudah ada.
3. Di pengaturan autentikasi email di portal Microsoft Defender, periksa status DKIM dari domain kustom dan catatan DNS yang diperlukan. Setelah menambahkan nilai yang disarankan ke DNS, verifikasi bahwa penandatanganan telah diaktifkan.

4. Perkenalkan DMARC secara bertahap. Analisis pengirim sebenarnya dan kegagalan autentikasi melalui laporan, lalu tentukan penguatan kebijakan. Jika Anda hanya menambahkan pernyataan kebijakan tanpa membaca laporan, akan sulit mendeteksi masalah.
5. Kirim email uji coba ke alamat eksternal di luar organisasi dan periksa hasil SPF, DKIM, dan DMARC serta kesesuaiannya di header penerima. Meskipun status DNS normal, Anda perlu menguji jalur pengiriman yang sebenarnya.

Kondisi di mana contoh SPF dapat digunakan sebagaimana adanya

Untuk domain kustom yang DNS publiknya Anda kelola, nilai TXT berikut adalah contoh dasar ketika Microsoft 365 adalah satu-satunya layanan pengirim. Contoh ini berlaku untuk layanan komersial Microsoft secara global; layanan khusus pemerintah atau yang dioperasikan di Tiongkok dapat memerlukan domain include yang berbeda. Gunakan nilai spesifik layanan di pusat admin dan dokumentasi Anda. Jika sebuah situs web atau layanan pemasaran juga mengirim secara langsung menggunakan domain yang sama, jangan mengganti kebijakan Anda saat ini hanya dengan contoh ini. Bandingkan panduan wizard domain dan panduan konfigurasi resmi setiap pengirim.

v=spf1 include:spf.protection.outlook.com -all

include merujuk pada lingkup pengiriman Microsoft 365 dan -all menyatakan sumber pengiriman yang tidak diizinkan oleh mekanisme SPF harus diperlakukan sebagai kegagalan SPF. Membuat dua catatan SPF TXT dengan nama yang sama untuk memasukkan Microsoft 365 dan layanan eksternal secara terpisah adalah konfigurasi yang tidak benar. Gabungkan sumber pengiriman yang diperlukan dalam satu kebijakan SPF dan hapus pengirim yang tidak diperlukan. Catatan TXT untuk verifikasi kepemilikan selain SPF memiliki tujuan yang berbeda dan tidak perlu dihapus. Pilih berdasarkan skenario pengiriman dalam Panduan pengaturan SPF Microsoft.

Saat menggabungkan layanan, juga periksa batas 10 pencarian DNS SPF selama evaluasi. Mekanisme include bertingkat juga dihitung: memiliki kurang dari 10 penyedia atau entri include tidak menjamin bahwa evaluasi tetap dalam batas.

Nilai yang dipilih saat mengatur DKIM dan DMARC

Di portal Defender dengan label antarmuka bahasa Inggris, buka domain kustom melalui Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM. Buat kunci jika diperlukan, kemudian masukkan nama dan target dari dua catatan CNAME (canonical name) yang ditampilkan di detail domain pada penyedia DNS Anda. Catatan CNAME menunjuk satu nama DNS ke nama lainnya; dalam pengaturan ini, catatan tersebut menghubungkan pencarian DKIM ke catatan kunci Microsoft. Salin nama selector dan target yang diberikan untuk tenant Anda alih-alih membuatnya dari blog lama. Microsoft memperkenalkan format target baru untuk domain kustom baru pada Mei 2025, sementara domain yang sudah ada dapat mempertahankan format lama.

Setelah propagasi DNS, aktifkan tombol penandatanganan DKIM untuk domain dan periksa statusnya. Jika CNAME belum terdeteksi, periksa nama yang dimasukkan, penyedia DNS yang benar-benar mengelola domain, dan waktu deteksi. Dua catatan yang sudah disimpan tidak berarti penandatanganan sudah aktif. Ikuti prosedur konfigurasi DKIM Microsoft sesuai status domain saat ini.

Kebijakan DMARC awal dapat diatur sebagai konfigurasi berfokus pada laporan yang dapat menganalisis pengirim yang sah. Berikut adalah contoh menggunakan example.com sebagai domain contoh. Publikasikan catatan TXT di _dmarc untuk domain Anda sendiri, dan ganti dmarc@example.com pada nilai rua=mailto: dengan kotak surat laporan nyata yang dikendalikan oleh organisasi Anda. Alamat sampel tersebut bukan tujuan untuk digunakan tanpa perubahan.

v=DMARC1; p=none; rua=mailto:dmarc@example.com

p=none adalah kebijakan awal yang tidak meminta karantina atau penolakan untuk kegagalan DMARC itu sendiri, dan tidak menonaktifkan filter spam atau keamanan lainnya. Parameter rua menentukan tujuan penerimaan laporan agregat. Anda harus siap untuk benar-benar menerima dan menganalisis di alamat itu, dan jika menggunakan alamat layanan pelaporan eksternal, Anda juga harus memeriksa kondisi persetujuan DNS tambahan. Setelah memverifikasi keselarasan pengirim yang sah dan jalur pengiriman, Anda memperkuat kebijakan ke langkah quarantine dan reject. Kondisi rinci mengikuti panduan implementasi DMARC.

Verifikasi catatan DNS dan autentikasi pada email yang baru dikirim

Kirim email baru ke alamat uji untuk setiap jalur pengiriman, seperti email karyawan, formulir pertanyaan web, CRM, dll. Di sisi penerima, buka pesan asli dan header internet untuk memeriksa hasil SPF, DKIM, dan DMARC di Authentication-Results sistem penerima, dan juga bandingkan domain penandatangan DKIM dengan From yang ditampilkan. Anda memerlukan hasil pesan yang baru dikirim setelah perubahan, bukan "email lama normal."

Jika DNS normal tetapi CRM tertentu gagal, periksa domain pengirim dan pengaturan penandatangan untuk jalur tersebut terlebih dahulu. Jika badan yang ditandatangani berubah atau server pengirim berbeda selama proses pengiriman, hasilnya bisa bervariasi. Lulus autentikasi tidak menjamin email masuk ke inbox, dan reputasi, spam, serta kebijakan konten juga berpengaruh.

Nilai rekaman bervariasi tergantung pada domain dan waktu konfigurasi. Tujuan dari artikel ini bukan untuk menghafal nilai-nilai tersebut, tetapi untuk membandingkan nilai yang diberikan oleh pusat manajemen , nilai aktual di DNS, dan hasil autentikasi di sisi penerima . Jika ada masalah dalam menerima atau mengirim email, identifikasi ruang lingkup dampak berdasarkan rekaman DNS sebelum perubahan. Jika email yang sah terdampak, bandingkan kebijakan sebelumnya dan konfigurasi pengirim untuk mengembalikan hanya perubahan yang bermasalah dan uji kembali. Jangan menghapus semua rekaman SPF, DKIM, dan DMARC atau mempertahankan kebijakan DMARC yang ketat tanpa mengetahui penyebabnya. Dalam laporan, bedakan antara kegagalan pengirim yang sah dan pengiriman palsu yang mencurigakan, serta tentukan tindakan lanjutan sesuai.