DMARC, SPF & DKIM Explained: Protect Your Business Email Domain | Cyborium | Robert Braxton

Robert Braxton explains how DMARC, SPF, and DKIM protect your business from email impersonation fraud — and why most Australian SMEs are unknowingly leaving the door open.

Every week, I speak to business owners who are confident their email security is fine. They have Office 365 or Google Workspace. They pay a reputable hosting provider. They have not had any visible email problems. And yet, when we run a domain analysis on their business email domain, the results are consistently alarming. Here is the reality: most Australian small and medium-sized businesses are unknowingly broadcasting an open invitation to cybercriminals to impersonate them — and are simultaneously damaging their own email deliverability by failing to implement three standards that have been available for years. Those three standards are DMARC, SPF, and DKIM. If you do not know what they are, or if you know what they are but have not fully implemented them, this article is for you. What Is Email Domain Impersonation — and Why It Matters When a cybercriminal wants to defraud your clients, suppliers, or employees, one of the most effective methods available to them is email impersonation. They send an email that appears to come from your domain — your business identity — asking for a payment transfer, a credential, or sensitive information. This is called Business Email Compromise (BEC), and it is one of the most financially damaging forms of cybercrime in Australia. The Australian Signals Directorate's annual cyber threat report consistently identifies BEC as a top-three cause of financial loss for Australian businesses — not because of sophisticated technical attacks, but because of social engineering enabled by weak or absent email authentication. The victim of a BEC attack does not receive a virus. They receive what looks like a legitimate email from a trusted source, requesting a completely normal-looking action. The crime is enabled not by breaking your systems but by walking through the front door of your email identity, which you left unlocked. SPF: Declaring Who Is Allowed to Send Email on Your Behalf Sender Policy Framework (SPF) is the foundational layer of email authentication. It is a DNS record that declares, explicitly, which mail servers are authorised to send email using your domain. When an email arrives claiming to be from yourcompany.com, the receiving mail server checks your DNS to see if the server that sent it is on your SPF authorised list. If it is not, the receiving server knows the email is potentially fraudulent. SPF sounds simple — and the basic setup is relatively straightforward. But there are common implementation mistakes that create security gaps: Missing or misconfigured records.** If you have no SPF record at all, any server in the world can claim to send email from your domain and many receiving servers will accept it without question. Too many DNS lookups.** SPF records are limited to 10 DNS lookups. Businesses that use multiple email services — a primary mail provider, a CRM platform, a marketing automation tool, and a transactional email service — often exceed this limit without realising it, causing legitimate emails to fail SPF checks. Overly permissive policies.** An SPF record ending in ~all (soft fail) or +all (pass all) provides minimal protection. A properly configured SPF record should end in -all (hard fail), explicitly rejecting any sender not on the authorised list. DKIM: Cryptographic Proof That Your Emails Are Genuine DomainKeys Identified Mail (DKIM) adds a cryptographic signature to every email you send. This signature is generated using a private key held by your mail server and verified by the receiving server using a public key published in your DNS. The result is a mathematically verifiable proof that the email originated from your domain and has not been tampered with in transit. Any modification to the email — even a single character in the body — invalidates the signature. DKIM matters for two reasons: Authentication.** It provides cryptographic certainty that emails claiming to be from your domain are genuinely authorised by you. Anti-tampering.** It ensures that emails have not been modified between sending and receiving — critical for contracts, financial instructions, and any communication where the integrity of the content matters. Most enterprise email providers (Microsoft 365, Google Workspace) include DKIM capability, but it is often not enabled by default. Many businesses are operating without DKIM signatures even when their provider supports them, simply because no one has turned it on. DMARC: The Policy That Ties Everything Together DMARC — Domain-based Message Authentication, Reporting and Conformance — is the policy layer that tells receiving mail servers what to do when an email fails SPF or DKIM checks. Without DMARC, even a well-configured SPF and DKIM setup provides limited protection. A fraudulent email that fails both checks will still be delivered to the recipient's inbox in many cases because there is no policy telling the receiving server to reject it. DMARC adds that policy. It tells receiving servers: if an email claiming to be from my domain fails authentication checks, quarantine it (send it to junk) or reject it entirely. DMARC also provides a reporting mechanism. When enabled with aggregate reporting addresses, you receive regular reports from receiving mail servers detailing every email that claimed to be from your domain, whether it passed or failed authentication, and where it was sent from. This gives you real-time visibility into whether someone is attempting to impersonate your domain. The critical mistake most businesses make with DMARC:** They configure the record but leave the policy set to p=none. A DMARC policy of "none" means the record exists and reporting may be enabled, but no action is taken when emails fail authentication. Fraudulent emails sail through unchallenged. You have the record — but it offers no protection. The correct progression is: 1. Deploy DMARC with p=none and aggregate reporting enabled 2. Review the reports to understand legitimate email traffic and identify any misconfigurations 3. Advance to p=quarantine (failed emails go to junk) 4. Advance to p=reject (failed emails are not delivered at all) Many businesses complete steps 1 and 2 and never advance. That leaves their domain permanently vulnerable. What a Real Domain Analysis Reveals At Simple Complex Solutions and Cyborium, we run domain analysis audits as part of our cybersecurity advisory work. The findings are consistently revealing — not because businesses have been careless, but because these records are configured once and then forgotten. Across Australian SME domains, the most common findings are: DMARC policy stuck at p=none, providing no actual protection DKIM not enabled despite the mail provider supporting it SPF records with too many lookups, causing deliverability failures for legitimate emails No aggregate reporting address, meaning the business has no visibility into impersonation attempts The practical consequence is a business that believes its email is secure when it is actually an open target for impersonation fraud — and whose legitimate emails may be landing in customers' spam folders because the authentication signals are weak or missing. What to Do Right Now If you are not sure where your domain stands, the first step is a free domain analysis. Several reputable tools allow you to check your DMARC, SPF, and DKIM configuration instantly. If your DMARC policy is p=none or you have no DMARC record at all, that is your priority. Contact your IT provider, your email platform's support team, or reach out to Cyborium directly. This is not a weeks-long project — for most businesses, advancing from p=none to p=quarantine is achievable within days once you have visibility into your legitimate email traffic. The Cyborium email security assessment covers your full domain authentication posture — DMARC, SPF, DKIM, TLS, and BIMI — and produces a prioritised action plan that your IT team or provider can implement immediately. Email security is not glamorous. But it is foundational. And it is one of the few areas where, with three DNS records and the right configuration, you can eliminate an entire category of fraud risk for your business.