SPF, DKIM and DMARC explained: email authentication for Australian businesses

Why this matters more than it used to

Email authentication has existed for years, but for most of that time it was optional background infrastructure that IT people cared about and business owners didn't. That changed in February 2024 when Google and Yahoo introduced mandatory requirements for bulk senders: if you send significant email volume and your domain lacks proper authentication records, your emails will be rejected or quarantined outright.

Even for small businesses sending modest volumes, the practical stakes are real. Missing or misconfigured SPF, DKIM, and DMARC records are one of the most common reasons legitimate business emails land in spam folders. Getting them right costs an hour of your time and pays off indefinitely.

How email authentication works — the overview

When someone receives an email claiming to be from you@yourbusiness.com.au, their mail server checks your DNS records to verify the claim. Without these checks, anyone can send email that appears to come from your domain — a technique used extensively in phishing and spam.

The three records work as a layered system:

• SPF checks whether the sending mail server is on your approved list
• DKIM checks whether the email's content has been cryptographically signed by your domain
• DMARC checks that SPF and/or DKIM pass and align with the From address, then enforces a policy on what to do if they don't

Each one closes a different gap. A spammer can pass SPF (by using an authorised server) but fail DKIM. They can fake a DKIM signature but fail SPF. DMARC requires at least one of them to pass and align with the visible From domain, which is what actually matters to the recipient.

SPF — who is allowed to send email from your domain

SPF (Sender Policy Framework) is a DNS TXT record that lists the mail servers authorised to send email on behalf of your domain. When a receiving server gets an email from your domain, it looks up your SPF record and checks whether the sending server is on the list.

What an SPF record looks like

# Basic SPF record for a domain using cPanel hosting email
yourdomain.com.au.  IN  TXT  "v=spf1 a mx ~all"

# SPF record for a domain using Microsoft 365 for email
yourdomain.com.au.  IN  TXT  "v=spf1 include:spf.protection.outlook.com ~all"

# SPF record using both your hosting server and Microsoft 365
yourdomain.com.au.  IN  TXT  "v=spf1 a mx include:spf.protection.outlook.com ~all"

Breaking down the syntax

• v=spf1 — declares this as an SPF record
• a — authorises the IP address in your domain's A record
• mx — authorises the servers in your MX records
• include:spf.protection.outlook.com — includes Microsoft's list of authorised sending IPs
• ~all — soft fail: emails from unlisted servers are marked suspicious but not rejected. Use -all for a hard fail (rejected outright) once you're confident your record is complete

Important SPF constraints

You can only have one SPF TXT record per domain. If you add a second one, both will be ignored and SPF will fail. If you use multiple sending services, combine them into a single record using multiple include: statements.

SPF also has a 10 DNS lookup limit. Each include: statement counts as a lookup, and some include chains look up further records of their own. If you use many third-party senders (transactional email services, CRMs, marketing platforms), you can hit this limit. Tools like MXToolbox's SPF checker will warn you if you're approaching it.

DKIM — cryptographic proof that the email came from you

DKIM (DomainKeys Identified Mail) works differently to SPF. Rather than listing authorised servers, it uses a public/private key pair. Your mail server signs each outgoing email with a private key. The recipient's server looks up the corresponding public key in your DNS and uses it to verify the signature. If the signature checks out, the email hasn't been tampered with and genuinely came from a server that holds your private key.

What a DKIM record looks like

# DKIM record — the selector name varies by provider
default._domainkey.yourdomain.com.au.  IN  TXT
  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ..."

# Microsoft 365 uses two selectors: selector1 and selector2
selector1._domainkey.yourdomain.com.au.  IN  CNAME
  selector1-yourdomain-com-au._domainkey.yourtenant.onmicrosoft.com.

How to set up DKIM

Unlike SPF, you don't write a DKIM record from scratch — you generate the key pair through your mail provider and they give you the DNS record to add.

• cPanel hosting: Go to cPanel → Email → Email Deliverability. cPanel generates the key pair and shows you the DNS record to add. If your DNS is managed through cPanel, it will offer to add it automatically.
• Microsoft 365: Go to the Microsoft 365 Admin Centre → Settings → Domains → select your domain → DNS records. Microsoft provides the CNAME records to add to your DNS.
• Google Workspace: Admin Console → Apps → Google Workspace → Gmail → Authenticate email. Generate the key and add the provided TXT record to DNS.
• Other providers: Every major email platform has a DKIM setup guide — look for "DKIM" or "email authentication" in their documentation.

DMARC — policy enforcement and reporting

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the record that ties SPF and DKIM together and gives them teeth. It tells receiving mail servers what to do when an email from your domain fails authentication — and critically, it gives you a reporting mechanism so you can see what's happening.

DMARC also introduces the concept of alignment: it checks that the domain in the email's visible From address matches the domain that passed SPF or DKIM. This closes a spoofing gap where an attacker could pass SPF using a different domain while displaying your domain in the From address.

What a DMARC record looks like

# Start here — monitor only, no enforcement
_dmarc.yourdomain.com.au.  IN  TXT
  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com.au"

# Quarantine failing emails (send to spam folder)
_dmarc.yourdomain.com.au.  IN  TXT
  "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@yourdomain.com.au"

# Reject failing emails outright — only use once confident
_dmarc.yourdomain.com.au.  IN  TXT
  "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@yourdomain.com.au"

The three DMARC policies

DMARC reporting

The rua=mailto: tag tells receiving servers where to send aggregate reports. These arrive as XML files — not human-readable — but free tools like dmarcian and MXToolbox can parse and visualise them. Reading these reports during the p=none phase is how you discover any sending sources you've missed before you start enforcing policy.

The right order to implement these

Order matters. Don't jump ahead.

1. Set up SPF first. Get all your legitimate sending sources into a single SPF record. Use ~all (soft fail) while you're getting started.
2. Set up DKIM. Generate keys through each mail provider you use and add the DNS records. Wait for propagation and verify each one is signing correctly.
3. Add DMARC with p=none. Start collecting reports without enforcing anything. This is your safety net — it tells you if something's wrong before you risk blocking legitimate email.
4. Review reports for 2–4 weeks. Confirm that all your legitimate email is passing SPF and DKIM. Look for any sending sources you haven't accounted for.
5. Move to p=quarantine. Once you're confident, tighten SPF to -all (hard fail) and move DMARC to quarantine.
6. Move to p=reject. The end goal. Emails failing authentication are rejected outright.

Testing your setup

Don't assume it's working — verify it. These free tools will check your records and flag any issues:

• MXToolbox SuperTool — check SPF, DKIM, and DMARC records individually. Paste your domain and select the record type.
• Mail-Tester — send a test email to a unique address it gives you, then get a score showing whether SPF, DKIM, and DMARC passed. Excellent for an end-to-end check.
• dmarcian DMARC Inspector — specific DMARC record validation and report analysis.
• Google Postmaster Tools — if you send to Gmail users, this shows your domain reputation and authentication pass rates from Google's perspective.

Common mistakes

• Multiple SPF records. You can only have one. If you have two, both are ignored. Combine everything into a single record.
• Jumping to p=reject without monitoring first. Almost always breaks some legitimate sending path you'd forgotten about.
• Setting up DMARC without DKIM. DMARC requires at least one of SPF or DKIM to pass and align. If only SPF is set up and it passes on a forwarded email (which breaks SPF alignment), the email fails DMARC. DKIM survives forwarding; SPF often doesn't.
• Not updating SPF when adding new sending services. Every marketing platform, CRM, or transactional email service you add needs to be in your SPF record.
• Using +all instead of ~all or -all. The +all mechanism means "everyone is authorised," which defeats the purpose entirely.
• Not setting up DMARC at all. SPF and DKIM without DMARC still leave alignment gaps that spoofing attacks exploit. All three are needed.

Quick-reference checklist