Module 14: Diagnostic Tools and Safe Use — Email Security Support Training

On this page

Layer 3 — Troubleshooting

Module 14: Diagnostic Tools and Safe Use

Audience: L1 (core tool set — DNS/WHOIS, mailbox-native message trace, header analysis); L2/L3 (full tool set, including API testing and malware-analysis environments)

Prerequisites: Modules 1–5, 9, 11

Estimated time: 3–3.5 hours self-paced reading and exercises

Reference materials: Module 11 (security and privacy protocols, which this module operationalizes for specific tools); Product Validation Required — the product's own log/telemetry/API tooling and its approved malware-analysis environment

Learning Objectives

By the end of this module, you will be able to:

Use standard DNS, WHOIS, message-trace, and header-analysis tools correctly and safely.
Correctly classify any given piece of data as safe for a public tool, requiring an approved private tool, or never to be uploaded externally — using the 14.14 reference table without hesitation, under time pressure, on your first day using it for real.
Use mailbox-platform-native tools (Microsoft 365 message trace, Google Workspace log search, on-premises Exchange message tracking) to their full diagnostic value.
Use reputation and threat-intelligence sources appropriately, understanding their limitations — including why a "no result found" response is not the same as "confirmed safe."
Follow the organization's approved procedure for any malware or suspicious-URL analysis without exception, regardless of deadline pressure or your own confidence that a given case is probably harmless.

Key Terminology

Public tool: A general-purpose, non-approved, externally hosted service (e.g., a generic public "check this URL" or "scan this file" website) with no contractual data-handling agreement with the organization.
Approved private tool: A tool the organization has vetted and authorized for handling customer data, with an appropriate data-handling agreement or an isolated/sandboxed design.
Detonation: Actually executing or opening a file, or navigating to a URL, in an isolated environment in order to observe its behavior (see Module 10.8).
Threat intelligence source: A curated feed or database of known-malicious indicators (IPs, domains, hashes) used for reputation lookups.

Lesson

Nearly every investigation you run leans on tools — a DNS lookup, a message trace, a hash check, a header dump, occasionally a malware sandbox. Picking the right tool for the diagnostic question is only half of professional practice here. The other half, equally non-negotiable, is knowing exactly what is and is not allowed to leave your hands and go to that tool. A brilliant diagnosis built on an improper data submission is not a success story — it is an incident. This module walks through the standard toolkit end to end, tool by tool, and then builds the one habit every engineer needs to carry for the rest of their career here: correctly classifying a piece of data before it goes anywhere, not after.

14.1 DNS Lookup Tools

Your standard tools for DNS work are command-line utilities like dig and nslookup, plus reputable public DNS-lookup web interfaces when a command line isn't handy. The safe-use classification here is the simplest one you'll encounter in this whole module: domain names and DNS record content are public information by nature — anyone in the world can look them up without your help — so querying them through a public tool carries no data-handling risk and needs no special authorization.

One habit worth building early: when precision actually matters — for example, confirming whether a DNS change has propagated, or getting the authoritative, current answer rather than a cached one — query the domain's own authoritative name servers directly (Module 3.2) rather than trusting whatever a public resolver happens to have cached. A stale cached answer from a public resolver can send you chasing a problem that's already been fixed, or miss a problem that hasn't propagated to that resolver yet.

14.2 WHOIS and Registration-Information Tools

WHOIS lookups are how you check a domain's registration date (a key input to the domain-age reasoning in Module 10.10) and, where available, registrant information. Expect that detail to be increasingly redacted by privacy services — treat the absence of registrant detail as the normal, expected case, not as something suspicious in itself. A domain with fully redacted WHOIS is not automatically a red flag; the overwhelming majority of legitimately registered domains use privacy services today.

Safe-use classification: the domain name itself is safe to query through public WHOIS tools, exactly as with DNS lookups above. The discipline to hold onto is what you attach to that query. Query the domain name alone — never add customer-specific context to a public tool, such as framing your lookup around "we suspect this domain is being used to attack Customer X." The domain name by itself reveals nothing about your organization or your customer; typing customer-identifying context into a public tool's query box does.

Worked Example — Checking a Suspicious Domain with Public Tools

Say a ticket lands with a sender domain you don't recognize, and you want a quick read on it before deciding whether it warrants deeper investigation. Here's how I'd work it, narrating each step:

First, a DNS lookup to see what's actually configured for the domain:

$ dig MX suspicious-domain.example NS
suspicious-domain.example.  3600  IN  MX  10 mail.suspicious-domain.example.
suspicious-domain.example.  3600  IN  NS  ns1.registrar-dns.example.
suspicious-domain.example.  3600  IN  NS  ns2.registrar-dns.example.

Nothing here required anything but the domain name — no customer context attached, no need to route this through anything but a plain public tool. Next, a WHOIS lookup to see how old the registration is:

$ whois suspicious-domain.example
Registrar: Example Registrar, LLC
Creation Date: 2026-08-21T00:00:00Z
Registrant: REDACTED FOR PRIVACY

Again — just the domain name, nothing else, and again a public tool is the correct choice per 14.14. The redacted registrant tells me nothing by itself (that's the norm now, per 14.2 above), but the seven-day-old creation date is a meaningful data point I'd carry into the domain-age reasoning from Module 10.10. Notice what I did not do at any point: I never typed the customer's name, the ticket number, or anything identifying our organization into either query. That's the entire safe-use discipline for this category — the domain name travels alone.

14.3 Microsoft 365 Message Trace

Message trace is the authoritative record of what Exchange Online Protection actually did with a specific message — not what you'd expect it to have done, not what the customer remembers, but what actually happened at that system. It's essential for Playbooks 13.1, 13.4, and 13.7, and for any ticket where you need the mailbox platform's own record of events rather than inference (Module 2.6).

Search by Message-ID whenever you can — it's the precise, unambiguous key you learned to capture first back in Module 1.8. Sender/recipient/date-range search is a usable fallback when the Message-ID isn't available, but it returns a noisier result set and should be narrowed as tightly as the ticket allows.

Product Validation RequiredThe exact access level Support holds into a given customer's Microsoft 365 tenant — whether that's access the customer's own admin has granted directly, or a channel-partner delegated-access model — varies by customer relationship and must be confirmed for the specific account in front of you, never assumed from how a previous customer was set up.

14.4 Google Workspace Email Log Search

Google Workspace's equivalent of message trace is the email log search inside the Admin console. The same precision principle from 14.3 applies here without modification — search by Message-ID, or the RFC822 Message-ID field specifically, whenever it's available, for the same reason: it's the one identifier guaranteed not to have drifted between systems.

One thing to keep in mind that's specific to this platform: whether the customer has an Inbound Gateway configured (Module 2.3) affects what Google's own logs will show relative to the message's actual originating sender. If a gateway sits in front of Google Workspace, the log search may show the gateway as the immediate prior hop rather than the true external origin — know that going in, or you can misread the log as saying something it isn't.

14.5 Exchange Message Tracking (On-Premises)

For on-premises Exchange (Module 2.4), message tracking logs are typically retrieved through PowerShell — Get-MessageTrackingLog or an equivalent cmdlet — rather than through a web console. Because on-premises environments are less commonly opened up to third-party support directly, expect this access to be customer-mediated more often than not: the customer runs the query on their own system and shares the results with you, rather than you querying it yourself.

Don't assume which model applies. Confirm the customer's own access model for their on-premises environment before you plan your next diagnostic step around having direct tooling access you may not actually have.

14.6 Product Logs and Telemetry

Product Validation RequiredThis entire section is a placeholder. The product's own log and telemetry interface(s), the access model for reaching them, their retention period, and their query capability are not yet documented and cannot be described here without inventing product behavior — which this program will never do. This section will be completed once that documentation is available.

Until that documentation exists, the governing principle is not a mystery — it's the general standard from Module 11.9, and it applies regardless of which specific interface you end up using: access only what a specific ticket actually requires. Let the ticket's diagnostic need set the scope of what you pull, not the convenience of a broader export. That discipline doesn't change once the tool-specific detail is filled in; it's the baseline you should already be applying to every other tool in this module.

14.7 Browser Developer Tools

Developer tools come up occasionally — for portal-access issues (Playbook 13.26), or when you're investigating a rendering or display problem in a web-based interface. Their legitimate use here is inspecting network requests and console errors on a page you already have a reason to be looking at, not interacting with or navigating to a suspected-malicious destination.

A boundary worth stating plainlyNever use developer tools as a substitute for approved URL-analysis tooling (14.12–14.13) when you're investigating a suspicious link. The safety boundary that governs a suspicious URL doesn't change depending on which tool happens to be rendering the page — opening a suspicious link in your own browser's dev tools is exactly as unsafe as opening it in a normal browser tab, because it's still your own machine making the request.

14.8 Network Diagnostic Tools

Standard connectivity tools — ping, traceroute/tracert, and port-connectivity checks — become relevant under Playbook 13.18 when a network-layer issue is suspected between two mail systems.

The safe-use classification here is a little different from the DNS/WHOIS category above, and it's worth pausing on why. Testing connectivity to a customer's own infrastructure requires their awareness and authorization (Module 11.4) even though the technical action itself is low-risk — a ping is about as harmless a network action as exists. The reason isn't technical risk; it's that an unexpected connection attempt hitting a customer's network can trigger their own security monitoring and alerting, generating noise or even an incident on their side that has nothing to do with the actual problem you're troubleshooting. Get their awareness first, not because the action is dangerous, but because it's their environment and their monitoring stack that reacts to it.

14.9 API Testing Tools

These tools test the product's own API and webhook integrations (see Module 8's product-architecture content once it's available). Two rules apply every time: always test against a sandbox or non-production endpoint when one exists and is appropriate for the diagnostic question in front of you, and never test using live customer data through an API call that wasn't specifically authorized for that purpose. "It's just a test call" does not create authorization on its own.

Product Validation RequiredWhether the product provides a dedicated API testing or sandbox environment, and if so its details, are not yet documented here and must not be assumed or invented.

14.10 Text and Header-Analysis Tools

Header analysis itself is covered in depth in Module 5; this section is about where you're allowed to do that analysis. Once a message's headers have been sanitized of any customer-identifying or personal content, they're generally safe to run through a general-purpose text tool for pure structural analysis — checking hop order, spacing, formatting, and so on. The complete original message, with real customer or personal data still intact, is a different object entirely and needs to stay inside approved case-management or analysis tooling. Never drop a full, unsanitized message into a general-purpose public text-processing website just because it's a convenient way to reformat or search it.

14.11 Reputation and Threat-Intelligence Sources

These sources let you check an IP address, domain, or file hash against known-threat databases (Module 10.2). The safe-use classification follows the same logic you saw in 14.1 and 14.2: the indicator itself — an IP, a domain, a hash — is generally safe to query against a reputation source, because a hash or an IP address alone does not reveal any customer-identifying content. That's a meaningfully different situation from uploading the actual file or the actual message content, which is exactly what 14.12 and 14.13 exist to cover separately.

A subtle distinction worth testing yourself onTreat a "no result found" response from a reputation source as inconclusive, never as proof of safety. This is Module 10.2's reputation-lag limitation showing up again here in tool form, and it's consequential enough to be worth deliberately pressure-testing your own instincts on — see the knowledge check below.

14.12 File-Hash and URL-Analysis Services

File hashes are generally safe to submit to reputation or analysis services, public or private, because a hash is a fingerprint — it does not itself expose the file's actual content. The actual file is a completely different case, and so, less obviously, is the actual URL, because a URL can itself encode identifying information — a personalized tracking parameter, for instance, that ties back to a specific recipient or organization. Both the actual file and the actual URL require the organization's approved private analysis tooling. Never a general public "upload your file or URL here" service, for two distinct reasons that both matter:

Data exposure. Both a file and a URL can carry customer data to a third party with no data-handling agreement in place — the same underlying concern that governs 14.10's treatment of full messages.
Alerting the attacker. Submitting a URL to certain public scanners can itself tip off a sophisticated attacker that their infrastructure is under investigation, prompting them to change tactics, rotate infrastructure, or otherwise get ahead of the response before you've finished investigating. This risk exists independently of whether any customer data was exposed at all — it's about what the act of submission itself signals to whoever is watching that infrastructure.

14.13 Approved Malware-Analysis Environments

Product Validation RequiredThe organization's specific approved malware-analysis environment(s) are not yet documented here and must not be assumed or invented. What follows is the non-negotiable standard that applies regardless of which specific tool is eventually designated.

Suspected malware is analyzed only within an approved, isolated environment — never on a production workstation, never on a personal device, and never using a general-purpose public sandbox service, per Module 11.24. This is a hard boundary, not a preference, and it holds regardless of how confident you are that a given file is probably harmless.

If no approved environment is accessible to you for a specific case — maybe it's down, maybe you don't have access yet, maybe turnaround is slower than you'd like — the correct move is to escalate, not to improvise with an unapproved method. That instruction is worth sitting with, because the tempting alternative is exactly the scenario walked through below.

Worked Example — Deciding Where a Suspicious Attachment Goes

Here's the reasoning I'd walk through, out loud, the moment a suspicious attachment lands in front of me. A customer has flagged a message with an attachment they're worried about, and I need to decide where it goes for analysis — not whether it's malicious yet, just where it's allowed to go.

First question: is this the actual file, or just a fingerprint of it? It's the actual file. That alone rules out any public tool immediately, per 14.12 — the file itself might carry the customer's business content regardless of whether it turns out to be malicious, and a public "upload and scan" service has no data-handling agreement with us covering that content.

Second question: does that change if I'm fairly confident it's a false positive? No. My confidence level about the outcome has no bearing on where the file is allowed to travel before I know the outcome — the classification is about what the data is, not about my guess as to what the analysis will find. A file I'm 95% sure is clean is handled identically to a file I'm 95% sure is malicious, right up until an approved tool tells me otherwise.

Third question: where does it go, then? Per 14.13, only the organization's approved, isolated malware-analysis environment — never my own workstation, never a personal device, never a public multi-scanner site, no matter how well-known or reputable that public site is. If that approved environment isn't accessible to me right now for whatever reason, my next move is to escalate and say so plainly, not to reach for whatever is convenient in the moment.

That's the whole decision tree for this category, and notice it never actually required knowing anything about the file itself — the file's own content, or how dangerous it probably is, was never one of the questions.

14.14 Data Classification — What May Be Submitted Where

The one thing to memorize from this moduleEvery rule in this module compresses down to the table below. If you remember nothing else from Module 14, remember this table — it is the single artifact you should be able to recall instantly, under time pressure, without looking it up. Everything above this point exists to explain why the table says what it says; the table itself is what you'll actually reach for on a live ticket.

Data type	Public tool	Approved private tool	Never upload externally
Domain name / IP address (no customer context attached)	Yes	Yes	—
DNS record content	Yes	Yes	—
File hash (no file itself)	Yes	Yes	—
Sanitized / structural header excerpt (no real customer/personal data)	Generally yes	Yes	—
Complete original message with real customer/personal data	No	Yes	—
The actual suspected-malicious file	No	Yes (approved sandbox only)	Unapproved public "upload and scan" services
A URL that may encode identifying/tracking information	Generally no (case-by-case)	Yes	Unapproved public scanners for a URL believed to target this specific customer, without considering alert-to-attacker risk
Customer PII in any form	No	Only within approved case-management tooling	Any public or unapproved external service
Credentials, tokens, secrets, API keys	No	Only for the specific, authorized purpose of remediation	Any external service, public or private, absent a specific, authorized need

The standing rule, restated from Module 11.24: never upload a customer's suspected-malicious file, sensitive data, or message content to an unapproved public analysis service, regardless of how convenient it would be or how confident you are that "this one is probably fine." Convenience and confidence are exactly the two pressures the never-upload rule is designed to survive.

The same three-lane sort as the 14.14 table, drawn visually. Notice the middle and right lanes both refuse a public tool — the difference between them is whether an approved private tool is ever the answer at all.

Worked Example — Classifying Five Items from a Single Ticket

A single, moderately complex phishing ticket can easily contain five or six different data types in one investigation, each with its own answer under the 14.14 table. Let me walk through one such ticket item by item, the way I'd actually reason through it on a live case.

The sender's domain, pay-secure-update.example. This is just a domain name with no customer context attached — straight to a public DNS/WHOIS lookup, no restriction, per the first row of the table.
The full original message, headers and body, exactly as the customer forwarded it. This carries real customer data (their email address, internal routing hops, possibly other PII in the body). No public tool, ever. It stays inside approved case-management/analysis tooling.
The SHA-256 hash of an attached PDF, already computed by the mailbox platform. A hash alone doesn't expose the file's content, so this is safe to submit to a reputation source — public or private — for a quick check.
The actual PDF attachment itself. Different object from item 3, even though they're related. The file itself never goes to a public scanner; it goes only to the approved, isolated malware-analysis environment, per 14.13.
A link inside the message body that includes a long query string. I'd treat that query string as a plausible tracking parameter until proven otherwise — generally not a public-tool case, and case-by-case for exactly which approved tool applies, per the URL row of the table.

Five items, three different destinations, one consistent method: for each one, ask what the item actually is — a bare indicator, a full artifact with customer data, or something in between — and let the table answer the rest. The method never changes; only the answer does.

Hands-On Lab

Lab 14.1 — Data Classification Practicum

You will be given fifteen data items drawn from realistic ticket contexts — for example, a bare domain name, a full original message containing customer PII, a file hash, an actual suspected-malicious attachment, and a sanitized header excerpt, among others.

For each item:

Classify it per the 14.14 table — public tool, approved private tool, or never upload externally.
State the specific tool category that's appropriate for that item (e.g., "public DNS lookup," "approved malware-analysis environment," "approved case-management tooling").
Where an item is genuinely case-by-case (as the URL row can be), state what additional fact would resolve which side of the line it falls on.

Deliverable: a completed classification worksheet for all fifteen items, reviewed against the answer key.

Scenario-Based Exercise

Scenario: You're confident a suspicious attachment is probably just a false positive, and you're considering uploading it to a well-known public multi-scanner website to confirm quickly, since the organization's approved internal sandbox has a longer turnaround time and the customer is waiting on an answer.

Task: Draft the response you'd actually take in this situation — what you do instead of using the public scanner, and how you'd explain the delay to the customer — without compromising the never-upload standard regardless of your confidence level. Your answer should hold up exactly as well whether the file turns out to be malicious or completely benign, since you don't get to know that in advance.

Knowledge Check

Answer each question yourself before expanding it.

1. Why is a file hash generally safe to submit to a public reputation service, while the actual file is not?

A hash is a one-way mathematical fingerprint that does not itself expose or let anyone reconstruct the file's actual content — submitting it does not disclose customer data. The actual file may contain confidential business information, personal data, or content the customer never intended to share externally, none of which the hash reveals.

2. Why might submitting a suspicious URL to certain public scanners itself be a risk, separate from any data-exposure concern?

Some public scanners' submissions or results may be visible to, or inferable by, sophisticated attackers monitoring their own infrastructure — potentially alerting them that their campaign has been detected and prompting them to change tactics before the investigation is complete. This risk exists even when the URL itself contains no customer data.

3. What should you do if no approved malware-analysis environment is accessible for a specific case?

Escalate rather than improvising with an unapproved method — a public scanner, a personal device, a production workstation. This is a hard boundary per Module 11.24, not a judgment call to route around under time pressure, regardless of how the case seems to be going.

4. Why does "no result found" in a reputation lookup not confirm a file or URL is safe?

A lookup returning no result typically means no data exists yet for that specific indicator, not that it has been affirmatively verified as safe. This is especially true for newly created malicious infrastructure, which by definition hasn't had time to accumulate a negative reputation yet (Module 10.2).

Common Misconceptions

"A public scanner is fine for a quick check as long as I don't share the customer's name."

The file, URL, or message content itself can carry identifying or sensitive information independent of whether a customer name is explicitly attached to it — and public submission can also alert an attacker, a separate risk that has nothing to do with naming the customer at all.

"If nothing comes back from a reputation check, it's probably safe."

Absence of a known-bad result is not confirmation of safety, particularly for new or novel threats that simply haven't been seen and catalogued yet.

"Public tools and approved private tools are basically the same, just different websites."

They differ specifically in their data-handling agreements and exposure risk, not in their general lookup functionality — the distinction that matters is about where the data goes and who's accountable for it, not what the tool's interface looks like or how good its results are.

Key Takeaways

Treat the never-upload boundary in 14.14 as a hard line, not a judgment call. If you catch yourself reaching for a public tool for a file, a URL, or a full message, stop and route to the approved environment instead — every time, regardless of how confident you are that this particular case is fine.
Know the difference between a proficiency gap and a boundary violation, because they call for different responses from you. Forgetting to search by Message-ID first, or skipping the authoritative-nameserver step, is a normal skill gap you refine with practice and feedback. Using an unapproved public tool for a file, a URL, or message content is a hard-boundary issue, treated with the same seriousness as the password rule in Module 11 — not something to shrug off as "I'll be more careful next time."
Keep "no result found ≠ confirmed safe" active in your head every time you run a reputation lookup. It's a subtle distinction, which is exactly why it's worth deliberately testing yourself on it rather than assuming it'll be obvious in the moment.
When you're unsure which lane a piece of data belongs in, default to the more restrictive answer and ask, rather than guessing toward the more convenient one. The 14.14 table is designed to be fast to consult precisely so that guessing is never actually necessary.

Email Fundamentals - Module 14