Email Validation
Email validation reduces avoidable bounces before a message enters the sending pipeline. It should run before high-volume imports, signup flows, and transactional sends that cannot tolerate repeated delivery failures.
What validation catches
| Check | Why it matters |
|---|---|
| Syntax | Rejects addresses that cannot be delivered because the local part or domain is malformed. |
| Domain health | Detects domains without usable mail exchange records. |
| Disposable or risky addresses | Helps protect sender reputation when temporary inboxes are not acceptable for the use case. |
| Suppression state | Prevents sending to addresses that should not receive mail from the account. |
Validation does not guarantee inbox placement. It only confirms that an address is structurally and operationally suitable enough to attempt delivery.
Result shape
A successful validation returns a deliverability decision. Legacy docs describe successful results with deliverability: true and reason DELIVERABLE. Failed validation uses deliverability: false with a reason such as:
| Reason | Meaning |
|---|---|
SYNTAX | The address format is invalid. |
SPAM_TRAP | The address is likely unsafe for sending. |
DISPOSABLE | The address belongs to a temporary inbox provider. |
ROLE | The address is a role account such as admin@ or support@. |
BOUNCE | The address is expected to bounce. |
NO_INBOX | The address has no usable inbox. |
The legacy single-recipient validation flow accepts one email address at a time. Sending more than one email to that single-recipient operation returns an error.
API operations
Use asynchronous validation results for batch workflows. For signup forms, run validation server-side before creating downstream records.
Sending behavior
If an address is invalid, suppressed, or blocked by account policy, the send request may fail validation or be dropped before delivery. Your application should treat that as a data-quality outcome, not as a transient API outage.