Understanding Relay-Information Alerts in DMARC Reports

A DMARC report indicator marked “Relay-Information” alongside unknown servers can be unsettling, particularly when a domain owner expects every legitimate message to come from a familiar mail platform. This combination usually means that an intermediary, forwarding service, or unrecognised outbound system handled messages claiming to use the domain.

The label does not automatically prove that the domain has been compromised. “Relay-Information” is often a reporting platform’s interpretation rather than a universal DMARC XML field defined in one standard format. The unknown server may be a genuine third-party sender, a forwarding path, an old system, or an attacker attempting to impersonate the domain.

For an Australian business, the distinction matters. A Sydney retailer, Melbourne consultancy, or organisation using a .au domain may send mail through several providers, including Microsoft 365, Google Workspace, marketing platforms, ticketing systems and local hosting companies. DMARC data helps separate expected infrastructure from shadow IT and malicious activity.

What the indicator can represent

A relay is a system that passes, redirects, or sends email on behalf of another service. Mailing lists, helpdesk applications, customer relationship platforms and email security gateways can all appear as intermediate servers. Forwarding from a personal mailbox to an employee’s Gmail account may also alter the visible path and affect authentication results.

An unknown server means the reporting system cannot confidently associate the source IP, hostname or provider with the domain’s approved sending inventory. It may be a recently introduced service, an overlooked subdomain, or a provider whose infrastructure changes frequently. In other cases, it is a compromised account or a forged message using the organisation’s domain in the visible From address.

The first step is to compare the event with known business activity rather than treating the label as a verdict. A rise during an Australian sales campaign, end-of-financial-year promotion or Christmas trading period may correspond to a legitimate bulk-mail provider.

Authentication results provide the context

DMARC evaluates whether SPF or DKIM passes and whether the authenticated domain aligns with the visible From domain. A relay that passes DKIM with correct alignment is generally less concerning than an unknown source that fails both SPF and DKIM. The message count, sending time, recipient domains and policy action add further context.

SPF may fail when a forwarding service is involved because the forwarder’s IP is not authorised by the original domain. DKIM can survive forwarding, but modifications made by list software or security gateways may break the signature. Authenticated Received Chain, or ARC, can preserve information about earlier authentication decisions, although it does not make an untrusted sender legitimate by itself.

Use a reputation and authentication view such as sender metrics to examine patterns across the domain. Repeated low-volume failures from unrelated networks suggest a different risk from a stable relay that consistently produces aligned DKIM passes.

How to investigate unknown servers

Start with the source IP, reverse DNS name, autonomous system and report date. Check whether the address belongs to a recognised provider, an Australian hosting company, a cloud region in Sydney or Melbourne, or an unrelated residential or overseas network. Reverse DNS alone is not proof of legitimacy, but an absent or misleading hostname can increase concern.

Compare the server with invoices, vendor records and application settings. Marketing automation, payroll platforms, booking systems and customer support tools are often added by different departments. A local franchise or branch may have configured its own mail service without informing the central IT team.

Review message samples where available, but handle report data carefully. DMARC reports can reveal recipient domains and operational patterns, so access should be limited under internal privacy procedures and relevant Australian obligations. The Australian Spam Act 2003 also makes accurate sender identification and responsible commercial messaging important.

Distinguishing forwarding from spoofing

Legitimate forwarding often produces a recognisable pattern: modest volume, consistent relay infrastructure, and either DKIM alignment or evidence that the original message passed authentication before forwarding. Mailing-list traffic may show recurring list servers and predictable delivery times. These patterns should be documented as approved exceptions rather than broadly trusted forever.

Spoofing is more likely when unknown servers send large bursts, target unrelated recipients, fail both SPF and DKIM, or appear across many countries without a business explanation. A fake invoice campaign aimed at Brisbane customers or a credential lure imitating an Australian bank can use the domain’s name even when the real mail platform is secure.

Anti-spoofing controls should include a complete inventory of authorised senders, aligned DKIM for important services, an accurate SPF record and a DMARC policy that progresses from monitoring to enforcement. Practical anti-spoofing guidance can help translate those controls into checks for domain owners and security teams.

Turning reports into a trusted sender inventory

Treat each recurring relay as an item to classify: approved provider, forwarding path, legacy service, unknown business application or confirmed abuse. Record the owner, purpose, IP range, DKIM selector and expected volume. This creates a useful baseline for organisations operating across Sydney, Perth and regional offices.

A domain comparison can also reveal whether an authentication weakness is isolated or common in a sector. The dashboard comparison guide explains how to review trust information alongside comparable domains without relying on a single report event.

Once the source is understood, update DNS and vendor configurations narrowly. Do not add an unknown server to SPF merely because it appears in a report. Confirm ownership, require DKIM alignment where possible, monitor subsequent aggregate reports and escalate unexplained failures. In that way, “Relay-Information” becomes an investigative signal rather than a confusing alert.