Email is still how most South Australian councils and small businesses send invoices, rates notices, quotes, booking confirmations and payment requests. That makes your email domain valuable to criminals. If anyone can send a message that looks like it comes from your domain, they can ask your customers to pay a “new” bank account, send residents a fake overdue notice, or trick your own finance team into paying a fake supplier. The same weakness also hurts genuine mail: providers such as Gmail and Outlook increasingly send unauthenticated messages to junk or reject them. This guide explains the three DNS records that fix most of the problem (SPF, DKIM and DMARC), how to move to an enforcing policy without losing legitimate mail, and the extra controls that stop fake invoice scams. It is general guidance, not legal or security advice for your specific environment; confirm details with your IT provider and current ASD guidance.
How fake emails actually reach people
Not every fake email works the same way, and no single control stops them all. It helps to separate four patterns:
- Exact-domain spoofing. The message claims to be from your real domain. SPF, DKIM and an enforcing DMARC policy are designed to stop this at the receiving mail server.
- Lookalike domains. The criminal registers a similar name, such as an extra letter, a swapped character or a different ending. DMARC on your domain does not stop this; inbound filtering, staff awareness and monitoring for lookalike registrations do.
- Display-name tricks. The sender name says your chief executive or a supplier, but the address behind it is a free webmail account. External-sender tags and staff awareness are the main defences.
- A genuine mailbox taken over. The criminal signs in to a real staff or supplier account, often after phishing a password, then quietly sets forwarding rules and waits for an invoice thread. Multi-factor authentication, sign-in monitoring and payment verification are what stop this.
Business email compromise and payment redirection usually combine several of these patterns, which is why the technical records and the business process both matter.
SPF, DKIM and DMARC in plain words
| Record | What it does | Common mistakes |
|---|---|---|
| SPF (Sender Policy Framework) | A DNS text record listing the servers and services allowed to send mail for your domain. | More than one SPF record on the same domain; more than ten DNS lookups (the limit in the standard), so the record silently fails; forgotten senders such as a newsletter or invoicing tool. |
| DKIM (DomainKeys Identified Mail) | Each sending service signs messages with a private key; receivers check the signature against a public key published in your DNS. | DKIM turned on for Microsoft 365 or Google Workspace but not for the other services that send as you; services signing with their own domain instead of yours; old keys never rotated. |
| DMARC (Domain-based Message Authentication, Reporting and Conformance) | Tells receivers what to do when a message claiming your domain fails SPF and DKIM alignment: nothing (p=none), junk it (p=quarantine) or refuse it (p=reject). It also asks receivers to send you reports. | Publishing p=none and never moving on; no one reading the reports; subdomains left unprotected. |
The important idea is alignment. DMARC only passes when SPF or DKIM passes for the same domain that appears in the visible From address. A newsletter platform that passes SPF for its own domain does not help you; it needs to sign with DKIM for your domain, or send from a subdomain you have set up for it.
What Australian guidance and mailbox providers expect
- ASD guidance. The Australian Signals Directorate’s How to combat fake emails recommends SPF, DKIM and DMARC on every domain, starting DMARC in monitoring mode, moving to quarantine and then reject, applying the policy to subdomains, and capturing and reviewing the reports regularly.
- The ISM. The Information Security Manual includes controls for DMARC records that reject mail failing DMARC checks, including for subdomains, and for rejecting incoming mail that fails DMARC. If you supply SA Government or align with the SA Cyber Security Framework, expect these to come up in security questionnaires (see our guide to the SA ISMF for ICT suppliers).
- Gmail, Yahoo and Outlook. Since 2024 Google and Yahoo have required every sender to authenticate with SPF or DKIM, and bulk senders (Google sets the line at 5,000 messages a day) to use SPF, DKIM and a DMARC record aligned with the From domain. Microsoft applied similar rules to Outlook.com, Hotmail and Live addresses from May 2025. Even if you send far less, authenticated mail is far less likely to land in junk.
- The Spam Act 2003 (Cth). For newsletters and promotions, you need consent, clear sender identification and a working unsubscribe that is honoured within five working days. Providers also expect one-click unsubscribe on marketing mail.
Step one: find every service that sends as you
Most failed DMARC projects fail here. Before you change any policy, list everything that sends email using your domain. For a typical council or small business that includes:
- Microsoft 365 or Google Workspace mailboxes, shared mailboxes and distribution lists
- Accounting and invoicing tools that email invoices and statements (for example Xero or MYOB)
- CRM, marketing and newsletter platforms
- Website contact and booking forms, online payment receipts and e-commerce order emails
- Council systems that send rates notices, library notices, waste bookings or permit updates
- Help-desk and ticketing tools, monitoring alerts and backup reports
- Multifunction printers and scanners that email documents
- Agencies or contractors who send campaigns or notices on your behalf
Give each one an owner and decide whether it should send from your main domain or a dedicated subdomain (for example a subdomain just for newsletters). Subdomains keep a noisy marketing tool from affecting the reputation of your staff mail. If your systems are connected, our reference architecture for CRM and accounting integration with Xero and MYOB shows where these outbound messages typically come from.
A safe path from monitoring to reject
- Publish SPF and turn on DKIM for your main mail platform first, then for each other sender on your list. Keep SPF to one record and within the lookup limit.
- Publish DMARC in monitoring mode with aggregate reporting switched on, so receivers tell you who is sending as you. Send reports to a dedicated mailbox or a DMARC reporting service rather than a person’s inbox, because they are machine-readable files that arrive daily.
- Read the reports for two to four weeks. Every source should be either a known, fixed sender or something to block. Fix alignment for the legitimate ones; this is where most of the work is.
- Move to quarantine, optionally for a percentage of mail first, and watch the reports and help desk for genuine messages going to junk.
- Move to reject once reports are clean, and set the subdomain policy to reject as well unless a subdomain needs its own record.
- Keep watching. New tools get bought, suppliers change, keys need rotating. Make DMARC review part of onboarding any new system that sends email.
Typical records look like this (your provider gives the exact values):
- SPF:
v=spf1 include:(your mail provider) include:(your invoicing tool) -all - DMARC to start:
v=DMARC1; p=none; rua=(your reporting address) - DMARC when ready:
v=DMARC1; p=reject; sp=reject; rua=(your reporting address)
Do not forget parked domains
Councils and businesses often own extra domains: old names, campaign domains, alternative endings. Criminals love unused domains because no one is watching them. For any domain that never sends email, publish an SPF record that allows nothing (v=spf1 -all), a DMARC record at p=reject, and a “null MX” record so other servers know it does not accept mail.
Stopping fake invoices: controls beyond DNS
- Verify every change of bank details by phone using a number you already hold, never one in the email. Require a second person to approve changes to supplier or payee details, and tell your customers how you will (and will not) ever ask them to change payment details.
- Use strong MFA on every mailbox, with phishing-resistant methods for finance, executives, elected members and administrators. Our guide to Zero Trust and Conditional Access covers the policies, and our Essential Eight guide covers the wider baseline.
- Alert on suspicious mailbox rules. New rules that forward mail externally, delete messages or move them to obscure folders are a classic sign of takeover. Block automatic forwarding to external addresses unless there is an approved reason.
- Enforce DMARC on inbound mail and tag messages from outside the organisation, so a fake “internal” message stands out.
- Watch for lookalike domains of your own name and of your key suppliers, and register the most obvious variants of your own domain.
- Make reporting easy. Give staff a one-click way to report suspicious mail and thank them when they do.
If it happens
If money has been sent to a criminal, contact your bank immediately: speed matters for any chance of recovery. Report the incident through ReportCyber on the ASD cyber.gov.au website, reset the affected accounts, revoke active sessions, remove malicious mailbox rules and check what the attacker could see. If personal information was accessed, assess whether it is an eligible data breach; our guide to the Privacy Act and notifiable data breaches explains the steps.
A 90-day plan
- Weeks 1 to 2: inventory. List every domain you own and every service that sends as you, with an owner for each. Check the current SPF, DKIM and DMARC records.
- Weeks 3 to 4: authenticate. Fix SPF, turn on DKIM for each sender, lock down parked domains and publish DMARC in monitoring mode with reports.
- Weeks 5 to 8: fix alignment. Work through the reports sender by sender, move marketing mail to a subdomain if needed, and retire senders no one owns.
- Weeks 9 to 10: quarantine. Step up the policy, watch for genuine mail in junk, and tighten mailbox controls: MFA, forwarding rules and alerting.
- Weeks 11 to 12: reject and embed. Move to reject, document the payment verification process, brief staff and customers, and add DMARC checks to the onboarding of any new system.
Questions to ask your IT provider
- What DMARC policy do our domains have today, and who reads the reports?
- Which services send email as us, and does each one pass DKIM with our domain?
- Are our parked and unused domains protected so they cannot be used for fake email?
- Is MFA enforced on every mailbox, and are finance and admin staff using phishing-resistant methods?
- Will we be alerted if someone creates a forwarding rule or signs in from an unusual place?
- What is our written process for verifying a change of bank details, and has it been tested?
- Who adds a new sending service to SPF and DKIM when we buy a new tool?
This article reflects common practice as at late 2026. Mailbox provider rules and ASD guidance change, so confirm current requirements with your email platform, cyber.gov.au and your advisers before changing policies.
Talk to an Adelaide team
If you want your domain protected against spoofing without losing legitimate invoices, notices or newsletters, talk to us about an email security review or call 0402 401 584. We can start with a short, fixed-price review of your domains, sending services and mailbox controls that produces a prioritised plan you can use with any supplier. You can also read about our managed IT and cyber security and cloud and DevOps services.