Every week a Singapore SME discovers the hard way that anyone can send email “from” their domain – a spoofed invoice to a customer, a fake payment instruction to their own finance staff. The fix has existed for years: SPF DKIM DMARC Singapore adoption is just badly behind, which is why the Cyber Security Agency (CSA) promotes DMARC through its Internet Hygiene Portal. This guide explains the three records in plain English and walks through the setup for Microsoft 365 and Google Workspace (the same three records apply to mailboxes on cPanel hosting).
Why your invoices land in spam (and scammers send as you)
Email’s original design lets any server claim any sender address. Without authentication records, receiving servers cannot tell your real mail from a scammer’s – so they guess, and both problems follow: your legitimate mail gets flagged as suspicious, and criminal mail wearing your domain gets through. Since February 2024, Google and Yahoo have required bulk senders (5,000+ messages a day) to have DMARC in place at minimum – authentication has moved from best practice to table stakes, and smaller senders without it are increasingly filtered by association.
The three records, in plain English
| Record | What it does | What it looks like (DNS TXT) |
|---|---|---|
| SPF | Lists servers allowed to send for your domain | v=spf1 include:spf.protection.outlook.com -all |
| DKIM | Adds a cryptographic signature receivers can verify | CNAME selector1._domainkey.yourdomain.sg -> provider key |
| DMARC | Sets policy on failures + sends you reports | v=DMARC1; p=quarantine; rua=mailto:reports@yourdomain.sg |
Email spoofing protection: how the three work together
Real email spoofing protection needs all three, because each covers the others’ blind spots. SPF breaks when mail is forwarded; DKIM survives forwarding but says nothing about what to do on failure; DMARC supplies the missing enforcement – and crucially, it checks alignment: the domain your customer sees in “From:” must match the domain SPF or DKIM validated. That alignment check is what actually stops lookalike spoofing. DMARC’s reporting (the rua address) is the underrated half: aggregate reports show every server sending as your domain, which is how you discover both the spoofers and the legitimate tools – CRM, invoicing, newsletter – you forgot were sending on your behalf.
Set it up: Microsoft 365 and Google Workspace
- Publish SPF – one TXT record on your domain. Microsoft 365: v=spf1 include:spf.protection.outlook.com -all. Google Workspace: v=spf1 include:_spf.google.com ~all. Add includes for any other legitimate senders (invoicing, marketing) – and never publish two SPF records; merge them into one.
- Enable DKIM – in the Microsoft 365 Defender portal or Google Admin console, generate keys, then add the two CNAME (or TXT) selector records they give you. Turn signing on after DNS propagates.
- Publish DMARC in monitor mode – a TXT record at _dmarc.yourdomain.sg: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.sg. Nothing changes for delivery yet; you just start receiving reports.
- Read the reports for 2-4 weeks – add any legitimate senders the reports reveal into SPF/DKIM.
- Tighten to p=quarantine, then p=reject – once reports show only legitimate mail passing, escalate. Reject is the destination; that is the setting that makes spoofed mail bounce instead of landing.
How to read a DMARC report (and what week one actually shows)
Step 4 above is where most rollouts stall. Reports arrive as an email attachment, one per receiving provider, usually once a day, and they are GZIP-compressed XML rather than a readable summary.
Each record covers one sending IP. Four fields do the work: source_ip (who sent), count (how many messages), auth_results (whether SPF and DKIM passed on their own terms) and policy_evaluated (what DMARC concluded, and what the receiver did about it).
Compare the last two. A record showing SPF pass under auth_results but fail under policy_evaluated is not a broken report – it is alignment failing, and it almost always means a third-party service is sending with its own envelope domain. Microsoft’s field-by-field guide to the aggregate report gives the fix: configure that service to use your own domain in the MAIL FROM, or have it sign with DKIM on your domain.
A realistic week one: three or four known IPs passing cleanly, one or two failing alignment – the invoicing tool, the booking system – and a tail of unknown IPs sending at volume and failing everything. That tail is the spoofing. At p=none you are recording it, not stopping it.
Two habits keep it sustainable. Point rua at a dedicated mailbox rather than someone’s inbox, and review weekly while you are rolling out, monthly once the record sits at reject. Raw XML is hard going, so most teams feed it to a reporting service that renders a dashboard; the schema is published in RFC 7489 if you need to check what a field means.
The mistakes that break mail flow
- Two SPF records – instantly invalid; all rules must live in one record.
- Blowing the 10-lookup limit – SPF allows at most 10 DNS lookups; stacking includes from every SaaS tool breaks validation silently.
- Forgetting third-party senders – the accounting system that emails invoices needs to be in SPF/DKIM too, or reject mode will bounce your own invoices.
- Jumping straight to p=reject – without the monitoring phase, you enforce against senders you forgot existed.
- Set-and-forget – every new SaaS tool that sends mail needs adding; review reports quarterly.
Business email security beyond the three records
Authentication stops spoofing of your domain – it does not stop phishing from lookalike domains, compromised accounts or malicious links. Round out business email security with MFA on every mailbox, staff phishing awareness (our SME cybersecurity checklist covers the full stack), advanced filtering, and independent mailbox backup so a compromised or wiped mailbox is recoverable. A properly configured business email setup includes all of this from day one.
Frequently asked questions
What is DMARC vs DKIM vs SPF?
SPF is a DNS record listing the servers allowed to send email for your domain. DKIM adds a cryptographic signature to each message so receivers can verify it was not forged or altered. DMARC sits on top: it checks that the visible From domain aligns with what SPF or DKIM validated, tells receivers what to do on failure (none, quarantine or reject), and emails you reports on everyone sending as your domain.
Do you need SPF and DKIM for DMARC?
You need at least one of them for DMARC to pass, and you should run both – each covers the other’s blind spot (SPF breaks on forwarding; DKIM survives it). DMARC passes when SPF or DKIM validates and the validated domain aligns with the From address. Best practice is SPF plus DKIM plus a DMARC policy escalated to reject once reports are clean.
How do I check my SPF, DKIM and DMARC records?
Look up the TXT record on your domain (SPF), the selector records under _domainkey (DKIM), and the TXT record at _dmarc.yourdomain.sg (DMARC) – free web checkers do all three in one search, and CSA’s Internet Hygiene Portal offers a Singapore-focused check. Or send an email to a Gmail address and use “Show original”, which displays pass/fail for all three on a real message.
Is DMARC required in Singapore?
No law mandates it for general businesses, but the practical pressure is real: CSA actively promotes DMARC adoption, Google and Yahoo require it for bulk senders since February 2024, and enterprise customers increasingly check it before whitelisting suppliers. With 69.6% of Singapore domains still unprotected as of August 2026, having DMARC at reject is also a quiet competitive signal that your invoices are the real ones.
Will DMARC stop all phishing?
No – it stops exact-domain spoofing: mail pretending to be yourdomain.sg. Phishing from lookalike domains (yourd0main.sg), free webmail or compromised real accounts sails past DMARC. That is why authentication is one layer of business email security alongside MFA, filtering, staff training and mailbox backup – necessary, high-value, but not sufficient alone.
How long does a DMARC rollout take?
The DNS work is under an hour. The full rollout – publish in monitor mode, read reports for two to four weeks, add forgotten legitimate senders, then escalate to quarantine and finally reject – typically spans four to eight weeks. The elapsed time is deliberate: it is what prevents your own invoicing system from being bounced on day one of enforcement.
About the author
Written by the Rezolva IT team – we deploy email authentication to full reject policy on Microsoft 365 and Google Workspace for Singapore SMEs, alongside the mailbox security and backup around it. The Singapore adoption figures cited are from dmarcdkim.com’s tracker, checked August 2026.