Look up MX records for any domain to see mail server priorities, verify mail routing, and detect misconfigurations.
Enter a bare domain name to retrieve its DNS mail exchanger (MX) records and compare the preference numbers attached to each exchange. The viewer identifies the hostnames designated to receive mail for that domain, making primary and backup routes easier to inspect. The common mistake is reading a larger number as higher priority. MX preference works in the opposite direction: senders prefer the lowest numeric value, while records with equal values have equal preference. The result describes published DNS routing, not whether an SMTP server is reachable or willing to accept a particular recipient.
After you submit the domain, the viewer requests the MX resource-record set for that exact DNS name. Every ordinary MX answer contains a numeric preference and an exchange hostname. Looking up example.org does not inspect mailboxes or discover subdomains; it asks which exchangers are published for example.org. Enter the domain portion, not a full email address, URL, path, or SMTP server name.
Lower numbers are preferred. Senders normally try the lowest available preference tier before larger values. Exchanges with the same preference occupy the same tier; the number does not permanently select one as primary. Zero is not inherently a no-mail value. The special null MX signal is a single record whose exchange is the DNS root, written as a dot.
No. It means that the exchange is preferred for routing relative to the domain's other MX records. It does not measure latency, capacity, geographic distance, security, or deliverability. A higher-numbered exchange is commonly tried when a lower-numbered route is unavailable, but the viewer cannot show whether either server will actually accept a message.
No. It confirms only what the queried DNS answer publishes. Successful delivery also depends on hostname resolution, network reachability, SMTP behavior, and recipient policy. SPF, DKIM, and DMARC are separate records or mechanisms and are not established merely by seeing plausible MX records. Check those parts separately when diagnosing delivery or authentication failures.
The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.