How to Build a Recurring Report of Brand Email Domains

A brand can send email through its main domain, a marketing platform, a customer relationship system, a payroll provider, a ticketing tool and several agencies. Over time, these services create a wider sending footprint than the internal IT team may realise. A recurring report makes that footprint visible.

The objective is to identify every domain and subdomain sending messages on behalf of the organisation, then record who owns each service, which authentication controls it uses and whether it still has a legitimate business purpose. This helps prevent spoofing, delivery problems and forgotten third-party access.

For an Australian organisation, the process is especially useful across distributed teams in Sydney, Melbourne, Brisbane and Perth. Marketing, finance and customer support may each contract separate platforms, while .au domains, local subsidiaries and suppliers create additional variations that a single DNS review can miss.

Discovery method	What it reveals	Strength	Limitation
DMARC aggregate reports	Sending IPs, envelope domains and authentication results	Continuous visibility	Needs interpretation
DNS and SPF review	Declared email services and authorised senders	Quick to automate	Can include stale entries
DKIM selector review	Services signing messages for a domain	Confirms active signing	Selectors may be hard to attribute
Mailbox and gateway logs	Actual messages reaching users	Operational evidence	Access and retention vary

Define the reporting scope

Start with an inventory of every brand domain, subdomain and regional variation. Include the primary website domain, campaign domains, transaction subdomains and domains used by Australian business units. Record whether each is active, parked, redirected or reserved for future use.

Define “sending on behalf” precisely. The report should generally include domains appearing in the visible From address, the envelope-from or Return-Path field, and the DKIM signing domain. It should also distinguish a provider’s infrastructure domain from the organisation’s own domain so that ownership and risk are not confused.

Gather evidence from multiple sources

DMARC aggregate reports are the core data source because they show which IP addresses are sending mail that claims alignment with a protected domain. The DMARC project guide can help teams interpret rua data, alignment and policy results before building automation around them.

Add DNS collection for SPF, DKIM and DMARC records, plus message telemetry from secure email gateways and cloud mail platforms. A practical report combines observed sending activity with declared authorisation, rather than assuming that an SPF entry proves a service is still approved.

Set useful data fields

Each record should include the discovered domain, parent brand, sending provider, source IP or network, first-seen date, last-seen date and message volume. Store SPF status, DKIM status, DMARC alignment, policy mode and the relevant selector where available.

Add operational fields such as business owner, contract owner, purpose, data classification and review status. These details turn a technical list into an actionable register. A finance platform in Melbourne may require a different review path from a short-term event mailing service used by a Brisbane office.

Automate the collection cycle

Run DNS and reputation checks daily or weekly, while processing DMARC aggregate reports as they arrive. A scheduled job can normalise XML reports, resolve IP ownership, group equivalent providers and compare current results with the previous reporting period.

Use the platform’s bulk checking and API capabilities where possible, so new domains can be assessed consistently. Set thresholds for new senders, sudden volume changes, failed alignment and previously inactive domains becoming active. Preserve historical results so investigators can see when a service appeared or disappeared.

Verify ownership and legitimacy

A discovered domain is not automatically malicious. It may belong to a legitimate supplier, a newly launched product or a hosted service that has not yet been added to the central register. Ask the relevant business owner to confirm the purpose, provider and expected sending volume before removing access.

At the same time, treat unexpected activity seriously. The guidance on legitimate-domain phishing explains why a real domain can still be abused when authentication is weak or incomplete. Compare sender identity, links, authentication results and mailbox behaviour rather than relying on the domain name alone.

Present risk in a readable report

A useful recurring report has an executive summary, a complete sender-domain register, exceptions and changes since the previous issue. Highlight domains with no confirmed owner, missing DKIM, weak or absent DMARC enforcement, excessive SPF lookups and senders that fail alignment.

Use risk categories that non-specialists can understand: verified, needs review, unauthorised or inactive. Include evidence, affected services and a clear remediation owner. This is valuable for Australian organisations preparing security documentation under internal governance requirements, privacy obligations and the Notifiable Data Breaches scheme.

Connect findings to governance

Review the report with marketing, procurement, IT and security teams rather than leaving it with DNS administrators. Contracts for email platforms should require authentication support, access revocation and notification when sending infrastructure changes. Commercial messages should also remain consistent with Australia’s Spam Act 2003, including consent and unsubscribe requirements.

Schedule a formal review at least quarterly and after mergers, rebrands, agency changes or major platform migrations. The authentication audit checklist provides a structured way to confirm that DNS records, delegated services and enforcement policies still match the approved sender inventory. Over time, this recurring process creates a defensible record of who can send email for the brand and why.