How to Inspect Email Links and Tracking Pixels Without Opening Them

An email can contain links and remote images that contact another server when opened or rendered. A visible button may point to a different domain, a URL may wrap another destination in a redirect parameter, and a tiny image may act as a tracking pixel.

The safest first inspection does not open the link or render the message HTML. Once Email's email link and tracker checker reads pasted HTML locally in the browser and reports structural clues. It does not visit discovered URLs, request images, run scripts, follow redirects or upload the input.

Once Email itself is receive-only: it does not send, reply to or forward messages. The checker is a separate browser-local utility and does not change that product boundary.

Start with context, not the button

Before examining HTML, ask whether you expected the message. A real-looking logo, sender name or urgent subject is not proof of origin. If the message claims to concern a bank, workplace or account, open the organisation's known official site or app independently instead of following the email link.

The US Federal Trade Commission advises users not to click links or download attachments in unexpected messages and to contact the organisation through a website or number already known to be genuine. See the FTC's phishing protection guidance.

Inspect HTML without rendering it

Use source HTML only when you can obtain it safely and are authorised to inspect it. Do not paste passwords, live session cookies, private correspondence or other people's confidential information.

In the checker:

1. Paste the email HTML source, up to the documented 128 KB limit.
2. Select Inspect HTML.
3. Review discovered links, remote resources and active-content clues.
4. Clear the input when finished.

The tool parses tag and attribute text without creating a live email document. This distinction matters: rendering untrusted HTML could request remote content or activate browser behaviour that a text-only inspection avoids.

Clue 1: dangerous or executable schemes

Normal web destinations usually use https:. Schemes such as javascript: or other executable forms are unsafe in untrusted content. The checker flags dangerous scheme patterns rather than attempting to run them.

A flagged scheme is a reason to stop. A clean scheme is only the beginning of review; an HTTPS site can still be deceptive or compromised.

Clue 2: visible text and destination mismatch

A message may display a familiar domain while the underlying link points elsewhere. The checker compares visible link text with the parsed destination and highlights likely mismatches for manual review.

Read hostnames from right to left around the registrable domain. accounts.example.com belongs under example.com, while example.com.attacker.test belongs under attacker.test. Long subdomains, look-alike characters and Punycode hostnames beginning with xn-- deserve deliberate verification.

Do not assume every internationalised domain is malicious; Punycode is a technical representation used by legitimate sites too. It is a clue that the exact hostname needs checking, not a verdict.

Clue 3: nested redirect destinations

Marketing and security systems often wrap a destination in parameters such as url, target, redirect or continue. Attackers can use similar structures to hide where a click eventually goes.

The checker identifies common nested-destination parameters but does not follow them. That is intentional: following a link would contact external servers and could expose network data or reach harmful content. Compare any embedded destination with the service you expected, then use the known official site instead of testing a suspicious chain.

Clue 4: remote images and tracking pixels

An HTML email can reference an image hosted on a remote server. Loading it may reveal that the message was viewed and can expose request data such as time and network information. Very small or hidden remote images are common tracking-pixel clues.

Apple's current Mail privacy documentation explains that remote email content can reveal viewing activity, forwarding, IP address and related data, and describes how its own protection changes remote loading. Different clients and settings behave differently, so do not assume that protection is universal.

The Once Email checker lists remote resources without loading them. It flags tiny or hidden image patterns, but dimensions alone cannot prove intent. A large remote image can track, while a small image can be legitimate.

Clue 5: active content and automatic refresh

Scripts, embedded frames, objects and meta refresh instructions do not belong in a conservative email review path. The checker reports these patterns as active-content clues and never executes them.

Email clients may already block some active content, but client filtering is not a reason to trust the message. Treat unexpected active elements or automatic redirection as escalation signals.

What a clean result does not prove

The checker is deliberately limited. It does not perform:

• DNS, WHOIS or certificate validation;
• sender or domain reputation checks;
• live SPF, DKIM or DMARC verification;
• redirect following or final-destination discovery;
• malware, attachment or page-content scanning;
• a determination that a sender or request is legitimate.

HTML can also be incomplete or deliberately constructed to evade simple pattern checks. A result with no findings means only that the implemented clues were not found in the supplied text.

A safe decision sequence

Confirm that you initiated the activity, inspect without rendering, compare exact domains, avoid external requests, and independently open the known official service when action is necessary. Report suspected abuse without forwarding live secrets or opening attachments.

The tool helps turn opaque email HTML into a reviewable list. It reduces accidental loading and clicking; it does not replace judgment, endpoint protection or an organisation's security process.