Disposable Email Detection API
Block Mailinator, YOPmail, Guerrilla Mail, and 50,000+ other throwaway services with a single boolean in the verify response.
What Mailbeam checks
Every verification runs 7 checks in parallel and returns a structured result in under 100ms.
50,000+ disposable domains
Mailbeam's disposable database is updated continuously. When new temporary email services appear, they are typically added within 24 hours.
Subdomain and alias normalization
Many services use subdomains (user@mail.mailinator.com) or plus-addressing tricks. Mailbeam normalizes and checks all variants before lookup.
Boolean flag in every response
The `disposable` field is returned in the standard verify response — no separate API call needed. Your conditional is a single field check.
Distinct from role-based detection
Disposable and role-based detections are separate flags. A role-based address (info@company.com) is not disposable — they require different handling in your application.
Privacy providers are not flagged
ProtonMail, Tutanota, and similar privacy-focused services are legitimate providers. They are not included in the disposable database — only true throwaway services are flagged.
Returns alongside full verification
Since all checks run in parallel, adding disposable detection has zero overhead versus a verify call that only checks syntax or MX records.
How it works
Domain extracted and normalized
From the submitted email address, Mailbeam extracts the domain, strips plus-addressing tags, and resolves subdomain aliases to their root service.
Database lookup
The normalized domain is matched against the continuously updated disposable domain database. Lookup is a memory-resident hash check — zero additional latency.
Boolean returned in response
The `disposable: true/false` flag is included in the standard verify JSON response alongside `valid`, `score`, and all other check results.
Your application decides
Hard reject, show a warning, or allow with a note. You control the behavior — Mailbeam provides the signal.
Integrate in minutes
require "net/http"
require "json"
# No SDK yet — Mailbeam is one POST.
def verify_email(email)
uri = URI("https://api.mailbeam.dev/v1/verify")
request = Net::HTTP::Post.new(uri)
request["Authorization"] = "Bearer #{ENV.fetch('MAILBEAM_KEY')}"
request["Content-Type"] = "application/json"
request.body = { email: email }.to_json
response = Net::HTTP.start(uri.host, uri.port, use_ssl: true, read_timeout: 3) do |http|
http.request(request)
end
JSON.parse(response.body, symbolize_names: true)
end
def handle_signup(email)
result = verify_email(email)
unless result[:valid]
suggestion = result[:suggestion] ? " Did you mean #{result[:suggestion]}?" : ""
raise ArgumentError, "Invalid email address.#{suggestion}"
end
if result.disposable
raise ArgumentError,
"Temporary email addresses are not accepted. Please use a permanent email."
end
if result.role
# Route role-based emails to manual review, not automated flow
User.create!(email: email, review_queue: true)
else
User.create!(email: email, review_queue: false)
UserMailer.welcome(email).deliver_later
end
endWhen to use it
Free trial signup protection
Users who abuse free trials with new accounts almost always use disposable emails. Block them at signup before they cost you trial quota and distort activation metrics.
Referral and bonus program integrity
Referral programs are the most exploited feature in consumer apps. A disposable email check at registration stops the most common exploitation vector.
Waitlist quality gates
A pre-launch waitlist filled with throwaway emails is useless. Validate at signup so your launch email goes to real people who actually wanted to hear from you.
B2B lead form qualification
Disposable emails on demo request or contact forms are almost never genuine prospects. Filter them out before they enter your CRM and waste SDR time.
Frequently asked questions
How often is the disposable domain database updated?
The database is updated continuously. New disposable services detected by Mailbeam's monitoring are typically added within 24 hours.
Can someone bypass disposable detection using a custom domain?
Yes — a sophisticated user can set up a custom domain email for temporary use. Disposable detection covers known services, not custom domains. For high-security use cases, combine disposable detection with email confirmation links.
Does disposable detection slow down the verification?
No. The disposable check is a hash lookup against an in-memory database. It adds zero measurable latency to the verification call.
What about catch-all domains used for temporary email?
Some services generate random addresses at known catch-all domains. Catch-all detection works alongside the disposable list to flag these, and the capped `score` reflects the uncertainty even when `disposable` is false.
Ready to integrate?
Free tier includes 1,000 verifications/month. No credit card required.