Validation Statuses

Every completed validation response (HTTP 200) contains a result object with status and subStatus fields, plus top-level validatedAt, domain, and mailbox objects that carry domain- and mailbox-level signals about the email. This page documents each.

result.status

The following values may be returned:

• safe - Valid email that is safe to send to based on risk analysis. Includes both catch-all and non-catch-all addresses.
• do_not_mail_abuse - Valid email with high risk of manual spam reports. Avoid emailing and use alternative channels like Calls and LinkedIn.
• some_risk - Inconclusive result with identified risk factors. Remove for 30 days and re-analyze in bulk at that point.
• block_bounce_risk - Invalid email highly likely to bounce. Remove contact and source new email addresses.
• dead_email - Invalid account that won’t bounce due to catch-all setup. Use alternative communication channels.

For a more in-depth explanation of the Allegrow statuses, please check this article.

result.subStatus

result.subStatus provides additional context on valid emails. It takes one of the following values:

• primary - The email was identified as the contact's main email address. Particularly helpful for executives and senior decision-makers who may have more than one valid email address.
• null - No additional sub-status was determined.

allegrowStatus (deprecated)

For backward compatibility, every response also includes an allegrowStatus field at the top level that mirrors the value of result.status.

allegrowStatus is deprecated and will be removed in a future release. Please migrate your integrations to read result.status instead. During the deprecation period, result.status and allegrowStatus will always carry the same value.

more_time_required (sync endpoint only)

The sync POST /v1/email/validate endpoint will return an HTTP 202 response when validation takes longer than its 30-second budget. On a 202, the result object is absent and allegrowStatus is set to "more_time_required". The response includes a pollUrl and a retryAfter (seconds) — clients should poll that URL after the suggested wait to retrieve the actual result.

The recommended discriminator is the HTTP status code (200 vs 202), not the value of allegrowStatus. Once allegrowStatus is removed in a future release, the HTTP status code will remain the canonical signal for in-progress validations.

validatedAt

ISO 8601 timestamp of when this validation response was produced. Use it to stamp your own records with the moment of validation.

Example: "2026-04-22T10:30:00Z".

domain

Domain-level signals about the mail server that hosts the validated email.

domain.name

The domain portion of the email address (everything after the last @), lowercased. Useful when you're storing validation results separately from the original email and want to group or report by domain.

Example: "example.com".

domain.mxProvider

Allegrow's classification of the mail provider hosting this domain, normalised to lowercase. Common values include google, microsoft, proofpoint, and others. Returned as null when the provider could not be classified — typically for very small or self-hosted mail servers.

This is the classifier's best guess based on the domain's MX records. Use it for segmentation, reporting, or routing decisions in your own pipeline (e.g. "skip Gmail's send-attempt cap on these contacts").

domain.mxRecords

The MX record hostnames returned by DNS for this domain, in the order Allegrow received them. Hostnames only — MX priorities are not included. Empty array ([]) when the domain has no MX records.

Example:

["aspmx.l.google.com", "alt1.aspmx.l.google.com"]

domain.isCatchAll

Whether the domain is a catch-all or not.

• true — the receiving server accepts mail for any local part on this domain.
• false — the server rejects unknown local parts at SMTP time.
• null — Allegrow could not determine the behaviour.

mailbox

Mailbox-level signals about the specific local part of the email.

mailbox.isRoleAccount

true when the local part is a role account — generic team addresses like info@, support@, sales@, hello@, etc.

Role accounts are often not tied to a specific individual, tend to have lower engagement, and may indicate the email is not the right contact for personalised outreach. Use this signal to filter or de-prioritise role accounts in your own pipeline if engagement matters.

null when Allegrow could not determine whether the address is a role account.