DMARC: Cara Melindungi Reputasi Email Anda
Burung
13 Apr 2016
1 min read
Intisari Utama
DMARC membantu melindungi domain Anda dari phishing, spoofing, dan penggunaan email yang tidak sah dengan mempublikasikan praktik autentikasi Anda dan meminta penanganan tertentu untuk pesan yang gagal.
Ini bekerja bersama dengan SPF dan DKIM untuk memastikan keselarasan domain dan mencegah email palsu merusak reputasi pengirim Anda.
Kebijakan DMARC yang kuat mendukung kepercayaan yang lebih tinggi, keterlibatan yang lebih tinggi, dan mempersiapkan domain Anda untuk masa depan saat ekosistem bergeser ke model reputasi berbasis domain.
Pemeriksaan validasi DMARC mengandalkan keselarasan domain antara domain From, domain Return-Path (SPF), dan domain penandatanganan DKIM.
Menyiapkan DMARC memerlukan penerimaan laporan, memahami data agregat vs. forensik, dan mengkonfigurasi alat untuk menganalisanya.
Anda memulai dengan kebijakan aman p=none untuk memantau lalu lintas sebelum beralih ke quarantine atau reject.
Menerbitkan catatan DMARC melibatkan pembuatan entri DNS TXT di _dmarc.yourdomain.com dengan kebijakan, alamat pelaporan, dan parameter opsional seperti penerapan persentase.
Mailbox pelaporan yang tepat (agregat + forensik) dan alat analisa penting untuk memantau kepatuhan, mendeteksi spoofing, dan memastikan keselarasan benar.
DMARC hanya memerlukan satu dari berikut ini untuk lolos: SPF yang selaras atau DKIM yang selaras.
Mengimplementasikan DMARC memperkuat keamanan email dan memainkan peran kunci dalam integritas merek, kepercayaan, dan keberterusan pengiriman jangka panjang.
Sorotan Q&A
Apa itu DMARC dan mengapa hal ini penting?
DMARC (Domain-based Message Authentication, Reporting, and Conformance) adalah kebijakan yang diterbitkan melalui DNS yang melindungi domain Anda dari spoofing dan phishing dengan menegakkan penyelarasan domain dan memungkinkan visibilitas melalui pelaporan.
Apakah DMARC merupakan protokol otentikasi?
Tidak, DMARC bukan autentikasi itu sendiri—ia bergantung pada SPF dan DKIM untuk mengautentikasi email dan menggunakan kebijakan + pelaporan untuk mengontrol bagaimana server penerima menangani kegagalan.
Apa yang diperiksa oleh DMARC?
Ini memverifikasi:
SPF otentikasi + penyelarasan
DKIM otentikasi + penyelarasan
Seorang pengirim hanya membutuhkan salah satu dari ini untuk lulus agar DMARC berhasil.
Apa itu "domain alignment"?
Ini adalah persyaratan bahwa domain From yang terlihat harus cocok (ketat) atau berbagi domain organisasi yang sama (santai) dengan domain SPF Return-Path atau domain penandatanganan DKIM.
Mengapa DMARC meningkatkan deliverability?
Karena penyedia kotak surat lebih mempercayai domain yang terautentikasi dan selaras. DMARC mencegah pesan palsu merusak reputasi Anda dan meningkatkan penempatan Inbox untuk email yang sah.
Apa perbedaan antara laporan DMARC agregat dan forensik?
Laporan agregat (RUA): Ringkasan XML dari hasil otentikasi di seluruh lalu lintas.
Laporan forensik (RUF): Contoh individu dari pesan yang gagal untuk analisis mendalam.
Kotak surat apa yang saya perlukan sebelum mempublikasikan DMARC?
Anda seharusnya membuat dua alamat, seperti:
agg_reports@yourdomain.com (RUA)
afrf_reports@yourdomain.com (RUF)
Ini menjaga aliran pelaporan terpisah dan lebih mudah untuk diurai.
Kebijakan DMARC apa yang harus saya mulai?
Senantiasa mulai dengan p=none. Ini memantau aktivitas otentikasi tanpa mempengaruhi pengiriman, memungkinkan Anda untuk mengidentifikasi masalah penyelarasan dan upaya pemalsuan dengan aman.
Apa kebijakan DMARC yang tersedia?
none: hanya monitor
quarantine: kirim pesan yang gagal ke spam
reject: blokir pesan yang gagal sepenuhnya
Di mana saya mempublikasikan rekaman DMARC?
Di DNS Anda di:
_dmarc.yourdomain.com
Ini harus berupa rekaman TXT yang menentukan kebijakan, versi, dan endpoint pelaporan Anda.
Seperti apa tampilan dasar catatan DMARC?
Contoh:
v=DMARC1; p=none; rua=mailto:agg_reports@yourdomain.com; ruf=mailto:afrf_reports@yourdomain.com; pct=100
Apa yang terjadi jika DMARC gagal?
Server penerima menerapkan kebijakan yang Anda minta (tidak ada, karantina, tolak), meskipun penanganan akhir sepenuhnya terserah pada penyedia. Kebijakan yang ketat dapat secara signifikan mengurangi upaya phishing yang menggunakan domain Anda.
Dalam postingan ini, kami akan memberi tahu Anda semua yang perlu Anda ketahui tentang memanfaatkan DMARC untuk melindungi reputasi email Anda, dan memberikan petunjuk tentang cara mengatur ini untuk domain Anda.
Sebuah Alat Efektif untuk Melawan Surat Penipuan
Sering disebutkan bersamaan dengan protokol otentikasi email SPF dan DKIM, DMARC, atau Domain-based Message Authentication, Reporting, and Conformance, bukanlah protokol otentikasi itu sendiri. Sebaliknya, tujuan dari DMARC adalah untuk memungkinkan kami, pemilik domain, untuk melindungi reputasi email kami dengan cara:
Mengumumkan praktik otentikasi email,
Meminta perlakuan untuk email yang gagal dalam pemeriksaan otentikasi, dan
Meminta laporan tentang email yang mengklaim berasal dari domainnya.
DMARC dapat menjadi alat yang efektif bagi kami untuk digunakan dalam melawan email penipuan yang menargetkan nama domain kami (misalnya, phishing dan spoofing), dan yang dapat meningkatkan kepercayaan lebih tinggi di antara penerima kami untuk email kami. Untuk organisasi yang memerlukan enkripsi end-to-end di luar otentikasi, menerapkan S/MIME dengan metode pengumpulan kunci publik penerima yang efisien memberikan lapisan keamanan tambahan. Kepercayaan yang lebih tinggi ini, pada gilirannya, harus mengarah pada keterlibatan yang lebih tinggi dengan email kami, dan email yang dibuka dan menghasilkan klik mendorong penjualan dan ROI yang lebih tinggi untuk kampanye email kami.
Selain melindungi domain kami, kami memprediksi bahwa menerapkan DMARC sekarang akan menjadi cara yang sangat baik untuk "melindungi masa depan" domain kami. Di sini di Bird, kami percaya bahwa seiring industri bergerak ke IPv6, hampir pasti akan beralih dari model reputasi berbasis IP ke model reputasi berbasis domain. Reputasi berbasis domain akan membutuhkan otentikasi berbasis domain, dan DMARC, bersama dengan DKIM dan SPF, akan membantu domain membangun reputasi berbasis domain jauh sebelum itu mungkin benar-benar diperlukan.
Dalam postingan ini, kami akan memberi tahu Anda semua yang perlu Anda ketahui tentang memanfaatkan DMARC untuk melindungi reputasi email Anda dan memberi Anda petunjuk tentang cara mengaturnya untuk domain Anda.
Sering disebutkan bersamaan dengan protokol otentikasi email SPF dan DKIM, DMARC, atau Domain-based Message Authentication, Reporting, and Conformance, bukanlah protokol otentikasi itu sendiri. Sebaliknya, tujuan dari DMARC adalah untuk memungkinkan kami, pemilik domain, untuk melindungi reputasi email kami dengan cara:
Mengumumkan praktik otentikasi email,
Meminta perlakuan untuk email yang gagal dalam pemeriksaan otentikasi, dan
Meminta laporan tentang email yang mengklaim berasal dari domainnya.
DMARC dapat menjadi alat yang efektif bagi kami untuk digunakan dalam melawan email penipuan yang menargetkan nama domain kami (misalnya, phishing dan spoofing), dan yang dapat meningkatkan kepercayaan lebih tinggi di antara penerima kami untuk email kami. Untuk organisasi yang memerlukan enkripsi end-to-end di luar otentikasi, menerapkan S/MIME dengan metode pengumpulan kunci publik penerima yang efisien memberikan lapisan keamanan tambahan. Kepercayaan yang lebih tinggi ini, pada gilirannya, harus mengarah pada keterlibatan yang lebih tinggi dengan email kami, dan email yang dibuka dan menghasilkan klik mendorong penjualan dan ROI yang lebih tinggi untuk kampanye email kami.
Selain melindungi domain kami, kami memprediksi bahwa menerapkan DMARC sekarang akan menjadi cara yang sangat baik untuk "melindungi masa depan" domain kami. Di sini di Bird, kami percaya bahwa seiring industri bergerak ke IPv6, hampir pasti akan beralih dari model reputasi berbasis IP ke model reputasi berbasis domain. Reputasi berbasis domain akan membutuhkan otentikasi berbasis domain, dan DMARC, bersama dengan DKIM dan SPF, akan membantu domain membangun reputasi berbasis domain jauh sebelum itu mungkin benar-benar diperlukan.
Dalam postingan ini, kami akan memberi tahu Anda semua yang perlu Anda ketahui tentang memanfaatkan DMARC untuk melindungi reputasi email Anda dan memberi Anda petunjuk tentang cara mengaturnya untuk domain Anda.
Sering disebutkan bersamaan dengan protokol otentikasi email SPF dan DKIM, DMARC, atau Domain-based Message Authentication, Reporting, and Conformance, bukanlah protokol otentikasi itu sendiri. Sebaliknya, tujuan dari DMARC adalah untuk memungkinkan kami, pemilik domain, untuk melindungi reputasi email kami dengan cara:
Mengumumkan praktik otentikasi email,
Meminta perlakuan untuk email yang gagal dalam pemeriksaan otentikasi, dan
Meminta laporan tentang email yang mengklaim berasal dari domainnya.
DMARC dapat menjadi alat yang efektif bagi kami untuk digunakan dalam melawan email penipuan yang menargetkan nama domain kami (misalnya, phishing dan spoofing), dan yang dapat meningkatkan kepercayaan lebih tinggi di antara penerima kami untuk email kami. Untuk organisasi yang memerlukan enkripsi end-to-end di luar otentikasi, menerapkan S/MIME dengan metode pengumpulan kunci publik penerima yang efisien memberikan lapisan keamanan tambahan. Kepercayaan yang lebih tinggi ini, pada gilirannya, harus mengarah pada keterlibatan yang lebih tinggi dengan email kami, dan email yang dibuka dan menghasilkan klik mendorong penjualan dan ROI yang lebih tinggi untuk kampanye email kami.
Selain melindungi domain kami, kami memprediksi bahwa menerapkan DMARC sekarang akan menjadi cara yang sangat baik untuk "melindungi masa depan" domain kami. Di sini di Bird, kami percaya bahwa seiring industri bergerak ke IPv6, hampir pasti akan beralih dari model reputasi berbasis IP ke model reputasi berbasis domain. Reputasi berbasis domain akan membutuhkan otentikasi berbasis domain, dan DMARC, bersama dengan DKIM dan SPF, akan membantu domain membangun reputasi berbasis domain jauh sebelum itu mungkin benar-benar diperlukan.
Dalam postingan ini, kami akan memberi tahu Anda semua yang perlu Anda ketahui tentang memanfaatkan DMARC untuk melindungi reputasi email Anda dan memberi Anda petunjuk tentang cara mengaturnya untuk domain Anda.
Terms to Know
Sebelum kita memulai mengatur DMARC untuk domain Anda, kami ingin memastikan bahwa kita berbicara dalam bahasa yang sama. Mari kita mulai dengan mendefinisikan beberapa istilah yang akan kita gunakan di seluruh dokumen ini.
RFC5322.From Domain
RFC5322.From Domain adalah bagian domain dari alamat email yang biasanya dilihat oleh penerima email kita saat sedang dibaca. Dalam contoh berikut, RFC5322.From domain adalah "joesbaitshop.com"
Dari: Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= Domain
DKIM adalah protokol autentikasi yang memungkinkan sebuah domain untuk mengambil tanggung jawab atas sebuah pesan dengan cara yang dapat divalidasi oleh penerima pesan; ini dilakukan dengan penggunaan tanda tangan kriptografi yang dimasukkan ke dalam header pesan saat meninggalkan titik asalnya. Tanda tangan ini secara efektif adalah snapshot dari tampilan pesan pada saat itu, dan penerima dapat menggunakan snapshot ini untuk melihat apakah pesan telah tiba di tujuannya tanpa perubahan. Proses menghasilkan dan memasukkan snapshot ini disebut penandatanganan DKIM, dan domain yang mengambil tanggung jawab untuk pesan dengan menandatanganinya memasukkan namanya ke dalam header dalam tag kunci-nilai sebagai "d=signingDomain", oleh karena itu disebut sebagai DKIM d= domain.
Return-Path Domain
Return-Path domain, kadang-kadang disebut sebagai RFC5321. From Domain atau Mail From domain, adalah domain ke mana bounces dialihkan; ini juga domain di mana pemeriksaan SPF dilakukan selama transaksi email. Domain ini biasanya tidak terlihat oleh penerima kecuali penerima cukup cerdas untuk melihat semua header dalam pesan yang diberikan.
Secara default, semua email yang dikirim melalui bird.com akan memiliki birdmail.com sebagai Return-Path domainnya, seperti dalam contoh berikut:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Namun, agar DMARC bekerja untuk domain Anda, Anda ingin memanfaatkan domain bounce kustom, yang akan berakhir dengan domain yang sama seperti domain pengirim Anda, misalnya, bounces.yourdomain.com saat menggunakan yourdomain.com sebagai domain pengirim Anda.
Organizational Domain
Istilah "Organizational Domain" mengacu pada domain yang diserahkan ke registrar untuk membuat kehadiran domain di internet. Untuk Bird, domain organisasi kami adalah bird.com dan birdmail.com.
Domain Alignment
Istilah terakhir untuk dipahami mengenai DMARC adalah "Domain Alignment," dan ini datang dalam dua varian: "relaxed" dan "strict."
Relaxed Domain Alignment
Dua domain dikatakan memiliki alignment domain yang relaxed ketika Organizational Domain mereka sama. Misalnya, a.mail.bird.com dan b.foo.bird.com memiliki alignment domain yang relaxed karena Organizational Domain yang sama, yaitu bird.com.
Strict Domain Alignment
Dua domain dikatakan dalam alignment domain yang strict jika dan hanya jika mereka identik. Jadi, foo.bird.com dan foo.bird.com adalah dalam alignment strict, karena dua domain tersebut identik. Di sisi lain, foo.bird.com dan bar.foo.bird.com hanya dalam alignment relaxed.
DMARC Domain Alignment Requirements
Agar pengecekan validasi DMARC dapat lulus, DMARC memerlukan alignment domain sebagai berikut:
Untuk SPF, RFC5322.From domain dan Return-Path domain harus dalam alignment
Untuk DKIM, RFC5322.From domain dan DKIM d= domain harus dalam alignment
Alignment ini bisa relaxed atau strict, berdasarkan kebijakan yang diterbitkan dari domain pengirim.
Sebelum kita memulai mengatur DMARC untuk domain Anda, kami ingin memastikan bahwa kita berbicara dalam bahasa yang sama. Mari kita mulai dengan mendefinisikan beberapa istilah yang akan kita gunakan di seluruh dokumen ini.
RFC5322.From Domain
RFC5322.From Domain adalah bagian domain dari alamat email yang biasanya dilihat oleh penerima email kita saat sedang dibaca. Dalam contoh berikut, RFC5322.From domain adalah "joesbaitshop.com"
Dari: Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= Domain
DKIM adalah protokol autentikasi yang memungkinkan sebuah domain untuk mengambil tanggung jawab atas sebuah pesan dengan cara yang dapat divalidasi oleh penerima pesan; ini dilakukan dengan penggunaan tanda tangan kriptografi yang dimasukkan ke dalam header pesan saat meninggalkan titik asalnya. Tanda tangan ini secara efektif adalah snapshot dari tampilan pesan pada saat itu, dan penerima dapat menggunakan snapshot ini untuk melihat apakah pesan telah tiba di tujuannya tanpa perubahan. Proses menghasilkan dan memasukkan snapshot ini disebut penandatanganan DKIM, dan domain yang mengambil tanggung jawab untuk pesan dengan menandatanganinya memasukkan namanya ke dalam header dalam tag kunci-nilai sebagai "d=signingDomain", oleh karena itu disebut sebagai DKIM d= domain.
Return-Path Domain
Return-Path domain, kadang-kadang disebut sebagai RFC5321. From Domain atau Mail From domain, adalah domain ke mana bounces dialihkan; ini juga domain di mana pemeriksaan SPF dilakukan selama transaksi email. Domain ini biasanya tidak terlihat oleh penerima kecuali penerima cukup cerdas untuk melihat semua header dalam pesan yang diberikan.
Secara default, semua email yang dikirim melalui bird.com akan memiliki birdmail.com sebagai Return-Path domainnya, seperti dalam contoh berikut:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Namun, agar DMARC bekerja untuk domain Anda, Anda ingin memanfaatkan domain bounce kustom, yang akan berakhir dengan domain yang sama seperti domain pengirim Anda, misalnya, bounces.yourdomain.com saat menggunakan yourdomain.com sebagai domain pengirim Anda.
Organizational Domain
Istilah "Organizational Domain" mengacu pada domain yang diserahkan ke registrar untuk membuat kehadiran domain di internet. Untuk Bird, domain organisasi kami adalah bird.com dan birdmail.com.
Domain Alignment
Istilah terakhir untuk dipahami mengenai DMARC adalah "Domain Alignment," dan ini datang dalam dua varian: "relaxed" dan "strict."
Relaxed Domain Alignment
Dua domain dikatakan memiliki alignment domain yang relaxed ketika Organizational Domain mereka sama. Misalnya, a.mail.bird.com dan b.foo.bird.com memiliki alignment domain yang relaxed karena Organizational Domain yang sama, yaitu bird.com.
Strict Domain Alignment
Dua domain dikatakan dalam alignment domain yang strict jika dan hanya jika mereka identik. Jadi, foo.bird.com dan foo.bird.com adalah dalam alignment strict, karena dua domain tersebut identik. Di sisi lain, foo.bird.com dan bar.foo.bird.com hanya dalam alignment relaxed.
DMARC Domain Alignment Requirements
Agar pengecekan validasi DMARC dapat lulus, DMARC memerlukan alignment domain sebagai berikut:
Untuk SPF, RFC5322.From domain dan Return-Path domain harus dalam alignment
Untuk DKIM, RFC5322.From domain dan DKIM d= domain harus dalam alignment
Alignment ini bisa relaxed atau strict, berdasarkan kebijakan yang diterbitkan dari domain pengirim.
Sebelum kita memulai mengatur DMARC untuk domain Anda, kami ingin memastikan bahwa kita berbicara dalam bahasa yang sama. Mari kita mulai dengan mendefinisikan beberapa istilah yang akan kita gunakan di seluruh dokumen ini.
RFC5322.From Domain
RFC5322.From Domain adalah bagian domain dari alamat email yang biasanya dilihat oleh penerima email kita saat sedang dibaca. Dalam contoh berikut, RFC5322.From domain adalah "joesbaitshop.com"
Dari: Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= Domain
DKIM adalah protokol autentikasi yang memungkinkan sebuah domain untuk mengambil tanggung jawab atas sebuah pesan dengan cara yang dapat divalidasi oleh penerima pesan; ini dilakukan dengan penggunaan tanda tangan kriptografi yang dimasukkan ke dalam header pesan saat meninggalkan titik asalnya. Tanda tangan ini secara efektif adalah snapshot dari tampilan pesan pada saat itu, dan penerima dapat menggunakan snapshot ini untuk melihat apakah pesan telah tiba di tujuannya tanpa perubahan. Proses menghasilkan dan memasukkan snapshot ini disebut penandatanganan DKIM, dan domain yang mengambil tanggung jawab untuk pesan dengan menandatanganinya memasukkan namanya ke dalam header dalam tag kunci-nilai sebagai "d=signingDomain", oleh karena itu disebut sebagai DKIM d= domain.
Return-Path Domain
Return-Path domain, kadang-kadang disebut sebagai RFC5321. From Domain atau Mail From domain, adalah domain ke mana bounces dialihkan; ini juga domain di mana pemeriksaan SPF dilakukan selama transaksi email. Domain ini biasanya tidak terlihat oleh penerima kecuali penerima cukup cerdas untuk melihat semua header dalam pesan yang diberikan.
Secara default, semua email yang dikirim melalui bird.com akan memiliki birdmail.com sebagai Return-Path domainnya, seperti dalam contoh berikut:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Namun, agar DMARC bekerja untuk domain Anda, Anda ingin memanfaatkan domain bounce kustom, yang akan berakhir dengan domain yang sama seperti domain pengirim Anda, misalnya, bounces.yourdomain.com saat menggunakan yourdomain.com sebagai domain pengirim Anda.
Organizational Domain
Istilah "Organizational Domain" mengacu pada domain yang diserahkan ke registrar untuk membuat kehadiran domain di internet. Untuk Bird, domain organisasi kami adalah bird.com dan birdmail.com.
Domain Alignment
Istilah terakhir untuk dipahami mengenai DMARC adalah "Domain Alignment," dan ini datang dalam dua varian: "relaxed" dan "strict."
Relaxed Domain Alignment
Dua domain dikatakan memiliki alignment domain yang relaxed ketika Organizational Domain mereka sama. Misalnya, a.mail.bird.com dan b.foo.bird.com memiliki alignment domain yang relaxed karena Organizational Domain yang sama, yaitu bird.com.
Strict Domain Alignment
Dua domain dikatakan dalam alignment domain yang strict jika dan hanya jika mereka identik. Jadi, foo.bird.com dan foo.bird.com adalah dalam alignment strict, karena dua domain tersebut identik. Di sisi lain, foo.bird.com dan bar.foo.bird.com hanya dalam alignment relaxed.
DMARC Domain Alignment Requirements
Agar pengecekan validasi DMARC dapat lulus, DMARC memerlukan alignment domain sebagai berikut:
Untuk SPF, RFC5322.From domain dan Return-Path domain harus dalam alignment
Untuk DKIM, RFC5322.From domain dan DKIM d= domain harus dalam alignment
Alignment ini bisa relaxed atau strict, berdasarkan kebijakan yang diterbitkan dari domain pengirim.
Cara DMARC Bekerja untuk Melindungi Reputasi Email Anda
Ketika kita berbicara tentang penyedia kotak surat atau domain lain yang “memeriksa DMARC”, atau “memvalidasi DMARC”, atau “menerapkan kebijakan DMARC”, yang kita maksud adalah bahwa domain yang menerima pesan melakukan langkah-langkah berikut:
Menemukan domain RFC5322.From dari pesan
Mencari kebijakan DMARC domain tersebut di DNS
Melakukan validasi DKIM Signature
Melakukan Validasi SPF
Memeriksa keselarasan domain
Menerapkan kebijakan DMARC
Agar sebuah pesan lolos validasi DMARC, pesan tersebut harus lolos dari salah satu dari dua pemeriksaan otentikasi dan keselarasan. Jadi, sebuah pesan akan lolos validasi DMARC jika salah satu dari berikut ini benar:
Pesan tersebut lolos pemeriksaan SPF dan domain RFC5322.From dan domain Return-Path selaras, atau
Pesan tersebut lolos validasi DKIM dan domain RFC5322.From dan domain DKIM d= selaras, atau
Keduanya di atas benar
Ketika kita berbicara tentang penyedia kotak surat atau domain lain yang “memeriksa DMARC”, atau “memvalidasi DMARC”, atau “menerapkan kebijakan DMARC”, yang kita maksud adalah bahwa domain yang menerima pesan melakukan langkah-langkah berikut:
Menemukan domain RFC5322.From dari pesan
Mencari kebijakan DMARC domain tersebut di DNS
Melakukan validasi DKIM Signature
Melakukan Validasi SPF
Memeriksa keselarasan domain
Menerapkan kebijakan DMARC
Agar sebuah pesan lolos validasi DMARC, pesan tersebut harus lolos dari salah satu dari dua pemeriksaan otentikasi dan keselarasan. Jadi, sebuah pesan akan lolos validasi DMARC jika salah satu dari berikut ini benar:
Pesan tersebut lolos pemeriksaan SPF dan domain RFC5322.From dan domain Return-Path selaras, atau
Pesan tersebut lolos validasi DKIM dan domain RFC5322.From dan domain DKIM d= selaras, atau
Keduanya di atas benar
Ketika kita berbicara tentang penyedia kotak surat atau domain lain yang “memeriksa DMARC”, atau “memvalidasi DMARC”, atau “menerapkan kebijakan DMARC”, yang kita maksud adalah bahwa domain yang menerima pesan melakukan langkah-langkah berikut:
Menemukan domain RFC5322.From dari pesan
Mencari kebijakan DMARC domain tersebut di DNS
Melakukan validasi DKIM Signature
Melakukan Validasi SPF
Memeriksa keselarasan domain
Menerapkan kebijakan DMARC
Agar sebuah pesan lolos validasi DMARC, pesan tersebut harus lolos dari salah satu dari dua pemeriksaan otentikasi dan keselarasan. Jadi, sebuah pesan akan lolos validasi DMARC jika salah satu dari berikut ini benar:
Pesan tersebut lolos pemeriksaan SPF dan domain RFC5322.From dan domain Return-Path selaras, atau
Pesan tersebut lolos validasi DKIM dan domain RFC5322.From dan domain DKIM d= selaras, atau
Keduanya di atas benar
Membuat DMARC Bekerja untuk Domain Anda
Sekarang setelah kami menjelaskan mekanisme DMARC, mari kita bahas tentang cara membuat DMARC bekerja untuk kita, yang melibatkan tiga langkah berikut:
Membuat persiapan untuk menerima laporan DMARC
Memutuskan kebijakan DMARC apa yang akan digunakan untuk domain Anda
Menerbitkan catatan DMARC Anda
Kami akan membahas masing-masing detail di bawah ini, tetapi kami akan memberi tahu Anda langsung bahwa langkah 1 di atas akan menghabiskan sekitar 95% dari waktu persiapan Anda.
Sekarang setelah kami menjelaskan mekanisme DMARC, mari kita bahas tentang cara membuat DMARC bekerja untuk kita, yang melibatkan tiga langkah berikut:
Membuat persiapan untuk menerima laporan DMARC
Memutuskan kebijakan DMARC apa yang akan digunakan untuk domain Anda
Menerbitkan catatan DMARC Anda
Kami akan membahas masing-masing detail di bawah ini, tetapi kami akan memberi tahu Anda langsung bahwa langkah 1 di atas akan menghabiskan sekitar 95% dari waktu persiapan Anda.
Sekarang setelah kami menjelaskan mekanisme DMARC, mari kita bahas tentang cara membuat DMARC bekerja untuk kita, yang melibatkan tiga langkah berikut:
Membuat persiapan untuk menerima laporan DMARC
Memutuskan kebijakan DMARC apa yang akan digunakan untuk domain Anda
Menerbitkan catatan DMARC Anda
Kami akan membahas masing-masing detail di bawah ini, tetapi kami akan memberi tahu Anda langsung bahwa langkah 1 di atas akan menghabiskan sekitar 95% dari waktu persiapan Anda.
Menyiapkan untuk Menerima Laporan DMARC
Setiap domain yang menerbitkan kebijakan DMARC harus terlebih dahulu bersiap untuk menerima laporan terkait domainnya. Laporan ini akan dihasilkan oleh domain mana pun yang melakukan validasi DMARC dan melihat email yang mengklaim berasal dari domain kami, dan akan dikirimkan kepada kami setidaknya setiap hari. Laporan akan datang dalam dua format:
Laporan agregat, yang merupakan dokumen XML yang menunjukkan data statistik tentang seberapa banyak email yang dilihat pelapor dari setiap sumber, hasil autentikasinya, dan bagaimana pesan tersebut diperlakukan oleh pelapor. Laporan agregat dirancang untuk diurai mesin, dengan data mereka disimpan di suatu tempat untuk memungkinkan analisis lalu lintas keseluruhan, audit aliran pesan domain kami, dan mungkin identifikasi tren dalam sumber email yang tidak terautentikasi dan berpotensi menipu.
Laporan forensik, yang merupakan salinan individu dari pesan yang gagal autentikasi, masing-masing terlampir dalam sebuah pesan email penuh menggunakan format yang disebut AFRF. Laporan forensik seharusnya berisi header lengkap dan isi pesan, tetapi banyak pelapor menghapus atau menyembunyikan beberapa informasi karena masalah privasi. Meskipun demikian, laporan forensik masih bisa berguna baik untuk memecahkan masalah autentikasi domain kami sendiri dan untuk mengidentifikasi, dari URI dalam isi pesan, domain dan situs web jahat yang digunakan untuk menipu pelanggan pemilik domain kami.
Persiapan untuk menerima laporan-laporan ini melibatkan pertama-tama membuat dua kotak surat dalam domain kami untuk menangani laporan ini, seperti agg_reports@ourdomain.com dan afrf_reports@ourdomain.com. Catat bahwa nama kotak surat tersebut sepenuhnya sewenang-wenang, dan tidak ada persyaratan untuk penamaan bagian lokal dari kotak surat; kami bebas memilih nama apa pun yang kami inginkan, tetapi tetap pisahkan keduanya untuk memudahkan pemrosesan.
Setelah nama kotak surat dipilih dan dibuat di domain kami, hal berikutnya yang harus dilakukan di sini adalah meletakkan alat untuk membaca kotak surat ini dan memanfaatkan data tersebut, terutama laporan data agregat, yang sekali lagi dirancang untuk diurai mesin, bukan dibaca manusia. Laporan forensik, di sisi lain, mungkin dapat dikelola hanya dengan membacanya sendiri, tetapi kemampuan kami untuk melakukannya akan bergantung pada pemahaman klien email kami tentang cara menampilkan pesan dalam format AFRF dan pada volume laporan yang kami terima.
Meskipun mungkin bagi kami untuk membuat alat kami sendiri untuk memproses laporan DMARC, sampai saat Bird menyediakan layanan semacam itu untuk pelanggan bird.com (sesuatu yang kami pertimbangkan, tetapi belum menjanjikan), kami merekomendasikan agar kami menggunakan alat yang sudah tersedia untuk tugas tersebut.
Setiap domain yang menerbitkan kebijakan DMARC harus terlebih dahulu bersiap untuk menerima laporan terkait domainnya. Laporan ini akan dihasilkan oleh domain mana pun yang melakukan validasi DMARC dan melihat email yang mengklaim berasal dari domain kami, dan akan dikirimkan kepada kami setidaknya setiap hari. Laporan akan datang dalam dua format:
Laporan agregat, yang merupakan dokumen XML yang menunjukkan data statistik tentang seberapa banyak email yang dilihat pelapor dari setiap sumber, hasil autentikasinya, dan bagaimana pesan tersebut diperlakukan oleh pelapor. Laporan agregat dirancang untuk diurai mesin, dengan data mereka disimpan di suatu tempat untuk memungkinkan analisis lalu lintas keseluruhan, audit aliran pesan domain kami, dan mungkin identifikasi tren dalam sumber email yang tidak terautentikasi dan berpotensi menipu.
Laporan forensik, yang merupakan salinan individu dari pesan yang gagal autentikasi, masing-masing terlampir dalam sebuah pesan email penuh menggunakan format yang disebut AFRF. Laporan forensik seharusnya berisi header lengkap dan isi pesan, tetapi banyak pelapor menghapus atau menyembunyikan beberapa informasi karena masalah privasi. Meskipun demikian, laporan forensik masih bisa berguna baik untuk memecahkan masalah autentikasi domain kami sendiri dan untuk mengidentifikasi, dari URI dalam isi pesan, domain dan situs web jahat yang digunakan untuk menipu pelanggan pemilik domain kami.
Persiapan untuk menerima laporan-laporan ini melibatkan pertama-tama membuat dua kotak surat dalam domain kami untuk menangani laporan ini, seperti agg_reports@ourdomain.com dan afrf_reports@ourdomain.com. Catat bahwa nama kotak surat tersebut sepenuhnya sewenang-wenang, dan tidak ada persyaratan untuk penamaan bagian lokal dari kotak surat; kami bebas memilih nama apa pun yang kami inginkan, tetapi tetap pisahkan keduanya untuk memudahkan pemrosesan.
Setelah nama kotak surat dipilih dan dibuat di domain kami, hal berikutnya yang harus dilakukan di sini adalah meletakkan alat untuk membaca kotak surat ini dan memanfaatkan data tersebut, terutama laporan data agregat, yang sekali lagi dirancang untuk diurai mesin, bukan dibaca manusia. Laporan forensik, di sisi lain, mungkin dapat dikelola hanya dengan membacanya sendiri, tetapi kemampuan kami untuk melakukannya akan bergantung pada pemahaman klien email kami tentang cara menampilkan pesan dalam format AFRF dan pada volume laporan yang kami terima.
Meskipun mungkin bagi kami untuk membuat alat kami sendiri untuk memproses laporan DMARC, sampai saat Bird menyediakan layanan semacam itu untuk pelanggan bird.com (sesuatu yang kami pertimbangkan, tetapi belum menjanjikan), kami merekomendasikan agar kami menggunakan alat yang sudah tersedia untuk tugas tersebut.
Setiap domain yang menerbitkan kebijakan DMARC harus terlebih dahulu bersiap untuk menerima laporan terkait domainnya. Laporan ini akan dihasilkan oleh domain mana pun yang melakukan validasi DMARC dan melihat email yang mengklaim berasal dari domain kami, dan akan dikirimkan kepada kami setidaknya setiap hari. Laporan akan datang dalam dua format:
Laporan agregat, yang merupakan dokumen XML yang menunjukkan data statistik tentang seberapa banyak email yang dilihat pelapor dari setiap sumber, hasil autentikasinya, dan bagaimana pesan tersebut diperlakukan oleh pelapor. Laporan agregat dirancang untuk diurai mesin, dengan data mereka disimpan di suatu tempat untuk memungkinkan analisis lalu lintas keseluruhan, audit aliran pesan domain kami, dan mungkin identifikasi tren dalam sumber email yang tidak terautentikasi dan berpotensi menipu.
Laporan forensik, yang merupakan salinan individu dari pesan yang gagal autentikasi, masing-masing terlampir dalam sebuah pesan email penuh menggunakan format yang disebut AFRF. Laporan forensik seharusnya berisi header lengkap dan isi pesan, tetapi banyak pelapor menghapus atau menyembunyikan beberapa informasi karena masalah privasi. Meskipun demikian, laporan forensik masih bisa berguna baik untuk memecahkan masalah autentikasi domain kami sendiri dan untuk mengidentifikasi, dari URI dalam isi pesan, domain dan situs web jahat yang digunakan untuk menipu pelanggan pemilik domain kami.
Persiapan untuk menerima laporan-laporan ini melibatkan pertama-tama membuat dua kotak surat dalam domain kami untuk menangani laporan ini, seperti agg_reports@ourdomain.com dan afrf_reports@ourdomain.com. Catat bahwa nama kotak surat tersebut sepenuhnya sewenang-wenang, dan tidak ada persyaratan untuk penamaan bagian lokal dari kotak surat; kami bebas memilih nama apa pun yang kami inginkan, tetapi tetap pisahkan keduanya untuk memudahkan pemrosesan.
Setelah nama kotak surat dipilih dan dibuat di domain kami, hal berikutnya yang harus dilakukan di sini adalah meletakkan alat untuk membaca kotak surat ini dan memanfaatkan data tersebut, terutama laporan data agregat, yang sekali lagi dirancang untuk diurai mesin, bukan dibaca manusia. Laporan forensik, di sisi lain, mungkin dapat dikelola hanya dengan membacanya sendiri, tetapi kemampuan kami untuk melakukannya akan bergantung pada pemahaman klien email kami tentang cara menampilkan pesan dalam format AFRF dan pada volume laporan yang kami terima.
Meskipun mungkin bagi kami untuk membuat alat kami sendiri untuk memproses laporan DMARC, sampai saat Bird menyediakan layanan semacam itu untuk pelanggan bird.com (sesuatu yang kami pertimbangkan, tetapi belum menjanjikan), kami merekomendasikan agar kami menggunakan alat yang sudah tersedia untuk tugas tersebut.
Kebijakan DMARC Mana yang Digunakan
Spesifikasi DMARC menyediakan tiga pilihan bagi pemilik domain untuk menentukan perlakuan yang mereka inginkan terhadap surat yang gagal dalam pemeriksaan validasi DMARC. Pilihannya adalah:
none, yang berarti perlakukan surat tersebut sama seperti akan diperlakukan tanpa adanya pemeriksaan validasi DMARC
quarantine, yang berarti terima surat tersebut tetapi tempatkan di tempat selain Inbox penerima (biasanya di folder spam)
reject, yang berarti tolak pesan tersebut secara langsung
Penting untuk diingat bahwa pemilik domain hanya dapat meminta perlakuan seperti itu dalam catatan DMARC mereka; tergantung pada penerima pesan untuk memutuskan apakah akan mengikuti kebijakan yang diminta atau tidak. Beberapa akan melakukannya, sementara yang lain mungkin sedikit lebih lunak dalam menerapkan kebijakan, seperti hanya menempatkan surat di folder spam ketika kebijakan domainnya adalah reject.
Kami merekomendasikan kepada semua pelanggan kami bahwa mereka memulai dengan kebijakan none, sekadar untuk aman. Meskipun kami yakin dengan kemampuan kami untuk mengautentikasi surat Anda dengan benar melalui penandatanganan DKIM, tetap terbaik untuk meluangkan waktu memeriksa laporan tentang domain Anda sebelum semakin agresif dengan kebijakan DMARC Anda.
Spesifikasi DMARC menyediakan tiga pilihan bagi pemilik domain untuk menentukan perlakuan yang mereka inginkan terhadap surat yang gagal dalam pemeriksaan validasi DMARC. Pilihannya adalah:
none, yang berarti perlakukan surat tersebut sama seperti akan diperlakukan tanpa adanya pemeriksaan validasi DMARC
quarantine, yang berarti terima surat tersebut tetapi tempatkan di tempat selain Inbox penerima (biasanya di folder spam)
reject, yang berarti tolak pesan tersebut secara langsung
Penting untuk diingat bahwa pemilik domain hanya dapat meminta perlakuan seperti itu dalam catatan DMARC mereka; tergantung pada penerima pesan untuk memutuskan apakah akan mengikuti kebijakan yang diminta atau tidak. Beberapa akan melakukannya, sementara yang lain mungkin sedikit lebih lunak dalam menerapkan kebijakan, seperti hanya menempatkan surat di folder spam ketika kebijakan domainnya adalah reject.
Kami merekomendasikan kepada semua pelanggan kami bahwa mereka memulai dengan kebijakan none, sekadar untuk aman. Meskipun kami yakin dengan kemampuan kami untuk mengautentikasi surat Anda dengan benar melalui penandatanganan DKIM, tetap terbaik untuk meluangkan waktu memeriksa laporan tentang domain Anda sebelum semakin agresif dengan kebijakan DMARC Anda.
Spesifikasi DMARC menyediakan tiga pilihan bagi pemilik domain untuk menentukan perlakuan yang mereka inginkan terhadap surat yang gagal dalam pemeriksaan validasi DMARC. Pilihannya adalah:
none, yang berarti perlakukan surat tersebut sama seperti akan diperlakukan tanpa adanya pemeriksaan validasi DMARC
quarantine, yang berarti terima surat tersebut tetapi tempatkan di tempat selain Inbox penerima (biasanya di folder spam)
reject, yang berarti tolak pesan tersebut secara langsung
Penting untuk diingat bahwa pemilik domain hanya dapat meminta perlakuan seperti itu dalam catatan DMARC mereka; tergantung pada penerima pesan untuk memutuskan apakah akan mengikuti kebijakan yang diminta atau tidak. Beberapa akan melakukannya, sementara yang lain mungkin sedikit lebih lunak dalam menerapkan kebijakan, seperti hanya menempatkan surat di folder spam ketika kebijakan domainnya adalah reject.
Kami merekomendasikan kepada semua pelanggan kami bahwa mereka memulai dengan kebijakan none, sekadar untuk aman. Meskipun kami yakin dengan kemampuan kami untuk mengautentikasi surat Anda dengan benar melalui penandatanganan DKIM, tetap terbaik untuk meluangkan waktu memeriksa laporan tentang domain Anda sebelum semakin agresif dengan kebijakan DMARC Anda.
Mempublikasikan Kebijakan DMARC Anda
Kebijakan DMARC dari sebuah domain diumumkan dengan menerbitkan catatan DNS TXT pada tempat tertentu di namespace DNS, yaitu “_dmarc.domainname.tld” (perhatikan garis bawah pada awal). Catatan kebijakan DMARC dasar untuk domain contoh kita sebelumnya, joesbaitshop.com, mungkin terlihat seperti ini:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
Menganalisis catatan ini, kita memiliki:
v=DMARC1 menentukan versi DMARC (1 adalah satu-satunya pilihan saat ini)
p=none menentukan perlakuan yang diinginkan, atau kebijakan DMARC
rua=mailto:agg_reports@joesbait.com adalah kotak surat tempat laporan agregat harus dikirimkan
ruf=mailto:afrf_reports@joesbait.com adalah kotak surat tempat laporan forensik harus dikirimkan
pct=100 adalah persentase email yang ingin diterapkan oleh pemilik domain terhadap kebijakannya. Domain yang baru memulai dengan DMARC, terutama yang kemungkinan akan menghasilkan volume laporan yang tinggi, mungkin ingin memulai dengan angka yang jauh lebih rendah di sini untuk melihat bagaimana proses penanganan laporan mereka dapat menghadapi beban.
Ada opsi konfigurasi lain yang tersedia bagi pemilik domain untuk digunakan dalam catatan kebijakan DMARC mereka juga, tetapi tips yang telah kami berikan harus menjadi awal yang baik.
Kebijakan DMARC dari sebuah domain diumumkan dengan menerbitkan catatan DNS TXT pada tempat tertentu di namespace DNS, yaitu “_dmarc.domainname.tld” (perhatikan garis bawah pada awal). Catatan kebijakan DMARC dasar untuk domain contoh kita sebelumnya, joesbaitshop.com, mungkin terlihat seperti ini:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
Menganalisis catatan ini, kita memiliki:
v=DMARC1 menentukan versi DMARC (1 adalah satu-satunya pilihan saat ini)
p=none menentukan perlakuan yang diinginkan, atau kebijakan DMARC
rua=mailto:agg_reports@joesbait.com adalah kotak surat tempat laporan agregat harus dikirimkan
ruf=mailto:afrf_reports@joesbait.com adalah kotak surat tempat laporan forensik harus dikirimkan
pct=100 adalah persentase email yang ingin diterapkan oleh pemilik domain terhadap kebijakannya. Domain yang baru memulai dengan DMARC, terutama yang kemungkinan akan menghasilkan volume laporan yang tinggi, mungkin ingin memulai dengan angka yang jauh lebih rendah di sini untuk melihat bagaimana proses penanganan laporan mereka dapat menghadapi beban.
Ada opsi konfigurasi lain yang tersedia bagi pemilik domain untuk digunakan dalam catatan kebijakan DMARC mereka juga, tetapi tips yang telah kami berikan harus menjadi awal yang baik.
Kebijakan DMARC dari sebuah domain diumumkan dengan menerbitkan catatan DNS TXT pada tempat tertentu di namespace DNS, yaitu “_dmarc.domainname.tld” (perhatikan garis bawah pada awal). Catatan kebijakan DMARC dasar untuk domain contoh kita sebelumnya, joesbaitshop.com, mungkin terlihat seperti ini:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
Menganalisis catatan ini, kita memiliki:
v=DMARC1 menentukan versi DMARC (1 adalah satu-satunya pilihan saat ini)
p=none menentukan perlakuan yang diinginkan, atau kebijakan DMARC
rua=mailto:agg_reports@joesbait.com adalah kotak surat tempat laporan agregat harus dikirimkan
ruf=mailto:afrf_reports@joesbait.com adalah kotak surat tempat laporan forensik harus dikirimkan
pct=100 adalah persentase email yang ingin diterapkan oleh pemilik domain terhadap kebijakannya. Domain yang baru memulai dengan DMARC, terutama yang kemungkinan akan menghasilkan volume laporan yang tinggi, mungkin ingin memulai dengan angka yang jauh lebih rendah di sini untuk melihat bagaimana proses penanganan laporan mereka dapat menghadapi beban.
Ada opsi konfigurasi lain yang tersedia bagi pemilik domain untuk digunakan dalam catatan kebijakan DMARC mereka juga, tetapi tips yang telah kami berikan harus menjadi awal yang baik.
Ringkasan
Ada banyak yang harus dibongkar dalam informasi di atas! Kami harap Anda menemukan panduan cara membuat catatan kebijakan DMARC bermanfaat. Kami juga berharap penjelasan kami tentang mengapa DMARC penting membantu menjelaskan mengapa Anda harus mulai menggunakan alat penting ini untuk melindungi reputasi email Anda.
Tentu saja, ini bukanlah dokumen yang lengkap atau otoritatif tentang subjek ini. Jika Anda ingin mendalami lebih dalam atau membutuhkan lebih banyak bantuan, tempat yang bagus untuk memulai adalah FAQ resmi DMARC. Dan, tak perlu dikatakan lagi bahwa tim dukungan Bird siap membantu Anda mengonfigurasi akun Bird Anda untuk DMARC juga.
Terima kasih telah membaca—dan mulai lindungi domain Anda dengan DMARC hari ini!
Ada banyak yang harus dibongkar dalam informasi di atas! Kami harap Anda menemukan panduan cara membuat catatan kebijakan DMARC bermanfaat. Kami juga berharap penjelasan kami tentang mengapa DMARC penting membantu menjelaskan mengapa Anda harus mulai menggunakan alat penting ini untuk melindungi reputasi email Anda.
Tentu saja, ini bukanlah dokumen yang lengkap atau otoritatif tentang subjek ini. Jika Anda ingin mendalami lebih dalam atau membutuhkan lebih banyak bantuan, tempat yang bagus untuk memulai adalah FAQ resmi DMARC. Dan, tak perlu dikatakan lagi bahwa tim dukungan Bird siap membantu Anda mengonfigurasi akun Bird Anda untuk DMARC juga.
Terima kasih telah membaca—dan mulai lindungi domain Anda dengan DMARC hari ini!
Ada banyak yang harus dibongkar dalam informasi di atas! Kami harap Anda menemukan panduan cara membuat catatan kebijakan DMARC bermanfaat. Kami juga berharap penjelasan kami tentang mengapa DMARC penting membantu menjelaskan mengapa Anda harus mulai menggunakan alat penting ini untuk melindungi reputasi email Anda.
Tentu saja, ini bukanlah dokumen yang lengkap atau otoritatif tentang subjek ini. Jika Anda ingin mendalami lebih dalam atau membutuhkan lebih banyak bantuan, tempat yang bagus untuk memulai adalah FAQ resmi DMARC. Dan, tak perlu dikatakan lagi bahwa tim dukungan Bird siap membantu Anda mengonfigurasi akun Bird Anda untuk DMARC juga.
Terima kasih telah membaca—dan mulai lindungi domain Anda dengan DMARC hari ini!
