Email Authentication for Malaysian Businesses: SPF, DKIM and DMARC

The invoice that never arrived

A customer emails to ask where their receipt is. You resend it. It still doesn't land — not bounced, not blocked outright, just quietly filed into a spam folder nobody checks, or dropped without a trace. If your website sends email — order confirmations, contact form replies, password resets, invoices — and any meaningful share of it isn't reaching the inbox, the cause is very rarely your email content. It's almost always that the receiving mail server, running Gmail, Outlook or Yahoo's spam filtering, couldn't confirm your domain actually authorised that message to be sent. Three DNS records fix that, and each does a genuinely different job.

SPF: a guest list for your domain

Sender Policy Framework (SPF) is a DNS record that lists which mail servers are allowed to send email claiming to be from your domain. When a receiving server gets a message from "yourbusiness.com," it checks the SPF record for that domain and asks: is the server that just delivered this message actually on the approved list? If not, that's a strong spam signal.

The catch with SPF alone is that it only checks the technical sending server — the invisible "envelope" address — not the "From:" name a recipient actually sees in their inbox. A message can pass SPF while still showing a spoofed sender name, which is exactly why SPF was never meant to work by itself.

DKIM: a tamper-evident seal on the message

DomainKeys Identified Mail (DKIM) works differently. Your mail system attaches a cryptographic signature to each outgoing message, generated using a private key only you hold. The receiving server looks up the matching public key in your DNS and checks whether the signature is valid and whether the message has been altered since it was signed. Where SPF checks "did this come from an approved server," DKIM checks "was this message actually written by the domain it claims, and has it been tampered with in transit." A message can travel through several forwarding servers and still carry a valid DKIM signature, which is one reason DKIM tends to be more resilient than SPF alone.

DMARC: the policy that ties the first two together, and reports back

Domain-based Message Authentication, Reporting and Conformance (DMARC) is the record that makes SPF and DKIM actually useful for stopping impersonation. It does two things: it states what a receiving server should do with a message that fails authentication (do nothing, quarantine it to spam, or reject it outright), and it asks receiving servers to send back regular reports on mail claiming to come from your domain — which is often the first time a business discovers someone has been spoofing it.

Critically, DMARC also introduces alignment, the detail that trips up most DIY setups. SPF and DKIM can each individually "pass" while checking a different domain than the one a recipient actually sees in the "From:" field — for instance, a marketing platform sending on your behalf might pass its own SPF check while your domain sits unverified in the visible From address. DMARC alignment requires that the domain in SPF or DKIM's own passing check actually matches the domain shown to the recipient, either exactly (strict alignment) or at the organisational-domain level (relaxed alignment, the more common default) (dmarcian, "DMARC Alignment"). Without alignment, DMARC fails even when SPF and DKIM both individually pass — and this is the step most small business email setups miss, because it requires all three records to be configured to actually agree with each other, not just exist.

Why "it worked fine before" doesn't mean it still will

Gmail and Yahoo made authentication effectively mandatory for anyone sending meaningful volumes of mail. Google's official sender guidelines require every sender to authenticate with SPF or DKIM. For senders crossing roughly 5,000 messages a day to personal Gmail addresses, the bar rises to SPF and DKIM both, alignment at the organisational level, and a DMARC record for the sending domain, at minimum monitor-only (p=none) (Google, "Email sender guidelines"). Senders who cross roughly 5,000 messages a day to personal Gmail addresses face additional requirements — a published DMARC policy, a spam complaint rate that stays well under 0.3%, and one-click unsubscribe support on marketing mail — and both Google and Microsoft have moved to permanently rejecting non-compliant bulk mail rather than just spam-foldering it (Google, "Email subscription guidelines for senders"; industry summary at PowerDMARC, "Bulk Email Sender Rules"). Yahoo runs a closely matched set of rules — SPF, DKIM and DMARC required, spam complaints capped, one-click unsubscribe honoured within two days.

Most business websites aren't sending 5,000 emails a day and will never hit the bulk-sender thresholds directly. But the baseline authentication expectation — valid, aligned SPF and DKIM, and a published DMARC record — increasingly applies to any sending domain, not just bulk senders, because spam filters use these signals as a general trust factor regardless of volume. A domain with no SPF record, no DKIM, and no DMARC record at all now reads as a mild red flag to modern filtering, even for a single transactional email a day.

The danger of going straight to "reject"

DMARC's strictest setting, p=reject, tells receiving servers to refuse outright anything that fails alignment. It's the setting that actually stops spoofing — and it's also the setting that, deployed carelessly, silently blocks your own legitimate mail. The standard, safer path is to start at p=none (report-only, nothing gets blocked) for a monitoring period, read the reports DMARC generates to find every legitimate source sending on your behalf — your website's contact form, an invoicing tool, a CRM, a payroll provider, a newsletter platform — get each one properly authenticated, and only then step up to quarantine and eventually reject, often using a percentage rollout (pct=) to catch problems before they affect all mail (Valimail, "DMARC Reject Policy"). Skip that monitoring period and jump straight to reject, and the first sign of trouble is often a customer saying their password reset email never arrived — because it was silently discarded by their own mail provider, on your instruction. Subdomains inherit the parent domain's DMARC policy unless a separate subdomain policy (sp=) is set, which is a common way a strict policy on the main domain unexpectedly blocks mail from a barely-used subdomain nobody remembered was still sending.

Keep transactional mail off your main sending identity

One practical habit worth adopting early: send transactional email — receipts, password resets, order confirmations — from a dedicated subdomain (something like mail.yourbusiness.com or notify.yourbusiness.com) rather than your primary domain, and keep marketing or bulk mail on a separate subdomain again. Each subdomain carries its own sender reputation, its own SPF, DKIM and DMARC configuration, and its own warm-up period with mailbox providers. Isolating them means a marketing campaign that gets flagged for spam complaints doesn't drag down deliverability for the receipt your customer is waiting on, and a struggling transactional stream doesn't poison your newsletter's inbox placement either (Suped, "Should I use subdomains for transactional and promotional emails"). This is a genuinely useful pattern for a growing Malaysian business, but it does add setup work — it isn't worth doing for a single low-volume contact form, only once email volume and variety start to matter to the business.

Where this usually goes wrong in practice

The failure mode worth worrying about is rarely a badly configured DMARC policy — it's more often no DMARC record at all, an SPF record left over from a hosting or email provider that changed years ago, and no DKIM signing configured on the sending service in the first place. None of these are visible from the website itself; they only show up when you check DNS records directly and test actual message delivery. If you're not certain what your domain's current SPF, DKIM and DMARC status is, that uncertainty is itself the answer worth acting on.

An honest option, not a guarantee

Fixing email authentication doesn't guarantee every message lands in the inbox — deliverability depends on sending reputation, content, engagement history and more, and no one can promise inbox placement. What a proper review can do is confirm the DNS-level basics are actually in place and correctly aligned, which is the foundation everything else sits on. JagaWeb's Essential System Review (RM1,500, currently RM999 until 16 September 2026) includes email authentication as one of its eight control points, alongside a decision-ready report and a 30-day action plan for a single site of up to 25 pages. Reach us at sales@jagaweb.my, or on WhatsApp through jagaweb.my, or jagaweb.my.