SPF, DKIM, and DMARC: what the email authentication stack actually stops

Business email compromise and brand-impersonation fraud have sat near the top of the ASD Annual Cyber Threat Reports for years, and the 2023–2024 edition is no exception — self-reported BEC losses to Australian organisations have continued to climb, and the adversary playbook is stable: impersonate a supplier, a senior executive, or a professional services firm, redirect a payment, vanish. What has changed is the ceiling on how convincing the impersonation can be, because generative models now produce clean copy in the right register at scale.

Against that backdrop, the three DNS records that govern email authentication — SPF, DKIM, and DMARC — are doing more work than they used to. They are not a complete defence against BEC (we'll get to why), but they are the control that decides whether an attacker can send email that actually comes from your domain rather than a lookalike. That distinction matters, because mail that authenticates against your real domain passes every user's inbox test and most automated ones.

Most Australian organisations we review have all three records configured. Most of them are configured in a way that does not quite work. This post walks through what each record actually does, the failure modes we see in practice, and what a functioning configuration looks like.

SPF — Sender Policy Framework

SPF is a DNS TXT record that lists the servers authorised to send email on behalf of your domain. When a receiving mail server accepts a message, it checks the envelope sender's domain, looks up that domain's SPF record, and verifies whether the message came from an IP address the record permits.

A minimal SPF record looks like:

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

The -all at the end is the bit that matters. It tells receivers to reject any message from a server not on the list. A trailing ~all ("softfail") asks receivers to accept the message but mark it suspicious; +all permits anything and is worse than no record at all.

Where SPF fails on its own. SPF authenticates the envelope sender — the address used during the SMTP handshake — not the From: address the recipient actually sees. An attacker can send a message with an envelope sender of bounces@attacker.example (which passes SPF for their own domain) while displaying From: ceo@yourcompany.com.au in the visible header. SPF alone does nothing about that. SPF is also fragile against the 10 DNS lookup limit in the specification — every include: counts, and once you add Microsoft 365, Google Workspace, your ticketing system, your marketing platform, and two legacy vendors nobody has decommissioned, you are already over. A record that exceeds the limit fails with a permerror, and receivers treat that as if there were no record at all.

DKIM — DomainKeys Identified Mail

DKIM adds a cryptographic signature to outbound messages. Your mail server signs selected headers (including From:, Subject:, and Date:) and the body of the message with a private key; the matching public key is published in your DNS. Receiving servers fetch the public key, verify the signature, and gain two guarantees: the mail really was sent by someone in possession of your private key, and the signed content has not been modified in transit.

A DKIM record lives at a selector-specific subdomain — for example:

selector1._domainkey.yourcompany.com.au. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0G..."

The selector (here selector1) lets you rotate keys and run multiple signing services concurrently — Microsoft 365, Google Workspace, Mailchimp, Zendesk, and so on each use their own selector.

Where DKIM fails on its own. DKIM does not, by itself, force anything. A message that fails DKIM verification is not automatically rejected — the receiving server decides what to do with it, and in the absence of a DMARC policy (below) that decision is usually "deliver anyway, maybe with a warning flag." DKIM also does not prevent an attacker from sending unsigned mail; it only proves authenticity of signed mail. Finally, DKIM signatures are scoped to the signing domain, which is not necessarily the From: domain — this is the gap DMARC alignment closes.

DMARC — the policy that ties the other two together

DMARC is the record that tells receiving servers what to do when SPF and DKIM checks on a message claiming to come from your domain fail, and it is the record that introduces the concept of alignment — requiring that the domain SPF or DKIM authenticated matches the domain the user sees in the From: header. It is the element that actually closes the spoofing gap.

A functioning DMARC record looks like:

_dmarc.yourcompany.com.au. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-aggregate@yourcompany.com.au; ruf=mailto:dmarc-forensic@yourcompany.com.au; fo=1; adkim=s; aspf=s"

The three policy values are p=none (monitor only — receivers still deliver failing mail, but send you reports), p=quarantine (failing mail goes to the recipient's spam folder), and p=reject (failing mail is refused outright). Only p=reject stops spoofed mail reaching the inbox.

The rua= address receives daily aggregate reports from receiving mail providers — invaluable for seeing which services are sending on your behalf and which are failing alignment. The ruf= address receives per-message forensic reports where the provider supports them.

Where DMARC fails on its own. A DMARC record at p=none is a monitoring tool, not a control. We regularly encounter organisations that put DMARC in place two years ago, read the reports for a week, and never moved past p=none. The attacker's perspective on a p=none record is that nothing stands in the way of spoofing the domain; they simply send.

DMARC also does nothing about lookalike domains. A message from yourc0mpany.com.au or yourcompany-au.net is a different domain and the attacker's own SPF, DKIM and DMARC records apply. Brand impersonation via lookalike is a domain-monitoring and takedown problem, not a DMARC problem.

The configuration pitfalls we see in Australian estates

Five recurring failure modes account for most of the authentication gaps we find during advisory work.

DMARC stuck at p=none indefinitely. The most common one. Organisations reach p=none, see the reports, get nervous about legitimate mail being rejected, and never move. The fix is the staged rollout the specification was designed for: p=none → p=quarantine pct=25 → p=quarantine pct=100 → p=reject, with the aggregate reports read at each stage to catch legitimate senders that are failing alignment.

SPF record over the 10-lookup limit. Particularly common in organisations that have accumulated SaaS vendors over a decade. The record parses as a permerror and every downstream check behaves as if there is no SPF at all. The fix is either rationalising the sender list, using an SPF flattening service (which resolves and inlines the IP ranges at the cost of needing to refresh on vendor changes), or moving low-volume senders onto a subdomain that has its own SPF.

DKIM configured only for the primary mail provider. We regularly see Microsoft 365 or Google Workspace signing correctly, while the marketing platform, the CRM, the support system, and the finance platform all send unsigned mail that passes SPF (because their sending IPs are include:d) but fails DKIM. The DMARC aggregate reports will show this clearly — the fix is to enable DKIM signing with a dedicated selector at each sending service.

From: domain misalignment on transactional mail. Invoices, password resets, and CRM notifications frequently come from a vendor-controlled subdomain rather than your primary domain. SPF and DKIM pass for the vendor, but DMARC alignment fails because the From: header says yourcompany.com.au and the authenticated domain is vendor-mail.net. The fix is custom-domain configuration at each vendor (CNAME records pointing at vendor infrastructure with your own DKIM selector), which is tedious but is what actually makes the stack work end-to-end.

Parked and unused domains without restrictive records. Every domain your organisation owns — including defensive registrations, domains from acquisitions you forgot about, and subdomains of those — can be used to send spoofed mail unless it has SPF and DMARC records that say otherwise. For a domain that sends no mail at all, the correct records are:

yourdomain.com.au.          IN TXT "v=spf1 -all"
*._domainkey.yourdomain.com.au. IN TXT "v=DKIM1; p="
_dmarc.yourdomain.com.au.   IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-aggregate@yourprimarydomain.com.au"

That combination states, plainly, that no server is authorised to send mail for the domain and any claim otherwise should be refused.

What the stack does not stop

It is worth being specific about the limits, because this is a control that is often oversold.

The email authentication stack stops exact-domain spoofing. An attacker who tries to send mail claiming to be from yourcompany.com.au to a receiver that honours DMARC will fail, and the message will not reach the inbox.

The stack does not stop lookalike-domain impersonation. The attacker registers yourc0mpany.com.au or yourcompany-group.com, configures it with its own valid SPF, DKIM and DMARC (which passes trivially because the attacker controls the domain), and sends mail that is cryptographically perfect — just from a different domain than the one the user expects. This is a brand-monitoring and domain-watch problem; it is addressed by registrar monitoring, certificate transparency alerting, and a takedown process, not by DMARC policy changes.

The stack does not stop display-name spoofing in environments that do not surface the full sender address. A phone-first mail client that shows From: Jane Smith and hides the address itself will not protect the user against jane.smith@attacker-domain.net. User interface is the control here, not DNS.

The stack does not stop compromised legitimate accounts. If an attacker phishes your CFO's credentials, bypasses or steals session tokens around your MFA, and sends mail from within your tenant, every authentication check passes because the mail really is being sent by your infrastructure. This is why phishing-resistant MFA, conditional access, and EDR continue to matter alongside email authentication.

And finally, the stack does not stop the social-engineering content of BEC on its own. A well-authenticated email asking for an urgent wire transfer to a new supplier account is still a wire transfer fraud if the recipient acts on it. The control that closes this gap sits in finance — verified supplier change procedures, dual authorisation for changes to payment details, and a culture of out-of-band verification for unusual requests.

A minimal Australian baseline

For any Australian organisation handling customer data or making payments on behalf of a client — which is to say, effectively all of them — the baseline we would advise any client to reach on email authentication is the following.

Every domain owned by the organisation, whether used for mail or not, should have SPF and DMARC records. Primary sending domains should have DKIM configured for every service that sends mail on the domain's behalf, with vendor-specific selectors. DMARC policy should be p=reject on the primary domain, reached via a staged rollout from p=none. Aggregate reports should go to a monitored mailbox or a dedicated analytics service (there are several good ones; the categories of vendor include DMARC management platforms and managed email security services) so that failing senders are caught and corrected rather than ignored.

For organisations subject to APRA CPS 234 or the SOCI Act risk management obligations, the presence of authenticated email sending is not specifically enumerated as a control — but an information asset hit with a spoofing-enabled BEC incident is a control failure that the regulator will ask about. Getting the records right is cheap; the operational discipline of reading the reports and keeping the sender list clean is where the cost sits.

Putting this into your own environment

If you have DMARC at p=none and you have had it there for more than three months, or if you are not sure which services are signing your outbound mail, or if you have a portfolio of parked domains with no authentication records at all, those are the three things worth fixing this quarter. Our advisory team works with Australian organisations on exactly that uplift — from the report-reading and sender rationalisation to the DMARC staged rollout. If that is useful, the DFIR and advisory services page is the place to start a conversation.