DNS Lookup and Bulk Check Tool Guide

22 June 2026 · 13 min read

The DNS Lookup tool lets you read the live, published email-authentication records for any domain on the internet, not just the domains in your own account. It is the fastest way to answer questions like "is this record actually live yet?", "what selector is this sender using?", "do all forty of our brands have a DMARC policy?" and "how does our setup compare with a competitor's?". It runs the same DNS resolution the platform uses internally, so what you see here is what mail receivers see.

You will find it in the dashboard at app.dmarcengine.com under DNS Lookup (the URL is /lookup). The page opens with the heading DNS Lookup and the description "Look up DMARC, SPF, DKIM, MTA-STS, BIMI, and MX records for any domain". Directly beneath that sits a row of four tabs: Single Lookup, Quick Check, Bulk Lookup and Compare. Each tab is a separate mode of the same underlying lookup engine, and this page documents all four, plus the Recent Lookups history and the CSV export.

If you are not signed in, or you want to share a result with someone who is not a customer, the public free tools mirror the same checks: the DMARC checker, SPF checker, DKIM checker, BIMI checker and MTA-STS checker. The dashboard tool adds bulk lookups, side-by-side comparison, parsed-tag breakdowns and lookup history on top of those.

What the tool does and does not do

The DNS Lookup tool is a read-only diagnostic. It queries public DNS and shows you what is published right now. It does not change anything, it does not require the domain to be in your account, and it does not need the domain to be delegated to the platform. That makes it safe to point at any domain, including ones you do not control.

It is deliberately separate from the editing surfaces. To change a record on one of your own domains you use the product configuration screens: Hosted DMARC at /dmarc, Hosted SPF at /spf, Hosted DKIM, Hosted MTA-STS and Hosted BIMI. The lookup tool is where you verify those changes have propagated, or investigate a domain you are about to onboard. See Adding your first domain and Delegating your DNS for the editing side.

Because the endpoint is shared and lightweight, it is rate limited to roughly 30 lookups per minute per client. If you exceed that, the tool stops and shows the message "Too many lookups. Please slow down and try again in a minute." This almost never affects manual use; it can appear during a very large bulk run, in which case wait a minute and run the remainder. Bulk and Quick Check runs already pace their requests to stay under the limit.

Single Lookup

The Single Lookup tab is the default view and the one you will use most. It checks one record type, on one domain, and shows you the full result with a parsed breakdown.

There are three inputs in a single row, followed by the action button.

Domain is the free-text field on the left, with the placeholder Enter domain (e.g. google.com). Type the bare domain only: no https://, no www., no trailing slash, no path. For example, enter example.com, not https://www.example.com/. The tool validates this before querying, so an invalid string returns "Invalid domain" rather than a misleading "Not Found".
Record Type is the dropdown to the right of the domain. It offers seven types: DMARC, SPF, DKIM, MTA-STS, BIMI, MX and TLS-RPT. The type you choose determines which hostname the tool queries (see the table of hostnames below).
Selector is a field that only appears when Record Type is set to DKIM or BIMI. Both of those record types live at a hostname that includes a selector label, so the tool needs to know which one to ask for. It is hidden for all other types because they have a single, fixed hostname.

Press Lookup (or simply press Enter while the domain field is focused) to run the query. The button shows a spinner while the lookup is in flight.

The Selector field, explained

A DKIM record does not live at the bare domain. It lives at <selector>._domainkey.<domain>. The selector is a short label that the sending system chooses when it publishes its public key, so a single domain can have many DKIM keys live at once (one per sender, or one per key rotation). Common selectors include google, s1, s2, selector1, selector2, k1, dkim and mandrill, but they are arbitrary and vendor-specific.

To check a DKIM record you must therefore know the selector. If you leave the Selector field blank, the tool queries the conventional default selector, which many domains do not use, so a blank lookup often returns Not Found even on a correctly configured domain. The selector is usually visible in the DKIM-Signature: header of an email you have received from that domain, on the s= tag. For your own hosted domains, the dashboard shows you the selector when you configure Hosted DKIM.

BIMI uses the same pattern at <selector>._bimi.<domain>, and the Selector field appears for BIMI for the same reason. The near-universal BIMI selector is default, so leaving the field blank is usually correct for BIMI; fill it in only if a sender uses a non-default BIMI selector.

Which hostname each record type queries

Knowing the exact hostname the tool resolves helps you read the result and reproduce it in your own DNS client. For a domain example.com:

DMARC queries _dmarc.example.com (TXT, starting v=DMARC1).
SPF queries example.com itself (TXT, starting v=spf1).
DKIM queries <selector>._domainkey.example.com (TXT containing p=).
MTA-STS queries _mta-sts.example.com (TXT, starting v=STSv1).
BIMI queries <selector>._bimi.example.com (TXT, starting v=BIMI1).
MX queries example.com for its mail-exchanger records.
TLS-RPT queries _smtp._tls.example.com (TXT, starting v=TLSRPTv1).

For the full meaning of each record, its delegation model and example values, see the DNS record reference.

Reading the result

When the lookup completes, a result card appears with several parts. Not every part shows for every record type; the tool renders only what is relevant.

A Found badge (green, with a tick) or a Not Found badge (red) shows at the top, next to the record type heading. Found means a record of the requested type was published at the expected hostname; Not Found means nothing of that type was there. Not Found is a real, useful answer: for DMARC or SPF it usually means the domain is unprotected.
The hostname that was actually queried is shown on the right in a monospace font (for example _dmarc.example.com). Always glance at this to confirm the tool asked the question you meant, especially for DKIM where the selector is part of the hostname.
A CNAME box appears when the hostname is a CNAME pointing somewhere else. This is exactly what you want to see on a domain delegated to the platform: a DMARC delegation, for instance, shows the hostname pointing at a hosted target. If you delegated a record but the CNAME box is missing, the delegation has not propagated or was published at the wrong name. See Delegating your DNS.
The raw record is shown in a monospace box, exactly as published, character for character. This is the authoritative text; copy from here if you need to paste a record elsewhere.
For MX lookups, instead of a single record you get an MX table listing each mail server by Priority and Mail Server, sorted with the lowest (most preferred) priority first. The table is sortable by clicking the Priority column header.
For records with structured tags, a Parsed Tags grid breaks the record into its individual key/value pairs (for DMARC that is p, sp, adkim, aspf, rua and so on), so you can read a long record at a glance without parsing it by eye.

SPF records get two extra, SPF-specific panels:

SPF Mechanisms lists every mechanism in order, with its qualifier shown in colour: a green + (pass), an amber ~ (softfail) or a red - (fail/hardfail), followed by the mechanism type as a badge and its value. This makes it obvious whether a record ends in -all or the much weaker ~all.
Top-level DNS lookups counts the lookup-causing mechanisms (include, a, mx, ptr, exists, redirect) at the top level of the record only. It is labelled "Excludes nested includes" precisely because it is not the full recursive count. SPF has a hard limit of ten DNS lookups across the whole expanded record, and an include: can hide many more lookups inside it, so do not read this number as your pass/fail margin against the limit. To get the true, fully expanded count and to fix an over-limit record, use the authenticated SPF tooling and How SPF flattening works, or the public SPF checker.

If something goes wrong, the tool tells you which kind of problem it is. "Invalid domain" or "Invalid selector" means the input failed validation before any query ran. "DNS lookup failed" means the query itself could not complete (an upstream or network error), which is different from a clean Not Found. The rate-limit message is described above.

Quick Check: all record types at once

The Quick Check tab answers "is this domain set up at all?" in a single action. Enter one domain in the field (placeholder Enter domain (e.g. example.com)) and press Check All. The tool runs DMARC, SPF, DKIM, MTA-STS, BIMI and MX lookups for that one domain in parallel and lays the results out as six cards in a grid.

Each card is colour-coded for an instant read: a green border and Found badge where the record exists, a red border and Not Found where it does not, and an amber border where that individual check errored. Each card shows the queried hostname and a short preview of the record (for MX, the first few mail servers). Because DKIM needs a selector and Quick Check does not prompt for one, the DKIM card uses the default selector; treat its result as "is there a default-selector DKIM key" rather than a complete DKIM audit, and switch to Single Lookup with the real selector when you need certainty.

Quick Check is the ideal first step when you pick up a new domain. It is faster than running six single lookups and it gives you the whole posture of the domain on one screen, which you can then drill into on the Single Lookup tab.

Bulk Lookup: many domains at once

The Bulk Lookup tab checks the same record type across a list of domains. This is the tab to use for portfolio audits, mergers, or any time you manage many brands and want a single overview.

In the large textarea on the left, paste your domains, one per line. The placeholder shows the expected shape:

   domain1.com
   domain2.com
   domain3.com

Blank lines and stray whitespace are ignored, so you can paste straight from a spreadsheet column without cleaning it up first.
2. On the right, choose the Record Type from the same seven options as Single Lookup: DMARC, SPF, DKIM, MTA-STS, BIMI, MX or TLS-RPT. The whole list is checked for this one type.
3. Press the Lookup All button. Its label includes a live count of how many domains it detected, for example Lookup All (12 domains), which is a quick sanity check that the tool parsed your list the way you expected.

The tool paces the requests internally so a large list stays within the rate limit, then shows a results table headed Results. Each row has:

Domain, in monospace. The column is sortable by clicking its header.
Status, a badge: green Found, red Not Found, or amber Error for a domain whose lookup itself failed.
Hostname, the hostname queried for that domain (or the error text, if the row errored).
Record, a truncated preview of the published record.
CNAME, the CNAME target if the hostname is delegated, otherwise a dash.

Because Bulk Lookup runs one record type per pass, a thorough portfolio audit usually means running it several times: once for DMARC to find unprotected domains, once for SPF, and so on. Sort by Status (via the table's sort controls) to push the Not Found rows together and see your gaps immediately.

Tip: DKIM in Bulk Lookup uses a single selector value across the whole list (default when none is set in the underlying query), so it is only meaningful if all the domains share that selector. For mixed-vendor portfolios, audit DKIM per domain on the Single Lookup tab where you can set the correct selector each time.

Exporting results to CSV

Above the results table is an Export CSV button. Click it to download the full result set as a CSV file named after the record type you checked, for example lookup-DMARC-results.csv. The file contains one row per domain with these columns: domain, found, hostname, record, cname and error. Values are properly quoted, so records that contain commas (almost all DMARC and SPF records do) stay intact and open cleanly in any spreadsheet application.

The CSV is the right artefact to attach to a remediation ticket, share with a colleague, or keep as a point-in-time snapshot before you start fixing records. To analyse the aggregate (RUA) reports those policies generate once enforcement is underway, use the DMARC report analyzer or read Aggregate report analysis.

Compare: two domains side by side

The Compare tab puts the same record type for two domains next to each other. Enter the first domain under Domain 1, the second under Domain 2, choose the record Type, and press Compare. The tool looks up both at once and renders two result cards side by side, each with the same Found/Not Found badge, hostname, raw record and parsed breakdown you get on the Single Lookup tab.

This mode has two everyday uses. The first is benchmarking: put your domain against a peer or a well-known sender to see, for example, whether they enforce p=reject while you are still on p=none, or whether their SPF ends in -all while yours ends in ~all. The second is internal consistency: compare two of your own domains, or a parent domain against a subdomain, to confirm they carry the policy you expect. If one card errors while the other succeeds, the failing side simply shows its error text rather than a misleading empty record.

Recent Lookups (history)

The tool keeps a running history of your lookups so you can re-run them with one click. The Recent Lookups panel appears on the Single Lookup tab whenever you have history but no current result on screen (that is, before your first lookup of a session, or after you clear a result). It lists your most recent lookups, newest first, each as a clickable row showing:

a green tick or red cross indicating whether that lookup found a record,
the domain in monospace,
a badge for the record type that was checked,
and the time the lookup ran.

Click any row to reload that domain, record type and selector back into the form, ready to run again; this is the fastest way to re-check a record you are watching for propagation after a DNS change. Quick Check runs are recorded too, tagged ALL; clicking one of those reloads the domain with the type reset to DMARC so you can drill in.

A few details worth knowing about history:

It is stored locally in your browser, not in your account, so it is private to that browser and device and is not shared with your team. Clearing your browser storage clears it.
It keeps your most recent lookups (the latest twenty), and de-duplicates repeated checks of the same domain and type so the list stays useful rather than filling with repeats.
Use the Clear button at the top of the Recent Lookups panel to wipe the history immediately.

Because history lives in the browser, it is the right tool for an interactive investigation, not for an audit record you need to keep or hand off. For a durable, shareable artefact, run the check in Bulk Lookup and use Export CSV instead.

A typical workflow

Putting the tabs together, a common end-to-end flow looks like this:

Start on Quick Check with a single domain to see its whole posture (DMARC, SPF, DKIM, MTA-STS, BIMI, MX) on one screen.
Drop into Single Lookup to read any record in full, set the real DKIM Selector, and inspect the parsed tags and SPF mechanisms.
After you publish or delegate a record on one of your own domains, return to Single Lookup and re-run it (via Recent Lookups) until the CNAME box and the expected record appear, confirming propagation.
For a portfolio, switch to Bulk Lookup, paste every domain, run each record type in turn, sort by Status to find the gaps, and Export CSV for the remediation list.
Use Compare to benchmark against a peer or to check a parent and subdomain agree.

For the wider context of why these records matter and how to move a domain from monitoring to enforcement, see The enforcement journey, Understanding your DMARC record and the requirements overview. If a result surprises you, Troubleshooting and the glossary explain the most common record-level gotchas. To generate a brand-new policy from scratch rather than inspect an existing one, use the DMARC generator.

DNS lookup and bulk check