Email Authentication Basics for Australian SMEs

An invoice that lands in junk does not help your cashflow. A fake invoice that appears to come from your business can do considerably more damage.

Both problems bring us to email authentication. Specifically, SPF, DKIM and DMARC.

The names sound like something best left to the IT team. The business outcomes are much easier to understand: help receiving mail systems recognise your legitimate email, make your domain harder to impersonate, and identify problems before customers start asking awkward questions.

You do not need to become a DNS expert. You do need to know whether these controls are configured properly, who maintains them, and whether they cover every system sending email on your behalf.

Why email authentication matters

Your email domain is part of your business identity. Customers recognise it. Suppliers trust it. Staff use it every day.

That makes it useful to criminals too.

If someone can send a message that appears to come from your domain, they can borrow some of the trust you have spent years building. A fake payment request, a fraudulent change of bank details, or a convincing password reset can quickly become a financial and reputational problem.

Meanwhile, legitimate email needs to satisfy the receiving system's security checks. Incorrect authentication can contribute to rejected messages or delivery problems. That means missed enquiries, delayed approvals and invoices that nobody sees.

SPF, DKIM and DMARC help address these risks. The Australian Cyber Security Centre recommends using them together to reduce domain spoofing and strengthen email authentication.

They are not a guarantee of inbox delivery, and they do not stop every email scam. They are, however, an important part of getting the basics right.

What do SPF, DKIM and DMARC actually do?

Each control answers a different question. Together, they help receiving mail systems decide whether a message claiming to come from your business should be trusted.

SPF: Is this sending system authorised?

Sender Policy Framework, or SPF, identifies the servers and services authorised to send email for a domain used in the message's delivery information.

You publish that information in your Domain Name System, or DNS. When a receiving server checks the message, it compares the sending server against your published SPF record.

The important catch is that SPF does not, by itself, verify the address your customer sees in the From field. That is one reason an SPF record alone is not enough.

DKIM: Does the message have a valid signature?

DomainKeys Identified Mail, or DKIM, adds a digital signature to outgoing messages.

The receiving system checks that signature using a public key published in DNS. A valid signature helps confirm that the signed parts of the message have not changed since signing and that the message was signed by the domain identified in the signature.

Again, there is a catch. A valid signature from an unrelated domain does not prove that the visible sender address belongs to your business.

DMARC: Does the authentication match the visible sender?

Domain-based Message Authentication, Reporting and Conformance, or DMARC, connects authentication to the domain people actually see in the From address.

This connection is called alignment. In practical terms, the domain authenticated by SPF or DKIM needs to match, or meet the permitted alignment rules for, the visible From domain.

A message passes DMARC when at least one of those checks passes and aligns. Both do not have to pass, although configuring both properly gives you a stronger foundation.

DMARC also lets you publish a policy asking receiving systems how to handle messages that fail, and request reports showing how your domain is being used.

Put simply: SPF checks the sending infrastructure. DKIM checks the signature. DMARC checks whether the authentication supports the identity being presented to the recipient.

Microsoft 365 is only part of the picture

One of the easiest mistakes is to configure Microsoft 365 and assume the job is finished.

Your staff might send email through Outlook, but your business probably has other systems sending messages too:

• Your CRM and marketing platform.
• Accounting software sending invoices and reminders.
• Booking, payroll or practice-management systems.
• Website forms and automated notifications.
• Printers, scanners and older applications using email relays.

Each legitimate sending service needs an appropriate authentication setup. Otherwise, tightening your DMARC policy can expose a problem that was already there, just quietly waiting for its moment.

This is why managed Microsoft 365 services and email authentication need to work together. Your primary email platform matters, but so does every other system using your business identity.

How to implement email authentication without disrupting the business

The safest approach is straightforward: identify your senders, configure authentication, monitor the results, then enforce your policy.

Changing records first and asking questions later is certainly faster. It is also a reliable way to make yourself unpopular with finance.

1. Identify every legitimate sender

Start with an inventory of the platforms that send email using your domain or subdomains.

For each service, record:

• Who owns it within the business.
• Which domain appears in its From address.
• What it sends, such as invoices, campaigns or booking confirmations.
• How frequently it sends.
• What SPF and DKIM configuration the provider supports.

Ask finance, marketing and operations, not just IT. The person managing DNS may not know about a platform someone subscribed to six months ago.

2. Configure SPF and DKIM for your actual environment

Your SPF configuration should reflect the services you genuinely use. Your DKIM setup should cover each sending platform that supports it.

Follow the provider's instructions and test the result. Publishing a DNS record is not the same as confirming that outgoing messages are being authenticated correctly.

Avoid copying a sample configuration from a blog and assuming it fits. Email environments differ, and a plausible-looking record can still be wrong.

Because these controls rely on DNS, access and change management matter too. Managed DNS hosting and administration helps keep those changes controlled and the records maintained as your systems evolve.

3. Start DMARC in monitoring mode

A DMARC policy of p=none requests no quarantine or rejection action based on DMARC failure. When reporting is configured, it gives you visibility into the messages receiving systems see using your domain.

Use those reports to identify legitimate senders, investigate failures and check alignment.

Monitoring mode is a discovery stage. It is not the finished security outcome.

A report arriving in a mailbox is also not the same as someone reviewing it. Assign responsibility for interpreting the results and resolving issues.

4. Fix failures before moving to enforcement

Investigate legitimate messages that fail DMARC. The problem might be missing DKIM configuration, an incorrect SPF record, or authentication that does not align with your visible From domain.

Test real business workflows, not just a message sent from Outlook. Include an invoice, a marketing campaign, a website enquiry and any other important automated communication.

Your monitoring period needs to capture those workflows. A quiet week tells you very little about a system that only sends at month-end.

5. Move to quarantine, then reject

Once legitimate senders are accounted for and working correctly, strengthen the DMARC policy:

• p=quarantine asks receiving systems to treat failing messages as suspicious, commonly by placing them in junk.
• p=reject asks receiving systems to reject messages that fail DMARC.

Receiving systems make the final handling decision, but these policies give them clear instructions about messages claiming to come from your domain.

Move through enforcement with testing and monitoring. The objective is to block unauthorised use without interrupting legitimate business communication.

What these controls will not stop

Email authentication reduces the opportunity to spoof your domain. It does not make every authenticated message safe.

Someone using a compromised account can still send harmful email. Criminals can also register lookalike domains or impersonate a person through the display name shown in an inbox.

That is why authentication belongs alongside multi-factor authentication, email filtering, staff awareness and sensible payment-verification procedures.

A request to change bank details still deserves an independent check, even when the email looks convincing.

Likewise, successful authentication does not guarantee inbox placement. Receiving systems also consider other signals when deciding how to handle a message.

The practical goal is fewer avoidable delivery problems and stronger protection against impersonation, not a promise that every message will reach every inbox.

Keep it working as the business changes

Email authentication is not a set-and-forget exercise. New platforms arrive. Old services remain in records. Marketing changes providers. Someone adds another website form.

Without ownership, yesterday's correct configuration can become tomorrow's problem.

Build a few simple checks into your operating processes:

• Assign an owner for email domains, authentication and DNS changes.
• Require an authentication review before a new platform sends using your domain.
• Review DMARC reports and investigate unexpected sending sources.
• Remove obsolete authorisations when services are retired.
• Check your other registered domains, including those that do not send email.
• Document changes so delivery problems can be traced and resolved.

These tasks fit naturally within ongoing email management. They should not depend on someone remembering to check a record when there is spare time.

Know who is sending as your business

The useful question is not simply, "Do we have SPF, DKIM and DMARC?"

It is, "Do they cover every legitimate sender, are we enforcing an appropriate policy, and who is checking that they still work?"

Microsolve's Email Reputation Management service addresses that practical work: identifying sending sources, configuring authentication, moving towards enforcement and monitoring the results as your environment changes.

If you cannot confidently answer those questions today, talk to Microsolve about reviewing your email authentication. Your business identity should not be available for someone else to borrow.