Threat Intelligence
▲ TINGGI
Email Security: Panduan Lengkap SPF, DKIM, DMARC, dan Pencegahan Email Spoofing
13 Juli 2026 • Seraphim News • 23 mnt baca
Daftar Isi 13 bagian
Ringkasan Eksekutif
Email tetap menjadi vektor serangan nomor satu dalam keamanan siber. Lebih dari 91% serangan siber dimulai dengan sebuah email. Phishing, business email compromise (BEC), spoofing, dan malware delivery — semuanya masuk melalui inbox.
Namun, paradoksnya: mayoritas organisasi masih belum mengkonfigurasi perlindungan email dasar dengan benar:
- Hanya 47% domain memiliki SPF record yang valid
- Hanya 35% domain memiliki DKIM yang dikonfigurasi
- Hanya 15% domain memiliki DMARC policy yang enforce (p=reject)
- 100% domain tanpa DMARC reject bisa di-spoof — domain Anda bisa digunakan untuk mengirim email phishing yang tampak seperti berasal dari organisasi Anda
Email security modern dibangun di atas tiga pilar autentikasi: SPF, DKIM, dan DMARC. Ketiganya bekerja bersama untuk memverifikasi bahwa email benar-benar berasal dari pengirim yang diklaim dan tidak dimodifikasi dalam perjalanan.
Mengapa Email Security Masih Kritis di 2026
STATISTIK ANCAMAN EMAIL 2026
├── 91% serangan siber dimulai dengan email phishing
├── 3,4 miliar email phishing dikirim setiap hari
├── Business Email Compromise (BEC): kerugian $55 miliar sejak 2013
├── 36% kebocoran data melibatkan email (phishing + credential theft)
├── Rata-rata biaya per BEC attack: $135.000
├── 1 dari 3 karyawan akan mengklik link phishing (tanpa training)
├── AI-generated phishing email: 4,5x lebih efektif dari buatan manusia
└── Email spoofing: 96% perusahaan Fortune 500 pernah di-spoof domainnya
MENGAPA EMAIL RENTAN SECARA DESAIN:
├── SMTP (Simple Mail Transfer Protocol) — dibuat 1982
├── Tidak ada autentikasi built-in — siapa pun bisa mengirim email mengaku sebagai siapa pun
├── Header bisa dipalsukan (From:, Reply-To:, Return-Path:)
├── Enkripsi (TLS) bersifat opportunistic — tidak mandatory
└── SPF/DKIM/DMARC adalah retrofit — perlu konfigurasi manual
Tiga Pilar Autentikasi Email
CARA KERJA AUTENTIKASI EMAIL
PENGIRIM PENERIMA
───────── ─────────
┌──────────────┐
1. SPF: "Server mana yang │ SPF CHECK │
boleh kirim email atas │ │
nama domain saya?" │ IP 1.2.3.4 │
│ in SPF list? │
DNS: v=spf1 ip4:1.2.3.4 -all │ YES → PASS │
└──────────────┘
┌──────────────┐
2. DKIM: "Email ini asli, │ DKIM CHECK │
tidak diubah, dan │ │
ditandatangani oleh domain" │ Verify │
│ signature │
Header: DKIM-Signature: │ with pub key │
v=1; d=domain.com; ... │ from DNS │
│ YES → PASS │
└──────────────┘
┌──────────────┐
3. DMARC: "Apa yang harus │ DMARC CHECK │
dilakukan jika SPF atau │ │
DKIM gagal?" │ SPF: PASS │
│ DKIM: PASS │
DNS: v=DMARC1; p=reject; │ Domain aligned?│
rua=mailto:dmarc@domain.com │ YES → PASS │
└──────────────┘
SPF: Sender Policy Framework
SPF (Sender Policy Framework) adalah mekanisme yang memungkinkan pemilik domain menentukan server email mana yang diizinkan mengirim email atas nama domain tersebut. SPF bekerja dengan memeriksa IP address server pengirim terhadap daftar yang dipublikasikan di DNS.
CARA KERJA SPF
1. Pengirim: menambahkan SPF record di DNS
domain.com TXT "v=spf1 ip4:192.0.2.1 include:_spf.google.com -all"
2. Email terkirim dari server 192.0.2.1
Return-Path: bounce@domain.com
Connecting IP: 192.0.2.1
3. Server penerima:
a. Ambil SPF record dari domain di Return-Path
b. Cek: apakah IP 192.0.2.1 ada di SPF record?
c. HASIL: PASS (IP ada di SPF)
KOMPONEN SPF RECORD:
v=spf1 # Versi SPF (selalu spf1)
MECHANISMS (urutan penting — evaluasi left-to-right):
├── ip4:192.0.2.1 # Izinkan IP spesifik
├── ip4:192.0.2.0/24 # Izinkan IP range
├── ip6:2001:db8::/32 # Izinkan IPv6 range
├── a # Izinkan IP dari A record domain
├── mx # Izinkan IP dari MX record domain
├── include:_spf.google.com # Izinkan mekanisme dari domain lain
├── exists:%{i}.spf.domain.com # Dynamic SPF (jarang)
└── redirect=other.com # Gunakan SPF record domain lain
QUALIFIERS:
├── + (PASS) — default, boleh kirim
├── ? (NEUTRAL) — tidak ada keputusan
├── ~ (SOFTFAIL) — kemungkinan tidak sah, tapi diterima
└── - (FAIL) — pasti tidak sah, tolak
MODIFIERS:
├── redirect=domain.com # Redirect ke SPF domain lain (harus di akhir)
└── exp=explanation.txt # Custom error message untuk FAIL
CONTOH SPF RECORD:
# Hanya dari Google Workspace, semua yang lain tolak
v=spf1 include:_spf.google.com -all
# Dari on-prem Exchange + Google Workspace + marketing platform
v=spf1 ip4:203.0.113.10 include:_spf.google.com include:spf.marketing.com -all
# Soft fail untuk monitoring (transisi sebelum reject)
v=spf1 include:_spf.google.com ~all
BATASAN SPF:
├── Maksimal 10 DNS lookups (include, a, mx, ptr, exists)
├── Jika >10: SPF PermError — SPF invalid
├── Hanya memvalidasi domain di Return-Path (envelope from)
│ └── Bukan domain di From: header!
├── Email forwarding: SPF break
│ ├── Forwarder mengubah Return-Path
│ ├── Tapi tetap mengirim dari original Return-Path
│ └── SRS (Sender Rewriting Scheme) untuk mengatasi ini
└── Tidak melindungi display name spoofing (From: "CEO <attacker@evil.com>")
DKIM: DomainKeys Identified Mail
DKIM menambahkan tanda tangan digital (digital signature) ke setiap email yang dikirim. Tanda tangan ini memverifikasi bahwa email benar-benar berasal dari domain yang diklaim dan tidak dimodifikasi dalam perjalanan.
CARA KERJA DKIM
PERSIAPAN (SATU KALI):
├── Domain owner generate RSA key pair
├── Private key: disimpan di email server (tidak di DNS)
├── Public key: dipublikasikan di DNS sebagai TXT record
└── Selector: label untuk mengidentifikasi key
└── Format: <selector>._domainkey.<domain>
└── Contoh: google._domainkey.domain.com
SAAT MENGIRIM EMAIL:
1. Email server menghitung hash dari:
├── Body email (body hash)
└── Selected headers (From, To, Subject, Date, dll.)
2. Hash ditandatangani dengan private key
3. Tanda tangan dimasukkan ke header DKIM-Signature
HEADER DKIM-SIGNATURE:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=domain.com; s=selector1;
h=from:to:subject:date:message-id;
bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
b=KJ7F9Bw8Qx7cL3mN5pR2tV6yA8zD4eG1hJ3kM4oP6qS9uW0xZ2aC5dF7...
KOMPONEN:
├── v=1 : Versi DKIM
├── a=rsa-sha256: Algoritma (RSA + SHA256)
├── c=relaxed/relaxed: Canonicalization (header/body)
├── d=domain.com: Domain penanda tangan
├── s=selector1: Selector untuk lookup public key
├── h=... : Headers yang ditandatangani
├── bh=... : Body hash (base64)
└── b=... : Tanda tangan (base64)
SAAT MENERIMA EMAIL:
1. Server penerima ambil public key dari DNS:
selector1._domainkey.domain.com TXT
2. Verifikasi tanda tangan:
a. Hitung ulang hash dari body + headers
b. Decrypt tanda tangan dengan public key
c. Bandingkan hasilnya
3. HASIL:
├── PASS: Tanda tangan valid, email tidak diubah
├── FAIL: Tanda tangan tidak valid (email diubah atau palsu)
└── NONE: Tidak ada DKIM signature
PUBLIC KEY DI DNS:
google._domainkey.domain.com TXT
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."
COMPONENTS:
├── v=DKIM1 : Versi
├── k=rsa : Key type (rsa atau ed25519)
├── p=... : Public key (base64)
├── t=s : Flags (s = strict; i = testing)
└── h=sha256 : Hash algorithm
KONFIGURASI DKIM:
1. Generate key pair:
openssl genrsa -out private.key 2048
openssl rsa -in private.key -pubout -out public.key
2. Tambahkan public key ke DNS:
selector1._domainkey.domain.com TXT
"v=DKIM1; k=rsa; p=<public_key_content>"
3. Konfigurasi email server untuk menandatangani dengan private key
4. Rotasi key secara berkala (setiap 6-12 bulan):
├── Buat key baru dengan selector baru (selector2)
├── Tambahkan public key ke DNS
├── Tunggu TTL DNS expire (24-48 jam)
├── Mulai gunakan selector2
└── Hapus selector1 setelah periode transisi
CATATAN PENTING:
├── DKIM tidak menentukan apa yang harus dilakukan jika FAIL
│ └── Itu tugas DMARC
├── Gunakan RSA 2048-bit atau Ed25519
│ └── Jangan RSA 1024-bit — sudah tidak aman
├── Tanda tangani minimal headers: From, To, Subject, Date
├── Rotasi key secara berkala — jika private key bocor, semua email bisa dipalsukan
└── DKIM juga memvalidasi integritas — email tidak bisa diubah di tengah jalan
DMARC: Domain-based Message Authentication, Reporting, and Conformance
DMARC adalah kebijakan yang memberi tahu server penerima apa yang harus dilakukan jika email gagal autentikasi SPF atau DKIM. DMARC juga menyediakan mekanisme pelaporan sehingga pemilik domain bisa melihat siapa yang mengirim email atas nama domain mereka.
CARA KERJA DMARC
DMARC CHECK:
├── Apakah SPF PASS? (atau aligned?)
├── Apakah DKIM PASS? (atau aligned?)
├── Apakah domain di From: header aligned dengan domain yang diautentikasi?
└── HASIL:
├── PASS: SPF dan/atau DKIM pass + domain aligned
├── FAIL: Keduanya gagal atau tidak aligned
└── Tergantung policy (p=) apa yang akan dilakukan
DMARC DNS RECORD:
_dmarc.domain.com TXT
"v=DMARC1; p=reject; rua=mailto:dmarc@domain.com; ruf=mailto:forensics@domain.com; pct=100; sp=reject; aspf=s; adkim=s; fo=1; ri=86400"
TAG PENJELASAN:
v=DMARC1 : Versi DMARC
p= : Policy untuk domain utama
├── none : Hanya monitoring — tidak ada tindakan
├── quarantine : Kirim ke spam/junk folder
└── reject : Tolak email (jangan dikirim)
sp= : Policy untuk subdomain (opsional)
├── none / quarantine / reject
└── Jika tidak di-set: ikut policy p=
pct= : Persentase email yang diterapkan policy (0-100)
├── 100 = semua email
└── 50 = setengah (untuk testing bertahap)
rua= : Aggregate report — ringkasan harian
├── Format: mailto:dmarc@domain.com
└── Bisa multiple: mailto:a@a.com,mailto:b@b.com
ruf= : Forensic report — detail setiap kegagalan
├── Format: mailto:forensics@domain.com
├── Mengandung header asli — sensitif!
└── Pastikan penerima aman
aspf= : SPF alignment mode
├── s (strict): domain harus exact match
└── r (relaxed): subdomain juga boleh (default)
adkim= : DKIM alignment mode
├── s (strict): domain harus exact match
└── r (relaxed): subdomain juga boleh (default)
fo= : Forensic report options (opsional)
ri= : Reporting interval (default: 86400 = 24 jam)
rf= : Report format (default: afrf)
CONTOH KONFIGURASI DMARC:
# Tahap 1: Monitoring (mulai dari sini)
_dmarc.domain.com TXT
"v=DMARC1; p=none; rua=mailto:dmarc@domain.com;"
# Tahap 2: Quarantine 25%
_dmarc.domain.com TXT
"v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@domain.com;"
# Tahap 3: Quarantine 100%
_dmarc.domain.com TXT
"v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@domain.com;"
# Tahap 4: Reject (target akhir)
_dmarc.domain.com TXT
"v=DMARC1; p=reject; rua=mailto:dmarc@domain.com; ruf=mailto:dmarc-forensic@domain.com; pct=100; sp=reject; aspf=s; adkim=s;"
MEMBACA DMARC REPORT:
DMARC aggregate report (XML) berisi:
├── domain: domain yang dilaporkan
├── Policy: p= yang diterapkan
├── SPF result: PASS / FAIL / NONE
├── DKIM result: PASS / FAIL / NONE
├── Source IP: IP mana yang mengirim
├── Count: berapa banyak email
└── Disposition: apa yang dilakukan (none/quarantine/reject)
TOOLS UNTUK ANALISIS DMARC REPORT:
├── dmarcian
├── Postmark DMARC
├── Valimail
├── Agari
├── Cloudflare DMARC Management
└── Custom: parse XML + visualisasi di Grafana
PERJALANAN KE DMARC REJECT:
Minggu 1-2: p=none (kumpulkan data — siapa yang kirim email atas nama domain?)
Minggu 3-4: Analisis report, perbaiki masalah
├── Ada email legitimate yang gagal SPF/DKIM?
└── Perbaiki: tambah IP ke SPF, setup DKIM untuk semua pengirim
Bulan 2: p=quarantine pct=25%
Bulan 3: p=quarantine pct=100%
Bulan 4: p=reject (target akhir — domain tidak bisa di-spoof)
Setelah p=reject: attacker tidak bisa kirim email phishing
mengatasnamakan domain Anda
Konfigurasi Lengkap SPF + DKIM + DMARC
CONTOH KONFIGURASI LENGKAP UNTUK DOMAIN
Domain: example.com
Email Provider: Google Workspace + SendGrid untuk transactional
1. SPF RECORD:
example.com TXT
"v=spf1 include:_spf.google.com include:sendgrid.net -all"
2. DKIM RECORDS:
google._domainkey.example.com TXT
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg..."
sendgrid._domainkey.example.com TXT
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg..."
3. DMARC RECORD:
_dmarc.example.com TXT
"v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100; sp=reject; adkim=s; aspf=s;"
VERIFIKASI KONFIGURASI:
1. Cek SPF:
dig TXT example.com | grep spf
Atau: nslookup -type=TXT example.com
2. Cek DKIM:
dig TXT google._domainkey.example.com
Atau: nslookup -type=TXT google._domainkey.example.com
3. Cek DMARC:
dig TXT _dmarc.example.com
Atau: nslookup -type=TXT _dmarc.example.com
4. Online validators:
├── dmarcian.com/domain-checker
├── mxtoolbox.com
├── dmarctester.com
└── learndmarc.com
5. Kirim email uji:
Kirim ke Gmail → lihat headers
├── SPF: PASS
├── DKIM: PASS
└── DMARC: PASS
COMMON MISTAKES:
├── SPF: melebihi 10 DNS lookups
│ └── Solusi: subdomain terpisah, flatten SPF (jasa eksternal)
├── SPF: multiple SPF records (hanya boleh satu)
│ └── Solusi: gabungkan jadi satu record
├── DKIM: key terlalu lemah (1024-bit)
│ └── Solusi: gunakan minimal 2048-bit RSA
├── DKIM: lupa rotasi key
│ └── Solusi: jadwalkan rotasi setiap 6 bulan
├── DMARC: langsung p=reject tanpa monitoring
│ └── Solusi: mulai dari p=none, bertahap ke reject
├── DMARC: subdomain tidak di-cover
│ └── Solusi: gunakan sp= untuk subdomain
├── DMARC: lupa setup rua (tidak bisa lihat report)
│ └── Solusi: rua wajib — gunakan jasa analisis DMARC
└── Forgotten senders: third-party yang kirim email atas nama domain
└── Contoh: CRM, marketing platform, support desk, invoicing
MTA-STS dan TLS Reporting
MTA-STS (MTA STRICT TRANSPORT SECURITY)
MTA-STS memaksa koneksi email antar server menggunakan TLS terenkripsi.
Tanpa MTA-STS, TLS bersifat opportunistic — email bisa dikirim tanpa enkripsi
jika server penerima tidak mendukung TLS (downgrade attack).
MTA-STS POLICY (HOSTED DI WEB SERVER):
https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: aspmx.l.google.com
mx: alt1.aspmx.l.google.com
mx: alt2.aspmx.l.google.com
max_age: 604800
MTA-STS DNS RECORD:
_mta-sts.example.com TXT
"v=STSv1; id=2026071301"
CARA KERJA:
├── Server pengirim cek DNS: _mta-sts.domain TXT
├── Ambil policy dari HTTPS
├── Verifikasi TLS certificate (valid + trusted CA + match hostname)
├── Jika enforce: PUTUSKAN koneksi jika TLS tidak valid
├── max_age: cache policy selama X detik (604800 = 7 hari)
└── id: increment setiap kali policy berubah
TLS REPORTING (TLS-RPT):
_smtp._tls.example.com TXT
"v=TLSRPTv1; rua=mailto:tls-report@example.com"
Menyediakan laporan harian tentang:
├── Koneksi TLS yang berhasil
├── Koneksi TLS yang gagal
├── Alasan kegagalan: certificate expired, tidak ada TLS, hostname mismatch
└── Sumber IP yang mencoba mengirim dengan/without TLS
BIMI: Brand Indicators for Message Identification
BIMI (BRAND INDICATORS FOR MESSAGE IDENTIFICATION)
BIMI memungkinkan brand menampilkan logo terverifikasi di inbox
email penerima (Gmail, Apple Mail, Yahoo, dll.) sebagai bukti
visual bahwa email telah diautentikasi.
PRASYARAT BIMI:
├── DMARC: harus p=quarantine atau p=reject (bukan p=none)
├── SPF: PASS
├── DKIM: PASS
├── Domain: aligned
└── Logo: format SVG Tiny PS (SVG P/S)
BIMI DNS RECORD:
default._bimi.example.com TXT
"v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/cert.pem"
VMC (VERIFIED MARK CERTIFICATE):
├── Sertifikat yang memverifikasi kepemilikan logo
├── Diterbitkan oleh Certification Authority (DigiCert, Entrust)
├── Membutuhkan trademark registration
├── a= tag di BIMI record mengarah ke VMC
└── Wajib untuk Gmail dan beberapa provider
MANFAAT BIMI:
├── Meningkatkan brand trust di inbox
├── Meningkatkan email open rates (+10% rata-rata)
├── Membedakan email legitimate dari phishing
├── Insentif untuk implementasi DMARC reject
└── Indikator visual: pengguna bisa lihat logo terverifikasi
Analisis Header Email
MEMBACA EMAIL HEADERS UNTUK INVESTIGASI
CONTOH EMAIL HEADERS (DARI GMAIL):
Delivered-To: user@gmail.com
Received: by 2002:a05:6a00:xxx with SMTP id xxx;
Mon, 13 Jul 2026 10:30:00 +0700 (WIB)
Return-Path: <bounce@example.com>
Received: from mail.example.com (mail.example.com [192.0.2.1])
by mx.google.com with ESMTPS id xxx
for <user@gmail.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384);
Mon, 13 Jul 2026 10:30:00 +0700 (WIB)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=selector1;
h=from:to:subject:date;
bh=abc123...;
b=xyz789...
From: "John Doe" <john@example.com>
To: user@gmail.com
Subject: Important Update
Date: Mon, 13 Jul 2026 10:30:00 +0700
Message-ID: <20260713103000.12345@example.com>
Authentication-Results:
mx.google.com;
spf=pass (google.com: domain of bounce@example.com designates 192.0.2.1 as permitted sender) smtp.mailfrom=bounce@example.com;
dkim=pass header.i=@example.com header.s=selector1;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com
APA YANG DICEK:
1. RETURN-PATH (ENVELOPE FROM)
├── bounce@example.com
├── Ini yang divalidasi SPF
└── Apakah domain-nya legitimate?
2. FROM HEADER (DISPLAY FROM)
├── "John Doe" <john@example.com>
├── Ini yang divalidasi DMARC (alignment)
└── Apakah Return-Path header aligned dengan From?
3. RECEIVED CHAIN
├── Setiap server menambahkan Received header
├── Urutan: dari bawah ke atas
├── Cek IP pertama — apakah legitimate?
└── Cek apakah ada hop mencurigakan (IP asing)
4. AUTHENTICATION-RESULTS
├── spf=pass: SPF valid — IP diizinkan
├── dkim=pass: DKIM signature valid
├── dmarc=pass: DMARC aligned + policy dipenuhi
└── Jika spf=softfail, dkim=none, dmarc=fail → PHISHING
5. TANDA-TANDA SPOOFING / PHISHING:
├── Return-Path berbeda jauh dengan From
├── Received pertama dari IP mencurigakan (bukan server organisasi)
├── Tidak ada DKIM-Signature (padahal domain biasanya punya)
├── DKIM domain berbeda dengan From domain
├── Reply-To berbeda dengan From
├── Display name: "CEO Company" <ceo@different-domain.com>
└── Urgency language + attachment/link mencurigakan
TOOLS ANALISIS HEADER:
├── Gmail: Show Original → Lihat headers lengkap
├── mxtoolbox.com/emailheaders.aspx
├── google.com/tools/analyze/email-header
├── dmarcian.com/header-analyzer
└── Manual: baca dari bawah ke atas (Received chain)
Teknik Serangan Email dan Cara Mendeteksinya
TEKNIK SERANGAN EMAIL DAN PERTAHANAN
1. DISPLAY NAME SPOOFING
├── From: "CEO Perusahaan" <ceo@gmail.com>
├── SPF/DKIM/DMARC: tidak relevan — domain berbeda
├── Pertahanan:
│ ├── Email gateway: display name matching rules
│ ├── Banner: "Email dari luar organisasi" [EXTERNAL]
│ └── User training: lihat email address, bukan display name
2. LOOK-ALIKE DOMAIN
├── Dari: microsoft-support@micr0soft.com (0 bukan o)
├── Pertahanan:
│ ├── Domain monitoring: daftarkan domain yang mirip
│ ├── DMARC reject untuk domain sendiri
│ └── Third-party: daftarkan typo domains
3. REPLY-TO SPOOFING
├── From: legitimate@company.com
├── Reply-To: attacker@evil.com
├── Pertahanan:
│ ├── Email gateway: alert jika Reply-To berbeda dengan From
│ └── User training: periksa Reply-To saat membalas
4. BUSINESS EMAIL COMPROMISE (BEC)
├── Attacker kompromi akun email legitimate
├── Kirim dari akun yang sudah dipercaya
├── SPF/DKIM/DMARC: semua PASS (karena legitimate)
├── Pertahanan:
│ ├── MFA wajib — cegah kompromi akun
│ ├── Behavioral analytics: deteksi anomali
│ ├── Payment verification: konfirmasi via channel lain
│ └── Mailbox forwarding rules monitoring
5. HOMOGLYPH ATTACKS (UNICODE SPOOFING)
├── From: admin@amazоn.com (huruf 'о' Cyrillic)
├── Terlihat seperti amazon.com — tapi berbeda
├── Pertahanan:
│ ├── IDN homograph detection di email gateway
│ ├── Punycode conversion untuk domain dengan Unicode
│ └── Restriksi: hanya izinkan ASCII domain
6. ATTACHMENT-BASED ATTACKS
├── File: invoice.pdf.exe (double extension)
├── File: invoice.pdf (sebenarnya HTML dengan malware)
├── Password-protected ZIP (bypass AV scanning)
├── Pertahanan:
│ ├── Block executable attachments
│ ├── Sandbox analysis untuk semua attachment
│ ├── File type verification (magic bytes, bukan extension)
│ └── Block password-protected archives dari eksternal
7. LINK-BASED ATTACKS
├── URL: https://login-office365.com (bukan office.com)
├── URL shortener: bit.ly/xxx → redirect ke phishing
├── Time-bomb URLs: legitimate saat dikirim, redirect ke phishing nanti
├── Pertahanan:
│ ├── URL rewriting + real-time scanning (safe links)
│ ├── Block URL shorteners
│ ├── URL reputation check
│ └── Browser isolation untuk link tidak dikenal
Strategi Keamanan Email untuk Organisasi
STRATEGI KEAMANAN EMAIL — DEFENSE IN DEPTH
LAPISAN 1: AUTENTIKASI (SPF, DKIM, DMARC)
├── Target: DMARC p=reject
├── Progres: p=none → p=quarantine → p=reject
├── Subdomain: sp=reject
├── MTA-STS: enforce TLS
├── BIMI: logo terverifikasi (optional, tapi bagus untuk brand)
└── Hasil: domain tidak bisa di-spoof
LAPISAN 2: EMAIL GATEWAY (FILTERING)
├── Anti-spam: reputation-based, content-based, ML-based
├── Anti-malware: signature + sandbox analysis
├── Anti-phishing: URL rewriting, link scanning, domain reputation
├── Attachment scanning: sandbox detonation, file type verification
├── Impersonation protection: display name matching, look-alike detection
├── Email authentication enforcement: reject jika DMARC fail
└── Provider: Microsoft Defender for Office 365, Proofpoint, Mimecast, Abnormal
LAPISAN 3: MAILBOX SECURITY
├── MFA wajib — phishing-resistant (FIDO2/security key) untuk privileged users
├── Conditional Access: blokir login dari negara/device tidak dikenal
├── Mailbox forwarding rules monitoring — deteksi auto-forward ke attacker
├── Inbox rules monitoring — deteksi rule yang menyembunyikan email
├── Audit logging: siapa yang akses mailbox, dari mana, kapan
└── Account takeover detection: impossible travel, unusual activity
LAPISAN 4: ENDPOINT PROTECTION
├── Link protection: safe links di email + Teams + Office docs
├── Attachment sandbox: detonate di isolated environment
├── Browser isolation: buka link tidak dikenal di remote browser
├── EDR: deteksi jika user menjalankan malware dari attachment
└── DNS filtering: blokir domain phishing di level DNS
LAPISAN 5: USER AWARENESS
├── Phishing simulation: tes berkala (bulanan)
├── Just-in-time training: pelatihan saat user klik link phishing
├── Report button: mudah melaporkan email mencurigakan
├── Regular training: bukan hanya compliance checkbox
└── Metrics: track click rate, report rate, improvement over time
LAPISAN 6: INCIDENT RESPONSE
├── Playbook: email compromise, phishing campaign, BEC
├── Automated response:
│ ├── Pull email from inbox (post-delivery remediation)
│ ├── Block sender domain/IP
│ ├── Reset password untuk user yang terpengaruh
│ └── Alert SOC
├── Investigation tools:
│ ├── Email header analysis
│ ├── URL/link analysis
│ └── Attachment sandbox result
└── Post-incident:
├── Laporan ke regulator jika data bocor
├── Lessons learned
└── Update aturan filtering
Kesimpulan
Email security bukan fitur premium. Ini adalah kebutuhan dasar untuk setiap organisasi yang menggunakan email — dengan kata lain, setiap organisasi. Lebih dari 91% serangan siber dimulai melalui email; mengabaikan email security berarti membuka pintu depan untuk attacker.
Tiga langkah yang harus dilakukan setiap organisasi:
Dorong DMARC hingga p=reject. Ini adalah satu-satunya mekanisme yang mencegah domain digunakan dalam serangan phishing dan spoofing. Mulai dari p=none untuk mengumpulkan data, perbaiki masalah autentikasi, lalu naikkan bertahap ke quarantine dan akhirnya reject. Domain tanpa DMARC reject bisa di-spoof oleh siapa pun — dan attacker tahu itu.
Konfigurasikan SPF dan DKIM dengan benar. DMARC tidak berfungsi tanpa keduanya. Pastikan setiap layanan yang mengirim email atas nama domain terdaftar di SPF dan memiliki DKIM signature. Satu layanan yang terlupakan — entah itu CRM, platform marketing, atau sistem invoicing — bisa menjadi sumber kegagalan autentikasi.
Gunakan email gateway modern. Autentikasi adalah lapisan pertama, tapi tidak cukup sendiri. Email gateway dengan kemampuan anti-phishing, sandbox analysis, dan link protection adalah lapisan berikutnya yang wajib ada.
Email security adalah proses bertahap. Mulai dari SPF, lanjutkan ke DKIM, DMARC, MTA-STS, dan BIMI. Setiap langkah mengurangi celah yang bisa dimanfaatkan untuk spoofing dan phishing — melindungi tidak hanya organisasi sendiri, tapi juga organisasi lain yang menerima email dari domain Anda.
Sumber Referensi: RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC), RFC 8461 (MTA-STS), RFC 8460 (TLS-RPT), BIMI Working Group Specifications, NIST SP 800-177 Rev 1 (Trustworthy Email), NSA/CISA Email Security Guidance, Google Workspace Email Security Documentation, Microsoft Defender for Office 365 Documentation.
