## TL;DR
Stop lowercasing the whole email address. Unicode domains change shape when a naive lowercase hits them, and then HubSpot's email regex rejects the create. Keep the domain exactly as the source gave it, or convert it to punycode with an IDNA encoder, and lowercase only the local part.

```text
hubspot VALIDATION_ERROR on contact create  -  email property fails regex after agent lowercases a unicode domain
```

## Steps
1. Read the full VALIDATION_ERROR response and confirm the failing property is `email`. Do not guess at other fields.
   Expected: the error names the email property and shows the rejected value.
2. Log the original email from the source record next to the lowercased version your agent sent. Compare them character by character.
   Expected: you can see exactly which characters the lowercasing changed.
3. Retry the contact create with the domain in its original case, lowercasing only the part before the @ sign. Most unicode trouble lives in the domain.
   Expected: the create returns a 200 or 201 and a contact id.
4. If the original-case domain still fails, convert the domain to punycode (IDNA encoding) before sending, for example through your language's built-in IDNA encoder, and resubmit.
   Expected: HubSpot accepts the punycode domain and the contact is created.
5. Change the agent's normalization step permanently: validate the email format first, keep the source domain casing, and quarantine any address that fails validation for a human instead of mangling it.
   Expected: no more VALIDATION_ERROR on unicode domains in the next batch.

## Use this when
- The agent sees VALIDATION_ERROR naming the email property on contact create.
- The failure started after the agent added an email-lowercasing step.
- The addresses involve non-ASCII domains (accented characters, non-Latin scripts).

## Not for this skill when
- The error is a 401, 403, or 429 instead of a validation error.
- The failure is CONTACT_EXISTS (a duplicate), not a regex rejection.
- The local part of the address itself is malformed.

## Variant phrasings
- "hubspot email property validation failed on create"
- "contact create rejected by email regex after normalization"
- "unicode domain rejected by hubspot email validation"

## Why it happens
Naive lowercase functions are locale- and unicode-aware, so characters like the Turkish dotted capital I map to different characters than plain ASCII lowercasing would produce. HubSpot's email property regex expects a plain ASCII or punycode domain, so the transformed address no longer matches and the create is rejected. The data was fine; the normalization corrupted it.

## Edge cases
- Some providers lowercase the domain for you on read, so the "original" you log may already be altered. Pull the raw source value when you can.
- Punycode conversion can fail on domains with invalid unicode. Catch that failure and quarantine the address.
- Do not strip diacritics from the local part to "fix" this; that changes the mailbox identity.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Qy8oC-EJ_6-JEK12VRuPjw