Pertanyaan dan skenario
Sebuah perusahaan sedang mengonsolidasikan beberapa penyedia email di bawah satu domain pengirim. Jelaskan penyelarasan DMARC dan peran RFC 9989, 9990, dan 9991, lalu rancang validasi serta rollback dari p=none ke reject.
Ini cocok untuk peran platform, keamanan, infrastruktur email, dan diagnosis insiden lintas tim. Pertanyaan ini menguji penalaran protokol dan kontrol peluncuran; pertanyaan ini tidak mengharuskan klaim bahwa setiap penerima telah mengimplementasikan setiap RFC baru secara identik.
Apa yang sedang diuji oleh pewawancara
- Apakah Anda memisahkan peran dan input dari SPF, DKIM, dan DMARC.
- Apakah Anda mengetahui bahwa DMARC memerlukan setidaknya satu jalur SPF atau DKIM yang lolos (pass) dan selaras (aligned).
- Apakah Anda dapat membedakan inti DMARC RFC 9989, laporan agregat RFC 9990, dan laporan kegagalan RFC 9991.
- Apakah Anda dapat memperketat kebijakan dari observasi alih-alih beralih langsung ke
p=reject. - Apakah Anda dapat menangani penerusan (forwarding), pihak ketiga, subdomain, privasi laporan, dan rollback.
Pertanyaan klarifikasi sebelum menjawab
- Apakah identitas yang dilindungi adalah satu domain organisasi atau beberapa subdomain, dan apa domain From, Return-Path, serta DKIM d untuk setiap pengirim?
- Bagaimana tingkat kelolosan (pass) dan penyelarasan (alignment) SPF, DKIM, dan DMARC berdasarkan penyedia dan subdomain, dan apakah laporan agregat dapat diterima?
- Apakah pesan pemasaran, transaksional, dan karyawan dikirim dari domain yang sama, atau dapatkah dipisahkan?
- Apakah perilaku penerima telah diverifikasi melalui pengujian dan dokumentasi penyedia, atau kita hanya mengasumsikan dukungan standar?
Kerangka jawaban 30 detik
DMARC memeriksa apakah domain From yang terlihat selaras dengan domain SPF yang diautentikasi atau domain DKIM d; setidaknya satu jalur harus lolos dan selaras. RFC 9989 mendefinisikan inti DMARC, sedangkan RFC 9990 dan RFC 9991 mendefinisikan laporan agregat dan kegagalan. Mulailah dengan p=none sebagai mode observasi, uraikan (parse) laporan, perbaiki penyelarasan penyedia, subdomain, dan jenis pesan, lalu berpindahlah secara bertahap ke quarantine dan reject. Setiap langkah memerlukan metrik, pengujian representatif, dan rollback yang cepat. Nomor RFC baru bukanlah bukti bahwa setiap penerima menghasilkan laporan yang identik saat ini.
Jawaban mendalam langkah demi langkah
1. Petakan ketiga jalur identitas
SPF mengautentikasi apakah server pengirim diotorisasi, biasanya menggunakan domain amplop SMTP MAIL FROM. DKIM memverifikasi tanda tangan, dengan domain d miliknya berpartisipasi dalam penyelarasan. DMARC mengevaluasi domain From yang terlihat oleh penerima dan menerapkan kebijakan berdasarkan penyelarasan. Input-input ini berbeda, sehingga satu baris Authentication-Results bukanlah pengganti untuk memeriksa domain yang sebenarnya.
2. Nilai penyelarasan alih-alih sekadar status lolos (pass)
Kondisi kunci DMARC adalah SPF atau DKIM lolos dan domain yang diautentikasinya selaras dengan From di bawah mode relaxed atau strict organisasi. Penyedia dapat memiliki SPF yang lolos sementara envelope-from miliknya tidak selaras, atau DKIM lolos dengan domain d milik penyedia. Keduanya memerlukan perubahan domain, tanda tangan, atau batasan pengiriman.
3. Jelaskan batasan RFC 2026
RFC 9989 adalah spesifikasi inti DMARC dan menggantikan posisi historis RFC 7489. RFC 9990 menjelaskan laporan agregat untuk distribusi sumber jangka panjang, sedangkan RFC 9991 menjelaskan laporan kegagalan. Pisahkan antara "spesifikasi telah diterbitkan" dengan "setiap penerima mengeluarkan laporan yang sama"; verifikasi dukungan konkret dengan pengujian dan dokumentasi penyedia.
4. Rancang perubahan kebijakan secara bertahap
Publikasikan p=none terlebih dahulu dengan tujuan rua yang terkontrol dan kotak surat atau pipeline analisis dengan akses terkontrol. Agregasikan dimensi SPF, DKIM, From, subdomain, dan kegagalan berdasarkan pengirim, lalu perbaiki sumber-sumber yang sah (legitimate). Gunakan sp untuk subdomain yang dicakup secara cermat atau pisahkan subdomain transaksional dan pemasaran. Pindahlah ke quarantine hanya setelah lalu lintas sah stabil dan sumber yang tidak dikenal dapat dijelaskan, kemudian pertimbangkan reject.
5. Cantumkan verifikasi dan rollback dalam catatan perubahan (change record)
Simpan rekaman DNS, pengaturan penyedia, dan baseline laporan sebelum setiap perubahan. Setelah pengetatan, pantau pengiriman yang sah, kelolosan DMARC, kegagalan penyelarasan, keluhan, dan penundaan laporan. Uji penerusan (forwarding), milis, dan lampiran dengan kotak masuk nyata. Jika pengiriman yang sah menurun, kembalikan ke kebijakan sebelumnya atau persempit subdomain terlebih dahulu, lalu tentukan apakah propagasi, penandatanganan DKIM, penulisan ulang penerusan, atau laporan yang hilang menjadi penyebabnya.
Contoh jawaban berkualitas tinggi
Saya akan menginventarisasi domain From, MAIL FROM, dan DKIM d dari setiap pengirim, lalu menghitung kelolosan dan penyelarasan berdasarkan penyedia dan subdomain. DMARC tidak mengharuskan SPF dan DKIM lolos bersamaan; satu jalur yang lolos dan selaras sudah cukup. RFC 9989 memegang kebijakan inti, sedangkan RFC 9990 dan RFC 9991 mencakup dua jenis laporan, yang cakupan penerimanya harus diukur alih-alih diasumsikan. Saya akan mulai dari p=none, mengumpulkan laporan agregat, memperbaiki masalah pihak ketiga, penerusan, dan subdomain, lalu memperketat segmen yang tercakup ke quarantine sebelum reject. Setiap langkah mendapatkan ambang batas untuk pengiriman yang sah, penyelarasan, dan sumber yang tidak dapat dijelaskan, ditambah rollback DNS dan jalur isolasi subdomain. Hal tersebut membuat perubahan dapat diaudit dan membatasi dampak buruk ketika suatu asumsi salah.
Kesalahan umum
- Menyatakan DMARC lolos setelah SPF atau DKIM lolos tanpa memeriksa penyelarasan domain From.
- Memperlakukan MAIL FROM SPF, d DKIM, dan From yang terlihat sebagai bidang yang sama.
- Menyebut ketiga RFC 2026 sebagai "inti DMARC" tanpa memisahkan tanggung jawab laporan.
- Beralih ke
p=rejecttanpa baseline laporan dan memblokir email pihak ketiga yang sah. - Mengasumsikan penerusan (forwarding) mempertahankan SPF atau DKIM tanpa menguji milis dan jalur penerusan.
- Memublikasikan data laporan tanpa mempertimbangkan informasi alamat dan organisasi dalam laporan tersebut.
Pertanyaan lanjutan dan tanggapan
SPF lolos tetapi DMARC gagal. Apa yang Anda periksa terlebih dahulu?
Bandingkan domain terautentikasi SPF dengan From dan konfirmasikan penyelarasan relaxed atau strict. Kemudian periksa pewarisan subdomain, penulisan ulang, dan header pesan yang sebenarnya; IP pengirim yang diotorisasi saja tidak cukup.
DKIM lolos tetapi gagal setelah diteruskan (forwarding). Apa selanjutnya?
Periksa apakah penerus menulis ulang badan pesan (body) atau header yang ditandatangani dan apakah domain d serta selector masih dapat di-resolve. Untuk penerusan yang tidak terkontrol, evaluasi penandatanganan yang stabil, penanganan milis, dan subdomain yang terisolasi alih-alih menyembunyikan sumber yang tidak dikenal dengan melemahkan kebijakan.
Bagaimana Anda memutuskan untuk berpindah dari quarantine ke reject?
Gunakan irisan laporan berdasarkan penyedia, subdomain, dan jenis pesan untuk menunjukkan penyelarasan yang berkelanjutan, serta selesaikan pengujian penerusan, pemasaran, dan transaksional. Tetapkan ambang batas untuk pengiriman yang sah, kegagalan penyelarasan, keluhan, dan sumber yang tidak dapat dijelaskan, dengan jendela rollback.
Apa yang penting ketika alamat laporan berada di domain lain?
Konfirmasikan bahwa domain penerima secara eksplisit mengotorisasi hubungan pelaporan tersebut, dan batasi akses serta retensi dalam pipeline laporan. Pelaporan lintas domain tidak secara otomatis menjadi ekspor data yang tepercaya.
Sumber: RFC 9989, RFC 9990, RFC 9991, Google Gmail "Email sender guidelines," dan Dataford "Explaining Email Authentication Clearly" (URL lengkap dicatat dalam meta.json).