What Unknown SPF and DKIM Results Mean in a DMARC Report

A DMARC aggregate report usually shows how receiving mail systems evaluated messages claiming to come from a domain. Alongside counts, source IP addresses and policy actions, it may include SPF and DKIM authentication results. When both appear as “unknown”, “not available” or an equivalent blank state, the record needs careful interpretation.

This status does not automatically prove that the sender is malicious, nor does it confirm that SPF and DKIM are missing. It can reflect incomplete reporting, a limited receiver implementation, forwarding behaviour, parsing problems or an unusual mail path. Understanding the context helps Australian domain owners distinguish a technical reporting gap from a genuine spoofing risk.

What the unknown status actually indicates

In a DMARC report, an unknown SPF or DKIM value generally means the report does not provide a usable result for that check. The receiving organisation may have omitted the detail, used a non-standard format or been unable to evaluate the message fully.

This differs from a clear SPF “fail”, DKIM “fail”, “pass” or “none” result. A failure says an authentication test produced a negative outcome. Unknown says the available report data cannot establish what happened. The distinction matters when assessing suspicious mail sent in the name of a business, government department or .au domain.

The report may be incomplete rather than the email

Some mailbox providers produce limited aggregate reports. Their systems may record whether DMARC passed overall while leaving individual SPF and DKIM fields unavailable. Older software, privacy controls and different XML interpretations can also cause a receiving report to contain unknown values.

A report can also be damaged in transit. XML conversion, compression errors, incorrect namespaces or third-party report processing may remove authentication details. If the same source repeatedly produces incomplete records, compare the original attachment with the version imported into a monitoring platform before changing DNS settings.

Forwarding can obscure authentication evidence

Forwarding is a common reason for confusing authentication results. SPF often breaks when a message passes through an intermediary because the forwarding server is not authorised in the sender’s SPF record. DKIM may survive forwarding, but modifications to the subject, body or headers can invalidate the signature.

Australian organisations frequently use Microsoft 365, Google Workspace, marketing platforms, ticketing systems and outsourced customer-service mailboxes together. A message sent from Melbourne to a recipient in Perth might pass through several providers before delivery. If a forwarder or mailing list strips or changes authentication headers, the final report may have little reliable evidence to display.

The sending source may be poorly configured

Unknown results can point to a legitimate service that has not been configured correctly. A business might publish SPF for its main mail provider but forget an invoicing platform, CRM, bulk email service or appointment system. DKIM may be enabled for one tenant or subdomain while another sending stream uses no signature.

This is particularly relevant for Australian retailers, schools, property agencies and charities that rely on multiple SaaS vendors. Review the report’s source IP, envelope-from domain, header-from domain and message volume. A previously unseen source sending a large number of messages deserves closer attention, especially if it resembles a known brand or uses a lookalike domain.

DMARC alignment can still be the key signal

DMARC passes when either SPF or DKIM authenticates the message and aligns with the visible From domain, subject to the domain’s policy mode. Therefore, unknown individual results do not necessarily mean DMARC failed. The aggregate record may still show a pass, quarantine or reject outcome.

Check whether the report identifies an authenticated domain that differs from the domain customers see. A message could pass SPF for a vendor’s domain while failing alignment with the organisation’s From address. Conversely, a valid DKIM signature from the correct organisational domain may provide DMARC protection even when SPF is unavailable.

Use independent checks before taking action

DNS inspection can show whether the domain publishes an SPF policy and DKIM selector records. It cannot prove that every message uses them correctly, but it can reveal missing records, multiple SPF policies, invalid syntax and expired selectors. A sender trust check can add reputation and configuration context when a report contains little authentication detail.

Examine several reporting periods rather than reacting to one unknown record. Compare sending volume, source networks, recipient domains and policy dispositions. For an Australian business, also verify that transactional mail from local providers, .com.au addresses and regional marketing systems is included in the approved sending inventory.

Strengthen monitoring and authentication

Publish one valid SPF record, keep it within DNS lookup limits and include only services that genuinely send mail for the domain. Enable DKIM signing for each authorised platform, rotate selectors periodically and remove old records after confirming they are no longer required. Set DMARC reporting addresses that can receive and process aggregate feedback reliably.

Start with a monitoring policy when the sending landscape is unclear, then tighten enforcement as legitimate sources are authenticated. A domain owner can use DMARC guidance to understand reporting and anti-spoofing controls while investigating unknown entries. Security teams should retain reports, investigate abrupt changes and treat unexplained sources as potential impersonation attempts rather than assuming every unknown result is harmless.