Reading DMARC reports to uncover hidden third-party senders

Most Australian organisations rely on a stack of cloud tools to communicate with customers, from marketing platforms to invoicing systems. Each one can send email that appears to come from your domain, and major local receivers like Optus treat your reputation as a single shared asset. If a single service misbehaves, deliverability across the entire business suffers.

DMARC reports turn guessing into evidence. They show, in machine-readable form, every server that tried to send mail using your domain and whether it passed SPF or DKIM. For Australian teams operating under the Privacy Act and the Notifiable Data Breaches scheme, this visibility is also a practical defence against business email compromise, which the ACSC regularly flags as one of the costliest local threats.

The reports look intimidating, but once you know what to scan for, they reveal which third-party platforms are sending on your behalf, which are failing authentication, and which look like outright spoofing attempts.

Setting up DMARC reporting the right way

Before any useful data lands in your inbox, your DNS needs a DMARC record that explicitly asks for reports. A common Australian starting point looks like v=DMARC1; p=none; rua=mailto:[email protected]; fo=1. The p=none tag means you are watching only, not yet rejecting mail, which is sensible while you build a baseline.

You also need a mailbox or, far more practically, a dedicated ingestion address. Many local MSPs pipe reports into Postmark's DMARC tools, Valimail, or a self-hosted parser like parsedmarc. For organisations running multiple .au brands, an API-driven ingestion service that writes findings into a SIEM keeps everything queryable.

Make sure you also turn on the ruf tag for forensic reports if you want samples of failing messages. These can contain the full email body, so route them to a secured inbox that complies with the Privacy Act's storage rules.

Decoding the structure of an aggregate report

An RUA aggregate report is an XML file attached to your inbox, usually once a day per receiving server. The top-level fields tell you which organisation sent the report, often a global provider such as Google, Microsoft, or Yahoo, alongside local participants like Aussie recipient servers, the date range covered, and your policy as they saw it.

Inside, the real value sits in the record rows. Each row lists a source IP, message count, SPF and DKIM result (pass, fail, neutral, or none), and the alignment between those results and your From: header. A row where both authentication and alignment pass is your confirmed sender universe. A row where authentication passes but alignment fails usually points to a legitimate service sending through its own domain rather than yours.

Rows with no SPF or DKIM pass at all are where spoofing lives. Cross-checking the source IP against published ESP ranges quickly separates well-known marketing and transactional platforms from random botnets.

Telling legitimate services apart from spoofing

Once you have a list of sending IPs, the next step is attribution. Public allow-lists from SendGrid, Mailgun, Postmark, and Amazon SES give you a reliable starting point. For Australian-specific platforms, Campaign Monitor's IP ranges and Salesforce Marketing Cloud's allow-list should be bookmarked, because local marketing teams lean on them heavily.

A service is genuinely sending on your behalf when you can match the IP range to a provider you actually use, when the header_from aligns with your domain, and when DKIM signs with a key you published in DNS. Cross-referencing this with domain reputation data helps rank findings by real-world risk.

Spoofed traffic tends to arrive from residential ranges, bulletproof hosts, or cloud accounts freshly spun up. If the IP does not match any provider you pay and DKIM is not signed by your published key, treat it as malicious. There are also clever attacks that copy your SPF record almost exactly to slip past naive filters, and spotting them requires careful inspection of how the receiving server resolved the check.

Common third-party services in Australian stacks

Walk through any Australian e-commerce or SaaS business and the sending footprint usually includes Mailchimp or Klaviyo for newsletters, Stripe or Square for receipts, Zendesk for support replies, and an ATS like Workday or PageUp for HR notifications. Each must be authorised in your SPF record and ideally sign DKIM under a dedicated selector such as k1 or cmail.

Government-adjacent senders are worth noting. If your organisation handles tax, super, or health data, you may integrate with platforms that send on behalf of clients, and those flows need their own authentication. Financial services operating under APRA's CPS 234 often have a long list of vendors, from credit-reference agencies to fraud-screening partners, each quietly generating transactional mail.

Do not forget internal tooling. HR systems like Employment Hero, payroll services like Xero or MYOB, and even internal SharePoint notifications can sneak into your reports. The first pass through your DMARC data almost always surfaces at least one service the IT team had forgotten was configured.

Acting on findings and tightening the perimeter

The end goal is a clean, allow-listed ecosystem. Once you know which IPs belong to which vendors, build a flat-list SPF record (-ip4:192.0.2.0/24 -include:sendgrid.net -include:mailgun.org) and keep it under the ten-DNS-lookup limit that many receivers enforce. Publish a DKIM key for every platform that supports it, then move to p=quarantine once a fortnight of clean data confirms nothing legitimate is failing.

Reviewing reports weekly catches new vendors early. A new IP range appearing in your inbox without a matching service ticket is often the first sign of a forgotten integration or, worse, a shadow-IT deployment. Pair the human review with a continuous monitor that alerts on alignment failures, so a sudden spike from an unknown IP triggers a workflow rather than a scramble.

For teams that want a structured way to triage, learning to identify SPF spoofing attempts closes the loop between report analysis and frontline response. The discipline pays off in clean alignment, fewer false positives at major AU receivers, and a domain reputation that holds up under the scrutiny of the ACSC and your customers alike.