1. Read the recorded transfer state for the owned domain.
2. If that state may be stale, queue the supported domain sync and inspect its outcome before deciding another message is needed.
3. Confirm the provider actually requires a verification action and that the recipient can access the correct contact mailbox.
4. Submit the resend request with the required idempotency key.
5. Track the returned operation and ask the recipient to check the verified mailbox, including its spam or quarantine controls.
6. After the recipient completes the required action, reconcile the domain again and confirm the transfer's final state.

No. It shows the module accepted or processed the supported resend request. Provider dispatch, mail delivery and recipient verification remain separate events. Keep the operation reference if the provider reports that the message could not be sent.

Use the registrar's authorised contact-recovery process. Repeated resends to an inaccessible mailbox will not solve the problem, and this route is not a way to substitute another person's address. A registrant contact change can have its own verification or transfer consequences, so coordinate the plan with the current registrar.

Allow the provider's documented delivery and retry behaviour, and inspect the existing operation. Use a new request only for a deliberately separate resend after review. Identical transport retries retain their original idempotency key.

If the transfer has already completed or entered another lifecycle stage, follow that current state. Do not create a fresh inbound transfer merely because an old verification email was not found.

• Monitor and reconcile a pending domain transfer through the v2 API
• Synchronize a domain's current provider state through the v2 API
• Recover access to the contact email needed for a domain transfer
• Retry Domain Nexus requests without creating duplicate domain operations