Draft status: this is a first-draft explainer published to seed the Resources section. Specific numbers, Pacific examples and customer quotes are placeholders — edit before promoting.
If you’ve ever received an email “from your CEO” that turned out to be a scammer, you’ve already met the problem DMARC was designed to fix.
Without three small pieces of DNS configuration — SPF, DKIM and DMARC — your business domain can be impersonated by anyone with a working knowledge of email. They don’t need to hack your servers. They don’t need to breach your Microsoft 365. They just send mail from yourname@yourdomain.com and most receiving servers accept it.
Across the Pacific, the vast majority of business domains we check fall short of basic email authentication. Most owners don’t realise. This post explains what to do about it.
The three layers, in plain English
SPF — Sender Policy Framework is a public list of mail servers allowed to send email for your domain. When a receiving server gets a message claiming to be from yourdomain.com, it checks the list. If the sending server isn’t on it, the message is suspect.
DKIM — DomainKeys Identified Mail is a cryptographic signature attached to outbound mail. The receiving server uses your published public key to verify that the message was sent by an authorised system, and that nothing has tampered with it in transit.
DMARC — Domain-based Message Authentication, Reporting and Conformance is the policy that ties SPF and DKIM together. It tells receiving servers what to do when a message fails authentication: nothing, quarantine to spam, or reject outright. It also generates reports so you can see who’s trying to spoof you.
You need all three. SPF and DKIM are the locks; DMARC is the rulebook for what happens when someone fails the lock check.
What “no DMARC” actually means
If your domain has no DMARC policy — or a policy of p=none — receiving servers will note the failure in reports but still deliver the message. Your customers see a perfectly normal-looking email from your CEO asking them to wire payment to a new account. Your bank sees a request to change settlement details. Your suppliers see an invoice with new payment terms.
You don’t find out until somebody loses money.
A common pattern across Pacific businesses we’ve assessed:
- SPF exists but is too permissive (
?allor~allinstead of-all) - DKIM isn’t configured at all
- DMARC isn’t published
Each of those is fixable in an afternoon. The risk between today and that afternoon is real.
How to deploy DMARC safely
The mistake most teams make is publishing p=reject immediately. Reject means receiving servers throw out anything that fails authentication. If your real mail isn’t fully authenticated — and most isn’t, on day one — you start losing legitimate email.
The right sequence:
- Inventory who sends mail for you. Microsoft 365, your CRM, your marketing tool, the booking system, the payroll provider, the IT vendor’s helpdesk. All of them.
- Publish SPF and DKIM correctly for each. Most platforms have step-by-step DNS instructions.
- Publish DMARC at
p=nonewith arua=reporting address. This logs everything without changing delivery. - Wait two weeks. Read the reports. Find the senders you forgot. Fix their SPF/DKIM.
- Move to
p=quarantine. Failing mail now lands in spam, not the inbox. - Wait another two to four weeks. Confirm zero legitimate mail is being affected.
- Move to
p=reject. Now you’re protected.
Most organisations need 6-10 weeks all in. The first three steps are technical; the rest is monitoring patience.
Why this is harder than it looks (and why most businesses don’t finish)
The technical part is the easy half. The hard half is operational:
- You need to actually read the DMARC reports. They’re XML, they come from dozens of receivers, and they’re noisy.
- Every new SaaS tool that sends mail on your behalf adds a new sender to authenticate. If you don’t keep up, that tool’s mail starts bouncing.
- DNS changes need to be planned with whoever holds the registrar account.
- Errors are silent until your real mail stops arriving.
This is exactly why managed DMARC services exist. A few hours per month of expert attention is the difference between “we published DMARC” and “DMARC actually protects us a year later.”
The Pacific angle
Pacific business email is increasingly targeted because attackers know the same patterns work everywhere, but local IT teams are usually smaller. A successful spoof against a regional bank, a government department or a school can stay live for weeks.
The good news: the fix is the same fix used by enterprises worldwide. There’s no Pacific-specific obstacle to running DMARC properly — just a Pacific-specific shortage of internal capacity to do it.
Where to start
If you don’t know your current status, you can check in 10 seconds: head to our free domain check. The result tells you whether SPF, DKIM and DMARC are configured, and how strict your policy is. From there, you can choose to fix it yourself or have us run the managed bundle for you.
Either way, do something. The status quo is that anyone can be you.