Email Security for Singapore Businesses: Why DMARC, DKIM and SPF Are No Longer Optional

Email remains the single most common entry point for cyberattacks against Singapore businesses. Business Email Compromise (BEC) — where attackers impersonate executives, suppliers, or trusted partners to redirect payments or harvest credentials — costs Singapore organisations hundreds of millions of dollars each year. Yet a significant proportion of these attacks could have been blocked at the DNS layer with three technical controls most IT teams have heard of but fewer have fully implemented: SPF, DKIM, and DMARC.

These email authentication standards work together to prevent your domain from being spoofed. Without them, any attacker in the world can send email that appears to come from your company — your CEO, your finance director, your legal team — with no technical barrier whatsoever. With them correctly deployed, spoofed emails are rejected before they ever reach a recipient's inbox.

This guide explains what each control does, why partial deployment is dangerous, and the practical steps Singapore businesses need to take to get from where most organisations are today — partially configured, monitoring-only — to a hardened email security posture that satisfies MAS TRM, ISO 27001 Annex A, and CSA Cyber Trust Mark requirements.

What SPF, DKIM, and DMARC Actually Do

The three controls are distinct and complementary. Understanding what each one does — and does not do — is essential to understanding why all three are necessary.

SPF: Sender Policy Framework

SPF is a DNS TXT record that specifies which mail servers are authorised to send email on behalf of your domain. When a receiving mail server gets a message claiming to be from yourdomain.com.sg, it checks your SPF record to see whether the sending server is on the approved list. If it isn't, the message fails SPF.

SPF alone has a critical limitation: it checks the envelope sender (the technical FROM address used in SMTP), not the From header that users see in their inbox. This means an attacker can pass SPF while still spoofing the visible From address — a gap that DMARC closes.

DKIM: DomainKeys Identified Mail

DKIM uses public-key cryptography to sign outgoing messages. Your mail server attaches a digital signature to each email using a private key. Receiving servers retrieve the corresponding public key from your DNS and verify the signature. If the email was tampered with in transit, or if it wasn't actually signed by your mail server, DKIM fails.

DKIM provides message integrity — it proves the email wasn't modified after it left your server — and it links the message to your domain via a selector record in DNS. Like SPF, DKIM alone is not sufficient: it proves authenticity but doesn't tell receiving servers what to do with unauthenticated messages.

DMARC: Domain-based Message Authentication, Reporting and Conformance

DMARC is the policy layer that ties SPF and DKIM together. A DMARC DNS record tells receiving mail servers what to do with messages that fail authentication: nothing (p=none), quarantine them to spam (p=quarantine), or reject them outright (p=reject). Critically, DMARC also introduces alignment — it requires that the domain in the visible From header matches the domain used in either SPF or DKIM authentication, closing the spoofing gap that SPF alone leaves open.

DMARC also provides aggregate reporting: receiving servers send daily XML reports to an address you specify, showing which sources sent email from your domain, how many messages passed or failed authentication, and what policy was applied. These reports are invaluable for identifying shadow IT, compromised accounts, and misconfigured mail services.

Why Partial Deployment Is Dangerous — and Common

Most Singapore businesses that have attempted email authentication have SPF published, DKIM signing enabled (often because Microsoft 365 or Google Workspace sets it up by default), but DMARC either missing entirely or set to p=none. This is the most common failure mode — and it provides almost no protection.

A DMARC policy of p=none means "monitor only — don't reject or quarantine anything." It's a starting point for gathering data, not a security control. Organisations that deploy DMARC in monitoring mode and never advance to enforcement are in a worse position than they realise: they have the operational overhead of email authentication without the protection.

• No SPF, no DKIM, no DMARC — your domain can be freely spoofed. Anyone can impersonate your CEO or finance team with no technical barrier.
• SPF only, no DMARC — SPF passes on envelope checks but attackers can still spoof the visible From header. Header spoofing attacks bypass SPF entirely.
• DMARC at p=none — you receive reports but unauthenticated mail is still delivered. Provides visibility, not protection.
• DMARC at p=quarantine — spoofed messages go to spam. Good intermediate step, but determined attackers may craft messages that still get noticed.
• DMARC at p=reject — spoofed messages are rejected at the gateway. This is the target state.

The reason organisations stall at p=none is usually that they don't know all the legitimate sources sending email from their domain. Marketing automation tools, HR platforms, CRM systems, transactional email services — all of these may be sending email on behalf of your domain. Before enforcing DMARC, you need to identify all these sources and either authorise them via SPF includes or ensure they're DKIM-signing with your domain's keys. The DMARC aggregate reports are your discovery mechanism.

The Implementation Roadmap for Singapore Businesses

Getting from zero to p=reject is a structured process, not a one-day task. Here is a realistic phased approach:

Phase 1 — Audit and publish (Week 1–2)

Start by checking your current state. Use a tool like MXToolbox or dmarcian to query your existing SPF, DKIM, and DMARC records. Identify gaps, overly permissive SPF includes (+all or ?all are red flags), and whether DKIM keys are published for all your sending domains, including subdomains.

Publish a DMARC record at p=none with a rua reporting address you control. This begins aggregate report collection without changing any email delivery behaviour. If you have multiple domains (including dormant ones), publish DMARC records for all of them — dormant domains are frequently used for spoofing because they have no authentication controls.

Phase 2 — Analyse reports and authorise all senders (Weeks 2–6)

Review the DMARC aggregate reports daily for the first two weeks, then weekly. For every source showing authentication failures, investigate: is this a legitimate service that should be authorised, or is it an unauthorised sender? Common discoveries include marketing platforms (Mailchimp, HubSpot), transactional email providers (SendGrid, AWS SES), and third-party services that send invoices or notifications on your behalf.

For each legitimate source, either add it to your SPF record or configure DKIM signing with your domain. Update your SPF record carefully — SPF has a limit of 10 DNS lookups, and many organisations hit this limit when they have multiple authorised senders. Use SPF flattening tools if needed.

Phase 3 — Move to quarantine (Week 6–8)

Once aggregate reports show that your legitimate mail sources are authenticating correctly — ideally 95%+ pass rate for mail from your domain — change your DMARC policy to p=quarantine. Monitor for any legitimate mail that starts landing in spam, and resolve those sources before proceeding.

Phase 4 — Enforce rejection (Week 8–12)

With a clean authentication picture, advance to p=reject. At this point, any email that fails DMARC alignment will be rejected by compliant receiving servers. This eliminates domain spoofing as an attack vector — attackers cannot impersonate your domain in the visible From header.

Beyond DMARC: Completing Your Email Security Posture

DMARC, DKIM, and SPF address outbound spoofing — they prevent attackers from impersonating your domain to external recipients. But a complete email security posture also requires inbound controls to protect your users from attacks that don't spoof your own domain.

• Anti-phishing filtering — Advanced threat protection layers (Microsoft Defender for Office 365 Plan 2, Google Workspace's Advanced Phishing and Malware Protection) use machine learning and sandboxing to detect phishing emails that pass authentication checks from legitimate-looking domains.
• Brand impersonation protection — Attackers registering lookalike domains (infinitecybersecur1ty.com, infinite-cybersecurity.com.sg) to impersonate you to your clients. Brand monitoring and takedown services address this vector.
• BIMI (Brand Indicators for Message Identification) — An emerging standard that displays your verified logo in email clients for authenticated messages. Requires DMARC at p=reject and a Verified Mark Certificate (VMC). Singapore financial institutions increasingly use BIMI to signal authenticated communications to customers.
• MTA-STS and TLS-RPT — Enforce encrypted transport for inbound email to your domain, preventing downgrade attacks that strip TLS from email in transit.
• Security awareness training — Technical controls reduce the attack surface but cannot eliminate it entirely. Users who can recognise suspicious emails — even well-crafted ones — add a critical human layer of defence.

Regulatory and Compliance Drivers in Singapore

Email authentication is no longer just good practice — it is increasingly expected by Singapore's regulatory and certification frameworks.

MAS TRM Guidelines place email-borne threats squarely within the cyber resilience requirements for financial institutions. The 2025 revision emphasises phishing and BEC as material threat vectors that institutions must address through both technical controls and staff awareness. An FI that has not enforced DMARC is likely to face observations during an MAS technology risk examination.

ISO 27001:2022 Annex A Control A.8.22 (Web filtering) and the broader set of technology controls under A.8 establish a baseline for controlling inbound and outbound communication threats. DMARC at enforcement is consistent with the control intent, and auditors increasingly ask for evidence of email authentication as part of the A.8 control domain.

CSA Cyber Trust Mark Level 2 assessments evaluate anti-spoofing controls explicitly. Organisations pursuing the Cyber Trust Mark should treat DMARC enforcement as a pre-requisite, not something to address after certification begins.

PDPA obligations create additional urgency: a successful BEC attack that leads to unauthorised disclosure of personal data — customer records redirected to an attacker's account, HR data accessed via credential harvesting — triggers PDPA breach notification obligations. The PDPC's enforcement actions make clear that preventable technical failures are not treated sympathetically.

Practical Steps to Get Started This Week

If your organisation has not yet enforced DMARC, the following steps will begin the process immediately:

• Run a DMARC lookup on your domain at mxtoolbox.com or dmarcian.com. If no DMARC record exists, publish one at p=none with a reporting address today.
• Check your SPF record — ensure it ends with ~all (soft fail) or -all (hard fail), never +all. Count your DNS lookup chain and ensure you're within the 10-lookup limit.
• Verify DKIM keys — for Microsoft 365, check the DKIM page in the Security admin centre. For Google Workspace, check the Apps > Google Workspace > Gmail > Authenticate email settings.
• Set a 90-day target to reach p=reject — and assign ownership to a named individual, not a team. DMARC projects that lack a clear owner stall in the monitoring phase indefinitely.
• Inventory all your domains — including dormant, parked, and marketing domains. Every domain you own is a potential spoofing target.