Nothing technically stops someone typing your domain into the "from" field of an email. Without three specific DNS records in place, an attacker can send a message that appears to come from yourbusiness.com.au, and most inboxes will deliver it without complaint. SPF, DKIM, and DMARC are what close that gap - and a surprising number of Perth businesses have one or two of them configured without realising the third is what actually makes the other two effective.
What Email Spoofing Actually Exploits
Standard email was never built with authentication in mind. The "from" address a recipient sees is, by default, just a claim - nothing verifies it belongs to whoever sent the message. This is what lets an attacker send an invoice, a payment change request, or a phishing link that looks like it came from your managing director's email address, without ever compromising an actual account. SPF, DKIM, and DMARC are three separate DNS records that, together, give receiving mail servers a way to check whether a message claiming to be from your domain was actually authorised to be sent.
SPF: Which Servers Are Allowed to Send as You
SPF (Sender Policy Framework) is a DNS text record listing the mail servers and services permitted to send email on behalf of your domain - your Microsoft 365 or Google Workspace tenant, plus anything else that sends as you, such as an accounting platform, CRM, or marketing tool. A receiving server checks the sending server's IP address against this list. If it isn't there, the message fails SPF.
SPF has two well-known limitations worth understanding: it breaks when an email is forwarded through a server not on your list (the forwarding server becomes the "sender"), and it doesn't check the visible "from" name a recipient actually sees, only the technical return-path address behind it. That second gap is exactly what DKIM and DMARC exist to close.
DKIM: A Signature That Proves the Message Wasn't Altered
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing email, generated using a private key your mail server holds and verified using a matching public key published in your DNS. If any part of the message is altered in transit, or the signature doesn't match your published key, DKIM verification fails. Unlike SPF, DKIM travels with the message itself, so it generally survives being forwarded.
DMARC: The Policy That Ties SPF and DKIM Together
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the layer most Perth businesses skip, and it's the one that actually matters most. DMARC does two things: it tells receiving servers what to do with a message that fails SPF and DKIM checks and doesn't align with your domain (do nothing, quarantine it to junk, or reject it outright), and it gives you reporting - a regular summary of every server sending email claiming to be from your domain, including the ones you didn't authorise.
Without a DMARC policy, SPF and DKIM can both be correctly configured and a spoofed message can still land in an inbox, because nothing is enforcing what happens when authentication fails. DMARC is the record that turns "we can technically check this" into "failed messages actually get blocked."
Why You Need All Three, Not Just One
- SPF alone stops some spoofing but is easily defeated by forwarding and doesn't protect the visible sender name.
- DKIM alone proves a message wasn't tampered with, but doesn't verify the sending server was actually authorised.
- DMARC without SPF or DKIM configured properly has nothing to enforce - it depends on the other two to have anything to check alignment against.
- All three together is what closes the loop: authorised senders, verified content, and an enforced policy for anything that fails both checks.
Common Ways Perth Businesses Get This Wrong
- Multiple SPF records instead of one merged record - a domain can only have one valid SPF record; adding a second one for a new tool, rather than merging it into the existing one, breaks SPF entirely.
- DMARC left at
p=noneindefinitely - monitoring mode is the right starting point, but a policy that's never moved to quarantine or reject provides reporting only, with no actual enforcement. - A sending tool forgotten during DMARC rollout - the invoicing platform, the newsletter tool, or the booking system that sends as your domain gets left out of SPF and DKIM setup, then starts failing once enforcement is switched on.
- Nobody reviewing DMARC reports - the reports exist specifically to show unauthorised senders and legitimate senders you've missed, but they go unread in most small businesses because nothing is set up to summarise them.
Rolling Out DMARC Without Breaking Legitimate Email
The safe sequence is to start with a monitoring-only DMARC policy (p=none) with reporting enabled, then actually review those reports over a few weeks to identify every service that legitimately sends email as your domain. Once every real sender is accounted for in SPF and DKIM, the policy can move to quarantine, and eventually to reject, with confidence that legitimate mail won't be caught in the enforcement. Free tools such as MXToolbox can check what SPF, DKIM, and DMARC records currently exist for a domain, which is a useful starting point before making changes.
Frequently Asked Questions
Does Microsoft 365 or Google Workspace set these up automatically?
No. Both platforms sign outgoing mail with their own default DKIM key and generally satisfy basic SPF checks for their own sending, but a custom SPF record for your domain, your own DKIM selector, and a DMARC policy all have to be added manually as DNS records. Without them, your domain has no real protection against someone else spoofing it.
Will setting up DMARC break emails we send through other tools?
It can, if those tools aren't included in your SPF record or set up with their own DKIM signing. This is the most common cause of DMARC rollout problems - a business locks down its main mail platform but forgets that its CRM, accounting software, or marketing tool also sends mail as the business domain. That's exactly why DMARC should start in monitoring mode before any enforcement policy is applied.
How long does SPF, DKIM, and DMARC setup actually take?
The DNS records themselves can be added in under an hour. The part that takes longer is the DMARC rollout - reviewing reports to identify every legitimate sending source before moving from monitoring to enforcement, which is usually a process measured in weeks, not a single sitting.
Do we still need staff training if these are set up correctly?
Yes. SPF, DKIM, and DMARC protect your own domain from being spoofed by someone else - they don't stop a look-alike domain, a compromised supplier account, or a scam that doesn't involve email at all. They're one layer in a broader email security setup, not a complete answer on their own.
We set up and roll out SPF, DKIM, and DMARC properly for Perth businesses, including the reporting review that most providers skip.
Cybersecurity Services →Not sure what your domain's current SPF, DKIM, and DMARC status actually is?
Use our free Email Security Checker for an instant read of your domain's records, or call 0433 087 091 for a free, no-obligation review.
Check My Domain FreeFor related reading, see our guides to Email Security for Perth Businesses and Business Email Compromise: Stop Invoice Fraud.