SPF, DKIM, and DMARC explained for Australian small businesses (with copy-paste DNS examples)

Three DNS records decide whether your business email lands in customer inboxes or quietly disappears into junk folders. SPF, DKIM, and DMARC are the email authentication trio that every major mail provider, including Gmail, Outlook, and Apple Mail, now expects domains to publish. Get all three right and your delivery rate stays high. Get any of them wrong and you bleed customers without ever knowing.

This article covers what each record does in plain English, the exact DNS values to publish for the most common AU small business setups, and the order to roll them out so you don't accidentally block your own staff from sending email.

#Why all three records matter together

Each record solves a different piece of the same problem: how does a receiving mail server know that an email claiming to be from your domain actually came from you?

• SPF lists the IP addresses and mail services allowed to send mail for your domain.
• DKIM adds a cryptographic signature to each outbound email so receivers can verify it wasn't altered in transit.
• DMARC ties SPF and DKIM together, tells receivers what to do when one of them fails, and asks them to send you reports about who is sending mail using your domain.

Without DMARC, SPF and DKIM are advisory. Receivers see the failures but don't always act on them. With DMARC set to a strict policy, you tell Gmail and Microsoft "if it doesn't pass SPF or DKIM aligned with my domain, junk it or reject it outright." That single TXT record is what stops scammers from spoofing your domain in phishing campaigns.

In February 2024, Google and Yahoo started enforcing all three for any domain sending more than 5,000 emails per day to their users. The thresholds will keep dropping. Smaller senders are next.

#SPF: who is allowed to send for you

SPF stands for Sender Policy Framework. It is one TXT record at the apex of your domain (so on yourdomain.com.au, not on a subdomain). Inside that record you list every server, IP range, or third-party mail service allowed to send "From: [email protected]".

Here is the SPF record for a business that sends only through Google Workspace:

v=spf1 include:_spf.google.com -all

Read it like a sentence: "version 1 of SPF, include the rules from _spf.google.com, and reject everything else outright."

The four pieces:

1. v=spf1 says this is an SPF record. It must be the first thing.
2. include: pulls in the IP list of a third-party sender. Google publishes its current sending IPs at _spf.google.com. You don't have to know what they are.
3. -all is the strict ending. The dash means "fail if no rule above matched". A ~all (tilde) means "soft fail" which is more forgiving but easier to ignore. Always use -all for production.

#Common AU small business setups

If you send through Microsoft 365 only:

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

If you send through Google Workspace and a transactional service like Mailgun:

v=spf1 include:_spf.google.com include:mailgun.org -all

If you send through your own server too, add its IP:

v=spf1 ip4:103.45.67.89 include:_spf.google.com -all

If you have a marketing tool like Mailchimp doing newsletters, add their include:

v=spf1 include:_spf.google.com include:servers.mcsvc.net -all

#The two SPF mistakes everyone makes

The first one is the 10-lookup limit. SPF allows a maximum of 10 DNS lookups to resolve all the include: directives. Stack too many third-party services and you'll silently break your own SPF record. The scan flags this if it sees you're close to the limit. Solutions: use SPF flattening (a service like dmarcian or your own custom record), drop any include: you don't actually use, or move some senders to a subdomain.

The second one is multiple SPF records. You can only have one SPF TXT record per domain. If you publish two, every sane receiver will reject all of them as broken. Merge everything into a single record with multiple include: directives.

#DKIM: cryptographic signature on each email

DKIM stands for DomainKeys Identified Mail. Every email your server sends gets a digital signature in its headers. The receiver fetches your public key from DNS and verifies the signature. If it matches, the email is provably from you and provably unmodified since it left your server.

Unlike SPF, DKIM works at the content level, not the connection level. That matters because SPF breaks when an email is forwarded (the forwarding server's IP isn't in your SPF). DKIM survives forwarding because the signature is in the email itself.

#What you publish

Your mail provider gives you a public key. You publish it as a TXT record at a "selector" subdomain. Example for a Google Workspace domain using selector google:

google._domainkey.yourdomain.com.au   TXT   "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxxxxxx..."

The google._domainkey. prefix is the selector. Different providers use different selectors:

• Google Workspace: google (admins generate it from the Google Admin console)
• Microsoft 365: selector1 and selector2 (Microsoft uses two for rotation; both must exist)
• Mailgun: pic or whatever you set in the Mailgun dashboard
• Postmark: typically the date plus pm then your domain

You don't write the public key by hand. Your mail provider gives you the exact TXT value to paste. Your job is just adding it to DNS at the right name.

#The DKIM gotcha

If your scan says "DKIM signing not detected" but you've added the record, the most likely cause is that your mail provider isn't actually signing yet. Most providers have an "enable DKIM" toggle that you must turn on after publishing the DNS record. Until you flip it, no signature is added. Always go back into the mail provider's admin console and confirm DKIM signing is on.

#DMARC: tell receivers what to do when something fails

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is the policy layer that tells receiving mail servers what to do with an email claiming to be from your domain when SPF and DKIM disagree with that claim. It is also the only one of the three records that asks for reports back, which is how you discover who is trying to spoof your domain.

DMARC also lives as a TXT record. The name is _dmarc.yourdomain.com.au. The strictest possible record looks like:

_dmarc.yourdomain.com.au   TXT   "v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100; aspf=s; adkim=s"

The pieces:

• p=reject is the strictest policy. Receivers must reject any email failing both SPF and DKIM.
• rua=mailto: is where aggregate reports get sent. Daily summaries from every receiver. Use a service like Postmark's free DMARC monitor, dmarc.report, or dmarcian to make these XML reports readable.
• pct=100 means apply the policy to 100% of failing mail. You can ramp this up from 10 or 25 if you want a slow rollout.
• aspf=s and adkim=s enforce strict alignment. The "From:" header domain must exactly match the SPF and DKIM domains. Strict alignment catches sneaky subdomain abuse.

#The three policy modes

Roll DMARC out in stages. Don't go straight to reject.

1. p=none is monitoring mode. No mail is blocked. Receivers send you reports about which emails are passing and failing. Run this for two to four weeks. Read the reports. Find every legitimate sender of yours that is failing SPF or DKIM. Fix them.
2. p=quarantine sends failing mail to junk. You'll get complaints if your fixes from stage 1 missed something. Run this for another two to four weeks. Adjust as needed.
3. p=reject outright bounces failing mail. This is the goal. Once here, your domain becomes essentially unspoofable.

Most small businesses get stuck on p=none for years because the reports are unreadable XML. The free DMARC reporting services solve that. Hook one up before you publish your first DMARC record and the rollout becomes obvious.

#How to test before going strict

Three free tools:

1. Our free scan checks all three records on your domain in 30 seconds and flags exactly which ones are missing or misconfigured.
2. Postmark's free DMARC monitor at dmarc.postmarkapp.com gives you aggregated reports in plain English instead of XML.
3. mail-tester.com sends an email to a unique address and grades it on SPF, DKIM, DMARC, and a dozen other things. Useful for verifying a brand new sender.

For the first month after publishing each record, send yourself a test email from every system that should be sending on your behalf. Check the headers. Look for Authentication-Results: spf=pass, dkim=pass, and dmarc=pass. If any are missing or failing, fix before tightening policy.

#Privacy Act and brand impersonation in Australia

A common question from AU small businesses: is publishing strict email authentication a compliance requirement?

Strictly, no. The Privacy Act 1988 doesn't mandate SPF, DKIM, or DMARC by name. But the Notifiable Data Breaches scheme means that if scammers spoof your domain to phish your customers and get personal information, you may be on the hook to notify the OAIC and the affected individuals. Strict DMARC is one of the cheapest, fastest things you can put in place to reduce that risk.

The OAIC's 2024 Australian Cyber Threat Report explicitly listed business email compromise and phishing-via-spoofed-domains as the most common attack vector against Australian small businesses. DMARC at p=reject shuts that vector down entirely for unsophisticated attackers, who are most attackers.

#Common bugs we see in scans

• SPF too permissive: someone wrote v=spf1 +all which says "anyone in the world can send for me". Always use -all.
• DMARC stuck at p=none for years: monitoring is useful for weeks, not years. Push toward p=quarantine then p=reject.
• DMARC report addresses unreadable: nobody is reading the XML. Hook up a free reporter and you'll get plain-English summaries.
• Multiple SPF records: only ever publish one.
• DKIM record present but signing disabled: confirm the provider's signing toggle is on.
• Forgotten subdomains: _dmarc.yourdomain.com.au doesn't cover _dmarc.mail.yourdomain.com.au. If you send from a subdomain, publish DMARC there too.

#Run the free scan

Run our free scanner on your domain to see exactly which of these three records you have, whether they're configured strictly enough, and what to change. The technical report tells you the precise DNS values to add for your mail provider.