Menambahkan data DMARC

 

Menambahkan data DMARC

Anda menentukan fungsi DMARC dengan memasukkan data DMARC di setelan DNS domain.

Setelah menyiapkan teks data DMARC, tambahkan atau perbarui data TXT DNS di penyedia domain Anda. Untuk memperbarui data TXT DNS, masukkan baris teks yang menentukan data kebijakan DMARC di konsol pengelolaan untuk penyedia domain.

Setiap kali mengubah kebijakan DMARC dan memperbarui data, Anda harus memperbarui data TXT DNS di penyedia domain.

Subdomain atau domain tambahan

Jika Anda memiliki lebih dari satu domain, lakukan langkah-langkah di bawah untuk setiap domain. Setiap domain dapat memiliki kebijakan yang berbeda dan opsi laporan yang berbeda (ditentukan dalam data).

Jika Anda tidak membuat kebijakan DMARC untuk subdomain, subdomain tersebut akan mewarisi kebijakan DMARC domain induk. Untuk menentukan kebijakan DMARC bagi subdomain, gunakan sp tag kebijakan dalam data DMARC untuk domain induk.

Menambahkan atau memperbarui data

Lakukan langkah-langkah ini di konsol pengelolaan untuk host domain Anda, bukan di konsol Admin. Siapa host domain saya?

Penting: Konfigurasikan DKIM dan SPF sebelum mengonfigurasikan DMARC. DKIM dan SPF harus mengautentikasi pesan setidaknya selama 48 jam sebelum mengaktifkan DMARC.

  1. Siapkan baris atau file teks yang merepresentasikan data kebijakan Anda.
  2. Login ke konsol pengelolaan untuk host domain Anda.
  3.  Cari halaman tempat Anda memperbarui data DNS.
  4. Tambahkan data TXT DNS, atau ubah data yang ada, dengan memasukkan data Anda ke dalam data TXT untuk  _dmarc:
    1. Nama data TXT: Di kolom pertama, di bagian nama Host DNS, masukkan: _dmarc.solarmora.com
    2. Nilai data TXT: Di kolom kedua, masukkan teks untuk data DMARC Anda, misalnya:

      v=DMARC1; p=none; rua=mailto:dmarc-reports@solarmora.com

      Nama kolom mungkin berbeda untuk penyedia Anda. Nama kolom data TXT DNS antara satu penyedia dengan penyedia lainnya dapat sedikit berbeda. Domain yang digunakan di sini adalah domain contoh. Ganti solarmora.com dengan domain Anda sendiri.

  5. Simpan perubahan. 

Format data DMARC

Data DMARC dibuat dalam bentuk baris teks biasa. Teks ini adalah daftar tag dan nilai DMARC, yang dipisahkan dengan titik koma. Beberapa tag wajib diisi dan beberapa lainnya bersifat opsional.

Kebijakan DMARC memberi tahu server penerima tindakan apa yang harus diambil pada pesan yang tidak diautentikasi yang didapatkan dapatkan dari domain Anda. Tindakan yang harus diambil ditentukan dengan tag kebijakan (p) saat Anda menentukan data DMARC.

Ini adalah contoh data kebijakan DMARC. Tag v dan p harus dicantumkan terlebih dahulu, tag lainnya dapat dicantumkan dalam urutan apa pun:

v=DMARC1; p=reject; rua=mailto:postmaster@solarmora.com, mailto:dmarc@solarmora.com; pct=100; adkim=s; aspf=s

Tag data DMARC

TagWajib?Deskripsi dan nilai
v

Wajib

Versi DMARC. Harus berupa DMARC1.

p

Wajib

Menginstruksikan server email penerima tentang tindakan yang harus dilakukan terhadap pesan yang tidak lulus autentikasi.
  • none: Tidak mengambil tindakan terhadap pesan dan mengirimkannya ke penerima yang dimaksud. Mencatat pesan dalam laporan harian. Laporan dikirim ke alamat email yang ditentukan dengan opsi rua dalam data .
  • quarantine: Menandai pesan sebagai spam dan mengirimkan ke folder spam penerima. Penerima dapat meninjau pesan spam untuk mengidentifikasi pesan yang sah.
  • reject: Reject the message. With this option, the receiving server usually sends a bounce message  to the sending server.
pctOpsional

Harus berupa bilangan bulat dari 1 sampai 100. Jika opsi ini tidak digunakan di dalam data, kebijakan DMARC Anda akan diterapkan untuk 100% pesan yang dikirim dari domain.

Menentukan persentase pesan yang tidak diautentikasi tunduk pada kebijakan DMARC. Saat menerapkan DMARC secara bertahap, Anda dapat memulai dengan sebagian kecil pesan. Seiring makin banyak pesan dari domain Anda yang lulus autentikasi dengan server penerima, perbarui data dengan persentase yang lebih tinggi, hingga mencapai 100 persen.

Harus berupa bilangan bulat dari 1 sampai 100. Jika opsi ini tidak digunakan di dalam data, kebijakan DMARC Anda akan diterapkan untuk 100% pesan yang dikirim dari domain.

ruaOpsional

Alamat email untuk menerima laporan tentang aktivitas DMARC bagi domain Anda.

Alamat email harus menyertakan mailto:. Misalnya: mailto:dmarc-reports@solarmora.com

Untuk mengirim laporan ke lebih dari satu alamat email, pisahkan email dengan koma.

Opsi ini berpotensi menghasilkan email laporan dalam jumlah besar. Sebaiknya jangan gunakan alamat email Anda sendiri. Sebagai gantinya, pertimbangkan untuk menggunakan kotak surat khusus, grup, atau layanan pihak ketiga yang memiliki spesialisasi dalam laporan DMARC.

rufTidak didukungGmail tidak mendukung tag ruf, yang digunakan untuk mengirim laporan kegagalan. Laporan kegagalan juga disebut laporan forensik.
spOpsionalMenetapkan kebijakan untuk pesan dari subdomain dalam domain primer Anda. Gunakan opsi ini jika Anda ingin menggunakan kebijakan DMARC yang berbeda untuk subdomain Anda.
  • none: Take no action on the message and deliver it to the intended recipient. Log messages in a daily report. The report is sent to the email address specified with the rua option in the policy .
  • quarantine: Menandai pesan sebagai spam dan mengirimkan ke folder spam penerima. Penerima dapat meninjau pesan spam untuk mengidentifikasi pesan yang sah.
  • reject: Menolak pesan. Dengan opsi ini, server penerima harus mengirim pesan email tidak terkirim ke server pengirim

Jika Anda tidak menggunakan opsi ini di dalam data, subdomain akan mewarisi kumpulan kebijakan DMARC dari domain induk.

adkimOpsionalMenetapkan kebijakan penyelarasan untuk DKIM, yang menentukan seberapa ketat informasi pesan harus cocok dengan tanda tangan DKIM. Pelajari cara kerja penyelarasan.
  • s: Penyelarasan ketat. Nama domain pengirim harus sama persis dengan d=name yang sesuai di header email DKIM.
  • r: Relaxed alignment (default). Allows partial matches. Any valid subdomain of d=domain in the DKIM mail headers is accepted.
aspfOpsionalMenetapkan kebijakan penyelarasan untuk SPF, yang menentukan seberapa ketat informasi pesan harus cocok dengan tanda tangan SPF. Pelajari cara kerja penyelarasan.
  • s: Penyelarasan ketat. Header From pada pesan harus sama persis dengan nama domain di perintah SMTP MAIL FROM
  • r: Penyelarasan longgar (default). Memungkinkan pencocokan parsial. Semua subdomain yang valid dari nama domain dapat diterima.