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.

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.