DMARC for Australian SMEs: How to Move from "none" to "quarantine" and "reject" Safely

DMARC is most useful when it reaches enforcement.

A domain sitting forever at p=none may produce reports, but it does not ask receiving mail systems to quarantine or reject unauthorised messages. At the same time, moving directly to p=reject without preparation can interrupt legitimate email.

That tension is where many Australian SMEs get stuck.

They know domain spoofing is a risk. They know invoice fraud is common. They may have seen DMARC records recommended by Microsoft, Google, insurers, clients or IT providers. But they are not sure which systems send email for the domain, what the XML reports mean, or how to avoid breaking Xero invoices, website enquiries, Mailchimp campaigns, CRM messages, booking notifications or helpdesk replies.

The answer is a staged rollout.

Solway Web Consulting provides DMARC implementation and email security consulting for Australian SMEs, including DNS review, Microsoft 365 and Google Workspace checks, third-party sender discovery and practical enforcement planning.

Why DMARC matters for Australian SMEs

Email remains central to business trust. A small accounting firm may send tax documents and invoices by email. A legal practice may coordinate settlements and client instructions. A clinic may send appointment reminders and payment links. A builder may send progress claims. A consultant may send proposals and bank details.

When attackers spoof a domain, they borrow that trust. The recipient sees a familiar business name and a plausible From address. If the message asks for a payment change, a document upload or a login, the damage can happen quickly.

DMARC helps domain owners tell receiving mail systems how to treat mail that claims to be from their domain but does not authenticate properly. It is not a complete anti-phishing solution, because attackers can still use lookalike domains, compromised mailboxes or unrelated Gmail addresses. But it is one of the main controls for reducing direct spoofing of your exact domain.

The Australian Cyber Security Centre's guidance on business email compromise and broader cyber hygiene makes the same practical point: email risk is a business process risk, not just an IT issue. DMARC supports that risk reduction when it is implemented carefully.

Useful official references:

• ACSC guidance on protecting against business email compromise
• Google Workspace email sender guidelines
• Microsoft guidance on configuring DMARC

What DMARC protects against

DMARC protects against unauthorised use of a domain in the visible From address when the message fails both SPF alignment and DKIM alignment.

In plain English, DMARC helps with messages that pretend to be from yourbusiness.com.au but are not sent or signed by systems authorised for that domain.

That matters for:

• invoice fraud
• fake payment detail changes
• supplier impersonation
• fake document sharing messages
• fake quote approvals
• brand abuse
• customer confusion
• domain reputation problems

DMARC does not stop every email attack. If an attacker compromises a real Microsoft 365 mailbox, the message may authenticate because it is genuinely sent from the tenant. If an attacker registers a lookalike domain, such as a missing-letter version of your domain, DMARC on your real domain does not control that separate domain. If a user receives a phishing email from a free webmail account, DMARC on your domain is not the deciding control.

That is why DMARC should sit alongside MFA, passkeys or hardware security keys, secure payment approval processes, endpoint controls, staff awareness and reliable backups. For related account protection, see hardware MFA and passkey setup.

What p=none means

p=none is the monitoring stage.

A DMARC record with p=none tells receiving mail systems not to change delivery handling because of the DMARC policy. It can still request aggregate reports, usually through a rua address. Those reports show mail sources seen by receivers and whether messages passed SPF, DKIM and DMARC.

For example, a business might publish a record that requests reports while leaving policy at none. Over the next few weeks, reports may reveal:

• Microsoft 365 is sending aligned mail
• the website form is failing DKIM and SPF alignment
• Xero is sending legitimate invoice mail but needs domain authentication
• Mailchimp is signing with its own domain rather than the business domain
• an old CRM still sends reminders
• unknown overseas IP addresses are attempting to spoof the domain

This is valuable information. It gives the business evidence before enforcement.

The mistake is treating p=none as the finish line. It is better understood as a discovery and monitoring tool.

What p=quarantine means

p=quarantine asks receiving mail systems to treat failing messages as suspicious. In many environments, this means placing the message in spam or junk, although receivers make their own final decisions.

Quarantine is a useful intermediate step. It applies pressure against unauthorised mail while reducing the immediate risk of outright rejection. Some businesses move to quarantine with a percentage tag first, such as asking receivers to apply the policy to only part of failing mail. Whether that is useful depends on the domain, mail volume and risk appetite.

Before moving to quarantine, legitimate senders should be identified and aligned. That includes staff email, transactional mail, websites, CRMs, accounting platforms and marketing systems.

What p=reject means

p=reject asks receiving mail systems to reject messages that fail DMARC. This is the strongest policy and the usual goal for a mature DMARC implementation.

Reject is appropriate when the business has high confidence that legitimate senders are aligned and that future changes will be managed. It is especially valuable for domains used by clients, suppliers and staff as a trust signal.

But reject is not a badge to rush towards. A domain with unreviewed third-party senders can break important mail at reject. The business might not notice until invoices fail, booking confirmations disappear, or a client reports missing messages.

Why moving too fast can break legitimate email

The biggest DMARC rollout risk is not the DNS syntax. It is incomplete sender discovery.

Many SMEs underestimate how many services send mail for their domain. Microsoft 365 or Google Workspace is only the obvious one. The full list often includes:

• website contact forms
• Mailchimp newsletters
• Xero or MYOB invoices
• HubSpot or other CRMs
• Shopify or WooCommerce notifications
• booking and appointment platforms
• helpdesk systems
• recruitment tools
• payment platforms
• survey tools
• old hosting providers

Each system may need different authentication steps. Some need DKIM CNAME records. Some need SPF includes. Some need a custom return path. Some should send through Microsoft 365 or Google Workspace SMTP instead of directly from a web server. Some should use a subdomain.

If those systems are not aligned, a strict DMARC policy can tell receivers to block real mail.

How to identify every service sending email for your domain

Start with business process, not DNS.

Ask where email is generated:

• How do staff send ordinary email?
• Which platform sends invoices?
• Does the website send enquiries, quotes or booking confirmations?
• Is there an email marketing tool?
• Does the CRM send automated mail?
• Are support tickets sent from a helpdesk?
• Do payment providers send receipts?
• Are there legacy systems from a previous website, MSP or agency?

Then compare that list with DNS and DMARC reports. The business list tells you what should exist. The reports tell you what receivers are actually seeing.

For each sender, test a real message. Look at the headers. Confirm SPF pass or fail, DKIM pass or fail, and DMARC pass or fail. More importantly, confirm alignment with the visible From domain.

Reading DMARC reports without drowning in XML

DMARC aggregate reports are usually XML files. They are useful, but not friendly.

At a high level, each report groups messages by source IP, sending domain, authentication result and policy outcome. The useful questions are:

• Which services are sending mail for the domain?
• Which sources pass DMARC?
• Which sources fail DMARC?
• Are failures legitimate platforms that need fixing?
• Are failures likely spoofing attempts?
• Are there old systems still sending mail?
• Is mail volume consistent with the business's expectations?

For a small business, the goal is not to stare at XML forever. The goal is to turn reports into a sender inventory and remediation plan.

Some businesses use a DMARC reporting platform. Others use a consultant to review the data during rollout. Either way, someone needs to interpret the results and make decisions.

A safe DMARC rollout plan

Phase 1: discovery and current DNS review

Review the domain's current SPF, DKIM and DMARC records. Check for duplicate SPF records, too many SPF DNS lookups, missing DKIM selectors, old provider records and syntax errors. Identify whether Microsoft 365 or Google Workspace DKIM is enabled for the custom domain.

Phase 2: monitoring with p=none

Publish or correct a DMARC record with p=none and aggregate reporting. Let reports collect enough data to cover normal business cycles. For some businesses, invoice runs, campaigns, appointment reminders or monthly statements happen only at certain times.

Phase 3: fixing Microsoft 365, Google Workspace and third-party senders

Enable DKIM for Microsoft 365 or Google Workspace. Authenticate Mailchimp, Xero, HubSpot, Shopify, website forms, CRMs, booking systems and helpdesk tools. Remove old senders that are no longer needed. Consider subdomains for bulk or transactional mail where appropriate.

Phase 4: moving to quarantine

Once legitimate senders are aligned, move from p=none to p=quarantine. Monitor reports and user feedback. Watch for legitimate messages that now land in spam.

Phase 5: moving to reject

After the domain has operated cleanly at quarantine, move to p=reject. This gives stronger protection against direct domain spoofing. Keep watching for newly introduced systems that have not been authenticated.

Phase 6: ongoing monitoring

DMARC should be reviewed when the business changes email platform, website host, CRM, accounting system, marketing platform or DNS provider. It should also be checked after mergers, rebrands, new domains or new subdomains.

Common problems during DMARC implementation

Common implementation issues include:

• staff mail authenticates, but website forms fail
• SPF passes, but the Return-Path domain is not aligned
• DKIM passes, but the signing domain belongs to a vendor
• Mailchimp or CRM authentication is incomplete
• Xero or another accounting platform sends from an unverified domain
• a web developer configures a form to send as the visitor's address
• old SPF includes push the domain over the 10 lookup limit
• the business has multiple DNS zones and records are added in the wrong place
• reports are sent to an inbox that nobody monitors

These problems are fixable. The key is to find them before enforcement.

Invoice fraud and domain spoofing

Invoice fraud works because people trust familiar workflows. A message arrives at the right time, uses the right branding and asks for an action that feels normal.

DMARC helps reduce one version of that problem: fake mail sent using the exact business domain. If a criminal sends a payment change request from an unauthorised system using your visible From domain, a strong DMARC policy gives receiving mail systems a clear reason to reject it.

But invoice fraud also happens through compromised real mailboxes and lookalike domains. That is why DMARC should be paired with:

• MFA on Microsoft 365 and Google Workspace
• secure domain registrar access
• payment change verification by phone or known channels
• staff awareness for finance workflows
• restricted admin privileges
• monitoring for mailbox forwarding rules
• secure device and password practices

For broader controls, see Solway Web Consulting's small business cyber security review.

DMARC as an ongoing management service

DMARC is not a one-off DNS record. It is an operational control.

That means someone needs to own it. When marketing adds a new email platform, DMARC should be checked. When the website is rebuilt, forms should be tested. When the accounting system changes, invoice emails should be authenticated. When a new domain is registered, it should have a defensive DMARC policy even if it does not send mail.

Ongoing DMARC management usually includes:

• periodic DNS review
• report monitoring
• sender inventory updates
• testing after supplier changes
• policy enforcement planning
• plain-English reporting for management
• advice on subdomains and parked domains

This is particularly useful for SMEs that do not have an internal security team but do have real business risk tied to email trust.

When to ask for help

Ask for help when:

• you are unsure who sends email for the domain
• the domain handles invoices, client documents or regulated information
• SPF has multiple includes or errors
• DKIM is not enabled for Microsoft 365 or Google Workspace
• DMARC reports show unknown sources
• you want to move from none to quarantine or reject
• clients have reported suspicious messages using your domain
• your insurer, client or regulator has asked about email security

Solway Web Consulting provides DMARC implementation and monitoring for Australian SMEs, including staged rollout from p=none to p=quarantine and p=reject. For businesses in Sydney, related support is available through Sydney CBD small business IT security services.

Ask about DMARC implementation and monitoring Read the SPF, DKIM and DMARC guide