What SPF Passes but DKIM and DMARC Failures Reveal

An email can pass SPF and still present a serious trust problem. SPF confirms that the sending server is authorised to send for a domain, but it does not prove that the message content remained unchanged or that the visible From address is genuinely aligned with the authenticated domain.

DKIM and DMARC add those missing checks. DKIM applies a cryptographic signature to the message, while DMARC assesses whether SPF or DKIM aligns with the domain shown to the recipient. When DKIM fails and DMARC fails, the sender’s setup is usually incomplete, misconfigured, or being abused.

This pattern matters to Australian organisations sending invoices, staff notices, account alerts and marketing campaigns. A message that looks like it came from a .au domain may pass one technical test while still failing the broader identity checks used by Microsoft, Google and security gateways.

For a small business in Brisbane, a school in Adelaide or a national retailer with offices in Sydney and Perth, the result can be confusing: the email may arrive, yet its sender reputation can deteriorate. Understanding each authentication result helps separate a setup error from attempted spoofing.

What SPF actually proves

Sender Policy Framework uses a DNS TXT record to list servers and services allowed to send mail for a domain. If the receiving server sees an approved IP address, SPF passes. This is useful evidence, but it only relates to the SMTP envelope sender, sometimes called the Return-Path.

The visible From address can be different. An attacker may send from an authorised third-party platform while displaying a trusted brand in the From field. SPF can therefore pass even when the message’s apparent identity is misleading. Forwarding, mailing lists and ticketing systems can also alter the path enough to cause inconsistent results.

Why DKIM may fail

DomainKeys Identified Mail adds a signature to selected message headers and the body. The receiving server retrieves the public key from DNS and checks whether the signature matches. A failure may indicate a missing selector record, an incorrect public key, an expired configuration or a message changed after signing.

Common causes include a marketing platform using the wrong selector, an email gateway rewriting content, or a sender signing with a domain that no longer exists in the organisation’s DNS. A rotated key that was removed too quickly can produce failures across legitimate campaigns.

How DMARC evaluates the message

DMARC does not authenticate mail independently. It checks whether SPF or DKIM passes and whether the authenticated domain aligns with the visible From domain. Under relaxed alignment, related organisational domains may qualify; strict alignment requires an exact match.

If DKIM fails and the SPF-authenticated domain does not align, DMARC fails too. This can happen even when SPF itself passes. The key distinction is that authorisation to send is different from proving that the sender is allowed to represent the brand shown to the recipient.

What this says about the sender

The result usually points to a fragmented email architecture. The organisation may have published SPF correctly but forgotten to configure DKIM for one provider, failed to align a Return-Path domain, or added a new service without updating its authentication policy.

It can also indicate weak operational control. Multiple agencies, cloud platforms and internal systems may be sending on behalf of the same domain without a central inventory. For an Australian business moving quickly between vendors, that can happen during a website rebuild or a last-minute campaign before an EOFY promotion.

Legitimate errors versus spoofing

A genuine sender often shows repeatable, provider-specific failures. For example, messages from a CRM may fail DKIM while ordinary Microsoft 365 mail passes. Reviewing headers, DKIM selectors, sending IPs and DMARC reports can reveal whether the problem belongs to one known service.

Spoofing tends to produce unfamiliar infrastructure, unusual geographic sources or domains that resemble the brand. An email claiming to be from a bank, parcel company or government service deserves extra caution, particularly when it requests a password, payment or urgent transfer. Australian recipients should be wary of messages impersonating myGov, Australia Post or local financial institutions.

How security teams should respond

Domain owners should inventory every legitimate sender, publish a deliberate SPF record, enable DKIM with controlled selectors and set a DMARC policy. Starting with monitoring can help identify legitimate services before moving towards quarantine or reject. Teams can formalise this process with a security operations checklist that connects authentication results with incident response.

Security staff should also examine aggregate and forensic DMARC reports, while treating unexpected failures as useful signals rather than isolated delivery issues. Bulk checking is valuable when an organisation manages multiple brands, regional domains or acquired businesses across Australia.

Reputation still requires wider checks

Passing or failing authentication does not fully determine whether a sender is safe. A domain may have perfect SPF, DKIM and DMARC records yet suffer from compromised accounts, abusive sending behaviour, poor list hygiene or a history of spam complaints. Authentication confirms identity controls; reputation reflects how that identity has behaved.

That is why authentication results should be assessed alongside domain age, sending volume, blocklists and recipient complaints. A reputation score review can help explain why technically valid mail is still treated cautiously. In practice, SPF passing while DKIM and DMARC fail is a clear warning that the sender’s identity chain is only partially configured, and that mail should not automatically be trusted.