ローカル部分の最後にダッシュを付けたEメールID
Eメールのローカル部分の終わりにダッシュ（ - ）が付いている場合、それは有効なEメールですか？例えば、
または一般化すると、電子メールIDの最初または最後、あるいはその両方にある電子メールのローカル部分に有効なこれらの文字（Characters !#$%&'*+-/=?^_``{|}~ (ASCII: 33, 35-39, 42, 43, 45, 47, 61, 63, 94-96, 123-126)）のいずれかを使用できますか？
Googleはそれが無効であると言っているので、とりあえず私もそれを無効とみなします。ただし、RFCはローカル部分の先頭および/または末尾から[ドット]文字のみを除外します。
注：ドメインの部分については心配していません。DNSのせいで問題がさらに複雑になるため、質問と回答が複雑になります。
電子メールのローカル部分の最後にダッシュ（-）がある場合、それは有効な電子メールですか？ [...] Googleはそれが無効であると言っているので、RFCはローカル部分の開始および/または終了から[ドット]文字のみを除外しますが、当面は無効であると想定します。
有効です。他の多くのプロバイダーと同様に、local-partにできることについて独自のポリシーを持っているため、Googleによって拒否されたのは完全に異なるチェックを行うためです。
Googleまたは他のユーザーは、フォームが実際に要求既存の有効な電子メールアドレス（プロバイダーから）である場合にのみ、有効な電子メールアドレスをすべて受け入れる必要があります。たとえば、GmailのTo：/ Cc：フィールドが有効なアドレスを拒否した場合、エラーになります。
ただし、強調表示したフィールドでは、既存の電子メールアドレスの入力は求められません。 Googleシステムのアカウント名を要求します。これは、アカウントが作成された後にのみ電子メールアドレスの基礎となります。 Googleや他の誰かが、有効なアカウント名（または、実際にはメールボックス名）のセットを制限することを禁止するものはありません独自のシステム上。
または、言い換えると、「local-part」に許可される文字を定義することは、メールアプリケーションSMTPサーバーがRFC 822ヘッダーおよびSMTPコマンドでそのようなアドレスを受け入れる必要があることを意味しますが、できることについては何も言いません（ createそのようなメールボックス。 （実際、初期の電子メールRFCが作成され、ほとんどのメールボックスがまだOSレベルのアカウントに関連付けられていたとき、それらの名前には同様のまたはさらに厳しい制限がありました。）
たとえば、RFC 5321のこの部分（セクション4.1.2、ABNFの下）では、受信ホストが許可され、実際にshould自身のメールボックスの命名方法にはるかに厳しい制限があることを明示しています。
Local-partの上記の定義は比較的許容性がありますが、相互運用性を最大化するため、Local-partがQuoted-string形式を必要とする（または使用する）メールボックスやLocal-partが大文字である場合のメールボックスの定義を避ける必要があります（SHOULD） -敏感。
したがって、[email protected]isは構文的に有効ですが、それだけでは、Googleが作成を許可する必要があるという意味ではありません。
G Suite（正式にはドメイン向けのGoogle Apps）では、最後の文字としても、メールアドレス内にハイフン（ダッシュ）を使用できます。
ユーザー名には、文字（a〜z）、数字（0〜9）、ダッシュ（ - ）、アンダースコア（_）、アポストロフィ（ '）、およびピリオド（。）を含めることができます。
出典： 名前とパスワードのガイドライン
ご存じのとおり、Gmailでは電子メールアドレスにハイフンを使用できません。