DMARC: Cara Melindungi Reputasi Email Anda
Burung
13 Apr 2016
1 min read
Poin Penting
DMARC membantu melindungi domain Anda dari phishing, spoofing, dan penggunaan email yang tidak sah dengan menerbitkan praktik otentikasi Anda dan meminta penanganan khusus untuk pesan yang gagal.
Ini bekerja bersama dengan SPF dan DKIM untuk memastikan keselarasan domain dan mencegah email yang menipu merusak reputasi pengirim Anda.
Kebijakan DMARC yang kuat mendukung kepercayaan yang lebih tinggi, keterlibatan yang lebih tinggi, dan melindungi domain Anda di masa depan saat ekosistem beralih ke model reputasi berbasis domain.
Pemeriksaan validasi DMARC bergantung pada keselarasan domain antara domain From, domain Return-Path (SPF), dan domain penandatanganan DKIM.
Menyiapkan DMARC memerlukan penerimaan laporan, memahami data agregat vs. forensik, dan mengonfigurasi alat untuk menguraikannya.
Anda mulai dengan kebijakan aman p=none untuk memantau lalu lintas sebelum beralih ke karantina atau tolak.
Menerbitkan catatan DMARC melibatkan pembuatan entri TXT DNS di _dmarc.yourdomain.com dengan kebijakan, alamat pelaporan, dan parameter opsional seperti persentase rollout.
Kotak surat pelaporan yang tepat (agregat + forensik) dan alat penguraian sangat penting untuk memantau kepatuhan, mendeteksi spoofing, dan memastikan keselarasan sudah benar.
DMARC hanya membutuhkan satu dari yang berikut agar dapat lulus: SPF yang selaras atau DKIM yang selaras.
Menerapkan DMARC memperkuat keamanan email dan berperan penting dalam integritas merek, kepercayaan, dan pengiriman jangka panjang.
Sorotan Tanya jawab
Apa itu DMARC dan mengapa itu penting?
DMARC (Domain-based Message Authentication, Reporting, and Conformance) adalah kebijakan yang dipublikasikan melalui DNS yang melindungi domain Anda dari penipuan dan phishing dengan menerapkan keselarasan domain dan memungkinkan visibilitas melalui pelaporan.
Apakah DMARC merupakan protokol otentikasi?
No. DMARC bukan autentikasi itu sendiri—ini bergantung pada SPF dan DKIM untuk mengautentikasi surat dan menggunakan kebijakan + pelaporan untuk mengontrol bagaimana server penerima menangani kegagalan.
Apa yang diperiksa oleh DMARC?
Ini memverifikasi:
Autentikasi SPF + penyelarasan
Autentikasi DKIM + penyelarasan
Seorang pengirim hanya perlu salah satu dari ini agar DMARC berhasil.
Apa itu "penyelarasan domain"?
Ini adalah persyaratan bahwa domain From yang terlihat cocok (tegas) atau berbagi domain organisasi yang sama (relaksasi) dengan salah satu domain SPF Return-Path atau domain penandatanganan DKIM.
Mengapa DMARC meningkatkan keterkiriman?
Karena penyedia kotak surat lebih mempercayai domain yang terautentikasi dan ter-align. DMARC mencegah pesan yang dipalsukan merusak reputasi Anda dan meningkatkan penempatan di kotak masuk untuk email yang sah.
Apa perbedaan antara laporan DMARC agregat dan forensik?
Laporan agregat (RUA): Ringkasan XML dari hasil autentikasi di seluruh lalu lintas.
Laporan forensik (RUF): Sampel individu dari pesan yang gagal untuk analisis lebih mendalam.
Kotak surat apa yang saya butuhkan sebelum menerbitkan DMARC?
Anda harus membuat dua alamat, seperti:
agg_reports@yourdomain.com (RUA)
afrf_reports@yourdomain.com (RUF)
Ini menjaga aliran laporan terpisah dan lebih mudah untuk diparsing.
Kebijakan DMARC apa yang seharusnya saya mulai?
Selalu mulai dengan p=none. Ini memantau aktivitas otentikasi tanpa memengaruhi pengiriman, memungkinkan Anda untuk mengidentifikasi masalah keselarasan dan upaya penipuan dengan aman.
Apa kebijakan DMARC yang tersedia?
tidak ada: hanya memantau
karantina: kirim pesan yang gagal ke spam
tolak: blokir pesan yang gagal sepenuhnya
Di mana saya menerbitkan catatan DMARC?
Di DNS Anda di:
_dmarc.yourdomain.com
Ini harus menjadi catatan TXT yang menentukan kebijakan, versi, dan titik akhir pelaporan Anda.
Seperti apa bentuk 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 tetap menjadi tanggung jawab penyedia. Kebijakan yang ketat dapat secara signifikan mengurangi upaya phishing yang menggunakan domain Anda.
Dalam pos 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.
Dalam pos 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.
Dalam pos 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.
Alat Efektif untuk Melawan Surat Palsu
Sering disebut dalam napas yang sama dengan protokol autentikasi email SPF dan DKIM, DMARC, atau Domain-based Message Authentication, Reporting, and Conformance, tidaklah menjadi protokol autentikasi itu sendiri. Sebaliknya, tujuan DMARC adalah untuk memungkinkan kami, pemilik domain, melindungi reputasi email kami dengan:
Mengumumkan praktik autentikasi email,
Meminta perlakuan untuk email yang gagal pemeriksaan autentikasi, dan
Meminta laporan tentang email yang mengklaim berasal dari domainnya.
DMARC bisa menjadi alat yang efektif bagi kami dalam melawan email penipuan yang menargetkan nama domain kami (misalnya, phishing dan spoofing), dan dapat meningkatkan kepercayaan yang lebih tinggi di antara penerima kami terhadap email kami. Untuk organisasi yang memerlukan enkripsi end-to-end di luar autentikasi, menerapkan S/MIME dengan metode pengumpulan kunci publik penerima yang efisien memberikan lapisan keamanan tambahan. Kepercayaan yang lebih tinggi ini pada gilirannya, seharusnya menghasilkan keterlibatan yang lebih tinggi dengan email kami, dan email yang dibuka serta menghasilkan klik akan meningkatkan 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 beralih ke IPv6, hampir pasti akan bergeser dari model reputasi berbasis IP ke model reputasi berbasis domain. Reputasi berbasis domain akan memerlukan autentikasi berbasis domain, dan DMARC, bekerja sama dengan DKIM dan SPF, akan membantu domain membangun reputasi berbasis domain jauh sebelum itu mungkin benar-benar diperlukan.
Dalam posting ini, kami akan memberi tahu Anda semua yang perlu Anda ketahui tentang memanfaatkan DMARC untuk melindungi reputasi email Anda dan memberikan Anda petunjuk tentang cara mengaturnya untuk domain Anda.
Sering disebut dalam napas yang sama dengan protokol autentikasi email SPF dan DKIM, DMARC, atau Domain-based Message Authentication, Reporting, and Conformance, tidaklah menjadi protokol autentikasi itu sendiri. Sebaliknya, tujuan DMARC adalah untuk memungkinkan kami, pemilik domain, melindungi reputasi email kami dengan:
Mengumumkan praktik autentikasi email,
Meminta perlakuan untuk email yang gagal pemeriksaan autentikasi, dan
Meminta laporan tentang email yang mengklaim berasal dari domainnya.
DMARC bisa menjadi alat yang efektif bagi kami dalam melawan email penipuan yang menargetkan nama domain kami (misalnya, phishing dan spoofing), dan dapat meningkatkan kepercayaan yang lebih tinggi di antara penerima kami terhadap email kami. Untuk organisasi yang memerlukan enkripsi end-to-end di luar autentikasi, menerapkan S/MIME dengan metode pengumpulan kunci publik penerima yang efisien memberikan lapisan keamanan tambahan. Kepercayaan yang lebih tinggi ini pada gilirannya, seharusnya menghasilkan keterlibatan yang lebih tinggi dengan email kami, dan email yang dibuka serta menghasilkan klik akan meningkatkan 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 beralih ke IPv6, hampir pasti akan bergeser dari model reputasi berbasis IP ke model reputasi berbasis domain. Reputasi berbasis domain akan memerlukan autentikasi berbasis domain, dan DMARC, bekerja sama dengan DKIM dan SPF, akan membantu domain membangun reputasi berbasis domain jauh sebelum itu mungkin benar-benar diperlukan.
Dalam posting ini, kami akan memberi tahu Anda semua yang perlu Anda ketahui tentang memanfaatkan DMARC untuk melindungi reputasi email Anda dan memberikan Anda petunjuk tentang cara mengaturnya untuk domain Anda.
Sering disebut dalam napas yang sama dengan protokol autentikasi email SPF dan DKIM, DMARC, atau Domain-based Message Authentication, Reporting, and Conformance, tidaklah menjadi protokol autentikasi itu sendiri. Sebaliknya, tujuan DMARC adalah untuk memungkinkan kami, pemilik domain, melindungi reputasi email kami dengan:
Mengumumkan praktik autentikasi email,
Meminta perlakuan untuk email yang gagal pemeriksaan autentikasi, dan
Meminta laporan tentang email yang mengklaim berasal dari domainnya.
DMARC bisa menjadi alat yang efektif bagi kami dalam melawan email penipuan yang menargetkan nama domain kami (misalnya, phishing dan spoofing), dan dapat meningkatkan kepercayaan yang lebih tinggi di antara penerima kami terhadap email kami. Untuk organisasi yang memerlukan enkripsi end-to-end di luar autentikasi, menerapkan S/MIME dengan metode pengumpulan kunci publik penerima yang efisien memberikan lapisan keamanan tambahan. Kepercayaan yang lebih tinggi ini pada gilirannya, seharusnya menghasilkan keterlibatan yang lebih tinggi dengan email kami, dan email yang dibuka serta menghasilkan klik akan meningkatkan 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 beralih ke IPv6, hampir pasti akan bergeser dari model reputasi berbasis IP ke model reputasi berbasis domain. Reputasi berbasis domain akan memerlukan autentikasi berbasis domain, dan DMARC, bekerja sama dengan DKIM dan SPF, akan membantu domain membangun reputasi berbasis domain jauh sebelum itu mungkin benar-benar diperlukan.
Dalam posting ini, kami akan memberi tahu Anda semua yang perlu Anda ketahui tentang memanfaatkan DMARC untuk melindungi reputasi email Anda dan memberikan Anda petunjuk tentang cara mengaturnya untuk domain Anda.
Istilah yang Perlu Diketahui
Sebelum kita mulai 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 sepanjang dokumen ini.
Domain RFC5322.From
Domain RFC5322.From adalah bagian domain dari alamat email yang biasanya dilihat oleh penerima email kami saat dibaca. Dalam contoh berikut, domain RFC5322.From adalah “joesbaitshop.com”
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
Domain DKIM d=
DKIM adalah protokol otentikasi yang memungkinkan sebuah domain untuk bertanggung jawab atas sebuah pesan dengan cara yang dapat divalidasi oleh penerima pesan; ini dilakukan melalui penggunaan tanda tangan kriptografi yang dimasukkan ke dalam header pesan saat meninggalkan titik asalnya. Tanda tangan ini secara efektif adalah cuplikan dari apa yang terlihat oleh pesan pada saat itu, dan penerima dapat menggunakan cuplikan ini untuk melihat apakah pesan telah tiba tanpa perubahan di tujuannya. Proses menghasilkan dan memasukkan cuplikan ini disebut penandatanganan DKIM, dan domain yang bertanggung jawab atas pesan dengan menandatanganinya memasukkan namanya ke dalam header dalam tag kunci-nilai sebagai “d=signingDomain”, sehingga disebut sebagai domain DKIM d=.
Domain Return-Path
Domain Return-Path, terkadang disebut sebagai DomainRFC5321. From atau domain Mail From, adalah domain ke mana pengembalian diarahkan; itu juga adalah domain tempat pemeriksaan SPF dilakukan selama transaksi email. Domain ini biasanya tidak dilihat oleh penerima kecuali jika penerima cukup cerdas untuk melihat semua header dalam sebuah pesan tertentu.
Secara default, semua email yang dikirim melalui bird.com akan memiliki birdmail.com sebagai domain Return-Path-nya, seperti dalam contoh berikut:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Namun, untuk membuat DMARC bekerja untuk domain Anda, Anda ingin memanfaatkan domain pengembalian kustom, yang akan berakhir dengan domain yang sama dengan domain pengirim Anda, misalnya, bounces.yourdomain.com ketika menggunakan yourdomain.com sebagai domain pengirim Anda.
Domain Organisasi
Istilah “Domain Organisasi” mengacu pada domain yang diajukan kepada registrar untuk membuat keberadaan domain tersebut di internet. Untuk Bird, domain organisasi kami adalah bird.com dan birdmail.com.
Penyelarasan Domain
Istilah terakhir untuk dipahami terkait DMARC adalah “Penyelarasan Domain,” dan itu hadir dalam dua varian: “relaksasi” dan “ketat.”
Penyelarasan Domain yang Relaks
Setiap dua domain dikatakan memiliki penyelarasan domain yang relaks ketika Domain Organisasi mereka sama. Misalnya, a.mail.bird.com dan b.foo.bird.com memiliki penyelarasan domain yang relaks karena Domain Organisasi mereka yang sama, bird.com.
Penyelarasan Domain yang Ketat
Dua domain dikatakan memiliki penyelarasan domain yang ketat jika dan hanya jika mereka identik. Jadi, foo.bird.com dan foo.bird.com dalam penyelarasan ketat, karena kedua domain tersebut identik. Di sisi lain, foo.bird.com dan bar.foo.bird.com hanya dalam penyelarasan relaks.
Persyaratan Penyelarasan Domain DMARC
Agar pemeriksaan validasi DMARC dapat lulus, DMARC memerlukan adanya penyelarasan domain sebagai berikut:
Untuk SPF, domain RFC5322.From dan domain Return-Path harus dalam penyelarasan
Untuk DKIM, domain RFC5322.From dan domain DKIM d= harus dalam penyelarasan
Penyelarasan dapat bersifat relaks atau ketat, berdasarkan kebijakan yang dipublikasikan dari domain pengirim.
Sebelum kita mulai 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 sepanjang dokumen ini.
Domain RFC5322.From
Domain RFC5322.From adalah bagian domain dari alamat email yang biasanya dilihat oleh penerima email kami saat dibaca. Dalam contoh berikut, domain RFC5322.From adalah “joesbaitshop.com”
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
Domain DKIM d=
DKIM adalah protokol otentikasi yang memungkinkan sebuah domain untuk bertanggung jawab atas sebuah pesan dengan cara yang dapat divalidasi oleh penerima pesan; ini dilakukan melalui penggunaan tanda tangan kriptografi yang dimasukkan ke dalam header pesan saat meninggalkan titik asalnya. Tanda tangan ini secara efektif adalah cuplikan dari apa yang terlihat oleh pesan pada saat itu, dan penerima dapat menggunakan cuplikan ini untuk melihat apakah pesan telah tiba tanpa perubahan di tujuannya. Proses menghasilkan dan memasukkan cuplikan ini disebut penandatanganan DKIM, dan domain yang bertanggung jawab atas pesan dengan menandatanganinya memasukkan namanya ke dalam header dalam tag kunci-nilai sebagai “d=signingDomain”, sehingga disebut sebagai domain DKIM d=.
Domain Return-Path
Domain Return-Path, terkadang disebut sebagai DomainRFC5321. From atau domain Mail From, adalah domain ke mana pengembalian diarahkan; itu juga adalah domain tempat pemeriksaan SPF dilakukan selama transaksi email. Domain ini biasanya tidak dilihat oleh penerima kecuali jika penerima cukup cerdas untuk melihat semua header dalam sebuah pesan tertentu.
Secara default, semua email yang dikirim melalui bird.com akan memiliki birdmail.com sebagai domain Return-Path-nya, seperti dalam contoh berikut:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Namun, untuk membuat DMARC bekerja untuk domain Anda, Anda ingin memanfaatkan domain pengembalian kustom, yang akan berakhir dengan domain yang sama dengan domain pengirim Anda, misalnya, bounces.yourdomain.com ketika menggunakan yourdomain.com sebagai domain pengirim Anda.
Domain Organisasi
Istilah “Domain Organisasi” mengacu pada domain yang diajukan kepada registrar untuk membuat keberadaan domain tersebut di internet. Untuk Bird, domain organisasi kami adalah bird.com dan birdmail.com.
Penyelarasan Domain
Istilah terakhir untuk dipahami terkait DMARC adalah “Penyelarasan Domain,” dan itu hadir dalam dua varian: “relaksasi” dan “ketat.”
Penyelarasan Domain yang Relaks
Setiap dua domain dikatakan memiliki penyelarasan domain yang relaks ketika Domain Organisasi mereka sama. Misalnya, a.mail.bird.com dan b.foo.bird.com memiliki penyelarasan domain yang relaks karena Domain Organisasi mereka yang sama, bird.com.
Penyelarasan Domain yang Ketat
Dua domain dikatakan memiliki penyelarasan domain yang ketat jika dan hanya jika mereka identik. Jadi, foo.bird.com dan foo.bird.com dalam penyelarasan ketat, karena kedua domain tersebut identik. Di sisi lain, foo.bird.com dan bar.foo.bird.com hanya dalam penyelarasan relaks.
Persyaratan Penyelarasan Domain DMARC
Agar pemeriksaan validasi DMARC dapat lulus, DMARC memerlukan adanya penyelarasan domain sebagai berikut:
Untuk SPF, domain RFC5322.From dan domain Return-Path harus dalam penyelarasan
Untuk DKIM, domain RFC5322.From dan domain DKIM d= harus dalam penyelarasan
Penyelarasan dapat bersifat relaks atau ketat, berdasarkan kebijakan yang dipublikasikan dari domain pengirim.
Sebelum kita mulai 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 sepanjang dokumen ini.
Domain RFC5322.From
Domain RFC5322.From adalah bagian domain dari alamat email yang biasanya dilihat oleh penerima email kami saat dibaca. Dalam contoh berikut, domain RFC5322.From adalah “joesbaitshop.com”
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
Domain DKIM d=
DKIM adalah protokol otentikasi yang memungkinkan sebuah domain untuk bertanggung jawab atas sebuah pesan dengan cara yang dapat divalidasi oleh penerima pesan; ini dilakukan melalui penggunaan tanda tangan kriptografi yang dimasukkan ke dalam header pesan saat meninggalkan titik asalnya. Tanda tangan ini secara efektif adalah cuplikan dari apa yang terlihat oleh pesan pada saat itu, dan penerima dapat menggunakan cuplikan ini untuk melihat apakah pesan telah tiba tanpa perubahan di tujuannya. Proses menghasilkan dan memasukkan cuplikan ini disebut penandatanganan DKIM, dan domain yang bertanggung jawab atas pesan dengan menandatanganinya memasukkan namanya ke dalam header dalam tag kunci-nilai sebagai “d=signingDomain”, sehingga disebut sebagai domain DKIM d=.
Domain Return-Path
Domain Return-Path, terkadang disebut sebagai DomainRFC5321. From atau domain Mail From, adalah domain ke mana pengembalian diarahkan; itu juga adalah domain tempat pemeriksaan SPF dilakukan selama transaksi email. Domain ini biasanya tidak dilihat oleh penerima kecuali jika penerima cukup cerdas untuk melihat semua header dalam sebuah pesan tertentu.
Secara default, semua email yang dikirim melalui bird.com akan memiliki birdmail.com sebagai domain Return-Path-nya, seperti dalam contoh berikut:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Namun, untuk membuat DMARC bekerja untuk domain Anda, Anda ingin memanfaatkan domain pengembalian kustom, yang akan berakhir dengan domain yang sama dengan domain pengirim Anda, misalnya, bounces.yourdomain.com ketika menggunakan yourdomain.com sebagai domain pengirim Anda.
Domain Organisasi
Istilah “Domain Organisasi” mengacu pada domain yang diajukan kepada registrar untuk membuat keberadaan domain tersebut di internet. Untuk Bird, domain organisasi kami adalah bird.com dan birdmail.com.
Penyelarasan Domain
Istilah terakhir untuk dipahami terkait DMARC adalah “Penyelarasan Domain,” dan itu hadir dalam dua varian: “relaksasi” dan “ketat.”
Penyelarasan Domain yang Relaks
Setiap dua domain dikatakan memiliki penyelarasan domain yang relaks ketika Domain Organisasi mereka sama. Misalnya, a.mail.bird.com dan b.foo.bird.com memiliki penyelarasan domain yang relaks karena Domain Organisasi mereka yang sama, bird.com.
Penyelarasan Domain yang Ketat
Dua domain dikatakan memiliki penyelarasan domain yang ketat jika dan hanya jika mereka identik. Jadi, foo.bird.com dan foo.bird.com dalam penyelarasan ketat, karena kedua domain tersebut identik. Di sisi lain, foo.bird.com dan bar.foo.bird.com hanya dalam penyelarasan relaks.
Persyaratan Penyelarasan Domain DMARC
Agar pemeriksaan validasi DMARC dapat lulus, DMARC memerlukan adanya penyelarasan domain sebagai berikut:
Untuk SPF, domain RFC5322.From dan domain Return-Path harus dalam penyelarasan
Untuk DKIM, domain RFC5322.From dan domain DKIM d= harus dalam penyelarasan
Penyelarasan dapat bersifat relaks atau ketat, berdasarkan kebijakan yang dipublikasikan dari domain pengirim.
Bagaimana 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 kami maksud adalah bahwa domain yang menerima pesan melakukan langkah-langkah berikut:
Menentukan domain RFC5322.From pesan
Mencari kebijakan DMARC domain tersebut di DNS
Melakukan validasi tanda tangan DKIM
Melakukan validasi SPF
Memeriksa keselarasan domain
Menerapkan kebijakan DMARC
Agar suatu pesan dapat lolos validasi DMARC, pesan tersebut harus lolos salah satu dari dua pemeriksaan otentikasi dan keselarasan. Jadi, pesan akan lolos validasi DMARC jika salah satu dari yang berikut ini benar:
Pesan lolos pemeriksaan SPF dan domain RFC5322.From dan domain Return-Path selaras, atau
Pesan lolos validasi DKIM dan domain RFC5322.From dan domain DKIM d= selaras, atau
Keduanya di atas adalah benar
Ikhtisar Jalur Validasi DMARC
Jalur otentikasi | Domain yang dibandingkan | Keselarasan yang dibutuhkan | Kondisi lolos DMARC |
|---|---|---|---|
SPF | RFC5322.From ↔ Return-Path | Relaksasi atau ketat | SPF lolos dan domain selaras |
DKIM | RFC5322.From ↔ DKIM d= | Relaksasi atau ketat | DKIM lolos dan domain selaras |
SPF + DKIM | Keduanya di atas | Salah satu selaras | Satu atau kedua pemeriksaan yang selaras lolos |
Ketika kita berbicara tentang penyedia kotak surat atau domain lain yang “memeriksa DMARC”, atau “memvalidasi DMARC”, atau “menerapkan kebijakan DMARC”, yang kami maksud adalah bahwa domain yang menerima pesan melakukan langkah-langkah berikut:
Menentukan domain RFC5322.From pesan
Mencari kebijakan DMARC domain tersebut di DNS
Melakukan validasi tanda tangan DKIM
Melakukan validasi SPF
Memeriksa keselarasan domain
Menerapkan kebijakan DMARC
Agar suatu pesan dapat lolos validasi DMARC, pesan tersebut harus lolos salah satu dari dua pemeriksaan otentikasi dan keselarasan. Jadi, pesan akan lolos validasi DMARC jika salah satu dari yang berikut ini benar:
Pesan lolos pemeriksaan SPF dan domain RFC5322.From dan domain Return-Path selaras, atau
Pesan lolos validasi DKIM dan domain RFC5322.From dan domain DKIM d= selaras, atau
Keduanya di atas adalah benar
Ikhtisar Jalur Validasi DMARC
Jalur otentikasi | Domain yang dibandingkan | Keselarasan yang dibutuhkan | Kondisi lolos DMARC |
|---|---|---|---|
SPF | RFC5322.From ↔ Return-Path | Relaksasi atau ketat | SPF lolos dan domain selaras |
DKIM | RFC5322.From ↔ DKIM d= | Relaksasi atau ketat | DKIM lolos dan domain selaras |
SPF + DKIM | Keduanya di atas | Salah satu selaras | Satu atau kedua pemeriksaan yang selaras lolos |
Ketika kita berbicara tentang penyedia kotak surat atau domain lain yang “memeriksa DMARC”, atau “memvalidasi DMARC”, atau “menerapkan kebijakan DMARC”, yang kami maksud adalah bahwa domain yang menerima pesan melakukan langkah-langkah berikut:
Menentukan domain RFC5322.From pesan
Mencari kebijakan DMARC domain tersebut di DNS
Melakukan validasi tanda tangan DKIM
Melakukan validasi SPF
Memeriksa keselarasan domain
Menerapkan kebijakan DMARC
Agar suatu pesan dapat lolos validasi DMARC, pesan tersebut harus lolos salah satu dari dua pemeriksaan otentikasi dan keselarasan. Jadi, pesan akan lolos validasi DMARC jika salah satu dari yang berikut ini benar:
Pesan lolos pemeriksaan SPF dan domain RFC5322.From dan domain Return-Path selaras, atau
Pesan lolos validasi DKIM dan domain RFC5322.From dan domain DKIM d= selaras, atau
Keduanya di atas adalah benar
Ikhtisar Jalur Validasi DMARC
Jalur otentikasi | Domain yang dibandingkan | Keselarasan yang dibutuhkan | Kondisi lolos DMARC |
|---|---|---|---|
SPF | RFC5322.From ↔ Return-Path | Relaksasi atau ketat | SPF lolos dan domain selaras |
DKIM | RFC5322.From ↔ DKIM d= | Relaksasi atau ketat | DKIM lolos dan domain selaras |
SPF + DKIM | Keduanya di atas | Salah satu selaras | Satu atau kedua pemeriksaan yang selaras lolos |
Membuat DMARC Bekerja untuk Domain Anda
Sekarang setelah kita menjelaskan mekanika DMARC, mari kita bicarakan tentang bagaimana membuat DMARC bekerja untuk kita, yang melibatkan tiga langkah berikut:
Mempersiapkan untuk menerima laporan DMARC
Memutuskan kebijakan DMARC yang akan digunakan untuk domain Anda
menerbitkan catatan DMARC Anda
Kami akan membahas masing-masing ini secara rinci di bawah, tetapi kami akan memberi tahu Anda langsung bahwa langkah 1 di atas akan menghabiskan sekitar 95% dari waktu persiapan Anda.
Sekarang setelah kita menjelaskan mekanika DMARC, mari kita bicarakan tentang bagaimana membuat DMARC bekerja untuk kita, yang melibatkan tiga langkah berikut:
Mempersiapkan untuk menerima laporan DMARC
Memutuskan kebijakan DMARC yang akan digunakan untuk domain Anda
menerbitkan catatan DMARC Anda
Kami akan membahas masing-masing ini secara rinci di bawah, tetapi kami akan memberi tahu Anda langsung bahwa langkah 1 di atas akan menghabiskan sekitar 95% dari waktu persiapan Anda.
Sekarang setelah kita menjelaskan mekanika DMARC, mari kita bicarakan tentang bagaimana membuat DMARC bekerja untuk kita, yang melibatkan tiga langkah berikut:
Mempersiapkan untuk menerima laporan DMARC
Memutuskan kebijakan DMARC yang akan digunakan untuk domain Anda
menerbitkan catatan DMARC Anda
Kami akan membahas masing-masing ini secara rinci di bawah, tetapi kami akan memberi tahu Anda langsung bahwa langkah 1 di atas akan menghabiskan sekitar 95% dari waktu persiapan Anda.
Mempersiapkan untuk Menerima Laporan DMARC
Setiap domain yang menerbitkan kebijakan DMARC harus terlebih dahulu mempersiapkan diri untuk menerima laporan mengenai domainnya. Laporan ini akan dihasilkan oleh domain mana pun yang melakukan validasi DMARC dan melihat email yang mengaku berasal dari domain kami, dan akan dikirim kepada kami setidaknya secara harian. Laporan akan datang dalam dua format:
Laporan agregat, yang merupakan dokumen XML yang menunjukkan data statistik tentang seberapa banyak email yang dilihat oleh pelapor dari setiap sumber, apa hasil autentikasi yang diperoleh, dan bagaimana pesan tersebut diperlakukan oleh pelapor. Laporan agregat dirancang untuk diparse oleh mesin, dengan data mereka disimpan di suatu tempat untuk memungkinkan analisis lalu lintas secara keseluruhan, audit aliran pesan di domain kami, dan mungkin juga untuk mengidentifikasi tren dalam sumber-sumber email yang tidak terautentikasi dan mungkin bersifat penipuan.
Laporan forensik, yang merupakan salinan individu dari pesan yang gagal autentikasi, masing-masing dibungkus dalam satu pesan email lengkap yang menggunakan format yang disebut AFRF. Laporan forensik seharusnya mengandung header lengkap dan badan pesan, tetapi banyak pelapor yang menghapus atau menyunting beberapa informasi karena kekhawatiran privasi. Meskipun demikian, laporan forensik masih bisa berguna baik untuk memecahkan masalah autentikasi domain kami sendiri maupun untuk mengidentifikasi, dari URI dalam badan 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 di domain kami untuk menangani laporan ini, seperti agg_reports@ourdomain.com dan afrf_reports@ourdomain.com. Perlu dicatat bahwa nama-nama kotak surat tersebut sepenuhnya sewenang-wenang, dan tidak ada persyaratan untuk penamaan bagian lokal dari kotak surat; kami bebas memilih nama-nama apa pun yang kami inginkan, tetapi tetaplah memisahkan keduanya untuk memudahkan pemrosesan.
Setelah nama kotak surat dipilih dan dibuat di domain kami, hal selanjutnya yang perlu dilakukan di sini adalah menempatkan alat untuk membaca kotak surat ini dan memanfaatkan data tersebut, terutama laporan data agregat, yang sekali lagi dirancang untuk diparse oleh mesin, bukan dibaca oleh manusia. Laporan forensik, di sisi lain, mungkin dapat dikelola hanya dengan membacanya sendiri, tetapi kemampuan kami untuk melakukannya akan bergantung baik pada pemahaman klien email kami tentang cara menampilkan pesan dalam format AFRF dan pada volume laporan yang kami terima.
Sementara itu mungkin bagi kami untuk menulis alat kami sendiri untuk memproses laporan DMARC, sampai saat Bird menyediakan layanan semacam itu untuk pelanggan bird.com (sesuatu yang sedang kami pertimbangkan, tetapi belum bisa dijanjikan), kami merekomendasikan agar kami memanfaatkan alat yang sudah tersedia untuk tugas tersebut.
Setiap domain yang menerbitkan kebijakan DMARC harus terlebih dahulu mempersiapkan diri untuk menerima laporan mengenai domainnya. Laporan ini akan dihasilkan oleh domain mana pun yang melakukan validasi DMARC dan melihat email yang mengaku berasal dari domain kami, dan akan dikirim kepada kami setidaknya secara harian. Laporan akan datang dalam dua format:
Laporan agregat, yang merupakan dokumen XML yang menunjukkan data statistik tentang seberapa banyak email yang dilihat oleh pelapor dari setiap sumber, apa hasil autentikasi yang diperoleh, dan bagaimana pesan tersebut diperlakukan oleh pelapor. Laporan agregat dirancang untuk diparse oleh mesin, dengan data mereka disimpan di suatu tempat untuk memungkinkan analisis lalu lintas secara keseluruhan, audit aliran pesan di domain kami, dan mungkin juga untuk mengidentifikasi tren dalam sumber-sumber email yang tidak terautentikasi dan mungkin bersifat penipuan.
Laporan forensik, yang merupakan salinan individu dari pesan yang gagal autentikasi, masing-masing dibungkus dalam satu pesan email lengkap yang menggunakan format yang disebut AFRF. Laporan forensik seharusnya mengandung header lengkap dan badan pesan, tetapi banyak pelapor yang menghapus atau menyunting beberapa informasi karena kekhawatiran privasi. Meskipun demikian, laporan forensik masih bisa berguna baik untuk memecahkan masalah autentikasi domain kami sendiri maupun untuk mengidentifikasi, dari URI dalam badan 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 di domain kami untuk menangani laporan ini, seperti agg_reports@ourdomain.com dan afrf_reports@ourdomain.com. Perlu dicatat bahwa nama-nama kotak surat tersebut sepenuhnya sewenang-wenang, dan tidak ada persyaratan untuk penamaan bagian lokal dari kotak surat; kami bebas memilih nama-nama apa pun yang kami inginkan, tetapi tetaplah memisahkan keduanya untuk memudahkan pemrosesan.
Setelah nama kotak surat dipilih dan dibuat di domain kami, hal selanjutnya yang perlu dilakukan di sini adalah menempatkan alat untuk membaca kotak surat ini dan memanfaatkan data tersebut, terutama laporan data agregat, yang sekali lagi dirancang untuk diparse oleh mesin, bukan dibaca oleh manusia. Laporan forensik, di sisi lain, mungkin dapat dikelola hanya dengan membacanya sendiri, tetapi kemampuan kami untuk melakukannya akan bergantung baik pada pemahaman klien email kami tentang cara menampilkan pesan dalam format AFRF dan pada volume laporan yang kami terima.
Sementara itu mungkin bagi kami untuk menulis alat kami sendiri untuk memproses laporan DMARC, sampai saat Bird menyediakan layanan semacam itu untuk pelanggan bird.com (sesuatu yang sedang kami pertimbangkan, tetapi belum bisa dijanjikan), kami merekomendasikan agar kami memanfaatkan alat yang sudah tersedia untuk tugas tersebut.
Setiap domain yang menerbitkan kebijakan DMARC harus terlebih dahulu mempersiapkan diri untuk menerima laporan mengenai domainnya. Laporan ini akan dihasilkan oleh domain mana pun yang melakukan validasi DMARC dan melihat email yang mengaku berasal dari domain kami, dan akan dikirim kepada kami setidaknya secara harian. Laporan akan datang dalam dua format:
Laporan agregat, yang merupakan dokumen XML yang menunjukkan data statistik tentang seberapa banyak email yang dilihat oleh pelapor dari setiap sumber, apa hasil autentikasi yang diperoleh, dan bagaimana pesan tersebut diperlakukan oleh pelapor. Laporan agregat dirancang untuk diparse oleh mesin, dengan data mereka disimpan di suatu tempat untuk memungkinkan analisis lalu lintas secara keseluruhan, audit aliran pesan di domain kami, dan mungkin juga untuk mengidentifikasi tren dalam sumber-sumber email yang tidak terautentikasi dan mungkin bersifat penipuan.
Laporan forensik, yang merupakan salinan individu dari pesan yang gagal autentikasi, masing-masing dibungkus dalam satu pesan email lengkap yang menggunakan format yang disebut AFRF. Laporan forensik seharusnya mengandung header lengkap dan badan pesan, tetapi banyak pelapor yang menghapus atau menyunting beberapa informasi karena kekhawatiran privasi. Meskipun demikian, laporan forensik masih bisa berguna baik untuk memecahkan masalah autentikasi domain kami sendiri maupun untuk mengidentifikasi, dari URI dalam badan 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 di domain kami untuk menangani laporan ini, seperti agg_reports@ourdomain.com dan afrf_reports@ourdomain.com. Perlu dicatat bahwa nama-nama kotak surat tersebut sepenuhnya sewenang-wenang, dan tidak ada persyaratan untuk penamaan bagian lokal dari kotak surat; kami bebas memilih nama-nama apa pun yang kami inginkan, tetapi tetaplah memisahkan keduanya untuk memudahkan pemrosesan.
Setelah nama kotak surat dipilih dan dibuat di domain kami, hal selanjutnya yang perlu dilakukan di sini adalah menempatkan alat untuk membaca kotak surat ini dan memanfaatkan data tersebut, terutama laporan data agregat, yang sekali lagi dirancang untuk diparse oleh mesin, bukan dibaca oleh manusia. Laporan forensik, di sisi lain, mungkin dapat dikelola hanya dengan membacanya sendiri, tetapi kemampuan kami untuk melakukannya akan bergantung baik pada pemahaman klien email kami tentang cara menampilkan pesan dalam format AFRF dan pada volume laporan yang kami terima.
Sementara itu mungkin bagi kami untuk menulis alat kami sendiri untuk memproses laporan DMARC, sampai saat Bird menyediakan layanan semacam itu untuk pelanggan bird.com (sesuatu yang sedang kami pertimbangkan, tetapi belum bisa dijanjikan), kami merekomendasikan agar kami memanfaatkan alat yang sudah tersedia untuk tugas tersebut.
Kebijakan DMARC Mana yang Harus Digunakan
Spesifikasi DMARC menyediakan tiga pilihan bagi pemilik domain untuk menentukan perlakuan yang mereka pilih terhadap email yang gagal pemeriksaan validasi DMARC. Mereka adalah:
tidak ada, yang berarti perlakukan email sama seperti yang akan diperlakukan terlepas dari pemeriksaan validasi DMARC
karantina, yang berarti terima email tetapi tempatkan di tempat lain selain Kotak Masuk penerima (biasanya di folder spam)
tolak, yang berarti menolak pesan secara langsung
Penting untuk diingat bahwa pemilik domain hanya dapat meminta perlakuan seperti itu dalam catatan DMARC mereka; terserah kepada penerima pesan untuk memutuskan apakah akan menghormati kebijakan yang diminta atau tidak. Beberapa akan melakukannya, sementara yang lain mungkin lebih longgar dalam menerapkan kebijakan, seperti hanya memindahkan email ke folder spam ketika kebijakan domain ditolak.
Kami merekomendasikan kepada semua pelanggan kami agar mereka memulai dengan kebijakan tidak ada, hanya untuk lebih aman. Meskipun kami yakin dengan kemampuan kami untuk mengautentikasi email Anda dengan benar melalui penandatanganan DKIM, tetap yang terbaik adalah meluangkan waktu untuk memeriksa laporan tentang domain Anda sebelum menjadi lebih agresif dengan kebijakan DMARC Anda.
Spesifikasi DMARC menyediakan tiga pilihan bagi pemilik domain untuk menentukan perlakuan yang mereka pilih terhadap email yang gagal pemeriksaan validasi DMARC. Mereka adalah:
tidak ada, yang berarti perlakukan email sama seperti yang akan diperlakukan terlepas dari pemeriksaan validasi DMARC
karantina, yang berarti terima email tetapi tempatkan di tempat lain selain Kotak Masuk penerima (biasanya di folder spam)
tolak, yang berarti menolak pesan secara langsung
Penting untuk diingat bahwa pemilik domain hanya dapat meminta perlakuan seperti itu dalam catatan DMARC mereka; terserah kepada penerima pesan untuk memutuskan apakah akan menghormati kebijakan yang diminta atau tidak. Beberapa akan melakukannya, sementara yang lain mungkin lebih longgar dalam menerapkan kebijakan, seperti hanya memindahkan email ke folder spam ketika kebijakan domain ditolak.
Kami merekomendasikan kepada semua pelanggan kami agar mereka memulai dengan kebijakan tidak ada, hanya untuk lebih aman. Meskipun kami yakin dengan kemampuan kami untuk mengautentikasi email Anda dengan benar melalui penandatanganan DKIM, tetap yang terbaik adalah meluangkan waktu untuk memeriksa laporan tentang domain Anda sebelum menjadi lebih agresif dengan kebijakan DMARC Anda.
Spesifikasi DMARC menyediakan tiga pilihan bagi pemilik domain untuk menentukan perlakuan yang mereka pilih terhadap email yang gagal pemeriksaan validasi DMARC. Mereka adalah:
tidak ada, yang berarti perlakukan email sama seperti yang akan diperlakukan terlepas dari pemeriksaan validasi DMARC
karantina, yang berarti terima email tetapi tempatkan di tempat lain selain Kotak Masuk penerima (biasanya di folder spam)
tolak, yang berarti menolak pesan secara langsung
Penting untuk diingat bahwa pemilik domain hanya dapat meminta perlakuan seperti itu dalam catatan DMARC mereka; terserah kepada penerima pesan untuk memutuskan apakah akan menghormati kebijakan yang diminta atau tidak. Beberapa akan melakukannya, sementara yang lain mungkin lebih longgar dalam menerapkan kebijakan, seperti hanya memindahkan email ke folder spam ketika kebijakan domain ditolak.
Kami merekomendasikan kepada semua pelanggan kami agar mereka memulai dengan kebijakan tidak ada, hanya untuk lebih aman. Meskipun kami yakin dengan kemampuan kami untuk mengautentikasi email Anda dengan benar melalui penandatanganan DKIM, tetap yang terbaik adalah meluangkan waktu untuk memeriksa laporan tentang domain Anda sebelum menjadi lebih agresif dengan kebijakan DMARC Anda.
menerbitkan Kebijakan DMARC Anda
Kebijakan DMARC sebuah domain diumumkan dengan menerbitkan catatan DNS TXT di tempat tertentu dalam namespace DNS, yaitu “_dmarc.domainname.tld” (perhatikan garis bawah di depan). Catatan kebijakan DMARC dasar untuk domain contoh kita sebelumnya, joesbaitshop.com, mungkin terlihat sesuatu 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"
Memecah 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 di mana laporan agregat harus dikirimkan
ruf=mailto:afrf_reports@joesbait.com adalah kotak surat di mana laporan forensik harus dikirimkan
pct=100 adalah persentase email di mana pemilik domain ingin kebijakannya diterapkan. Domain yang baru memulai dengan DMARC, terutama yang kemungkinan besar menghasilkan volume laporan yang tinggi, mungkin ingin memulai dengan angka yang jauh lebih rendah di sini untuk melihat bagaimana proses penanganan laporannya menangani beban ini.
Ada opsi konfigurasi lain yang tersedia bagi pemilik domain untuk digunakan dalam catatan kebijakan DMARC mereka, tetapi tips yang kami berikan seharusnya menjadi awal yang baik.
Kebijakan DMARC sebuah domain diumumkan dengan menerbitkan catatan DNS TXT di tempat tertentu dalam namespace DNS, yaitu “_dmarc.domainname.tld” (perhatikan garis bawah di depan). Catatan kebijakan DMARC dasar untuk domain contoh kita sebelumnya, joesbaitshop.com, mungkin terlihat sesuatu 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"
Memecah 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 di mana laporan agregat harus dikirimkan
ruf=mailto:afrf_reports@joesbait.com adalah kotak surat di mana laporan forensik harus dikirimkan
pct=100 adalah persentase email di mana pemilik domain ingin kebijakannya diterapkan. Domain yang baru memulai dengan DMARC, terutama yang kemungkinan besar menghasilkan volume laporan yang tinggi, mungkin ingin memulai dengan angka yang jauh lebih rendah di sini untuk melihat bagaimana proses penanganan laporannya menangani beban ini.
Ada opsi konfigurasi lain yang tersedia bagi pemilik domain untuk digunakan dalam catatan kebijakan DMARC mereka, tetapi tips yang kami berikan seharusnya menjadi awal yang baik.
Kebijakan DMARC sebuah domain diumumkan dengan menerbitkan catatan DNS TXT di tempat tertentu dalam namespace DNS, yaitu “_dmarc.domainname.tld” (perhatikan garis bawah di depan). Catatan kebijakan DMARC dasar untuk domain contoh kita sebelumnya, joesbaitshop.com, mungkin terlihat sesuatu 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"
Memecah 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 di mana laporan agregat harus dikirimkan
ruf=mailto:afrf_reports@joesbait.com adalah kotak surat di mana laporan forensik harus dikirimkan
pct=100 adalah persentase email di mana pemilik domain ingin kebijakannya diterapkan. Domain yang baru memulai dengan DMARC, terutama yang kemungkinan besar menghasilkan volume laporan yang tinggi, mungkin ingin memulai dengan angka yang jauh lebih rendah di sini untuk melihat bagaimana proses penanganan laporannya menangani beban ini.
Ada opsi konfigurasi lain yang tersedia bagi pemilik domain untuk digunakan dalam catatan kebijakan DMARC mereka, tetapi tips yang kami berikan seharusnya menjadi awal yang baik.
Ringkasan
Ada banyak yang perlu dipahami dari informasi di atas! Kami berharap Anda menemukan panduan untuk membuat catatan kebijakan DMARC bermanfaat. Kami juga berharap penjelasan kami tentang mengapa DMARC itu penting membantu menjelaskan mengapa Anda harus mulai menggunakan alat penting ini untuk melindungi reputasi email Anda.
Tentu saja, ini bukan dokumen yang lengkap atau otoritatif tentang subjek tersebut. Jika Anda ingin menyelami lebih dalam atau membutuhkan bantuan lebih lanjut, tempat yang baik untuk memulai adalah FAQ DMARC resmi. Dan, tidak perlu dikatakan bahwa tim dukungan MessageBird siap membantu Anda mengonfigurasi akun MessageBird Anda untuk DMARC juga.
Terima kasih telah membaca—dan mulai lindungi domain Anda dengan DMARC hari ini!
Ada banyak yang perlu dipahami dari informasi di atas! Kami berharap Anda menemukan panduan untuk membuat catatan kebijakan DMARC bermanfaat. Kami juga berharap penjelasan kami tentang mengapa DMARC itu penting membantu menjelaskan mengapa Anda harus mulai menggunakan alat penting ini untuk melindungi reputasi email Anda.
Tentu saja, ini bukan dokumen yang lengkap atau otoritatif tentang subjek tersebut. Jika Anda ingin menyelami lebih dalam atau membutuhkan bantuan lebih lanjut, tempat yang baik untuk memulai adalah FAQ DMARC resmi. Dan, tidak perlu dikatakan bahwa tim dukungan MessageBird siap membantu Anda mengonfigurasi akun MessageBird Anda untuk DMARC juga.
Terima kasih telah membaca—dan mulai lindungi domain Anda dengan DMARC hari ini!
Ada banyak yang perlu dipahami dari informasi di atas! Kami berharap Anda menemukan panduan untuk membuat catatan kebijakan DMARC bermanfaat. Kami juga berharap penjelasan kami tentang mengapa DMARC itu penting membantu menjelaskan mengapa Anda harus mulai menggunakan alat penting ini untuk melindungi reputasi email Anda.
Tentu saja, ini bukan dokumen yang lengkap atau otoritatif tentang subjek tersebut. Jika Anda ingin menyelami lebih dalam atau membutuhkan bantuan lebih lanjut, tempat yang baik untuk memulai adalah FAQ DMARC resmi. Dan, tidak perlu dikatakan bahwa tim dukungan MessageBird siap membantu Anda mengonfigurasi akun MessageBird Anda untuk DMARC juga.
Terima kasih telah membaca—dan mulai lindungi domain Anda dengan DMARC hari ini!
