Without DMARC, SPF, and DKIM records on your domain, anyone can send email that appears to come from your business address. Suppliers get fooled. Customers get phished. Your brand gets used to commit fraud. Here's what these records do and how to check if yours are configured.
Email spoofing — sending email that appears to come from a domain you don't control — has been possible since email was invented. The three DNS records that prevent it (SPF, DKIM, and DMARC) have existed as standards for over a decade. And yet a significant proportion of New Zealand business domains still don't have them configured correctly.
To check your own domain, go to mxtoolbox.com and run an SPF, DKIM, and DMARC lookup on your domain. Many businesses that believe their email is secure discover that one or more of these records is missing or misconfigured.
SPF — Sender Policy Framework
SPF is a DNS record that lists the mail servers authorised to send email on behalf of your domain. When a receiving mail server gets an email claiming to be from yourbusiness.co.nz, it checks your SPF record to confirm the sending server is on the approved list. If it's not, the receiving server can reject the message or mark it as spam.
A correct SPF record looks something like: v=spf1 include:spf.protection.outlook.com -all (for Microsoft 365 senders). The -all at the end is a hard fail — telling receiving servers to reject mail that doesn't match. Many SPF records use ~all (soft fail), which marks mail as suspicious but still delivers it — less effective than hard fail.
DKIM — DomainKeys Identified Mail
DKIM adds a cryptographic signature to every email sent from your domain. The signature is generated using a private key held by your mail server and verified using a public key published in your DNS. If an attacker intercepts and modifies an email in transit, the DKIM signature breaks — revealing the tampering. For Microsoft 365, DKIM is enabled in the Microsoft Defender admin portal and adds a DNS record to your domain.
DMARC — Domain-based Message Authentication, Reporting and Conformance
DMARC builds on SPF and DKIM, telling receiving mail servers what to do when an email fails authentication checks: nothing (p=none — monitoring only), quarantine it to spam (p=quarantine), or reject it outright (p=reject). DMARC also sends aggregate reports to a specified email address showing you how your domain is being used to send email — including any spoofing attempts.
The critical point: DMARC only protects you if it's set to p=quarantine or p=reject. A DMARC policy of p=none does nothing to stop spoofing — it only provides reporting. Most domains that "have DMARC" are set to p=none and providing no actual protection.
The Correct Configuration
For Microsoft 365 customers, Optimyze configures: SPF with -all, DKIM enabled and published in DNS, and DMARC at p=reject with aggregate reports sent to a monitored mailbox. This configuration means that email claiming to be from your domain that wasn't sent through your authorised mail system will be rejected by properly configured receiving mail servers — preventing your domain from being used in phishing attacks against your suppliers, customers, and staff.
If your domain doesn't have DMARC at p=reject, criminals can send email that looks exactly like it came from you. Your customers receive it. Your suppliers act on it. Your reputation takes the damage.
