Find missing DMARC records across your domain database

A domain without a DMARC record gives attackers more room to impersonate a trusted organisation. If that domain appears in your customer, supplier, marketing or asset database, it may be sending email without a clear policy for handling messages that fail authentication.

Bulk checking lets you review hundreds or thousands of domains in one operation instead of opening each DNS record manually. This is useful for Australian organisations managing multiple brands, subsidiaries, campaign domains and regional properties such as .com.au and .au addresses.

The objective is to identify domains where DMARC is absent, incorrectly published or too weak for the organisation’s risk profile. A missing record does not always mean that mail is currently being spoofed, but it removes an important layer of visibility and policy enforcement.

Trusted Sender Score provides domain reputation and email authentication checks for this type of review. Its bulk tools can help security teams turn a large domain list into a prioritised set of DNS and anti-spoofing tasks.

Prepare a clean domain inventory

Start by exporting the domains you want to assess from your CRM, DNS management platform, marketing system, certificate inventory or threat intelligence database. Remove URL paths, email addresses and protocol prefixes so each row contains a domain name such as example.com.au.

Deduplicate the file before uploading it. A business with offices in Sydney, Melbourne and Perth may have several systems recording the same domain, while a group with multiple brands may own both .com.au and .au versions. Keeping one domain per row makes the results easier to interpret and report.

Include domains that are used for sending, receiving or representing the organisation, even if they are not part of the main website. Forgotten campaign domains and retired brand names can still be used in phishing if their DNS settings remain active.

Run the bulk DMARC check

Open the bulk checking feature and upload the prepared list in the supported format. The service should test each domain’s _dmarc DNS record and return a result that distinguishes between a record being present, missing, malformed or potentially misconfigured.

A missing DMARC result generally means that no usable TXT record was found at _dmarc.domain. For example, a check for brand.com.au looks for a policy at _dmarc.brand.com.au. Do not confuse this with checking the root domain’s general TXT records; DMARC has a specific DNS location.

For background on syntax, tags and policy choices, consult this DMARC guide before changing production records. Understanding p=none, p=quarantine and p=reject helps prevent a rushed policy change from affecting legitimate mail.

Separate missing records from weak protection

Filter the results to isolate domains with no DMARC record. Then review the remaining findings for related issues, including invalid syntax, missing reporting addresses, a monitoring-only policy or an enforcement policy that does not align with the organisation’s security requirements.

A p=none record means the domain can collect authentication reports without asking receivers to quarantine or reject failing messages. It is useful during deployment, but it does not provide the same anti-spoofing control as an enforcement policy. A domain with p=quarantine or p=reject may still need review if SPF, DKIM alignment or authorised sending services are incomplete.

The anti-spoofing factsheet can help teams assess whether a domain’s configuration supports stronger conformance. This distinction matters for Australian retailers, health providers and professional firms that regularly appear in scam campaigns monitored by customers and regulators.

Prioritise domains for remediation

Not every missing record deserves the same immediate response. Rank domains by business importance, email volume, public visibility and likelihood of being imitated. A primary bank, university or government-related domain should usually receive attention before an unused internal test domain.

Check which platforms send mail on behalf of each domain, including Microsoft 365, Google Workspace, customer relationship systems, ticketing tools and email marketing providers. Confirm that SPF and DKIM are configured and aligned before moving from monitoring to enforcement. Keep a record of approved senders and the person responsible for each DNS zone.

Australian organisations should also account for local operational arrangements. A Brisbane-based franchise network, for example, may allow separate agencies to send from a shared brand domain, while a Sydney head office may control DNS centrally. Documenting those arrangements avoids accidental disruption during remediation.

Turn results into a repeatable process

Save the bulk scan output with the date, source list and responsible team. A scheduled review can identify newly registered domains, acquired brands and records that disappear after a DNS migration. Comparing results over time provides a practical measure of authentication coverage.

Security teams with larger inventories can connect checks to internal workflows through the platform’s developer capabilities. The API threat intelligence guide explains how trust data can support enrichment and prioritisation in existing systems.

Use the findings to create remediation tickets, notify domain owners and verify changes after DNS propagation. A simple dashboard showing total domains, missing DMARC records, monitoring-only policies and enforced policies gives leadership a clear view of progress and helps keep spoofing risks visible.