Email was never built with authentication in mind. The protocol trusts whatever name a sender types into the “From” field, which means anyone, anywhere, can send a message that looks like it came from your domain. SPF, DKIM and DMARC are the three DNS records that close that gap, and setting them up correctly is one of the highest-value, lowest-cost changes most organisations can make.

For businesses across Papua New Guinea and the Pacific, this matters more than most people realise. Email remains the primary channel for invoices, purchase orders and payment instructions between businesses, government departments and banks. A convincing spoofed email requesting a change of bank details or an urgent transfer can do far more damage than a blocked attachment ever could.

Why Anyone Can Send Email “From” Your Domain

The email system was designed in an era when trust between mail servers was simply assumed. Nothing in the core protocol stops a sender from typing any address into the “From” field, including yours. This is what makes spoofing possible: an attacker doesn’t need to breach your systems, only convince a mail server somewhere to accept a message claiming to be from you.

SPF, DKIM and DMARC exist to close that gap. They give receiving mail servers, such as Gmail, Outlook, or a local ISP’s mail platform, a way to check whether a message claiming to be from your domain was actually authorised to be sent, and whether it arrived unmodified.

SPF: Who’s Allowed to Send

Sender Policy Framework (SPF) is a DNS record that lists which mail servers are permitted to send email on behalf of your domain. When a message arrives, the receiving server checks the sending server’s address against your SPF record. If it isn’t listed, the message fails the check.

SPF sounds simple, but it breaks easily. Every service that sends email using your domain, whether that’s a website contact form, an accounting platform, or a marketing tool like HubSpot, needs to be added to the record. Businesses often discover missing entries only after legitimate email starts landing in spam.

DKIM: Proving the Message Wasn’t Altered

DomainKeys Identified Mail (DKIM) adds a digital signature to outgoing messages, generated using a private key that only your mail system holds. The matching public key sits in a DNS record. Receiving servers use it to confirm the message genuinely came through your infrastructure and wasn’t altered along the way.

Where SPF checks the sending server, DKIM checks the message itself. A message can pass SPF and still fail DKIM, or the reverse, which is one reason the two are meant to work together rather than as substitutes for each other.

DMARC: The Record That Actually Takes Action

Domain-based Message Authentication, Reporting and Conformance (DMARC) is the record that ties SPF and DKIM together and tells receiving servers what to do when a message fails both checks: let it through, send it to spam, or reject it outright. Without a DMARC record, receiving servers make that call on their own, inconsistently, and you get no visibility into what’s happening.

DMARC also generates reports showing who is sending email using your domain, including services you may have forgotten about and, occasionally, attackers actively trying to spoof it. That visibility is often the most valuable part of the whole setup.

Why Pacific Businesses Are Particularly Exposed

Organisations across PNG and the wider Pacific often run a wider mix of sending services than they realise: a local ISP for day-to-day mail, an accounting platform for invoices, a marketing tool for newsletters, and sometimes a branch office with its own arrangement entirely. Each one needs to be accounted for in SPF, DKIM and DMARC, and each one is easy to miss.

Business email compromise scams, where an attacker impersonates a supplier, a finance contact or an executive to redirect a payment, are already a significant and growing cost worldwide. In a region where email is often the primary way businesses coordinate payments and instructions across islands and time zones, the absence of these records leaves an easy opening that costs an attacker nothing to try.

A Practical Checklist for Getting Started

• Inventory every service that sends email using your domain, not just your primary mail platform.
• Publish an SPF record covering all of them, and keep it updated as services change.
• Enable DKIM signing on each sending service and publish the matching public keys.
• Publish a DMARC record starting in monitoring mode before any enforcement.
• Review DMARC reports regularly to catch missing services or genuine spoofing attempts.
• Move to quarantine, then reject, only once reporting shows nothing legitimate will be blocked.
• Revisit the setup whenever a new sending service or marketing platform is introduced.

None of these records require new hardware or ongoing licensing costs, which makes them one of the better returns on effort available in cybersecurity. The main requirement is patience: get the inventory right, watch the reports, and move to enforcement in stages rather than all at once.

Important: This article provides general guidance only. DNS and email authentication changes can affect mail delivery and should be planned, tested and rolled out in stages by appropriately qualified personnel.