All emails (notification, system, etc.) not being received by our email server.

[SilverBullitt]

To preface this, I put the word "our" in the title, but I am the client's IT provider and they are having a tough go with notifications coming from Hubspot. They are using the free version, which is another story, but for now I think I am at a point that there is a bug here or a half setup domain.

They are not receiving any emails from Hubspot to their primary domain for anything, including password reset notifications. Because of this, I am assuming that it isn't just a user setting inside Hubspot. Their MX record is pointing to their M/O365 tenant correctly (XXX.mail.protection.outlook.com).

We've done a Message Trace on the Exchange Online servers for any incoming mail from @hubspot.com or @notifications@hubspot.com and we get no results - Searching over the past 10 days. (I signed up for a user account here and tested the forgot password feature to verify the email address / domain it is sending from.) From what i read in the documentation from Hubspot below to self-troubleshoot and M365, the message trace would show the message if there was any client email issues (SPF, quarantine, junk folder, etc.). 

I've been through the ideas here already: https://knowledge.hubspot.com/marketing-email/not-receiving-hubspot-system-or-notification-emails, anything from here: https://community.hubspot.com/t5/Tips-Tricks-Best-Practices/E-mail-Notifications-not-working/m-p/652... . But nothing has worked.

I'm down to thinking that somehow the email delivery domain somehow was half-setup / internal mail routing record in hubspot that causes the app to decide to direct the mail somewhere other than the server listed in the MX record. Its been at least 2 months at this point. As far as I can tell the free version doesn't let you set a email delivery domain, but maybe it used to and it is now half-configured? But even then, i'm more scratching my head that the password reset emails do not come through either.

Any one have any thoughts? I'm hoping I am just missing something simple here, but running out of options. Definitely owe somebody a beer for this one.

[SilverBullitt]

And in a followup, running a Message Trace on the server just using the recipient email address of the password reset and no sender filters, we still get no messages that have been sent by Hubspot to the domain.

[ArisudanTiwari]

Hi @SilverBullitt ,
Totally understand the frustration, and your message sounds like you’ve already covered a lot of ground.
Can you confirm that @hubspot.com and @notifications.hubspot.com are allow‑listed in Microsoft 365 Defender, specifically under Tenant Allow/Block List → Rules & Policies?
Also, as a diagnostic step, try creating a test user in your HubSpot portal with a non-M365 email address (like Gmail or Outlook.com). If that user receives emails without an issue, then we can safely say the problem lies in the recipient environment (M365 side), not with HubSpot itself.

Since this is a free HubSpot account, you won’t be able to reach out to HubSpot Support directly. So I’m tagging a couple of HubSpot Community Managers here in case they can help escalate or provide deeper insight.
@Victor_Becerra @Jaycee_Lewis @DianaGomez 

[SilverBullitt]

@ArisudanTiwari - Somehow this was marked as a solution. Just unmarking it as we haven't made progress with the hubspot community team. If @Victor_Becerra @Jaycee_Lewis @DianaGomez would know who we can reach, that would be awesome!

[Victor_Becerra]

Hi @SilverBullitt ,
Can you DM me the domain associated with your customer portal?Also, did your client have a trial active at some point
Just to clarify - with a free account, we don't have access to the actual portal settings as community managers, which may limit how we can directly assist with this email delivery issue.
Thanks!

[SilverBullitt]

Thanks Arisudan, yes we've placed any of the HubSpot domains (I had a list of approx. 5) in the allowlists. we can confirm external domains from the client one does work, which makes sense in the same context that the email-based  password reset function doesn't work for the client domain either. 

I appreciate you tagging a few people as well. Thanks