SPF, DKIM and DMARC Explained for Australian Businesses: A Practical Email Authentication Guide

Email authentication is one of those controls that looks simple until a real business domain is reviewed.

The DNS records may appear to exist. Microsoft 365 or Google Workspace may be sending mail. Staff may be receiving replies. Invoices may be going out. Nothing looks broken from the outside.

That does not mean the domain is protected.

For Australian SMEs, professional services firms, clinics, consultants, trades and agencies, business email is still the main channel for invoices, referrals, quotes, client records, password resets and supplier changes. If a criminal can send convincing email that appears to come from your domain, the risk becomes a trust, cash flow and reputation problem.

SPF, DKIM and DMARC are the three core email authentication controls used to reduce that risk. They do not solve every phishing problem, and they do not replace MFA, staff training, endpoint protection or careful payment processes. But when implemented properly, they make it much harder for someone else to use your domain in direct spoofing attacks and they improve the hygiene of your legitimate email.

Solway Web Consulting provides email security and DMARC setup for Australian and Sydney businesses that need practical DNS review, Microsoft 365 or Google Workspace configuration, DMARC monitoring and plain-English recommendations.

Why Australian businesses are taking email authentication seriously

Small and medium businesses in Australia often run lean technology environments. A typical firm might use Microsoft 365 for staff email, Xero for invoicing, a website for enquiries, Mailchimp for campaigns, a CRM for leads and a booking platform for reminders. Each service may send email using the business domain.

That creates a simple question: which systems are actually allowed to send mail for the domain?

If the answer is unclear, the business has a problem. Old suppliers may still be listed in SPF. DKIM may only be enabled for the main mailbox platform. A website form may be sending from an address it does not control. A CRM may send quotes with a generic return path. A marketing tool may use the visible From domain but not sign with an aligned DKIM domain.

Attackers look for exactly this kind of mess. Email spoofing is especially damaging when the target already trusts the brand or the person named in the message. An accountant can be impersonated to send bank detail changes. A law firm can be spoofed during settlement activity. A healthcare clinic can be copied in fake appointment or payment messages. A builder or trade business can be impersonated during staged payments.

The Australian Cyber Security Centre has long warned about business email compromise and invoice fraud risks. Email authentication is only one layer in that wider problem, but it is a useful layer because it helps receiving mail systems distinguish authorised mail from unauthorised use of a domain.

Useful official references:

• ASD Essential Eight explained
• Microsoft guidance on SPF in Microsoft 365
• Google Workspace email authentication overview

What SPF actually does

SPF stands for Sender Policy Framework. In plain English, it is a DNS TXT record that lists the mail servers authorised to send email for a domain.

A simple SPF record might say that Microsoft 365 is allowed to send mail for example.com. Another domain might include Google Workspace, a website host, a CRM and an email marketing platform.

When a receiving mail server gets a message, it can check the domain used in the SMTP envelope, often called the Return-Path or bounce domain. It then looks up the SPF record for that domain and checks whether the sending IP address is permitted.

SPF is useful, but there are limits.

First, SPF checks the envelope domain, not necessarily the visible From address that a person sees. That is why SPF alone does not reliably stop visible From domain spoofing.

Second, SPF has a DNS lookup limit. The SPF specification limits SPF evaluation to 10 DNS lookups. Every include, a, mx, exists and redirect-style mechanism can consume lookups. It is common to see Australian SME domains with too many includes because several old platforms were added over time and never removed. Once the lookup limit is exceeded, SPF can fail in ways that are not obvious to the business.

Third, a domain should have one SPF record. Two separate v=spf1 records do not combine cleanly and usually create a permanent error.

SPF is best treated as an inventory of authorised sending infrastructure. It should be deliberate, short enough to work, and reviewed when suppliers change.

What DKIM actually does

DKIM stands for DomainKeys Identified Mail. It adds a cryptographic signature to outgoing email.

The sending system signs parts of the message with a private key. The matching public key is published in DNS under a selector, such as selector1._domainkey.example.com or a Google-generated selector. The receiving mail system retrieves the public key and checks whether the signature is valid.

In plain English, DKIM helps prove that a message was authorised by a domain and was not materially changed after signing.

DKIM depends on the correct signing domain and selector records. Microsoft 365 and Google Workspace can both sign mail with DKIM, but DKIM is not always enabled by default for custom domains or may be left using a provider domain instead of the organisation's own domain. Third-party systems such as Mailchimp, HubSpot, Shopify, Xero, booking platforms and helpdesk tools may each need their own DKIM DNS records.

Common DKIM problems include DKIM not being enabled for the custom domain, selector records missing from DNS, old selector records left behind after provider changes, and third-party platforms signing with their own domain instead of the business domain.

DKIM is often the most reliable path to DMARC alignment for cloud email because SPF alignment can be affected by forwarding and provider-managed bounce domains.

What DMARC actually does

DMARC stands for Domain-based Message Authentication, Reporting and Conformance.

DMARC ties SPF and DKIM to the visible From domain. It lets a domain owner publish a DNS policy telling receiving mail systems what to do when a message fails DMARC checks. The main policies are:

• p=none, which monitors but does not ask receivers to block
• p=quarantine, which asks receivers to treat failing mail suspiciously, often by placing it in spam
• p=reject, which asks receivers to reject failing mail

DMARC can also generate aggregate reports showing which systems send mail that claims to be from the domain and whether those messages pass SPF, DKIM and DMARC alignment.

DMARC is powerful because it focuses on the domain visible to users. But it needs to be implemented carefully. If legitimate senders are not aligned, a strict DMARC policy can cause real mail to be quarantined or rejected.

Why SPF, DKIM and DMARC must work together

SPF, DKIM and DMARC are separate controls, but they are strongest as a set.

SPF answers: is this sending server authorised for the envelope domain?

DKIM answers: was this message signed by a domain with a valid key?

DMARC answers: did SPF or DKIM pass in a way that aligns with the visible From domain, and what policy should the receiver apply if not?

For DMARC to pass, a message generally needs either SPF alignment or DKIM alignment. It does not need both, but relying on only one is fragile. A sound implementation usually aims for both where possible.

This is why simply adding an SPF include for every platform is not enough. A CRM may pass SPF for its own bounce domain but fail DMARC alignment because the visible From address uses your business domain. A website form may send as reception@example.com through a web host that is not authorised and not DKIM signing as your domain. A marketing system may require both SPF and DKIM setup before it is aligned.

The difference between authentication and alignment

Authentication and alignment are often confused.

An email can pass SPF but not align with the visible From domain. It can pass DKIM but be signed by a third-party domain that does not align. In both cases, the message may be authenticated in a narrow technical sense but still fail DMARC.

The key identifiers are:

• visible From domain: the address users see, such as accounts@example.com
• Return-Path domain: the envelope sender or bounce domain used for SPF
• DKIM signing domain: the domain shown in the d= part of the DKIM signature
• DMARC organisational domain: the domain DMARC uses to judge alignment

DMARC alignment means the authenticated SPF or DKIM domain matches, or is acceptably related to, the visible From domain depending on relaxed or strict alignment settings.

For a business owner, the practical takeaway is this: do not stop at "SPF passes" or "DKIM passes". Check whether the pass aligns with the domain your customers actually see.

Why "email still sends" does not mean authentication is correct

Email is forgiving. That is useful for delivery, but dangerous for assumptions.

A business can send email for months with a broken SPF record. Staff may not notice because some receivers still accept the messages. A DKIM selector may be missing, yet email continues to leave Microsoft 365. A DMARC record may be set to p=none, which means failing mail is reported but not blocked. A third-party invoicing system may deliver mail successfully to some clients while failing authentication at others.

Authentication failures often show up indirectly: mail lands in spam, clients report missing invoices or booking emails, DMARC reports show unknown senders, the domain is spoofed in fake payment messages, or a stricter receiving organisation rejects messages.

This is why an email domain security audit should test actual messages from every important sending source, not just check whether a DNS record exists.

Common SPF, DKIM and DMARC mistakes

The most common mistakes are practical rather than exotic.

Duplicate SPF records are near the top of the list. A domain should not have separate SPF records for Microsoft 365, Google Workspace and Mailchimp. They need to be combined into one valid record while staying within lookup limits.

Too many SPF lookups are also common. This usually happens when old providers remain in DNS or when nested includes expand into several additional lookups. Flattening SPF without understanding the provider's changing IP ranges can create maintenance problems, so this needs care.

Broken DKIM is another regular issue. A business may assume DKIM is enabled because Microsoft 365 or Google Workspace is in use, but the custom domain may not be signing correctly.

Missing third-party authentication is a major source of DMARC failure. Accounting systems, CRMs, email marketing platforms, helpdesk systems, booking tools and website form services often need separate setup.

Website contact forms are a special problem. A form should usually send from a domain the website mailer is authorised to use, with the visitor's email placed in Reply-To.

Microsoft 365 and Google Workspace considerations

Microsoft 365 and Google Workspace both support SPF, DKIM and DMARC, but neither removes the need for DNS governance.

For Microsoft 365, SPF commonly includes Microsoft's sending infrastructure, but Microsoft itself notes that SPF alone is not enough to prevent spoofing of a Microsoft 365 domain. DKIM should be enabled for the custom domain, and DMARC should be introduced in a monitored way.

For Google Workspace, Google recommends setting up SPF and DKIM, and using DMARC to tell receiving servers what to do with mail that does not pass. Google also provides specific guidance for senders, including requirements for bulk senders.

The important point for Australian businesses is that Microsoft 365 or Google Workspace covers only part of the environment. It may cover staff mail, but not necessarily Xero invoices, HubSpot campaigns, website forms, Shopify notifications or helpdesk replies.

Third-party platforms: CRMs, websites, invoicing and email marketing

Every platform that sends email for your domain needs to be identified and assessed.

Common legitimate senders include Microsoft 365 or Google Workspace, Xero or MYOB, Mailchimp, HubSpot, Shopify, WooCommerce, website forms, helpdesk systems, payment platforms and booking tools.

The question is not only "does this platform send?" The question is "does this platform authenticate and align with our From domain?"

Some platforms provide DKIM CNAME records. Some use a custom bounce domain for SPF alignment. Some require verification before signing with your domain. Some may be better configured on a subdomain.

This is where SPF and DKIM consulting becomes valuable. The work is partly DNS, partly mail flow analysis and partly supplier management.

A practical email authentication checklist

Use this checklist before enforcing DMARC:

• List every system that sends mail for the domain.
• Confirm there is only one SPF record.
• Check SPF includes are current and under the DNS lookup limit.
• Enable DKIM for Microsoft 365 or Google Workspace custom domains.
• Confirm DKIM selector records resolve correctly.
• Authenticate third-party platforms individually.
• Test real emails from staff mail, website forms, invoicing, CRM and marketing systems.
• Check SPF alignment and DKIM alignment, not only pass/fail.
• Publish a DMARC record with reporting.
• Start with p=none while reviewing reports.
• Move gradually to quarantine and then reject only after legitimate senders are aligned.
• Review records when changing website hosts, CRMs, email platforms or accounting systems.

When to use an SPF, DKIM and DMARC consultant

Professional help is useful when the business cannot afford accidental mail disruption, when multiple vendors send email, or when DMARC reports are not being reviewed.

An independent consultant should be able to review DNS without unsafe changes, map legitimate senders, configure Microsoft 365 or Google Workspace DKIM, interpret DMARC aggregate reports, identify alignment failures, advise on subdomains, produce a plain-English report and stage enforcement safely.

Solway Web Consulting provides email security and DMARC setup for Australian SMEs, including DNS hygiene, SPF and DKIM review, Microsoft 365 and Google Workspace checks, and practical next steps. Related services include a small business cyber security review and hardware MFA and passkey setup for high-value business accounts.

Final thoughts

SPF, DKIM and DMARC are not magic. They will not stop every phishing email, and they will not fix weak payment approval processes. But they are important controls for any Australian business that relies on email for trust.

The best approach is measured: understand who sends for your domain, fix SPF and DKIM properly, monitor DMARC, then move towards enforcement when the evidence supports it.

For businesses sending invoices, client documents, referrals or regulated information, an Email Domain Security Audit is a practical first step.

Ask about an Email Domain Security Audit View Sydney business security services