Email Lookup
Analyze an email address and its domain's anti-spoofing posture: mailbox type, aliasing, disposable and role detection, plus SPF, DMARC and DKIM read live or from the last domain scan, and an aggregate risk score.
The email lookup breaks an address down and reads it against what mlab already knows about its domain. It tells you the mailbox type, whether the address is a disposable or role account, whether aliasing hides the real inbox, and how spoofable the domain is based on its published SPF, DMARC and DKIM records.
The address analysis is computed locally. The mail policy comes from the last completed domain scan when one exists, and is otherwise resolved live over DNS, so the anti-spoofing verdict no longer requires anyone to have scanned the domain first. domain_scan.mail_source says which of the two you are reading: they are not equal evidence, because a full scan expands SPF includes, counts lookups and grades the result, while the live probe only reads what is published.
Domain age and reputation still need a scan and are reported as not available otherwise. Nothing is emailed, and the lookup does not launch a scan or count against a quota.
1. How to look up an address
From the search bar. Paste an email address. mlab detects it and routes you to /email/{address}.
By URL. Open https://mlab.sh/email/{address} directly.
2. What you get
| Field | Meaning |
|---|---|
| Mailbox type | Standard, role account (admin@, support@), consumer provider (Gmail, Outlook), or disposable |
| Anatomy | Local part, domain, and the Unicode rendering of an internationalized domain |
| Sub-address tag | The tag in an address like user+shop@domain, which often reveals who the address was given to |
| Canonical mailbox | The inbox the mail actually lands in once aliasing (dots, tags) is removed |
| Spoofability | How spoofable the domain is, derived from its DMARC policy: rejected, quarantined, monitor only, trivially spoofable, or unknown |
| MX | Number of mail servers found on the domain, when DNS records were collected |
| Domain age | Age in days from WHOIS, when collected |
| Published mail policy | The SPF, DMARC and DKIM records the verdict is based on |
| Findings | Risk signals about the address or its domain, each with a severity |
The spoofing verdict and MX status come from a domain scan when one exists, and from a live DNS lookup otherwise. Domain age still needs a scan, so the module says so and offers to run one. The address analysis itself depends on neither.
mlab holds no breach data. The web module offers hand-off links to third-party services (Have I Been Pwned, OSINT Industries) that only disclose the address when you click.
3. API
This lookup is available through the REST API. See the API Guide for authentication and quotas.
GET /api/v1/scan/email?email={address}
curl -H "Authorization: Bearer YOUR_API_KEY" \
"https://mlab.sh/api/v1/scan/[email protected]"The response carries the same data as the web module:
{
"email": "[email protected]",
"local": "user",
"domain": "example.com",
"domain_unicode": null,
"tag": null,
"canonical": "[email protected]",
"canonical_differs": false,
"mailbox_type": "Standard",
"is_role": false,
"is_free_provider": false,
"is_disposable": false,
"domain_scan": {
"scanned": true,
"spoofability": {
"verdict": "Spoofing rejected",
"summary": "DMARC policy is p=reject: forged mail from this domain should be dropped."
},
"mx": { "count": 5 },
"domain_age_days": 9241,
"auth": {
"spf": { "present": true, "record": "v=spf1 include:_spf.example.com -all" },
"dmarc": { "present": true, "record": "v=DMARC1; p=reject; rua=mailto:[email protected]" },
"dkim": { "present": true, "selectors": ["default", "selector1"] }
}
},
"findings": []
}When the domain has never been scanned, domain_scan.scanned is false but the mail policy is still resolved live, so spoofability, mx and auth are populated with mail_source: "live". Only domain_age_days stays null.
verdict: "Unknown" now means something narrower than before: the domain has no scan and its records could not be resolved. This keeps "not collected" distinct from "collected and empty", so the API never implies a domain has no MX record when it was simply never looked at.
Aggregate score
Alongside the findings, the response carries a score block: a 0 to 100 value, a band (clean, suspect, high, critical) and every weighted reason behind it. The reasons are published on purpose, each with a stable code and its weight, so the number can be taken apart rather than trusted.
{
"score": {
"value": 65,
"band": "high",
"conclusive": true,
"reasons": [
{ "code": "email.no_dmarc", "weight": 25, "label": "No DMARC record: the address is trivially forgeable" },
{ "code": "email.no_spf", "weight": 10, "label": "No SPF record" },
{ "code": "email.domain_newborn", "weight": 30, "label": "Domain registered in the last 30 days" }
]
}
}Read conclusive before reading the score. When it is false there was no published mail policy to judge, so a low number means little is known, not that the address is trustworthy.
The score is built only from checkable facts: membership of a throwaway list, the registration date, and whether a DMARC policy exists and what it says. Being a consumer mailbox carries a small weight only because it contradicts a corporate claim, and an enforced DMARC policy is the one signal that lowers the score.
MAC Address Lookup
Decode a MAC address offline: vendor from the IEEE OUI registry, universal vs local administration, randomization, virtualization and the IPv6 address SLAAC would derive from it.
Phone Number Lookup
Validate a phone number in E.164 form and read its country, line type, originally allocated operator, canonical formats and scam-shape findings, all offline.