Trying to log into OpenAI platform today. One time password email is not being sent. I now know the issue is likely with OpenAI and not my email provider.
To reproduce the issue I signed up to the OpenAI platform with a new email address at the same domain.
New account: email2@mydomain[dot]com.
I assert that emails from openai can be received from an email different from the affected account. Registration is successful.
Affected account: email1@mydomain[dot]com.
When I invite email1@mydomain[dot]com to be a member of my newly registered openai account no email is received.
As a control a new account is registered. When i register an email is received.
Control account: email3@mydomain[dot]com
This new user is invited from email2@mydomain[dot]com to be a member. When i invite the control account the email is received. The invitation is accepted and a new member is successfully added.
In the above scenario i test two separate features of the platform that include an email step. The result of the test with the control included suggest there is an issue affecting one or more openai accounts where emails from noreply@tm.openai.com are not being sent as expected.
Affected account: Unable to login. Unable to be invited. No email received.
New account: Able to login. Emails receieved.
Control account: Able to login. Able to be invited. Emails received.
I am currently unable to use the service i am paying for because of this bug.
I read the FAQ about Didn’t Receive the OTP Email?Email filters (spam, junk), incorrect email address on file. I have checked my spam/junk folder, re-sent the OTP, verified my email address, contacted support but am feeling like a second rate customer because support won’t acknowledge that I am unable to access the platform due to changes made to my account.
I have since investigated the issue and updated my original post with its process and results. I also assigned new tags to the issue as I felt the issue i encountered was not specifically with ChatGPT rather it is with platform access to the API which is developer facing.
Note that i use the tag API but am not specifically meaning the API endpoints. My issue is with services provided by platform.openai.com. One time password email not receieved. Member invite email not receieved.
Update 3:
I was able to get in contact with William representing OpenAI support. William writes:
Hello,
Thank you for reaching out to OpenAI Support.
We understand you’re not receiving One-Time Password (OTP) emails. No worries, we’re here to help!
If you don’t receive an email, or if the reset password process doesn’t work, it’s possible that you initially authenticated using your Google, Microsoft, or Apple account. If you used one of those methods, try logging in with that authentication method instead. For example, if you initially signed up with your Microsoft account, you should be able to log in by clicking the ‘Continue with Microsoft Account’ button on the login screen.
We hope this helps! If you have any further questions or suggestions, please don’t hesitate to reach out.
Best,
William
OpenAI Support
This information is useful but not immediately helpful. My password was reset since registering and it worked. Additionally I signed in last week so something has changed since then.
Update 4:
I was put in touch with Dadi from OpenAI support. Dadi kindly reviewed my account to confirm that while what William says is true it was not relevant for resolving the issue with not receiving OTA or member invite emails from noreply@tm.openai.com.
My email provider reports that no filter lists or deny lists are blocking messages from this email address and I have proven this by registering a new account with OpenAI from the same email provider.
Update 5:
It appears that the email associated with the account was reported erroneously internally and resulted in suspension of services. I want the issue to be resolved quickly and did not expect resolution to take so long. But did not realise that the segmentation of support teams meant those assigned did not initially have access to the required resources for investigation.
If anybody in the future encounters something like this it is possible a similar thing happened to you. Open source OpenAI is probably the best way to go to avoid the dangerous political struggles that are internal decision making should they ever occur. In such a case I wish your issue resolved with great haste.
Holy molly. i am experiencing the same exact issue. i have been bugging my email provider and they said no OTP was coming from openai. i tested with a different account and the OTP and reset password as coming through, but not for my affected account. the support from the help center is useless and ai generated. How did you get hold of a human and what was the ultimate resolution. i am going circles for more than a week
The chat dialog I had open refreshed then closed before I could read the most recent progress update on the issue from support. You have my wishes for great haste.
I was able to resolve this by logging in with a google account associated with the same email address. In case you are encountering a similar problem an approach like this may work for you
I have additional information relevant for this bug which arose inadvertently as i was seeking a solution to the issue. I did not know where best to post this information but felt a responsibility to share in the light of a collective commitment to open sharing.
──────────────────────────────────────────────────────────────────
THREAT OVERVIEW
──────────────────────────────────────────────────────────────────
Name: Domain-Intercepted Account Takeover
Type: Infrastructure Manipulation → DNS Hijacking → Email-Based Account Compromise
──────────────────────────────────────────────────────────────────
SUMMARY
──────────────────────────────────────────────────────────────────
A malicious actor gains unauthorized control over a victim’s DNS records or mail-exchange (MX) configuration, enabling them to redirect or intercept the victim’s email flow. By wielding control over the associated email address, the attacker can fraudulently:
• Register new accounts at OAuth/SSO providers using the victim’s email.
• Initiate password resets or link new OAuth credentials to existing SaaS accounts.
This tactic leverages the widespread assumption that “control of the email address = identity ownership,” making it a strategic target for threat actors seeking user-account takeover.
──────────────────────────────────────────────────────────────────
RELEVANT MITRE ATT&CK TACTICS & TECHNIQUES
──────────────────────────────────────────────────────────────────
• TA0001: Initial Access
– T1584.002: Compromise Infrastructure – DNS Hijacking
• TA0005: Defense Evasion
– (Potential custom or relevant technique for mail interception)
• TA0006: Credential Access
– T1586: Compromise Accounts (sub-technique for email account or authentication tokens)
──────────────────────────────────────────────────────────────────
CAPEC REFERENCE
──────────────────────────────────────────────────────────────────
• CAPEC-630: DNS Hijacking
• CAPEC-151: Identity Spoofing (via Email)
──────────────────────────────────────────────────────────────────
INDICATORS & OBSERVED ARTIFACTS
──────────────────────────────────────────────────────────────────
• Unexpected DNS record changes (A, MX, or CNAME) pointing to unfamiliar servers.
• Unusual OAuth registration attempts or authorization grants for existing user emails.
• Sudden account resets or “password-changed” notifications without user initiation.
──────────────────────────────────────────────────────────────────
IMPACT
──────────────────────────────────────────────────────────────────
• Account Takeover: Full control of targeted SaaS accounts (e.g., music streaming, productivity tools, etc.).
• Potential Data Exfiltration: Access to personal user data, subscription details, payment methods.
• Broader Credential Reuse: If the hijacked email is reused across multiple services, the attacker can pivot and escalate.
──────────────────────────────────────────────────────────────────
RECOMMENDATIONS
──────────────────────────────────────────────────────────────────
DNS Security Controls • Implement registrar locks, 2FA at the DNS registrar, and monitoring for record changes.
Email Verification Hardening • Require additional proof-of-ownership methods where domain-based emails are used (e.g., multi-factor authentication, separate security questions, or out-of-band verification).
OAuth Linking Protections • Enforce re-authentication or explicit user approval flow when linking a new OAuth provider to an existing account.
Logging & Alerting • Monitor for anomalous DNS changes and suspicious account recovery or new OAuth registration events.
Threat Intelligence Sharing • Share IoCs or suspicious DNS records via STIX/TAXII or within MISP communities to give early warning to partners.
──────────────────────────────────────────────────────────────────
CONCLUSION
──────────────────────────────────────────────────────────────────
This threat scenario underscores the danger of relying solely on “email = identity” assumptions when a domain can be hijacked. By seizing control of DNS or mail flow, an adversary can compromise numerous downstream SaaS accounts. Proactive DNS monitoring, multi-factor authentication, and careful OAuth link validation are vital to mitigate such account takeover attacks.
