Email Authentication (SPF, DKIM, DMARC)

SPF works by publishing a DNS record that lists exactly which mail servers are authorized to send email on a domain's behalf, so a receiving server can check whether the message actually came from an approved source. DKIM adds a cryptographic signature to outgoing mail using a private key, allowing the recipient to verify with a matching public key published in DNS that the message was not altered in transit and genuinely originated from a system holding that key. DMARC then aligns the results of SPF and DKIM with the domain shown in the visible 'From' address and publishes a policy, none, quarantine, or reject, instructing receiving servers what to do with messages that fail alignment, while also generating aggregate reports that show a domain owner exactly who is sending mail using their domain. A related, optional standard called BIMI lets a verified brand logo appear next to authenticated messages in supporting inboxes once DMARC is enforced.

Without these records properly configured, nothing stops an attacker from configuring their own outgoing server to display a 'From' address that matches a trusted domain exactly, since the original email protocol was never designed to verify sender identity. This gap is the technical mechanism behind most email spoofing and a large share of brand impersonation and business email compromise, since a forged message claiming to be from a bank, government agency, or company executive is far more convincing than one from an obviously unrelated address. Indonesian banks, insurers, and government agencies are frequent impersonation targets precisely because they are widely trusted, making full email authentication deployment a meaningful control for protecting both customers and internal staff, and increasingly an expectation under OJK and ISO 27001 communications security guidance.

Deployment is usually gradual: organizations typically start DMARC in monitoring-only mode, reviewing the aggregate reports to confirm every legitimate sending source, internal mail servers, marketing platforms, helpdesk tools, is correctly authorized, before moving the policy to quarantine and eventually reject. Skipping straight to a reject policy without this review risks blocking legitimate mail that has not yet been accounted for. Every domain and subdomain an organization owns should be covered, including ones that never send mail, since an unprotected subdomain is an easy target for an attacker to spoof.