Not receiving email from Stackpack?

Last updated: October 14, 2026

If you expected an email from Stackpack and it hasn't arrived, this guide walks through the most common causes, from quickest to check to least common. Most missing email issues are resolved by the first section.

Quick checks (2 mins)

  1. Search all mail for stackpack.ai. Check your Spam or Junk folder, and search your whole mailbox rather than just the inbox. Filters and rules can file messages somewhere unexpected.

  2. Confirm the address on your Stackpack account. Notifications go to the email address on your Stackpack profile. If you've recently changed roles or email addresses, the old one may still be on file.

  3. Check for inbox rules. Look for any rule or filter that moves, archives, or deletes mail based on the sender or subject.

  4. Ask your IT team about quarantine. Many organizations quarantine suspicious mail before it reaches your mailbox. In Microsoft 365, users can often review their own quarantine at security.microsoft.com/quarantine. Google Workspace administrators can review held mail in the Admin console.

  5. Marketing vs. product email. Unsubscribing from Stackpack newsletters does not affect product notifications. If you're missing a newsletter or product update specifically, check whether you previously unsubscribed.

Where Stackpack email comes from

All email from Stackpack is sent from an address ending in @stackpack.ai. We never send from other domains. Our mail falls into three groups:

  • Product notifications — invitations, approvals, alerts, reports, and similar messages generated by the Stackpack platform.

  • Messages from the Stackpack team — email from your account manager or our support team.

  • Product updates and newsletters — occasional announcements, which you can unsubscribe from at any time.

All three are authenticated with SPF, DKIM, and DMARC. If a message claims to be from Stackpack but fails these checks, we've asked receiving mail systems to reject it. That protects you from phishing, but it also means that anything which breaks authentication on your side can cause legitimate mail to go missing. The sections below cover the two situations where that happens.

Allowlisting Stackpack

If your organization maintains a list of approved senders, ask your IT team to add the domain stackpack.ai. Please allowlist by domain rather than by IP address: we send through more than one provider, and the IP addresses change without notice.

If your mail filter matches on the envelope (Return-Path or bounce) address rather than the visible From address, note that product notifications currently use em342.stackpack.ai as their bounce domain, and newsletters are delivered through HubSpot and may carry a hubspotemail.net envelope. Allowlisting the From domain stackpack.ai is simpler and covers everything.

Google Workspace administrators: in the Admin console, under Gmail → Spam, phishing, and malware, you can add stackpack.ai to an approved-senders list so our mail bypasses the spam filter.

Microsoft 365 with a third-party email security service

This is the most common cause we see for Stackpack email landing in quarantine or being rejected, and it is specific to one setup: Microsoft 365 combined with a separate email security product such as Check Point Harmony Email (Avanan), Perception Point, Trellix (FireEye), Proofpoint, Mimecast, or similar.

What happens: these services scan incoming mail and then hand it to Microsoft 365. In the process they can rewrite links or modify the message, and Microsoft sees the mail arriving from the security service rather than from us. Unless Microsoft 365 has been told to trust that service, it treats the message as failing authentication and quarantines or rejects it, even though the message is genuinely from Stackpack.

How to tell: if your IT team views the message headers of a quarantined example, the Authentication-Results header will show dmarc=fail, and the message will have passed through your security vendor's servers before reaching Microsoft.

The fix is on your side (Stackpack cannot change it), and Microsoft documents two options depending on how your service is deployed:

  • If the security service receives your mail before Microsoft 365 (your domain's MX record points to the service), configure Enhanced Filtering for Connectors. This tells Microsoft to evaluate the original sender rather than the service.

  • If the service scans mail after Microsoft 365 receives it and then re-delivers it, add the service as a trusted ARC sealer. This lets Microsoft use the authentication results recorded before the service modified the message.

Your security vendor's own documentation will say which applies and give the exact domain or IP addresses to enter. Both changes are made in the Microsoft Defender portal and typically take a few minutes.

Forwarding and distribution lists

If Stackpack email is sent to one address and automatically forwarded to another, or delivered through a distribution list or group, the forwarding step can break authentication. Most major providers (including Google and Microsoft) preserve authentication across their own forwarding, but some forwarding services and older mail systems do not.

Previously bounced addresses

If your mail system rejected a Stackpack message in the past, for example because the mailbox was full, the address didn't exist yet, or a security gateway refused it, we may have paused sending to that address to protect our delivery reputation. This can persist even after the original problem is fixed.

If you've resolved an issue on your side and still aren't receiving mail, contact Stackpack Support and we'll check whether your address needs to be reset.

Still not receiving mail?

Contact Stackpack Support (support@stackpack.ai) with as much of the following as you can provide:

  • The email address that should be receiving mail

  • What email you were expecting and roughly when

  • Any bounce or non-delivery message you or your IT team received

  • For IT teams: the full message headers of a quarantined or rejected example, if one is available

With headers we can usually pinpoint the cause in a single reply.

Technical reference for IT teams

  • Sending domain: stackpack.ai (all mail; From address always ends in @stackpack.ai)

  • Authentication: SPF, DKIM, and DMARC are published for stackpack.ai. DKIM signatures use d=stackpack.ai, so a correctly delivered message shows dkim=pass header.d=stackpack.ai in its authentication results.

  • Bounce domains: em342.stackpack.ai for product notifications; hubspotemail.net for newsletters

  • Allowlisting: by domain (stackpack.ai), not by IP address

  • Microsoft 365 with a third-party gateway: see the section above for Enhanced Filtering for Connectors and trusted ARC sealers