Security is a core requirement for any service that processes email addresses and API traffic. This document describes Emailyze's security practices: how we authenticate requests, protect data in transit and at rest, handle the data you send us, and how you can report vulnerabilities. We aim to be transparent and factual. If you have questions or concerns, contact us.
Emailyze uses API key authentication. When you create an account, you generate one or more API keys. Each key is a long, random string that uniquely identifies your account and authorizes requests. You include the key in the Authorization header (e.g., Authorization: Api-Key YOUR_KEY) or as a query parameter when calling the API.
API keys are stored hashed on our servers. We use industry-standard hashing so that even if our database were compromised, the raw keys could not be recovered. When you create a key, we show the full value once. After that, we never display the full key again—only a truncated version for identification. If you lose a key, revoke it and create a new one. Never share keys in public repositories, logs, or client-side code. Rotate keys periodically as a best practice.
All API traffic is encrypted in transit. We require HTTPS for every request. Our API endpoints are served over TLS 1.2 or higher. Certificates are valid and issued by trusted certificate authorities. This ensures that email addresses and API keys cannot be intercepted or modified in transit over the network.
When you integrate Emailyze, use https:// URLs only. Do not send requests over plain HTTP. Most HTTP clients and libraries enforce HTTPS by default when you specify an https:// URL. If you run our Docker image on-premise, configure TLS at your load balancer or reverse proxy so that traffic to your instance is also encrypted.
We minimize the data we store. When you check an email address via the API, we perform a lookup against our domain database and return the result. We do not persistently store the email addresses you check. Logs may temporarily capture request metadata (e.g., timestamp, endpoint, API key ID) for debugging and abuse prevention, but we do not log the full email addresses in a way that persists beyond operational needs. Our data retention policy limits how long such metadata is kept.
Our domain database contains domain names (e.g., tempmail.com, guerrillamail.com), not individual email addresses. This data is used solely to power the disposable-email detection service. We do not sell or share it with third parties for marketing or other purposes. For details on data collection, retention, and your rights, see our privacy policy.
Our hosted API runs on infrastructure managed with security in mind. We use cloud providers that maintain strong security postures and compliance certifications. Services are isolated, and access to production systems is restricted and audited. We apply security updates to dependencies and operating systems in a timely manner. Backups are encrypted and stored securely.
We do not overclaim. If we achieve formal certifications such as SOC 2 or ISO 27001 in the future, we will update this document. For now, we describe our practices honestly and encourage you to evaluate them against your requirements.
If your organization requires that no email data leave your environment, our self-hosted Docker option gives you full control. You deploy our Docker image on your own infrastructure. All lookups happen locally. No email addresses or API traffic are sent to us. You manage your own database, backups, and network security. The same API contract and response format apply, so you can switch between hosted and self-hosted without changing your integration code.
Self-hosting is ideal for enterprises with strict data residency, compliance, or sovereignty requirements. You are responsible for securing your deployment: keeping the image updated, configuring TLS, and managing access to your instance.
If you discover a security vulnerability in Emailyze—whether in our API, dashboard, or documentation—we want to hear from you. Please report it responsibly. Do not exploit the vulnerability beyond what is necessary to confirm it.
Send your report to our security contact (e.g., security@emailguard.example.com or the address listed on our website). Include a description of the issue, steps to reproduce, and any impact assessment. We will acknowledge receipt promptly and work with you to understand and address the issue. We ask that you allow us a reasonable time to fix the vulnerability before disclosing it publicly. We do not pursue legal action against researchers who report issues in good faith and follow responsible disclosure practices.
We appreciate the security community's efforts to help keep Emailyze and our users safe.
You can rotate API keys at any time. Create a new key, update your integration to use it, then revoke the old key. Revocation takes effect immediately—requests with the old key will be rejected. We recommend rotating keys periodically (e.g., quarterly) and whenever a key may have been exposed. There is no downtime during rotation if you use a brief overlap period where both keys work.
We take privacy seriously. Our service is designed to minimize data collection. We do not build profiles of individuals from the email addresses you check. Our domain database contains domain names only—no personal data. When you use the hosted API, request metadata may be logged for operational and abuse-prevention purposes, but we limit retention and do not use it for advertising or third-party sharing. For full details on data practices, see our privacy policy. If your organization requires specific compliance documentation (e.g., DPA, security questionnaire), contact us. Our self-hosted option may satisfy requirements that cannot be met by a hosted service. We continuously improve our security posture and welcome feedback from customers and researchers. Security is an ongoing effort, not a one-time checklist. We review our practices regularly, apply lessons from incidents and industry best practices, and update this document when our approach changes.