DMARC, SPF, and Why Your Supplier's Email Domain Matters More Than You Think

The Email Authentication Stack, Explained Simply

Three DNS records — SPF, DKIM, and DMARC — form the email authentication infrastructure that allows receiving mail servers to verify that an email genuinely originated from the domain it claims to be from. Together, they address one of the oldest and most exploited weaknesses in email: the fact that anyone can send an email claiming to be from any address they choose.

Understanding these records does not require deep technical knowledge. What matters for supplier verification is knowing what the presence or absence of each record tells you about a supplier's email infrastructure — and what that implies about the risk of receiving a fraudulent email purporting to be from them.

SPF — Sender Policy Framework

An SPF record is a DNS TXT record that lists the mail servers authorised to send email on behalf of a domain. When your mail server receives an email from smith@smithplumbing.com.au, it checks the SPF record for smithplumbing.com.au to see whether the sending server is on the approved list. If it is not, the email fails SPF.

SPF alone does not prevent spoofing of the visible "From" address — it only checks the envelope sender, which is not the address most users see. But it is the first layer of the email authentication stack, and its absence is a signal that the domain operator has not implemented basic email security.

DKIM — DomainKeys Identified Mail

DKIM adds a cryptographic signature to outgoing emails. The signature is generated using a private key held by the sender and can be verified by anyone using the corresponding public key, which is published in the domain's DNS. A valid DKIM signature proves that the email was sent by someone controlling the domain's private key and that it has not been modified in transit.

DKIM is harder to check externally (it requires examining the email headers of a received message, not just the DNS records) but its presence in a received email is the strongest single indicator that the email is genuinely from the domain it claims.

DMARC — Domain-based Message Authentication, Reporting and Conformance

DMARC ties SPF and DKIM together and adds a policy layer. A DMARC record tells receiving mail servers what to do when an email fails both SPF and DKIM checks: nothing (p=none), put it in spam (p=quarantine), or reject it (p=reject).

A domain with DMARC set to p=reject is extremely difficult to spoof in a way that will reach the recipient's inbox. If a fraudster tries to send an email claiming to be from @smithplumbing.com.au, and smithplumbing.com.au has DMARC p=reject, most major email providers will reject the message before it is delivered.

A domain with no DMARC record — or with DMARC set to p=none — can be spoofed freely. The spoofed email will pass basic filtering and land in the recipient's inbox looking like a genuine communication from the supplier.

What the Absence of DMARC Actually Means

A supplier whose domain has no DMARC record is not necessarily fraudulent. Many legitimate Australian businesses have never configured DMARC — it is not a legal requirement, it requires DNS access and some technical knowledge to set up, and many small businesses rely on email services that do not configure it by default.

What the absence of DMARC means is that the supplier's domain can be spoofed by a fraudster. If you receive an email from @smithplumbing.com.au requesting updated banking details, and smithplumbing.com.au has no DMARC, you cannot be certain that the email actually came from smithplumbing.com.au. It might have come from a server in another country entirely.

This shifts the risk calculus: a supplier with no DMARC is not a high-risk supplier, but a request to change banking details from such a supplier warrants a phone callback to confirm, because email authentication alone cannot verify the request's legitimacy.

BIMI and DANE — The Next Layer

Two newer email authentication standards provide additional trust signals:

BIMI (Brand Indicators for Message Identification) allows organisations to display a verified logo in the email client beside their messages. Implementing BIMI requires DMARC enforcement (p=quarantine or p=reject) and, in most implementations, a Verified Mark Certificate issued by a certificate authority. A supplier with a BIMI record has invested meaningfully in email authentication infrastructure.

DANE/TLSA (DNS-Based Authentication of Named Entities) uses DNSSEC to cryptographically bind TLS certificates to domain names for SMTP connections. A DANE/TLSA record on port 25 means that encrypted mail transfer to this domain is protected against man-in-the-middle interception. It is an advanced configuration seen primarily in organisations with sophisticated IT infrastructure.

Gumshoe checks for BIMI and DANE records as part of the email infrastructure verification, surfacing them in the check detail for suppliers that have implemented them.

MTA-STS — The Practical Middle Ground

MTA-STS (Mail Transfer Agent Strict Transport Security) is a simpler alternative to DANE that achieves a similar goal: ensuring that email is transmitted between servers using encrypted, verified TLS connections. It does not require DNSSEC and is therefore more accessible to organisations without advanced DNS infrastructure. A supplier with an MTA-STS record has configured their mail environment to resist downgrade attacks on email encryption.

"A domain with no DMARC record can be spoofed by anyone. If you receive a banking-change request from a supplier whose domain has no DMARC, you cannot be certain the email actually came from them — regardless of what the From address says."

How to Use This Information in Practice

For supplier verification purposes, the key question is: given this supplier's email authentication configuration, how confident can I be that an email from their domain is actually from them?

• DMARC p=reject + SPF + DKIM: High confidence. Spoofing this domain is technically difficult and unlikely to succeed.
• DMARC p=quarantine + SPF: Reasonable confidence. Spoofed emails will usually be filtered to spam.
• DMARC p=none or missing: Low confidence. Spoofing is straightforward. Apply additional scrutiny to any payment requests from this supplier.
• No MX records: This domain cannot send or receive email. Any invoice arriving from an email address on this domain is fraudulent by definition.

Gumshoe surfaces all of these signals automatically — SPF, DMARC policy, BIMI, MTA-STS, DANE/TLSA, MX servers — as structured metadata in the email infrastructure check, with the specific records visible for review. For accountants who need to explain their verification process to auditors or insurers, this level of detail provides the documentation that "we checked the email address" never could.

Uncommon Insights

One of the lesser-known implications of a supplier's email domain lacking a DMARC record is the potential for ASIC to view this as a failure to maintain adequate risk management systems, potentially breaching Section 180(1) of the Corporations Act 2001. This is particularly relevant for publicly listed companies, as ASIC may take the view that the absence of basic email security measures demonstrates a lack of due care and diligence by directors.

Despite the ATO's increasing focus on cyber-enabled crime, many Australian businesses remain unaware that a supplier's email domain without an SPF record may be a red flag for potential phishing scams. In fact, the ATO's own guidelines for protecting against email scams specifically recommend verifying the authenticity of emails by checking the sender's SPF record. By not doing so, businesses may be leaving themselves open to potential losses and reputational damage.

It's worth noting that the presence of a DMARC record with a p=none policy does not necessarily mean that a supplier's email domain is insecure. However, in the context of ASIC's Regulatory Guide 221 on risk management systems, a p=none policy may be seen as inadequate for managing the risk of email spoofing. In contrast, a p=reject policy demonstrates a much higher level of commitment to email security and may be viewed more favourably by regulators.

Interestingly, the Australian Cyber Security Centre's (ACSC) guidelines for email security specifically recommend implementing DMARC with a p=reject policy, but do not provide guidance on how to verify a supplier's DMARC record. This oversight highlights the need for businesses to take a proactive approach to verifying their suppliers' email security measures, rather than simply relying on government guidelines or industry best practices.