SPF, DKIM, and DMARC: How Email Authentication Protects Your Australian Business

Managed IT & Cybersecurity

SPF, DKIM, and DMARC: How Email Authentication Protects Your Australian Business

If someone told you that right now, any person on the internet could send an email that looks exactly like it came from your business — same domain, same display name, indistinguishable to the naked eye — would you want to fix that? The answer should be yes. And the fix is a set of three DNS-based email authentication standards: SPF, DKIM, and DMARC.

Most Australian small and medium businesses have heard at least one of these acronyms, usually from an IT provider, a security article, or a notification from Google or Microsoft. But understanding what they do, how they work together, and how to actually get them configured is another matter entirely.

This guide explains all three in plain terms — what they are, why they matter for Australian businesses specifically, and how to go from no email authentication to full enforcement without accidentally blocking your own legitimate mail.

Why Email Spoofing Is a Serious Problem

Email was not designed with security in mind. The protocols that underpin it were built in an era when the internet was a small, trusted academic network. As a result, the basic mechanics of email do not verify that the sender is who they claim to be. Anyone with access to a mail server can send an email claiming to be from any domain — including yours.

Email spoofing is the practice of forging the sender address in an email so that it appears to come from a trusted domain. For an attacker targeting your customers, suppliers, or staff, this is extremely valuable. They can craft an email that looks exactly like a genuine message from your business — your domain, your branding, your tone — and use it to request payments, steal login credentials, or deliver malware.

This technique sits at the foundation of business email compromise, one of the most financially damaging cyber threats to Australian businesses. The Australian Signals Directorate consistently reports business email compromise as a leading cause of financial losses across all business sizes, with the average incident costing tens of thousands of dollars. It is also the engine behind phishing campaigns that impersonate well-known brands, government agencies, and trusted local suppliers.

Without email authentication, there is nothing technically preventing anyone from sending an email that appears to come from @yourcompany.com.au. You do not need to be hacked. You do not need to have done anything wrong. The vulnerability exists simply because your domain exists, and email authentication has not been configured to stop it.

The good news is that SPF, DKIM, and DMARC directly address this problem. When all three are correctly configured and enforced, spoofed emails purporting to come from your domain are rejected before they reach anyone's inbox.

How Email Authentication Works — The Basics

SPF, DKIM, and DMARC are all published in your domain's DNS — the same system that tells the internet where your website lives and where to deliver your email. They do not require any changes to your email platform itself (beyond enabling DKIM signing), and they are invisible to your recipients when everything is working correctly.

The three records work as a layered system.

SPF answers the question: "Is this mail server authorised to send email on behalf of this domain?" It is a list of approved sending sources published in DNS.

DKIM answers the question: "Was this email sent by an authorised system, and has it been tampered with in transit?" It uses a cryptographic signature that can be verified by any receiving mail server.

DMARC answers the question: "What should I do if SPF or DKIM fails?" It is a policy record that instructs receiving mail servers to deliver, quarantine, or reject emails that fail authentication — and it tells you about failures via automated reports.

Together, they close the gap that has existed in email since its inception. Let us look at each one in more detail.

SPF — Sender Policy Framework

SPF is the simplest of the three to understand. It is a DNS TXT record you publish on your domain that says: "These are the mail servers and services that are permitted to send email from this domain. If an email arrives from somewhere else claiming to be from us, treat it with suspicion."

When a receiving mail server gets an email claiming to be from @yourdomain.com.au, it looks up your domain's SPF record and checks whether the server that actually sent the email is on your approved list. If it is, SPF passes. If it is not, SPF fails — and depending on your DMARC policy (covered below), that email may be rejected or quarantined.

How to read an SPF record

Here is a typical SPF record for an Australian business using Microsoft 365:

v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all

Breaking this down:

  • v=spf1 — declares this as an SPF record (version 1 is the only version in use)
  • include:spf.protection.outlook.com — authorises Microsoft 365's mail servers to send on behalf of this domain
  • include:_spf.google.com — authorises Google Workspace's mail servers
  • -all — the hard fail qualifier, meaning any server not listed in the record should fail SPF; this is the correct setting for most businesses

The -all at the end is important. Using ~all (soft fail) or ?all (neutral) is weaker and less effective. A hard fail (-all) tells receiving servers to treat unauthorised senders as definitively unapproved.

Common SPF entries for Australian businesses

Most Australian businesses use one or more of the following in their SPF record:

  • Microsoft 365: include:spf.protection.outlook.com
  • Google Workspace: include:_spf.google.com
  • Xero (if sending invoices or notifications from your domain): check Xero's documentation for their current SPF include
  • Campaign Monitor, Mailchimp, or other marketing platforms: each publishes its own SPF include value in its documentation

The 10-lookup limit

SPF has a technical limitation worth knowing: it enforces a maximum of 10 DNS lookups per evaluation. Each include: directive counts as a lookup, and some includes trigger further lookups of their own. If your SPF record exceeds this limit, legitimate emails can fail SPF — not because the sender is unauthorised, but because the DNS lookup chain is too long.

This is a surprisingly common problem for businesses that have added multiple email platforms over time. If you are using a CRM, a marketing tool, a billing platform, and a helpdesk system — all sending email on your behalf — your SPF record can exceed the limit. Flattening your SPF record (consolidating the IP addresses rather than chaining includes) solves this, but requires care to ensure all legitimate sources remain covered.

DKIM — DomainKeys Identified Mail

DKIM adds a cryptographic signature to every outgoing email. Think of it as a tamper-evident seal: it proves the email was sent by an authorised system and that its content has not been altered in transit.

Here is how it works. Your email platform generates a pair of cryptographic keys — a private key and a public key. The private key is held by your mail system and used to sign outgoing emails. The public key is published in your DNS as a DKIM record. When a receiving mail server gets an email from your domain, it fetches your public key from DNS and uses it to verify the signature on the email. If the signature checks out, DKIM passes. If it does not — because the email was forged, or modified in transit — DKIM fails.

Why DKIM matters alongside SPF

SPF tells you whether the sending server is authorised. But SPF does not say anything about the email's content. An attacker who routes mail through an authorised server — or exploits a weakness in your SPF record — could still pass SPF while delivering a tampered message. DKIM closes that gap by verifying the integrity of the message itself.

Together, SPF and DKIM provide two independent lines of verification. DMARC then decides what to do when either or both fail.

Enabling DKIM in Microsoft 365

Microsoft 365 does not enable DKIM signing by default for custom domains. You need to turn it on. The process involves:

  1. Going to the Microsoft 365 Defender portal (security.microsoft.com) and navigating to Email and Collaboration, then Policies and Rules, then Threat Policies, then DKIM.
  2. Selecting your domain and enabling DKIM signing. Microsoft generates two CNAME records that you need to add to your domain's DNS.
  3. Once the CNAME records are published in DNS (which can take up to 48 hours to propagate), returning to the DKIM settings in the Defender portal and enabling DKIM signing for the domain.

For Google Workspace, DKIM signing is configured in the Google Admin console under Apps, Gmail, Authenticate email. Google provides a TXT record (rather than CNAME records) that you add to your DNS, then you enable signing from the same screen.

If you use a third-party email platform for marketing or transactional emails, that platform will have its own DKIM configuration process. Each sending platform that uses your domain needs its own DKIM key published in DNS.

DMARC — Domain-based Message Authentication, Reporting & Conformance

DMARC is the policy layer that makes SPF and DKIM enforceable. Without DMARC, passing or failing SPF or DKIM has no guaranteed consequence — each receiving mail server handles failures in its own way. DMARC standardises that response.

A DMARC record is another DNS TXT record published on your domain. It tells receiving mail servers: "If an email from my domain fails SPF or DKIM alignment, here is what you should do with it." It also enables reporting — major mail providers send you daily XML reports showing every source that sent email claiming to be from your domain.

DMARC alignment

It is worth understanding DMARC alignment, because it is what ties the three records together. DMARC does not just check whether SPF and DKIM pass — it checks whether they align with the domain in the email's From: header. This prevents attackers from using a related but different domain to pass SPF while spoofing your From: address.

The three DMARC policy levels

DMARC has three policy options, set via the p= tag:

p=none — monitor only. Emails that fail authentication still deliver normally. The domain owner receives DMARC reports but no action is taken against failing emails. This is the starting point — not the destination.

p=quarantine — failing emails are sent to the recipient's spam or junk folder rather than the inbox. This is an intermediate enforcement level used while testing.

p=reject — failing emails are rejected entirely and not delivered. This is the goal. A domain with p=reject fully enforced means spoofed emails from your domain will not reach anyone's inbox anywhere — they are blocked at the receiving server before delivery.

The DMARC journey

Moving from no email authentication to full enforcement is not something you do overnight, and attempting to jump straight to p=reject without preparation can block legitimate mail you did not know was being sent using your domain. The recommended approach is:

Start with p=none and configure your rua= reporting address. This lets you receive DMARC aggregate reports without affecting email delivery. Review those reports over several weeks to identify every source sending email from your domain — your mail platform, your marketing tools, your accounting software, your helpdesk system, and any other services.

For each legitimate source you identify in the reports, confirm that SPF and DKIM are correctly configured for that source. If a service is not in your SPF record, add it. If a service does not have DKIM signing configured, set it up.

Once you are confident all legitimate sources pass SPF and DKIM, move to p=quarantine. At this stage, failing emails go to spam rather than being blocked entirely. Monitor your reports and test carefully. If any legitimate mail starts landing in spam, investigate the cause.

When you are satisfied that no legitimate mail is failing, move to p=reject. At this point your domain is fully protected.

Example DMARC record

v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; sp=reject; adkim=s; aspf=s

Breaking this down:

  • v=DMARC1 — declares this as a DMARC record
  • p=reject — the policy for the root domain: reject emails that fail authentication
  • rua=mailto:[email protected] — the address where aggregate reports are sent
  • ruf=mailto:[email protected] — the address where forensic (per-failure) reports are sent
  • sp=reject — the policy for subdomains; without this, attackers can spoof mail from subdomains of your domain (e.g. billing.yourdomain.com.au)
  • adkim=s — strict alignment for DKIM; the DKIM domain must match the From: domain exactly
  • aspf=s — strict alignment for SPF

Why does DMARC matter in Australia right now?

The Australian Signals Directorate's Blueprint for Secure Cloud explicitly lists SPF, DKIM, and DMARC as required email security controls. Government agencies subject to the Essential Eight framework are expected to implement all three. For private sector businesses, these controls are increasingly appearing as requirements in cyber insurance policies and client security assessments.

Internationally, Google and Yahoo mandated that bulk email senders have a DMARC policy (at minimum p=none) in place as of February 2024. This requirement signals the direction of travel across the industry. It is no longer a theoretical best practice — it is a baseline expectation.

For a broader look at how email authentication fits into your overall security posture, see Pickle's guide to the Essential Eight cybersecurity framework.

DMARC Reports — What They Tell You

DMARC aggregate reports are XML files sent daily by major mail providers — Google, Microsoft, Yahoo, and others — to the address specified in your rua= tag. Each report covers a 24-hour period and lists every source that sent email claiming to be from your domain, along with SPF and DKIM pass/fail results for each.

Raw XML files are not particularly readable. A DMARC reporting tool — such as Postmark's DMARC reporting feature, Dmarcian, or EasyDMARC — parses these files into a readable dashboard so you can see your email authentication landscape at a glance.

What to look for in your DMARC reports:

Authorised sources passing authentication — your Microsoft 365 or Google Workspace mail, your CRM, your billing system. These should show consistent SPF and DKIM passes. If any authorised source is failing, you need to fix its configuration.

Unexpected sending sources — IP addresses or mail servers you do not recognise sending email from your domain. These could be a forgotten marketing platform, a third-party service you are no longer using, or active spoofing attempts by external parties. Either way, they require investigation.

High volumes of failures from unknown sources — a spike in failed authentication attempts from IP addresses you do not own is a strong indicator that someone is actively attempting to spoof your domain. With p=reject in place, those attempts are blocked. Without enforcement, they are getting through.

DMARC reports are not just a setup tool — they are ongoing visibility into how your domain is being used and abused. Even after reaching p=reject, reviewing reports periodically lets you catch new services that have been added to your environment without proper email authentication being configured first.

Common Configuration Mistakes

Even businesses that have started on email authentication often have gaps in their setup. These are the mistakes Pickle sees most frequently.

Publishing SPF but not DKIM or DMARC. SPF alone provides only partial protection. Without DMARC, receiving mail servers have no policy to follow when SPF fails. Without DKIM, you lose message integrity verification and have one less authentication signal for DMARC to work with. All three records need to be in place.

Staying at p=none indefinitely. Starting with p=none is correct. Staying there is not. A p=none policy means attackers can spoof your domain freely and their emails will still deliver to inboxes. Many businesses set up DMARC, see it working, and never move through to enforcement. The only policy that actually protects your domain is p=reject.

Exceeding the SPF 10-lookup limit. As your business grows and you add more tools that send email on your behalf, your SPF record grows with it. Exceeding 10 DNS lookups causes SPF to permanently fail for your domain, meaning even legitimate mail starts getting flagged. This is often silent — you may not notice until customers report missing emails.

Forgetting subdomain policy. A DMARC record without the sp= parameter does not protect your subdomains. Attackers can target @billing.yourdomain.com.au or @support.yourdomain.com.au without being covered by your root domain's DMARC policy. Always include sp=reject in your DMARC record.

Not monitoring DMARC reports. Moving to p=reject without reviewing your DMARC reports first is the most dangerous mistake. If a legitimate service — an accounting platform, a helpdesk tool, a marketing system — is sending email on your behalf but is not in your SPF record and does not have DKIM configured, it will start failing silently the moment you enforce p=reject. Read your reports before you enforce.

Microsoft 365 implicit authentication is not enough. Microsoft 365 has built-in anti-spoofing protections, sometimes called implicit authentication. These protect Microsoft-to-Microsoft mail to some extent, but they do not protect recipients on other mail platforms (Gmail, Yahoo, corporate mail servers) from spoofed emails appearing to come from your domain. Publishing your own SPF, DKIM, and DMARC records is still necessary, regardless of which email platform you use.

Email authentication pairs well with multi-factor authentication as part of a layered approach to email security. Locking down who can send as your domain, and who can access your mail accounts, together significantly reduce your exposure to email-based attacks.

How Pickle Sets Up Email Authentication for Australian Businesses

Getting SPF, DKIM, and DMARC correctly configured — and moving through to full enforcement at p=reject — takes more than a one-time DNS edit. It requires understanding your email environment, identifying all services sending on your behalf, setting up reporting, reviewing that reporting over time, and making configuration changes in the right order.

Pickle's managed IT services include full SPF, DKIM, and DMARC configuration for Microsoft 365 and other email platforms. We handle the DNS records, the DKIM key generation and publishing, the DMARC policy setup, the reporting configuration, and the review process that moves you safely through from monitoring to full enforcement.

For businesses that already have partial configuration in place, we audit what is there, identify gaps, fix any issues with SPF lookup limits or missing subdomain policy, and get you to p=reject without disrupting your legitimate mail flow.

If your business does not yet have email authentication in place — or if you are not sure what you have — the best first step is to get a clear picture of where you stand.

Call us on 1300 688 588 or email [email protected] to talk through your current email security setup.

Frequently Asked Questions

Q: Do I need all three — SPF, DKIM, and DMARC — or just one?

A: You need all three working together. SPF alone tells receiving servers which mail servers are authorised, but without DMARC, there is no enforced policy when SPF fails. DKIM alone adds message integrity verification but also has no enforcement mechanism without DMARC. DMARC is the policy layer that makes both meaningful — but DMARC's alignment checking depends on SPF and DKIM being correctly configured first. Partial implementation offers partial protection. The goal is all three, with DMARC at p=reject.

Q: Will setting up DMARC to p=reject block legitimate emails?

A: It can, if you enforce before your legitimate sending sources are all correctly authenticated. This is exactly why the recommended approach is to start at p=none, collect and review DMARC aggregate reports over several weeks, ensure every legitimate source passes SPF and DKIM, then move to p=quarantine and finally p=reject. Done in the right order, with proper review of reports along the way, moving to p=reject should not block any legitimate mail. Jumping to enforcement without that preparation is where problems occur.

Q: How do I know if my domain is currently being spoofed?

A: The quickest way is to publish a DMARC record at p=none with a rua= reporting address and wait for aggregate reports to arrive. Within 24 to 48 hours, you will start receiving reports from major mail providers showing every source sending email as your domain. Unknown IP addresses in that data indicate potential spoofing. You can also use a free DMARC lookup tool (many are available online) to check whether your domain has a DMARC record at all — if it does not, your domain has no protection against spoofing.

Q: Does Microsoft 365 set up SPF, DKIM, and DMARC automatically?

A: Not entirely. Microsoft 365 automatically creates a basic SPF record for your domain when you verify the domain in the Microsoft 365 admin centre. However, this default SPF record only covers Microsoft's own servers — it does not include any other services you use to send email. DKIM signing is not enabled by default for custom domains; you have to configure it manually in the Microsoft 365 Defender portal and add CNAME records to your DNS. DMARC is not configured at all by default — that is entirely your responsibility. Microsoft 365 also has its own internal anti-spoofing mechanisms, but these do not replace publishing your own authentication records.

Q: How long does it take to go from p=none to p=reject?

A: For a straightforward environment — a business using one or two sending platforms — the full journey from initial setup to p=reject typically takes four to eight weeks. Most of that time is spent collecting and reviewing DMARC aggregate reports at p=none before moving to enforcement. For more complex environments with many services sending email on your behalf (CRMs, marketing platforms, billing tools, helpdesk software), it can take longer to identify and correctly authenticate all sending sources. Rushing the process risks blocking legitimate mail; taking the time to review reports properly means enforcement goes smoothly.