DMARC for Australian Businesses: A Microsoft 365 Guide to Stopping Email Spoofing

DMARC for Australian businesses is the cheapest fix for one of the most expensive problems in small business: someone sending invoices, bank detail changes and password resets that look exactly like they came from you. It takes a handful of DNS records and some patience, and in Microsoft 365 you do not need to buy anything extra to do it.

Most advice on this topic is written for marketers who send newsletters. This guide is written for the owner, office manager or IT lead who just wants to stop their domain being used against their own clients, suppliers and staff. We will cover what SPF, DKIM and DMARC actually do, why the usual "we are not a bulk sender" excuse misses the point, how to set it all up in Microsoft 365, and how to move to a reject policy without breaking your own email.

The Australian Cyber Security Centre received more than 84,700 cybercrime reports in 2024-25, roughly one every six minutes, and business email compromise sits near the top of the financial loss column. Spoofed and look-alike email is a big part of that story. A properly enforced DMARC policy will not stop every scam, but it removes the easiest one: an attacker typing your exact domain into the From line.

DMARC for Australian businesses: what it actually does

Email was designed in an era when nobody checked who was really sending a message. The "From" address you see in Outlook is just a label, and anyone with a basic mail server can type any label they like. SPF, DKIM and DMARC are three DNS-based checks that bolt some accountability onto that old design.

DMARC is the policy layer. It tells every receiving mail server three things: check whether the message passed SPF or DKIM in a way that lines up with the visible From domain, here is what to do if it did not (nothing, quarantine it, or reject it), and here is where to send me reports about what you saw. That third part is the underrated one. Reports show you who is sending email using your domain, including systems you forgot you had.

Without DMARC, a receiving server has to guess. Some will deliver a forged invoice from your domain straight to your client's inbox. With a reject policy in place, compliant receivers, including Microsoft, Google and Yahoo, will refuse the forged message before anyone sees it.

The "we are not a bulk sender" myth

Since 2024, Gmail and Yahoo have required SPF, DKIM and DMARC from anyone sending in volume, and Microsoft followed for Outlook.com, Hotmail and Live addresses, with enforcement starting in May 2025. The threshold is 5,000 messages a day to those consumer mailboxes. Non-compliant mail is junked or rejected, and the rejection code you will see in bounce messages is 550 5.7.515.

Plenty of small businesses read that and relax. Fewer than 5,000 emails a day, so the rule does not apply to us. That reading is technically correct and strategically wrong, for two reasons.

First, the bulk rules are about protecting the receiver from you. The bigger risk for a business is the reverse: an attacker sending to your customers as you. Attackers do not need to send 5,000 messages. They need one convincing invoice with changed bank details, sent to one accounts payable officer who has paid your real invoices before. Whether you are a bulk sender has no bearing on whether you can be impersonated.

Second, the same three records that satisfy the bulk rules are what every receiving system checks, whatever your volume. Microsoft 365, Google Workspace, secure email gateways and the mail servers inside your clients' businesses all use them to decide whether to trust a message. If your domain has weak or missing records, your legitimate email is more likely to land in junk too.

How SPF, DKIM and DMARC fit together

It helps to think of a courier delivering a parcel. SPF is the list of couriers you have authorised to collect parcels in your name. DKIM is the tamper-evident seal on the parcel. DMARC is your instruction to the receiving depot: if the parcel arrives with no seal, or from a courier not on the list, here is what to do with it.

The word that trips people up is alignment. A message can pass SPF but still fail DMARC if the domain that passed is not the same as, or a subdomain of, the domain in the visible From address. This is how a lot of marketing platforms and invoicing tools end up failing DMARC even though they look fine in a basic SPF check. They send on your behalf using their own return-path domain, so SPF passes for them rather than for you. DKIM signed with your domain is what rescues them.

Step one is not DNS: build your sender inventory

Here is the part most guides skip, and the one that decides whether your project finishes. The technical work of publishing a DMARC record takes minutes. The slow part is finding every system that sends email using your domain. In our experience, the sender inventory is where projects stall, and it is also why so many Australian domains sit at p=none indefinitely.

Think about everything that can send as you@yourbusiness.com.au:

• Your main mailboxes. Microsoft 365 or Exchange Online, including shared mailboxes and any mail flow connectors.
• Accounting and invoicing. Xero, MYOB, QuickBooks or an ERP that emails invoices and statements.
• Marketing and CRM. Mailchimp, HubSpot, Klaviyo, Campaign Monitor, Salesforce and similar tools.
• Operational systems. Helpdesk platforms, booking and scheduling tools, e-signature, payroll and HR systems.
• Devices and scripts. Multifunction printers that scan to email, monitoring tools, backup alerts and website contact forms.
• Old and forgotten services. A former web developer's SMTP relay, a retired CRM, a trial that never got cancelled.

Start by asking each department what tools email customers on their behalf. Then let DMARC aggregate reports confirm and extend the list. Publish a monitoring-only record first, wait two weeks, and read what the reports show. You will almost always find at least one sender nobody mentioned. That discovery is the real value of the first phase, and it is far cheaper to find it now than after you have told the world to reject unknown senders.

Setting up SPF, DKIM and DMARC in Microsoft 365

The steps below assume your email runs on Exchange Online and your DNS is managed somewhere you can edit TXT and CNAME records, whether that is your registrar, Cloudflare or another host. Make changes outside peak hours and keep a copy of your existing records before you touch anything.

1. SPF: one record, kept short

Your domain should have exactly one SPF record. Two records cause a permanent error, and most receivers treat that as a fail. For a business that only sends through Microsoft 365, the record includes the Microsoft SPF host. If you also use other platforms, each one adds its own include statement to the same record.

SPF allows a maximum of 10 DNS lookups. Every include, a, mx, exists and redirect counts, and so do the lookups nested inside the vendors' own records. Businesses with five or six marketing and operational tools can exceed the limit without noticing, which silently breaks SPF. If you are close, drop retired services first, then prefer DKIM-based authentication for those platforms instead of piling on more includes. During rollout, finish the record with a soft fail (~all). Once DMARC is enforcing, many organisations tighten it to a hard fail.

2. DKIM: switch it on for your custom domain

Microsoft 365 signs mail for your onmicrosoft.com domain by default, but your own domain needs DKIM enabled deliberately. In the Microsoft Defender portal, go to Email and collaboration, then Policies and rules, then Threat policies, then Email authentication settings, and open the DKIM tab. Select your domain and Microsoft will show you two CNAME records, known as selector1 and selector2. Publish both at your DNS host, wait for them to propagate, then switch signing on.

For third-party platforms, follow each vendor's guide to sign with your domain rather than theirs. Where a vendor offers a choice, pick 2048-bit keys. 1024-bit keys still work but are the weaker option and are being phased out by security-conscious receivers.

3. DMARC: start by watching

Publish a TXT record at _dmarc.yourdomain.com.au. For the first phase, the policy is p=none with an rua address that receives aggregate reports. Reports arrive as unreadable XML, so use a DMARC reporting service or a mailbox plus a report parser. Several low-cost tools will turn the files into a readable list of sources, volumes and pass rates. Pick one that is comfortable storing your data in an Australian or otherwise acceptable region if that matters for your obligations.

The rollout plan: from p=none to p=reject

The goal is p=reject, because that is the setting that actually blocks forged email. Getting there safely is a staged process, and the stages are about evidence, not about a fixed calendar. Here is a sensible path for an organisation with a handful of sending platforms.

The pct tag is your safety valve. It applies the policy to only a percentage of failing mail, so a mistake affects a fraction of messages rather than all of them. Step it up once reports show legitimate sources passing, for example 10, 25, 50 and then 100.

Do not skip stage one. Jumping straight to enforcement is the most common way to cause an outage, usually the day the finance team's invoicing platform stops delivering. And do not stay at stage one forever. A domain sitting at p=none reports on spoofing but blocks nothing, which gives leadership a comforting tick on a checklist while the exposure remains. Global monitoring data suggests only around a fifth of sampled domains have reached quarantine or reject, so the gap between "has a DMARC record" and "is protected by DMARC" is wide.

Seven mistakes we see again and again

• Two SPF records. A second record added by a vendor's instructions invalidates the first. Merge them into one.
• Exceeding the 10-lookup limit. Each platform you add pushes you closer. Audit includes every time you adopt a new tool.
• Enabling DKIM too early. Switching on signing before the CNAME records resolve breaks your own mail.
• Forgetting subdomains. Without sp=reject, attackers can spoof a subdomain such as accounts.yourbusiness.com.au even when the main domain is protected.
• Ignoring parked and unused domains. Domains you own but do not send from should publish a null SPF record and a reject policy. They are prime targets for spoofing.
• Nobody reads the reports. A DMARC record that sends reports to an unmonitored mailbox is only half a control.
• Treating it as a one-off. New tools, new staff and new vendors mean new senders. Review reports monthly.

The Australian context: why this is moving up the agenda

Australian government guidance already treats strong email authentication as standard hygiene. The ACSC advises blocking spoofed email with hard-fail SPF and a DMARC reject policy, and the Information Security Manual expects government domains to use DMARC to reject non-passing messages. Private businesses are not bound by the ISM, but the people who are bound by it, and the larger enterprises that follow it, increasingly expect their suppliers to look similar.

That shows up in three practical places. Supplier onboarding questionnaires now ask about SPF, DKIM and DMARC. Cyber insurance applications ask whether you have email filtering and authentication. And Essential Eight and Essentials series conversations, which we cover in our Essential Eight retirement roadmap and our Essential Eight compliance guide for Australian SMBs, keep coming back to the basics of stopping malicious email reaching people and impersonating the organisation.

There is a privacy angle as well. If a spoofed email from your domain tricks a client into handing over personal information, or a compromised mailbox leaks customer data, you may have to assess whether it is a notifiable data breach. Our guide to Privacy Act obligations and Microsoft 365 explains the reasonable steps test, and email authentication is one of the cheapest reasonable steps available. For a broader view of where you stand, see which cyber security rules apply to your business in 2026.

Finally, the scam landscape is changing. New scams legislation is putting more onus on businesses and platforms to show they took reasonable steps to prevent impersonation. Our summary of the Australian scam laws and what they mean when your business gets scammed is worth a read alongside this guide.

A 30-day plan you can start this week

• Days 1 to 3: Check what you have today. Look up your current SPF and DMARC records, note the policy, and confirm DKIM is enabled for your custom domain in Microsoft Defender.
• Days 4 to 7: Build the sender inventory by asking every team which tools email customers. Merge or fix SPF so there is one record and fewer than 10 lookups.
• Days 8 to 14: Publish DMARC at p=none with a monitored reporting address. Enable DKIM for Microsoft 365 and every third-party sender that supports it.
• Days 15 to 21: Read the reports. Fix every legitimate source that is failing alignment. Retire senders you no longer use.
• Days 22 to 30: Move to p=quarantine at 10 percent, then step up. Plan the move to p=reject and publish null records on parked domains.

Realistically, a business with a small number of sending tools can reach quarantine inside a month and reject within a quarter. A business with many platforms, acquired domains or a legacy mail relay needs longer, and that is fine. The aim is steady progress with reporting you can show to an auditor, an insurer or a client.

When to bring in a managed IT partner

You can do all of this yourself, and plenty of IT-savvy owners do. The cases where it pays to get help are the ones with moving parts: a mix of Microsoft 365 and older mail systems, several brands or domains, regulated clients who expect evidence, or no one internally who wants to own the DNS. A managed provider can run the inventory, handle the staged rollout, monitor the reports month after month, and fold the results into your wider security posture alongside Microsoft 365 Business Premium features such as Defender for Office 365.

If you would like a second pair of eyes first, our cybersecurity audit includes an email authentication review, and you can see how we price ongoing support on our managed IT support pricing page. We support businesses across Sydney and Australia, and you can learn more about IT services in Sydney.

Written by Dan Briggs, All IT Services. All IT is a Sydney-based managed IT provider supporting hospitality, not-for-profit and financial services organisations across Australia.