Validate Email Syntax
identity.validate_email_syntax
Overview
You send an email and we validate its syntax under a profile you choose: rfc (RFC 5321/5322-informed), practical (common deliverable subset, default), or strict_ascii (ASCII-only). We check structure, length limits, character rules, and IDNA domain conversion. A valid result means syntax only — not that the mailbox exists or is deliverable. We never perform DNS/MX lookups (checkMx is reported as unavailable). Do not use this to confirm deliverability.
A one-line regex either rejects addresses that work or accepts ones that cannot. You get a stable code per problem instead, so your form can say what is actually wrong and your import can decide which rows are worth keeping.
Reliability
Same address and same profile, same verdict — nothing here touches the network, so valid means the shape is right and nothing more. The limits we enforce are 254 characters for the whole address, 64 for the local part, 255 for the domain and 63 per domain label. A rejected address is a normal success with valid false and a populated defects list, so branch on valid rather than on your error path, and remember an info-severity defect leaves valid true. We reject the call itself only when email is missing, is not a string, or is longer than 1024 characters, when profile is not rfc, practical or strict_ascii, or when allowInternationalized or checkMx is not a boolean — the same payload will always fail the same way, so fix it rather than retry.
Context footprint
Returns validity, parsed parts when valid, and a defect list. A successful call costs 1 execution credit.
When to use it
When addresses arrive from a form, an import or an untrusted feed and you want to reject the structurally impossible ones before you store them.
When you need to know a mailbox exists or accepts mail, or when you want the address rewritten into a comparison form.
Scope
Non-goals
- Does not verify deliverability
- Does not perform MX/DNS lookups
- Does not confirm mailbox existence or ownership
Properties
Capabilities
Cost & billing
Flat rate per invocation
File handling
How we handle your data
What this means
This skill may receive sensitive content and may return submitted, transformed, extracted, or reformatted content.
Squillify guarantees
- Runs inside Squillify
- This skill runs inside Squillify.
- Payloads are not sent to an external service by this skill.
- Squillify does not permanently store submitted payloads.
- Telemetry records metadata only, not submitted content.
- Submitted payloads are not used for training.
- Submitted payloads are not reviewed by humans.
- This skill does not target sensitive data.
- Output may reveal sensitive derived information
Your responsibility
Squillify does not determine whether submitted content is sensitive. Your application is responsible for deciding what data it is allowed to submit. Your application is responsible for securing the response.
Input schema
| Field | Type | Required | Description |
|---|---|---|---|
| string | Yes | Email address to validate. | |
| profile | string | No | Validation profile; omit it for practical. |
| allowInternationalized | boolean | No | Whether internationalized domains are allowed; omit it for true. |
| checkMx | boolean | No | Whether unavailable MX checking is reported; omit it for false. |
Output schema
| Field | Type | Required | Description |
|---|---|---|---|
| valid | boolean | Yes | Whether no error-severity defect exists. |
| profile | string | Yes | Applied validation profile. |
| localPart | string | No | Parsed email component. |
| domain | string | No | Parsed email component. |
| asciiDomain | string | No | Parsed email component. |
| defects | array | Yes | From 0 through 16 structured syntax defects, each a closed code and a safe message. |
API contract
POST /v1/executecurl -sS -X POST "$BASE/v1/execute" -H "Authorization: Bearer $KEY" -H 'Content-Type: application/json' -d '{"skillKey":"identity.validate_email_syntax","input":{"email":"[email protected]"}}'import { Squillify } from "@squillify/sdk";
const sq = new Squillify({ apiKey: process.env.SQUILLIFY_API_KEY });
const { output } = await sq.execute("identity.validate_email_syntax", {"email":"[email protected]"});Errors
| Code | HTTP | Retryable | Description |
|---|---|---|---|
| VALIDATION_ERROR | 400 | No | The request payload failed schema validation. |
| UNAUTHORIZED | 401 | No | Missing or invalid API key. |
| SKILL_NOT_ACCESSIBLE | 403 | No | The API key is not granted access to this skill. |
| SKILL_NOT_AVAILABLE_FOR_PLAN | 403 | No | This skill is not included in your current plan. |
| PLAN_ELIGIBILITY_UNAVAILABLE | 503 | Yes | Plan eligibility could not be decided. Retry after backoff. |
| SKILL_NOT_FOUND | 404 | No | The requested skill or version does not exist. |
| TENANT_RATE_LIMITED | 429 | Yes | Request rate limit exceeded. Retry after backoff. |
| QUOTA_EXCEEDED | 429 | Yes | Plan quota exhausted. Retryable once the quota period resets. |
| EXECUTION_TIMEOUT | 504 | Yes | Execution exceeded the allowed time budget. |
Other limits
| Limit | Value |
|---|---|
| Recommended inline bytes | 32 KiB |
Limitations
- Does not verify deliverability
- Does not perform MX/DNS lookups
- Does not confirm mailbox existence or ownership
- Confirming a mailbox exists (requires network)
- Normalizing addresses for comparison (use identity.normalize_email)
- Assuming valid syntax implies the address is owned or reachable
How to call
POST /v1/execute (requires authentication)
{
"skillKey": "identity.validate_email_syntax",
"input": {
"email": "[email protected]"
}
}Examples
Standard address passes the practical profile
{
"email": "[email protected]"
}{
"localPart": "user",
"profile": "practical",
"valid": true,
"defects": [],
"domain": "example.com",
"asciiDomain": "example.com"
}Missing @ separator — valid=false with structured defects
{
"email": "userexample.com"
}{
"localPart": "",
"profile": "practical",
"valid": false,
"defects": [
{
"code": "MISSING_AT",
"message": "Address must contain '@'.",
"severity": "error"
}
],
"domain": "",
"asciiDomain": ""
}Recommended use cases
- Validate signup or profile form input before you store an address
- Sanity-check email columns in CSV or contact imports
- Reject structurally impossible addresses early in a pipeline
Avoid for
- Confirming a mailbox exists (requires network)
- Normalizing addresses for comparison (use identity.normalize_email)
- Assuming valid syntax implies the address is owned or reachable
Related skills
Composable with
Safety & privacy
- Runs without calling any external service.
- Your payloads are never stored permanently.
- Telemetry captures metadata only — never your payload contents.
- We never train models on your payloads.
- No human reviews your payloads.