Audit SPF, DKIM, dan DMARC membantu bisnis memeriksa apakah email dari domain perusahaan dapat diautentikasi serta bagaimana server penerima menangani pesan yang gagal. Pemeriksaan ini terutama berguna ketika bisnis memakai beberapa sumber pengiriman, seperti layanan email utama, aplikasi pemasaran, sistem transaksi, atau penyedia pihak ketiga.

Artikel ini menyediakan audit tingkat konfigurasi dan verifikasi berdasarkan dokumentasi Google Workspace dan Microsoft 365 yang tersedia pada 1 Oktober 2026. Karena petunjuk setiap penyedia berbeda, gunakan langkah di bawah sebagai kerangka pemeriksaan, lalu cocokkan perubahan DNS dengan dokumentasi penyedia email dan host domain Anda.

Hasil yang perlu dicapai dari audit

Audit tidak cukup hanya menemukan tiga catatan DNS. Hasil akhirnya seharusnya menunjukkan apakah sumber pengiriman yang sah tercakup, pesan benar-benar ditandatangani, domainnya selaras, dan kebijakan DMARC tidak memblokir email bisnis yang valid.

Secara ringkas, target audit adalah:

• mendata semua domain, subdomain, dan layanan yang mengirim email atas nama bisnis;
• memastikan sumber resmi tercakup dalam konfigurasi SPF;
• memastikan pesan keluar ditandatangani DKIM dan tanda tangannya dapat diverifikasi;
• memeriksa penyelarasan domain SPF atau DKIM dengan alamat pengirim yang terlihat oleh penerima;
• menilai kebijakan dan laporan DMARC sebelum memperketat penanganan pesan gagal;
• mencatat konfigurasi yang belum dapat dibuktikan atau masih bergantung pada pihak ketiga.

Cakupan ini tidak menggantikan audit keamanan email secara menyeluruh. Pemeriksaan difokuskan pada autentikasi berbasis domain, bukan konfigurasi akun pengguna, pemulihan data, atau seluruh mekanisme penyaringan pesan masuk.

Cara SPF, DKIM, dan DMARC saling melengkapi

SPF memeriksa apakah pesan berasal dari sumber yang diizinkan untuk domain pada alamat MAIL FROM atau envelope sender. DKIM memakai tanda tangan kriptografis: server pengirim menandatangani pesan dengan kunci privat, sedangkan server penerima membaca kunci publik yang dipublikasikan melalui DNS.

DMARC kemudian memakai hasil SPF dan DKIM sekaligus memeriksa penyelarasan domain dengan alamat From yang ditampilkan kepada penerima. Menurut dokumentasi Microsoft mengenai DMARC, pesan melewati DMARC apabila setidaknya salah satu pemeriksaan berikut berhasil:

• SPF lulus dan domain MAIL FROM selaras dengan domain pada alamat From; atau
• DKIM lulus dan domain penandatangan pada nilai d= selaras dengan domain pada alamat From.

Karena itu, status SPF atau DKIM “pass” belum cukup untuk menyimpulkan bahwa DMARC juga lulus. Auditor tetap harus memeriksa domain yang digunakan dan penyelarasannya.

Prasyarat sebelum mengubah DNS

Mulailah dengan inventaris sumber email. Ini merupakan usulan pencatatan praktis, bukan bukti bahwa sebuah domain telah patuh atau aman.

Komponen yang dicatat	Pertanyaan pemeriksaan
Domain dan subdomain	Domain mana yang muncul pada alamat From dan MAIL FROM?
Layanan pengirim	Apakah pesan dikirim melalui Google Workspace, Microsoft 365, aplikasi transaksi, atau layanan pemasaran?
Penanggung jawab	Siapa yang dapat mengakses konfigurasi layanan email dan DNS?
SPF	Apakah layanan tersebut sudah dicakup sebagai sumber resmi?
DKIM	Selector dan domain penandatangan apa yang digunakan?
DMARC	Apa kebijakan aktifnya dan ke mana laporan agregat dikirim?
Bukti verifikasi	Apakah tersedia header pesan terbaru dari pengiriman nyata?

Inventaris perlu mencakup subdomain yang dipakai layanan pihak ketiga. Microsoft menyarankan penggunaan subdomain untuk layanan email yang tidak berada di bawah kendali langsung organisasi, misalnya layanan pengiriman massal, agar masalah layanan tersebut tidak langsung memengaruhi domain email utama.

Pemisahan ini harus direncanakan sebelum memindahkan aliran email. Pembahasan konteksnya tersedia dalam panduan isolasi domain email operasional dan aktivitas marketing.

Audit SPF, DKIM, dan DMARC secara berurutan

1. Periksa cakupan SPF

Cocokkan daftar layanan pengirim dengan domain dan subdomain yang digunakan. Untuk domain kustom di Microsoft 365, dokumentasi Microsoft meminta SPF dikonfigurasi pada semua domain dan subdomain kustom yang digunakan untuk mengirim email.

Fokus audit SPF adalah menemukan dua jenis masalah: sumber resmi yang belum tercakup dan sumber lama yang masih tercatat meskipun tidak lagi digunakan. Paket riset ini tidak menyediakan sintaks audit SPF lintas platform, sehingga perubahan record perlu mengikuti dokumentasi penyedia masing-masing dan tidak dapat disimpulkan hanya dari contoh Microsoft 365.

Catat status setiap sumber sebagai:

• terverifikasi: layanan aktif dan ketercakupannya dapat dibuktikan melalui konfigurasi serta hasil autentikasi;
• perlu diperiksa: layanan dikenal, tetapi hubungan dengan record DNS belum jelas;
• tidak dikenal: muncul dalam data atau laporan, tetapi pemilik dan tujuan pengirimannya belum diketahui;
• tidak digunakan: layanan sudah dihentikan dan perlu ditinjau sebelum konfigurasi terkait diubah.

Jangan memperketat DMARC sebelum sumber pengiriman yang sah dipetakan. Microsoft memperingatkan bahwa kegagalan yang tidak disengaja dapat menyebabkan sistem tujuan menolak email yang sebenarnya valid.

2. Pastikan DKIM benar-benar menandatangani pesan

DKIM membutuhkan pasangan kunci. Kunci publik disimpan dalam record TXT DNS, sedangkan kunci privat berada pada server email untuk membuat tanda tangan pada pesan keluar.

Untuk Google Workspace, panduan resmi penyiapan DKIM Google menetapkan alur berikut:

1. buat pasangan kunci DKIM di konsol administrator;
2. tambahkan kunci publik sebagai record TXT pada penyedia DNS;
3. aktifkan autentikasi DKIM di konsol;
4. kirim pesan ke pengguna Gmail atau Google Workspace lain;
5. buka header lengkap dan periksa bagian Authentication-Results;
6. pastikan hasil DKIM menunjukkan DKIM=pass atau DKIM=OK.

Google menyatakan pengujian tidak dilakukan dengan mengirim pesan kepada diri sendiri. Jika header tidak memiliki hasil DKIM, pesan dari domain tersebut belum ditandatangani dengan DKIM atau konfigurasinya belum berfungsi sebagaimana diharapkan.

Khusus Google Workspace, pilih kunci 2048 bit jika penyedia domain mendukungnya. Opsi 1024 bit disediakan ketika host domain tidak mendukung kunci 2048 bit. Google juga menyebut bahwa setelah Gmail diaktifkan untuk organisasi, administrator mungkin perlu menunggu 24–72 jam sebelum kunci DKIM dapat dibuat di konsol, sedangkan autentikasi dapat memerlukan waktu hingga 48 jam setelah kunci ditambahkan.

Periksa pula gateway keluar yang memodifikasi pesan, misalnya dengan menambahkan footer. Dokumentasi Google menyebut perubahan oleh gateway keluar dapat mengganggu DKIM, sehingga pengujian harus memakai jalur pengiriman yang benar-benar digunakan bisnis.

3. Audit penyelarasan domain

Ambil header pesan dari setiap sumber pengiriman yang telah didata. Jangan menganggap seluruh layanan memakai domain penandatangan yang sama.

Untuk setiap pesan, bandingkan:

• domain pada alamat From yang terlihat oleh penerima;
• domain pada MAIL FROM yang diperiksa SPF;
• domain pada nilai d= dalam tanda tangan DKIM;
• hasil SPF, DKIM, dan DMARC pada Authentication-Results.

Jika SPF lulus tetapi domain MAIL FROM tidak selaras dengan From, jalur SPF tersebut tidak memenuhi pemeriksaan DMARC. Hal yang sama berlaku ketika DKIM lulus tetapi domain penandatangannya tidak selaras dengan From.

4. Tinjau record dan kebijakan DMARC

DMARC diaktifkan melalui record TXT pada host _dmarc. Kebijakannya memberi instruksi kepada sistem penerima mengenai pesan yang gagal autentikasi dan penyelarasan.

Kebijakan	Arti menurut dokumentasi Microsoft	Kegunaan dalam audit
p=none	Tidak menyarankan tindakan tertentu terhadap pesan gagal.	Dipakai untuk pengujian dan penyetelan sambil memantau hasil.
p=quarantine	Pesan diterima tetapi ditandai; penanganan akhirnya bergantung pada sistem tujuan.	Tahap pengetatan setelah sumber sah diperiksa.
p=reject	Pesan diminta untuk ditolak; penerapan aktual bergantung pada sistem tujuan.	Tujuan akhir yang disarankan Microsoft setelah pengujian dan verifikasi.

Microsoft menyarankan peluncuran bertahap: mulai dengan p=none, pantau hasil, lanjutkan ke p=quarantine, kemudian menuju p=reject setelah kegagalan yang tidak disengaja ditangani. Dokumentasi yang tersedia tidak menetapkan satu durasi pemantauan yang berlaku untuk semua organisasi, sehingga jangan mengarang batas waktu tetap.

Parameter pct dapat menentukan persentase pesan gagal yang dikenai kebijakan. Jika parameter tersebut tidak ditulis, nilai default menurut dokumentasi Microsoft adalah 100. Nilai di bawah 100 dapat dipakai untuk pengujian bertahap, tetapi bukan pengganti pemeriksaan sumber pengiriman.

5. Periksa laporan DMARC

Nilai rua menentukan tujuan laporan agregat. Menurut Microsoft, laporan ini biasanya dikirim sekali sehari dan dapat memuat alamat IP layanan pengirim, hasil autentikasi, serta tindakan yang diterapkan terhadap pesan yang gagal.

Audit laporan agregat perlu menjawab:

• sumber mana yang mengirim email menggunakan domain bisnis;
• sumber sah mana yang gagal SPF, DKIM, atau penyelarasan;
• sumber mana yang belum dikenali;
• tindakan apa yang diterapkan oleh penerima;
• apakah perubahan kebijakan menghasilkan kegagalan baru.

Microsoft menyarankan penunjukan orang tertentu untuk memantau laporan serta penggunaan kotak surat atau grup khusus, bukan kotak surat pengguna. Laporan dapat luas dan sulit diurai; Microsoft menyebut otomatisasi atau layanan eksternal sebagai opsi untuk membantu memahami data.

Menentukan prioritas temuan

Prioritas	Contoh temuan	Tindakan
Tinggi	DMARC sudah memakai kebijakan ketat, tetapi pengirim sah gagal penyelarasan.	Tahan pengetatan berikutnya dan periksa konfigurasi sumber tersebut.
Tinggi	Pesan keluar tidak memiliki tanda tangan DKIM yang dapat diverifikasi.	Periksa aktivasi DKIM, record TXT, selector, dan jalur pengiriman.
Menengah	Sumber aktif belum dapat dicocokkan dengan konfigurasi SPF.	Konfirmasi dengan pemilik layanan dan dokumentasi penyedia.
Menengah	Laporan DMARC diterima, tetapi tidak ada penanggung jawab pemantauan.	Tetapkan penerima dan jadwal peninjauan yang sesuai kebutuhan bisnis.
Rendah	Dokumentasi internal belum mencatat selector atau domain penandatangan.	Perbarui inventaris agar perubahan berikutnya dapat ditelusuri.

Urutan tersebut merupakan kerangka prioritas praktis, bukan standar kepatuhan. Dampak aktual harus dinilai berdasarkan layanan yang terlibat dan risiko terhentinya email bisnis.

Kapan membutuhkan bantuan penyedia atau tenaga teknis

Jangan melakukan perubahan DNS berisiko tinggi tanpa verifikasi tambahan apabila:

• bisnis tidak mengetahui seluruh sumber email yang aktif;
• domain dipakai bersama oleh banyak aplikasi atau unit usaha;
• layanan pihak ketiga mengubah pesan dalam perjalanan;
• pengirim sah gagal DMARC tanpa penyebab yang jelas;
• tim tidak memiliki akses ke DNS, header lengkap, atau laporan DMARC;
• kebijakan quarantine atau reject akan diterapkan pada domain produksi.

Google menyarankan menghubungi penyedia domain untuk bantuan terkait record TXT dan konfigurasi DNS pihak ketiga. Microsoft juga menyarankan meminta bantuan registrar atau penyedia hosting DNS jika administrator tidak terbiasa dengan konfigurasi tersebut.

Langkah berikutnya

Mulailah dengan satu domain atau subdomain yang memiliki sedikit sumber pengiriman. Buat inventaris, kirim pesan uji melalui setiap sumber, simpan hasil Authentication-Results, lalu cocokkan SPF, tanda tangan DKIM, penyelarasan domain, dan laporan DMARC.

Jangan langsung mengubah kebijakan menjadi p=reject hanya karena record SPF, DKIM, dan DMARC terlihat tersedia. Selesaikan temuan pada pengirim sah terlebih dahulu, pantau tahap p=none dan p=quarantine, kemudian pertimbangkan pengetatan berdasarkan hasil yang dapat diverifikasi.