ローカル部分の最後にダッシュが付いたメールID

電子メールのローカル部分の最後にダッシュ（-）がある場合、それは有効な電子メールですか？例えば、

an.unusual.email-@mydomain.com

または、一般化するために、これらの文字（Characters !#$%&'*+-/=?^_``{|}~ (ASCII: 33, 35-39, 42, 43, 45, 47, 61, 63, 94-96, 123-126)）のうち、電子メールIDの先頭および/または末尾の電子メールのローカル部分に有効なものはありますか？

Googleはそれが無効だと言っているので、RFCはローカル部分の開始および/または終了から[ドット]文字のみを除外しますが、当面はそれも無効であると想定します。

注：ドメイン部分については心配していません。これは、DNSが原因でより複雑になり、質問と回答が複雑になるためです。

https://social.technet.microsoft.com/Forums/ie/en-US/69f393aa-d555-4f8f-bb16-c636a129fc25/what-are-valid-and-invalid-email-address-characters

電子メールのローカル部分の最後にダッシュ（-）がある場合、それは有効な電子メールですか？[...] Googleはそれが無効であると言っているので、RFCではローカル部分の開始および/または終了から[ドット]文字のみを除外していますが、当面は無効と見なします。

有効です。Googleは完全に異なるチェックを実行するため、拒否されただけです。他の多くのプロバイダーと同様に、ローカルパーツに独自のポリシーがあります。

Googleまたは他の誰もが、フォームが実際に既存の有効なメールアドレス（プロバイダーから）を要求している場合にのみ、有効なすべてのメールアドレスを受け入れる義務があります。たとえば、GmailのTo：/ Cc：フィールドが有効なアドレスを拒否した場合、エラーになります。

ただし、強調表示したフィールドでは、既存の電子メールアドレスの入力は求められません。Googleシステムのアカウント名を要求します。これは、アカウントが作成された後にのみ、メールアドレスの基礎となります。Googleや他の誰かが自分のシステムで有効なアカウント名（または、実際にはメールボックス名）のセットを制限することを禁止するものはありません。

または、言い換えると、「local-part」に許可される文字を定義することは、メールアプリケーションのSMTPサーバーがRFC 822ヘッダーおよびSMTPコマンドでそのようなアドレスを受け入れる必要があることを意味しますが、そのようなメールボックスを作成できることについては何も言いません。（実際、初期の電子メールRFCが作成され、ほとんどのメールボックスがまだOSレベルのアカウントに関連付けられていたとき、それらの名前には同様の、またはさらに厳しい制限がありました。）

たとえば、RFC 5321のこの部分（セクション4.1.2、ABNFの下）では、受信ホストが許可されており、実際に、自身のメールボックスの命名方法について、はるかに厳しい制限が必要であると明示しています。

Local-partの上記の定義は比較的寛容ですが、最大限の相互運用性のために、メールを受信することを期待するホストは、Local-partがQuoted-string形式を必要とする（または使用する）メールボックスまたはLocal-partが大文字である場合のメールボックスの定義を避けるべきです（SHOULD） -敏感。

したがって、構文的にanunusualemail-@gmail.com は有効ですが、それだけではGoogleが作成を許可する必要があるという意味ではありません。

G Suite（正式にはドメイン向けGoogle Apps）では、最後の文字であっても、メールアドレス内でハイフン（ダッシュ）を使用できます。

ユーザー名には、文字（az）、数字（0-9）、ダッシュ（-）、アンダースコア（_）、アポストロフィ（ '）、およびピリオド（。）を含めることができます。

出典：名前とパスワードのガイドライン

ご指摘のとおり、Gmailではメールアドレスにハイフンを使用できません。