Karyawan AI untuk Audit SPF, DKIM, dan DMARC: Periksa Identitas Email Sebelum Promosi

Ditulis oleh Nugraha Labib Mujaddid, pembuat AgentBuff.

Email promosi yang terlihat rapi belum tentu dikirim dengan identitas domain yang benar. Untuk UMKM, kreator newsletter, dan usaha jasa, pekerjaan pertama bukan menambah volume kiriman, melainkan memastikan setiap aplikasi pengirim dapat membuktikan hubungan dengan domain bisnis. Karyawan AI dapat membantu menginventarisasi jalur pengiriman, membaca bukti autentikasi, dan menyiapkan usulan perbaikan. Perubahan DNS dan pengiriman kampanye tetap memerlukan keputusan manusia.

Artikel ini menawarkan workflow audit baca-saja, bukan layanan pengecekan domain tertentu. Semua nama usaha dan kejadian dalam contoh adalah ilustrasi. Tidak ada jaminan masuk inbox: autentikasi adalah satu bagian dari pengiriman email, bukan pengganti izin penerima, reputasi, konten yang relevan, atau pengelolaan keluhan.[6]

Masalah sebenarnya: satu domain, beberapa pengirim

Bayangkan studio desain kecil yang memakai email kantor untuk proposal, aplikasi invoice untuk tagihan, formulir website untuk notifikasi, dan platform newsletter untuk materi edukasi. Pemilik melihat semuanya memakai nama merek yang sama. Namun setiap jalur dapat memiliki konfigurasi autentikasi berbeda.

Mengambil satu email dari email kantor lalu menyimpulkan seluruh domain sehat adalah audit yang terlalu sempit. Sasaran audit yang disarankan di sini adalah satu baris bukti untuk setiap jalur pengirim yang disetujui, termasuk jalur yang jarang dipakai. Ini berbeda dari triase email bisnis, yang mengatur pesan masuk, prioritas, dan draf balasan. Di sini yang diperiksa adalah identitas teknis email keluar.

Mulai dari aplikasi yang benar-benar dipakai. Jangan memindai akun pihak lain, membeli daftar alamat, atau meminta AI mengirim promosi untuk menguji deliverability. Gunakan akun penerima uji milik tim atau pihak yang bersedia menerima pengujian.

Pahami tiga pemeriksaan tanpa menyamakan fungsinya

SPF menghubungkan domain pengirim pada lapisan pengiriman dengan server yang diizinkan. Google meminta catatan SPF mencakup pengirim yang digunakan domain, termasuk penyedia pihak ketiga. Nama tampilan di kotak masuk bukan pengganti bukti tersebut.[6]

DKIM memakai tanda tangan digital pada email yang diverifikasi menggunakan informasi kunci publik domain. Dalam audit, domain penandatangan penting karena belum tentu sama dengan domain yang terlihat oleh pembaca.[6][7]

DMARC mengevaluasi hubungan autentikasi dengan domain pada header From. Pesan dapat lulus melalui SPF yang lulus sekaligus selaras, atau DKIM yang lulus sekaligus selaras. Jadi, tulisan spf=pass pada sebuah header belum sendirian membuktikan DMARC lulus. Mode alignment yang dipakai juga perlu diperhatikan.[7]

DMARC sekaligus menyatakan kebijakan yang diminta kepada server penerima untuk pesan yang gagal pemeriksaan. Google menjelaskan pilihan none, quarantine, dan reject, serta fasilitas laporan. p=none adalah tahap observasi, bukan kebijakan penolakan pesan gagal.[7]

Implikasi operasionalnya sederhana: pisahkan tiga pertanyaan. Apakah konfigurasi tersedia? Apakah pesan yang benar-benar diterima lulus autentikasi? Apakah domainnya selaras dengan identitas From? Jangan merangkum semuanya menjadi satu centang hijau tanpa bukti.

Tetapkan ruang lingkup dan definisi selesai

Pilih satu domain bisnis yang Anda kelola dan catat subdomain yang benar-benar digunakan untuk mengirim. Tetapkan pemilik bisnis, pengelola DNS, administrator aplikasi pengirim, serta siapa yang dapat menyetujui perubahan. Peta kepemilikan ini dapat dimulai dari inventaris aset digital.

Definisi selesai yang disarankan:

• semua aplikasi pengirim yang diketahui sudah tercatat;
• setiap jalur aktif memiliki contoh pesan uji terbaru atau status belum diuji;
• hasil SPF, DKIM, DMARC, dan alignment dibedakan;
• setiap temuan memiliki sumber bukti, waktu pengamatan, owner, serta langkah berikutnya;
• tidak ada private key, token, atau kata sandi masuk laporan;
• perubahan yang diusulkan belum dianggap diterapkan;
• perubahan yang disetujui diperiksa kembali melalui DNS dan pesan uji baru.

Daftar ini adalah rekomendasi kerja, bukan standar sertifikasi. Jika satu jalur belum punya bukti, laporkan celahnya. Jangan menulis domain aman hanya karena alat pemeriksa menampilkan hasil baik untuk konfigurasi lain.

Workflow audit delapan langkah

1. Buat register jalur pengiriman

Catat fungsi bisnis, penyedia, domain From, alamat pengirim, identitas teknis bila tersedia, owner, serta tingkat kritikalitas. Bedakan proposal, invoice, pemulihan akun, notifikasi pesanan, dan newsletter. Hindari menyatukan dua aplikasi hanya karena keduanya memakai domain merek yang sama.

Mulai dengan pengetahuan tim dan panel aplikasi yang diizinkan. Beri status belum_dikonfirmasi untuk jalur yang hanya muncul dari invoice lama atau ingatan staf. Minta pemilik mengonfirmasi penggunaannya sebelum merekomendasikan pencabutan konfigurasi.

2. Kumpulkan bukti dengan akses minimum

Sumber dapat berupa ekspor DNS, hasil lookup publik domain milik sendiri, panduan resmi penyedia email, dan header pesan uji yang diterima. AI tidak membutuhkan kata sandi registrar atau hak mengubah DNS untuk merapikan bukti tersebut.

Header dapat memuat alamat, identitas pesan, serta informasi infrastruktur. Gunakan pesan uji tanpa data pelanggan, batasi akses berkas, dan hapus bagian yang tidak dibutuhkan. Jangan mengunggah seluruh mailbox ke alat pemeriksa publik hanya agar audit terlihat lengkap.

3. Catat konfigurasi tanpa menebak status pesan

Simpan nama record, tipe, nilai publik yang relevan, resolver atau sumber ekspor, serta waktu pembacaan. Cocokkan konfigurasi dengan petunjuk penyedia yang benar. Untuk DKIM, jangan menebak selector dari kebiasaan penyedia lain; ambil dari pengaturan resmi atau tanda tangan pesan yang bersangkutan.

Pisahkan status record_ditemukan, format_perlu_review, dan belum_diperiksa. Kehadiran record belum membuktikan bahwa aplikasi benar-benar menandatangani atau memakai jalur yang diharapkan. Bukti perilaku diperoleh pada tahap pesan uji.

4. Baca hasil autentikasi dari sisi penerima

Minta administrator mengirim pesan uji dari setiap aplikasi yang disetujui kepada mailbox uji tim. Audit ini tidak perlu menyertakan pengiriman massal. Ambil header dari fitur melihat sumber pesan pada layanan penerima, bukan hanya screenshot panel pengirim.

Catat hasil autentikasi yang dilaporkan sistem penerima tepercaya, domain yang diuji, domain penandatangan, domain From, waktu, dan identitas jalur. Jangan mempercayai sembarang baris header yang disalin dari pesan tak dikenal sebagai hasil verifikasi penerima.

Jika hanya tersedia screenshot berisi pass tanpa detail identitas, tandai bukti belum cukup. AI harus meminta header uji yang sesuai, bukan menyimpulkan alignment dari nama merek di subjek email.

5. Periksa alignment dan jalur pihak ketiga

Bandingkan domain pada From dengan identitas yang digunakan SPF atau DKIM sesuai mode alignment yang berlaku. DMARC memerlukan setidaknya satu jalur autentikasi yang lulus dan selaras; tidak cukup hanya menemukan SPF atau DKIM milik penyedia lain yang lulus.[7]

Contoh ilustratif: platform newsletter menampilkan alamat merek, tetapi tanda tangan memakai domain penyedia. Itu belum membuktikan kegagalan DMARC karena jalur SPF yang selaras mungkin masih tersedia. Sebaliknya, DKIM lulus juga belum membuktikan DMARC lulus bila tidak selaras dan tidak ada jalur SPF yang memenuhi. Baca seluruh bukti sebelum memutuskan.[7]

6. Ubah temuan menjadi antrean keputusan

Gunakan kategori praktis: bukti kurang, konfigurasi berbeda dari panduan penyedia, autentikasi gagal, alignment tidak terbukti, jalur tanpa owner, dan perubahan menunggu persetujuan. Tulis dampak bisnis secara spesifik, misalnya notifikasi pesanan belum diuji, bukan seluruh email pasti diblokir.

Untuk setiap usulan, sertakan nilai saat ini, perubahan yang diusulkan, panduan rujukan, jalur terdampak, pelaksana, approver, waktu pelaksanaan, rencana pemulihan, dan bukti yang harus dikumpulkan sesudahnya. Jangan membuat record siap-tempel dari tebakan. Nilai DNS harus berasal dari konfigurasi penyedia untuk akun yang benar.

7. Terapkan perubahan bertahap oleh pihak berwenang

Google menyarankan rollout DMARC bertahap: mulai dari kebijakan observasi none, tinjau laporan, lalu pertimbangkan penegakan setelah sumber pengiriman dipahami. Dokumentasinya menyarankan pemantauan setidaknya satu minggu sebelum menaikkan kebijakan jika tidak ada masalah.[8]

Jangan memperlakukan satu minggu sebagai jaminan cakupan semua proses. Usaha yang mengirim tagihan hanya pada akhir bulan perlu memastikan jalur itu juga diuji. Ini rekomendasi operasional: lama observasi harus mewakili siklus bisnis, bukan sekadar melewati kalender.

AI cukup membuat change set dan checklist. Pemegang akses DNS yang berwenang meninjau dan menerapkannya. Jangan menaikkan ke reject hanya karena sebuah contoh dokumentasi memakai nilai tersebut.

8. Verifikasi ulang dan simpan hasil

Setelah perubahan, baca kembali record pada nama yang tepat dan kirim ulang pesan uji dari jalur terdampak melalui administrator. Periksa hasil autentikasi di sisi penerima, bukan hanya notifikasi bahwa pengaturan berhasil disimpan. Bila hasil berbeda antar-pengamatan, catat waktunya dan lanjutkan pemeriksaan bersama pengelola DNS.

Status akhir sebaiknya terukur: lulus_pada_sampel, gagal_pada_sampel, menunggu_bukti, atau menunggu_perubahan. Jangan memakai status terjamin masuk inbox. Catat juga siapa yang mengonfirmasi hasil dan kapan jalur itu harus diperiksa lagi.

Format laporan yang dapat langsung dipakai

id_jalur:
fungsi_bisnis:
penyedia_dan_owner:
domain_from:
sumber_dns_dan_waktu:
referensi_pesan_uji:
hasil_spf_dan_domain:
hasil_dkim_dan_domain:
hasil_dmarc:
alignment_dan_buktinya:
status_kecukupan_bukti:
temuan_dan_dampak:
usulan_perubahan:
approver_dan_pelaksana:
hasil_verifikasi_ulang:
tanggal_review_berikutnya:

Simpan referensi pesan uji di lokasi terbatas, bukan di spreadsheet publik. Laporan manajemen cukup memuat status, dampak, owner, dan tautan ke bukti yang berhak mereka akses. Jangan menyalin private key DKIM: audit memerlukan bukti publik dan hasil verifikasi, bukan rahasia penandatangan.

Contoh operasional: studio kecil sebelum membuka newsletter

Studio ilustratif ini memiliki tiga jalur: email kantor, aplikasi invoice, dan newsletter baru. Email kantor lulus pada sampel; invoice belum mempunyai header uji; newsletter menunjukkan autentikasi penyedia tetapi alignment belum terbukti.

AI menulis tiga hasil terpisah, bukan satu skor domain. Owner invoice diminta menyiapkan pesan uji tanpa data pelanggan. Administrator newsletter memeriksa pengaturan domain khusus berdasarkan panduan penyedianya. Pengelola DNS menerima usulan perubahan untuk ditinjau, bukan instruksi otomatis.

Promosi ditahan sampai jalur newsletter memiliki bukti yang memadai. Namun invoice tidak dinyatakan rusak hanya karena belum diuji. Inilah nilai audit yang baik: ketidakpastian terlihat, pekerjaan mempunyai owner, dan perubahan tidak dilakukan dengan cara mencoba-coba di sistem produksi.

Instruksi siap pakai untuk karyawan AI

Audit baca-saja jalur email keluar domain bisnis yang saya kelola dari register pengirim, ekspor DNS, panduan resmi penyedia, dan header pesan uji yang diizinkan. Pisahkan keberadaan record, hasil autentikasi, serta alignment. Untuk setiap klaim, cantumkan sumber dan waktu. Jika bukti kurang, tulis belum terverifikasi. Jangan mengubah DNS, menaikkan kebijakan DMARC, mengirim kampanye, mengambil data pelanggan, atau menampilkan rahasia. Hasilkan register per jalur, temuan, change set untuk review manusia, dan checklist verifikasi ulang. Jangan menyatakan autentikasi sebagai jaminan inbox.

Uji instruksi ini dengan kasus bukti kurang, selector DKIM berbeda, aplikasi lama yang belum dikonfirmasi, serta pesan yang lulus autentikasi tetapi alignment belum terbukti. Agen harus mempertahankan status belum terverifikasi, bukan mengisi celah dengan asumsi.

Di mana AgentBuff membantu?

Situs resmi AgentBuff menawarkan agen melalui chat, koneksi alat kerja, serta tugas terjadwal. Untuk workflow ini, gunakan kemampuan yang benar-benar tersedia dan sudah diizinkan pada akun Anda. Jangan menganggap konektor DNS atau audit DMARC otomatis tersedia hanya karena workflow dapat dirancang.[1]

Mulai dari berkas DNS dan header uji yang disiapkan administrator. Karyawan AI dapat diarahkan menyusun register, membandingkan bukti dengan panduan, serta menyiapkan ringkasan review. Jika koneksi langsung tidak tersedia, jalur berbasis ekspor tetap layak. Tidak perlu memberi hak menulis DNS untuk memperoleh manfaat administratif.

Ingin menata pemeriksaan ini bersama pekerjaan rutin lain? Ajukan akses AgentBuff. Halaman pendaftaran saat pemeriksaan ini menyatakan akses dibuka bertahap melalui pengajuan; jangan menganggap akun langsung aktif setelah mengisi formulir.[2]

Sources

[1] https://agentbuff.id [2] https://agentbuff.id/register [6] https://support.google.com/mail/answer/81126?hl=en&visit_id=639278658508299863-1423158227&rd=1 [7] https://knowledge.workspace.google.com/admin/security/set-up-dmarc?hl=en&visit_id=639287033269834287-2277830942&rd=1 [8] https://knowledge.workspace.google.com/admin/security/recommended-dmarc-rollout?hl=en&visit_id=639282381532570656-1547245703&rd=1