Poin-poin penting

  • SPF (RFC 7208): Memublikasikan daftar alamat IP dan layanan pengiriman yang diizinkan mengirim email atas nama domain Anda pada envelope sender (Return-Path).
  • DKIM (RFC 6376): Menggunakan pasangan kunci asimetris untuk menambahkan tanda tangan kriptografis pada setiap pesan, sebagai bukti bahwa pesan tersebut diotorisasi oleh domain penanda tangan dan tidak diubah selama transit.
  • DMARC (RFC 7489): Memberi tahu server penerima cara menangani email yang gagal dalam alignment SPF dan DKIM (none, quarantine, atau reject) serta ke mana laporan agregat harus dikirim.
  • Sejak Februari 2024, Gmail dan Yahoo mewajibkan bulk sender (Gmail mendefinisikannya sebagai pengirim lebih dari 5.000 pesan per hari ke akun Gmail pribadi) untuk melakukan autentikasi dengan SPF sekaligus DKIM, memublikasikan record DMARC (minimal p=none), dan menyelaraskan domain From dengan SPF atau DKIM.

Ketika server email penerima seperti Google Workspace, Microsoft 365, atau Yahoo Mail menerima pesan dari contact@yourcompany.com, sistem filternya menjalankan serangkaian pemeriksaan teknis untuk memastikan apakah pesan tersebut benar-benar berasal dari pemilik sah domain itu, atau merupakan upaya spoofing maupun phishing.

Jika domain Anda belum memiliki record autentikasi yang diperlukan di DNS (Domain Name System), pesan Anda akan dianggap berisiko tinggi. Kemungkinan besar pesan tersebut masuk ke folder spam atau langsung ditolak di level SMTP, yang kemudian tercatat sebagai bounce di platform pengiriman Anda.

1. Tiga mekanisme inti autentikasi email

Untuk memahami bagaimana sistem keamanan email bekerja bersama, ada baiknya melihat peran masing-masing protokol yang berbeda namun saling melengkapi:

SPF (Sender Policy Framework)

SPF berfungsi seperti allowlist publik yang dipublikasikan di DNS Anda. Record ini menyatakan server mana saja yang boleh mengirim email atas nama domain Anda, baik yang diidentifikasi melalui alamat IP maupun melalui mekanisme include yang mengarah ke penyedia seperti Amazon SES, SendGrid, atau Mailgun. Server penerima memeriksa SPF terhadap domain envelope sender (MAIL FROM / Return-Path), bukan alamat From yang terlihat oleh penerima.

DKIM (DomainKeys Identified Mail)

DKIM memverifikasi integritas pesan. Saat pesan keluar dari server pengirim, tanda tangan digital dibuat menggunakan private key lalu ditambahkan ke pesan sebagai header DKIM-Signature. Server penerima mengambil public key yang sesuai dari DNS Anda dan menggunakannya untuk memverifikasi tanda tangan tersebut, sehingga dapat dipastikan bahwa header dan isi pesan yang ditandatangani tidak dipalsukan atau diubah di tengah jalan.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC adalah lapisan yang menyatukan SPF dan DKIM. DMARC mengharuskan server penerima memeriksa apakah domain pada alamat pengirim yang terlihat (Header From) sama dengan domain yang diautentikasi oleh SPF atau DKIM. Pemeriksaan ini dikenal sebagai alignment. Sebuah pesan lolos DMARC jika setidaknya salah satu dari keduanya lolos dan selaras. DMARC juga menentukan tindakan yang harus diambil server penerima saat autentikasi gagal, sekaligus menyediakan jalur untuk laporan agregat (RUA).

2. Struktur dan sintaks record SPF

Record SPF dipublikasikan sebagai record TXT pada domain yang digunakan di envelope sender. Untuk email yang dikirim dari server Anda sendiri atau dari Google Workspace, biasanya domain yang dimaksud adalah root domain:

Record Type: TXT
Host / Name: @ (or yourcompany.com)
Value / Content: v=spf1 include:amazonses.com ~all

Arti setiap bagian record:

  • v=spf1: Menyatakan versi SPF yang digunakan. Bagian ini wajib menjadi term pertama dalam record.
  • include:amazonses.com: Mengizinkan rentang IP pengiriman Amazon Simple Email Service (SES) untuk mengirim email atas nama domain. Jika Anda juga menggunakan SendGrid, padanannya adalah include:sendgrid.net. Perlu dicatat, pada Amazon SES, SPF baru selaras untuk DMARC jika Anda mengonfigurasi subdomain custom MAIL FROM (misalnya bounce.yourcompany.com) dan memublikasikan record ini di subdomain tersebut beserta record MX yang disediakan SES. Jika domain authentication dan automated security di SendGrid diaktifkan, SendGrid mengelola SPF untuk subdomain return-path-nya melalui CNAME, sehingga include di level root tidak diperlukan.
  • ~all (SoftFail): Menandakan bahwa email dari server yang tidak tercantum dalam daftar harus dianggap mencurigakan, tetapi umumnya tetap diterima. Ini adalah pilihan yang paling umum, terutama selama Anda masih mendata semua sumber pengiriman.
  • -all (HardFail): Menandakan bahwa email dari sumber yang tidak diotorisasi harus dianggap gagal secara pasti. Server penerima dapat menolaknya, meskipun kini banyak penyedia mailbox besar lebih mengandalkan hasil DMARC daripada menolak hanya berdasarkan SPF.
Catatan teknis penting: Menurut RFC 7208, sebuah domain hanya boleh memublikasikan satu record SPF; record yang lebih dari satu akan menimbulkan error permanen (permerror). Evaluasinya juga dibatasi maksimal 10 DNS lookup (termasuk include, a, mx, ptr, exists, dan redirect, beserta lookup bertingkat di dalamnya). Jika beberapa layanan mengirim dari domain yang sama (misalnya Google Workspace dan Amazon SES), gabungkan semuanya dalam satu record: v=spf1 include:_spf.google.com include:amazonses.com ~all.

3. Mengatur DKIM

Pengaturan DKIM umumnya melibatkan pembuatan pasangan kunci RSA, dengan panjang kunci 2048-bit sebagai batas minimum yang direkomendasikan saat ini. Saat Anda menghubungkan penyedia layanan pengiriman melalui eMailBase:

  1. Penyedia layanan membuat record DNS untuk selector DKIM-nya. Easy DKIM di Amazon SES menerbitkan tiga record CNAME dengan format <token>._domainkey.yourcompany.com; SendGrid menerbitkan dua record CNAME DKIM (s1._domainkey dan s2._domainkey) ditambah satu record untuk subdomain return-path-nya; sedangkan Mailgun biasanya menyediakan record TXT yang berisi public key.
  2. Masuk ke panel kontrol penyedia DNS Anda dan buat setiap record persis seperti yang diberikan.
  3. eMailBase akan otomatis melakukan query DNS dan mengonfirmasi aktivasi setelah record selesai terpropagasi.

4. Menerapkan penegakan DMARC secara aman

Memublikasikan kebijakan DMARC yang ketat sejak hari pertama dapat menyebabkan email yang sah ikut ditolak jika masih ada sumber pengiriman yang belum sepenuhnya tercakup oleh SPF atau DKIM. Record DMARC dipublikasikan sebagai record TXT di _dmarc.yourcompany.com, dan penerapan standarnya terdiri atas tiga fase:

Fase Sintaks kebijakan Tujuan operasional
Fase 1: Pemantauan v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com Mengumpulkan laporan agregat dan mengidentifikasi seluruh sumber pengiriman yang sah tanpa memengaruhi pengiriman.
Fase 2: Karantina v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourcompany.com Menerapkan kebijakan karantina (biasanya dikirim ke folder spam) pada 25% pesan yang gagal, lalu menaikkan persentasenya setelah laporan memastikan email yang sah lolos. Dukungan server penerima terhadap pct berbeda-beda, dan revisi standar DMARCbis menghapus tag tersebut.
Fase 3: Penolakan v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com Menginstruksikan server penerima untuk menolak semua email yang gagal DMARC, sehingga penggunaan domain Anda tanpa izin dapat diblokir.

5. Memverifikasi dan mengatasi masalah record DNS

Setelah semua record terpasang, Anda dapat memeriksanya dengan tool command-line standar:

# Check the SPF record
dig +short TXT yourcompany.com

# Check a DKIM record (replace the selector with your own)
dig +short CNAME selector._domainkey.yourcompany.com

# Check the DMARC record
dig +short TXT _dmarc.yourcompany.com

Di workspace eMailBase, pemeriksaan ini berjalan otomatis melalui DNS & Deliverability Manager, yang langsung menandai konflik sintaks dan record yang hilang begitu terdeteksi.

Pelajari lebih lanjut tentang praktik pengiriman yang bertanggung jawab di Kebijakan Anti-Spam eMailBase.