DMARC Mengaitkan Autentikasi Email dengan Domain From yang Terlihat

Email dapat membawa beberapa identitas domain sekaligus. Alamat yang tampil pada header From dapat berbeda dari envelope sender yang dipakai SMTP, sementara tanda tangan DKIM dapat menyebut domain lain lagi pada tag d=. SPF dan DKIM mengautentikasi identitas dari lapisan protokol yang berbeda tersebut; masing-masing mekanisme tidak dengan sendirinya mewajibkan domain terautentikasi cocok dengan domain yang ditampilkan kepada penerima pada From.

Domain-based Message Authentication, Reporting, and Conformance (DMARC), yang ditetapkan dalam RFC 7489, menghubungkan lapisan tersebut. Penerima mengevaluasi SPF dan DKIM, menguji keselarasan domain terhadap domain RFC5322.From, lalu mengambil kebijakan yang dipublikasikan domain itu. Pesan lolos DMARC ketika setidaknya satu jalur SPF atau DKIM yang memenuhi syarat berhasil diautentikasi sekaligus selaras.

SPF menyediakan jalur selaras melalui identitas envelope

SPF memvalidasi apakah klien SMTP yang terhubung diizinkan untuk suatu identitas SPF. Pada transaksi email biasa, identitas yang relevan umumnya adalah domain RFC5321.MailFrom. DMARC kemudian membandingkan domain terautentikasi tersebut dengan domain pada RFC5322.From.

Misalnya, sebuah pesan memuat:

MAIL FROM:<bounce@mail.example.com>
From: Billing <billing@example.com>

Jika SPF lolos untuk mail.example.com, keselarasan DMARC relaxed dapat menganggap hasil tersebut selaras dengan example.com karena keduanya berada pada organizational domain yang sama. Pada keselarasan strict, domain harus cocok persis sehingga jalur SPF ini tidak selaras.

Hasil SPF yang sukses untuk domain envelope yang tidak terkait tidak menghasilkan DMARC pass bagi example.com. Autentikasi SPF dan keselarasan DMARC merupakan keputusan terpisah.

DKIM menyediakan jalur selaras melalui domain penanda tangan

DKIM memasang tanda tangan kriptografis pada header pesan tertentu dan body pesan. Tag d= mengidentifikasi domain penanda tangan. DMARC membandingkan domain tersebut dengan RFC5322.From setelah verifikasi DKIM berhasil.

Tanda tangan yang disederhanakan dapat memuat:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026; ...

Untuk pesan dengan domain From example.com, tanda tangan valid dengan d=example.com selaras dalam mode strict maupun relaxed. Tanda tangan valid dari mailer.example.net tetap dapat membuktikan autentikasi DKIM untuk penanda tangan itu, tetapi tidak selaras dengan example.com sehingga tidak dapat sendirian membuat DMARC lolos untuk domain From tersebut.

Beberapa tanda tangan DKIM dapat hadir dalam satu pesan. DMARC hanya memerlukan satu tanda tangan DKIM valid dengan keselarasan yang sesuai untuk menyediakan jalur DKIM yang lolos.

Keselarasan relaxed dan strict menetapkan batas domain berbeda

Record DMARC dapat memilih mode keselarasan melalui aspf untuk SPF dan adkim untuk DKIM. Nilai default keduanya adalah keselarasan relaxed. Mode strict dipilih dengan s.

Record kebijakan dapat berbentuk:

v=DMARC1; p=reject; adkim=s; aspf=s

Keselarasan strict mewajibkan kecocokan domain DNS secara persis antara identifier terautentikasi dan RFC5322.From. Keselarasan relaxed membandingkan organizational domain menurut model domain dalam spesifikasi DMARC.

Perbedaan ini memengaruhi arsitektur email yang sah. Layanan yang menandatangani sebagai subdomain dapat memenuhi keselarasan relaxed tetapi gagal dalam keselarasan strict untuk alamat From pada parent domain. Memperketat keselarasan karena itu merupakan keputusan routing dan identitas, bukan sekadar perubahan sintaks pada record TXT.

Kebijakan diperiksa setelah hasil autentikasi dan keselarasan

Domain memublikasikan kebijakan DMARC di bawah _dmarc. Record ringkas dapat berupa:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Tag p menyatakan kebijakan penerima yang diminta untuk pesan yang gagal pada mekanisme DMARC. RFC 7489 menetapkan none, quarantine, dan reject. none tidak meminta perlakuan pengiriman khusus berdasarkan kegagalan DMARC, quarantine meminta penerima memperlakukan email yang gagal sebagai mencurigakan, dan reject meminta penolakan selama penanganan SMTP.

Nilai tersebut merupakan permintaan kebijakan terpublikasi dalam model pemrosesan DMARC. Nilai itu tidak mengubah SPF atau DKIM menjadi otorisasi pengirim universal dan tidak menjamin perlakuan identik oleh setiap penerima. Kebijakan lokal penerima tetap berperan.

Tag sp dapat menetapkan kebijakan untuk subdomain ketika tersedia. Tanpa tag tersebut, aturan DMARC yang berlaku menentukan pewarisan kebijakan parent. Operator domain karena itu perlu memperhitungkan subdomain yang secara sah mengirim email sebelum menerapkan kebijakan restriktif.

Laporan agregat menampilkan hasil autentikasi dan keselarasan

Tag opsional rua mengidentifikasi tujuan untuk feedback agregat. Penerima yang mendukungnya dapat mengirim laporan XML yang merangkum source IP yang diamati, jumlah pesan, disposition kebijakan, serta data evaluasi SPF atau DKIM selama periode pelaporan.

Laporan agregat tidak membawa body pesan asli sebagai bagian normal dari format record agregat. Laporan ini merupakan telemetri operasional untuk mengamati perilaku autentikasi di berbagai aliran email. Domain dapat memakai telemetri tersebut untuk mengidentifikasi sistem sah yang masih mengirim dengan identitas tidak selaras sebelum berpindah dari monitoring menuju kebijakan yang lebih ketat.

Pengiriman laporan memiliki aturan otorisasi tersendiri ketika tujuan berada di luar domain kebijakan. Mempublikasikan alamat rua eksternal secara sembarang tidak otomatis memberi otorisasi kepada domain tersebut untuk menerima laporan.

Forwarding memperlihatkan perbedaan jalur SPF dan DKIM

Forwarding email dapat mengubah klien SMTP yang terhubung ke penerima akhir. Identitas envelope awal kemudian dapat gagal SPF karena alamat IP sistem forwarding tidak diizinkan oleh domain asal. Tanda tangan DKIM dapat bertahan melewati forwarding jika konten yang ditandatangani tetap valid dan domain penanda tangan selaras dengan RFC5322.From.

Perbedaan tersebut menjadi bagian penting dari desain dua jalur DMARC. DMARC pass tidak mewajibkan SPF dan DKIM sama-sama lolos dan selaras. Satu jalur yang terautentikasi dan selaras sudah cukup. Sebaliknya, SPF dan DKIM masing-masing dapat melaporkan autentikasi sukses untuk domain yang tidak terkait dengan RFC5322.From sementara DMARC tetap gagal karena tidak satu pun hasilnya selaras.

DMARC dengan demikian menambahkan relasi identitas, bukan bukti independen ketiga mengenai asal pesan. Keputusannya dibentuk dari hasil SPF dan DKIM yang sudah ada, domain From yang terlihat, aturan keselarasan, serta kebijakan terpublikasi milik domain pengirim. Memisahkan komponen tersebut membuat kesalahan konfigurasi lebih mudah diisolasi: autentikasi dapat berhasil saat keselarasan gagal, dan penerapan kebijakan baru dimulai setelah perbedaan itu dievaluasi.