Email verification via SMTP only works if the domain accepts mail on the standard ports and protocols. But finding emails in the first place is harder.
The traditional inputs for discovery are: - DNS lookups (are there MX records?) - WHOIS data (who registered the domain?) - Website scraping (are emails listed on the site?) - Public records (company directory, LinkedIn, etc.)
They work — but they're slow, often stale, and increasingly behind paywalls or bot-detection layers.
Better approach: public data that companies emit accidentally.
When a company buys an SSL certificate for their domain, they list all subdomains they want to protect.
Issuer: Let's Encrypt
But here's the thing: certificates are public. Every certificate ever issued is logged in Certificate Transparency (CT) logs. Anyone can query them.
Some companies also list email addresses in cert metadata:
Subject: /CN=jane.smith@acme.com/O=Acme/C=US
This is rare, but when it happens, you've got a confirmed, real email address from company infrastructure.
1. Query CT logs for domain 2. Extract all Subject Alternative Names (tells us the organization's internal DNS names) 3. Cross-reference against known email patterns 4. If we see `mail.acme.com` in the cert, we know they use internal mail infrastructure (not Gmail) 5. If we see an email subject, we have a direct confirmation
This is passive. No violations.
Every commit on GitHub includes author metadata:
Date: 2025-03-15 10:34:22 Message: Fix auth bug in payment processor
Developers push code with their company email addresses all the time.
If you query GitHub's API for commits from employees at acme.com, you can: 1. Find the email in the commit author field 2. Extract the domain 3. Verify it via SMTP
This is public data. The developer published it. GitHub surfaces it in web UI and API.
1. Search for public repositories with commit history 2. Find commits with company domain email addresses 3. Extract the email and domain pattern 4. Return verified addresses for high-confidence patterns
Example: ``` Searching for @acme.com in GitHub commits Result: jane.smith@acme.com (commit on open-source library) sarah.kim@acme.com (commit on Acme's public repo) mike.chen@acme.com (same) Pattern identified: first.last@acme.com (100% confidence) ```
npm packages list maintainers with email addresses:
{
"name": "acme-auth-sdk",
"maintainers": [
{ "name": "Jane Smith", "email": "jane.smith@acme.com" }
]
}If Acme publishes libraries under a company npm account, their maintainers list real company emails.
Same principle: public data, developer published it voluntarily.
Same pattern across all package registries: - Every published package lists authors/maintainers - Maintainers often use company email addresses - This is searchable, public data
A company that publishes libraries is broadcasting its engineering team's email structure.
Here's where it gets delicate.
**Legal consideration:**
These sources (CT logs, GitHub, npm, PyPI) are: - Public - Searchable via official APIs - Not protected by CFAA (Computer Fraud & Abuse Act) - Acceptable for GDPR (you're not extracting PII, you're reading public data published by the person themselves)
**But:**
- You cannot scrape at scale in ways that violate ToS - You cannot use data for purposes the original source forbids - You need to respect GDPR right to be forgotten (if someone removes their email from GitHub, they may have the right to expect it not to be used)
**Best practice:**
- Source data from official APIs (GitHub API, npm API) not web scraping - Cache data for reasonable periods, not forever - If someone reports their email was misused, delist it - Document your sources
Coalstoke's approach: 1. Query CT logs via official Certificate Transparency API 2. Query GitHub API for public commit history 3. Query npm, PyPI, Maven Central via official APIs 4. Cross-reference against SMTP verification to confirm accuracy 5. Return only emails that pass SMTP verification
This combines public discovery with real verification.
Sending to a list of unverified emails extracted from CT logs is risky. Sending to verified emails is safe.
The combination is powerful: - CT logs + GitHub commits give you discovery speed (find contacts fast) - SMTP verification confirms they're real - Pattern learning improves future lookups
2. Query CT logs for acme.com certificates 3. Extract domain patterns and potential subdomains 4. Search GitHub for @acme.com commits 5. Extract emails from commit authors 6. SMTP verify each email 7. Return only verified results 8. Pattern engine learns: first.last@ is the format 9. Future lookups for acme.com use the pattern
Result: you get verified, discoverable emails. No guesses. No spam risk.
Not every company: - Publishes libraries (PyPI, npm) - Commits to open-source (GitHub) - Issues SSL certificates with email metadata
For those companies, pattern learning + SMTP verification is your fallback.
But for companies that do publish, public data is your speediest source.