Overview
This node verifies the validity and status of email addresses using the QuickEmailVerification API. It is useful for scenarios where you need to validate email addresses before sending marketing campaigns, user registrations, or any process requiring clean and deliverable email lists. The node can detect if an email is valid, invalid, disposable, role-based, or temporarily blocked (greylisted), and it supports retrying verification for greylisted emails.
Practical examples:
- Validating user sign-up emails to reduce bounce rates.
- Cleaning mailing lists by filtering out invalid or disposable emails.
- Checking if an email domain accepts all emails (accept-all) to assess deliverability risk.
Properties
| Name | Meaning |
|---|---|
The email address to verify. Example: name@email.com. |
|
| Enable Greylisting Retries | Whether to retry verification for emails temporarily blocked due to greylisting (reason = "temporarily_blocked"). Boolean true/false. |
| Retry Delay | Delay in seconds before retrying verification for greylisted emails. Only shown if greylisting retries are enabled. Default is 90 seconds. |
| Maximum Retries | Maximum number of retry attempts for greylisted emails. Only shown if greylisting retries are enabled. Default is 1. |
Output
The node outputs a JSON object with detailed verification results for each input email. The output fields include:
result: Verification result such as "valid", "invalid", or "unknown".reason: Explanation for the result, e.g., "accepted_email", "invalid_email", "temporarily_blocked".disposable: Boolean indicating if the email domain is disposable.accept_all: Boolean indicating if the domain accepts all emails (accept-all).role: Boolean indicating if the email is role-based (e.g., admin@, info@).safe_to_send: Boolean indicating if the email is safe for deliverability.email: Normalized email address.source: Origin of the verification result — either from the API, address cache, or domain cache.verifiedAt: Timestamp when the verification was performed.remainingCredits: Number of remaining API credits available.retryInfo(optional): Details about greylisting retries if they were performed, including whether retries happened, count, and success status.
If the node caches results, it may return cached data instead of calling the API every time.
Dependencies
- Requires an API key credential for the QuickEmailVerification service.
- Uses local file-based caching for email addresses and domains to improve performance and reduce API calls.
- Cache files are stored under the user's home directory in
.n8n/quickemailverification-address-cacheand.n8n/quickemailverification-domain-cache. - Node dependencies include:
keyvandkeyv-filefor caching.- Native Node.js modules:
path,os, andfs.
Troubleshooting
- API Key Issues: If the API key is missing or invalid, the node will fail to verify emails. Ensure the API key credential is correctly configured.
- Cache File Permissions: The node writes cache files to the user's home directory. Permission issues might prevent cache creation or cleanup. Verify that n8n has write access to these directories.
- Greylisting Retries: If enabled, retries occur only for emails temporarily blocked. Excessive retries may delay execution; adjust retry delay and max retries accordingly.
- Rate Limits / Quotas: Exceeding API credit limits will cause verification failures. Monitor
remainingCreditsin output to avoid this. - Error Handling: If an error occurs during verification and "Continue On Fail" is enabled, the node outputs an error message per item instead of stopping execution.