ARBOR: Password Reset Emails not received

[MYK-IT]

Hi,

 

Just wondered if any other schools are affected by this issue whereby Arbor password reset emails are not being received? As despite logging a support call (via SBS) many weeks ago and being advised it is a known issue, we are still impacted by this resulting in many students who have not successfully enrolled / accessed Arbor yet.

 

Quote

The suggested workaround is to manage resetting passwords for the students and advise of their initial credentials via other methods. Then they can change to one of their choice. The issue is apparently also affecting staff and guardians.

 

Whilst this may be our only option, we are also think that this (issue) is affecting internal Arbor-email staff to student communications too. But until we get all our students on-boarded we won't know how widespread this issue could be.

[Koldov]

Had this quite a bit a while ago when we started with Arbor and contacted support, but didn't really get any resolution.

 

Haven't had any issues for a while but I presume this is because now we're up and running everybody remembers their password... so I haven't bothered looking into it any further.

 

I found we were receiving the emails but they were all being quarantined (GMail) as is our current DMARC policy, so I could just release them. We set up everything they asked to the best of my ability with regards to DNS (DMARC, DKIM, SPF, TXT), I even put a rule in GMail to allow them (at least what I thought was). None of it worked, but that could be my fault as I'm not really confident in any of that stuff...

 

We added CNAME and added Domain Keys to our DNS, something to do with Sendgrid emails, but I noticed the password reset emails were coming from a different/additional server to the ones we'd allowed there.

 

I was told it was "logged as Known Problem (number 989983). This means that we can link together any other schools that report this issue which helps the Engineering team to prioritise their work"

Edited June 23, 2025 by Koldov

[MYK-IT]

Thanks @Koldov appears to be exactly the same process (albeit for M365) that I have already done etc. And advised of same issue number too!

 

Bizarrely, it is not affecting all student accounts and different, in that the emails don't get received at all (e.g. not in quarantine or when I use Defender Portal) to search for such sent emails etc.

 

Looks like I will have to generate temp passwords and distribute them to students (asking them to change once logged into Arbor), then get staff to 'test' communication (via Arbor) to their tutor / class / tutor group to confirm students can receive Arbor email-based communications.

 

 

Edited June 23, 2025 by MYK-IT

[Koldov]

Is your DMARC policy set to 'reject'?

[MYK-IT]

9 minutes ago, Koldov said:

Is your DMARC policy set to 'reject'?

 

No, it's set to quarantine.

[Koldov]

I've just sent myself a password reset email and it's gone into quarantine...

 

Thing is, I've looked through the header and can't see anything wrong, everything seems to pass.

 

I put the header in MX Toolbox and everything is OK.... DMARC, SPF, DKIM all show green.

 

The only thing I can think of is that the header contains the following line:

 

"X-Gm-Auto-Quarantined: 1" SMTP Header Tag

 

I haven't found much information about that, but I saw this post in the Google Cloud Community forum:

 

"Google Support confirmed that the SMTP header "X-Gm-Auto-Quarantined: 1" was inserted by the sending server, forcing a quarantine no matter what"

 

https://www.googlecloudcommunity.com/gc/Workspace-Q-A/quot-X-Gm-Auto-Quarantined-1-quot-SMTP-Header-Tag/m-p/542409

 

 

 

 

 

 

[MYK-IT]

32 minutes ago, Koldov said:

I've just sent myself a password reset email and it's gone into quarantine...

 

Thing is, I've looked through the header and can't see anything wrong, everything seems to pass.

 

I put the header in MX Toolbox and everything is OK.... DMARC, SPF, DKIM all show green.

 

The only thing I can think of is that the header contains the following line:

 

"X-Gm-Auto-Quarantined: 1" SMTP Header Tag

 

I haven't found much information about that, but I saw this post in the Google Cloud Community forum:

 

"Google Support confirmed that the SMTP header "X-Gm-Auto-Quarantined: 1" was inserted by the sending server, forcing a quarantine no matter what"

 

https://www.googlecloudcommunity.com/gc/Workspace-Q-A/quot-X-Gm-Auto-Quarantined-1-quot-SMTP-Header-Tag/m-p/542409

 

 

@KoldovAt least your emails are getting sent / received (into Quarantine!) which I could cope with! 😉

[Koldov]

OK, so did a little testing (probably not advised and certainly not with any 'scientific' methodology)...

 

Might not help the OP, but maybe O365 has similar security features, or someone else might find it useful.

 

For our quarantined email the 'Matched Rule' was 'Spoofing and Authentication'.

 

I have read previously that this will not have any 'Rule Description' given as it is deemed by Google that (from the link in my other post) "when you have these safety rules enabled, it will not show in the matched rules because they are actually not rules but are considered as configuration."

 

So, I went in to the 'Google Admin console > Apps > Google Workspace > GMail > Safety > Spoofing and authentication' and turned off each setting in turn and then tried to reset my Arbor password each time...

 

Strangely enough, the setting that seemed to work was 'Protect against spoofing of employee names' once that was unticked, the email came straight through to my inbox! I'm guessing maybe Arbor uses your username/domain to send an email to you, but from their servers...?

 

 

I think I reached my limit of Arbor password reset requests, because now it just gives me blank box with an exclamation mark (very helpful)... I swapped browsers from Chrome to Edge and it gave me a couple more tries, but now I'm completely locked out, so I'll double check my findings tomorrow if there's a timer...

 

Then hopefully someone can tell me what that means and how to get around it, without turning this setting off...

[MYK-IT]

@Koldov Your Google settings appear similar to O365 Spoofed Name / Domain mail-flow rules I've had configured for some time (example. How to stop Spoof Email in Office 365 - A step by step guide) as well as M365 A5 Domain / User Impersonation etc.

 

However, your overall issue appears different, as in the emails are being received from Arbor (albeit held in quarantine). Whereas our emails (via Arbor) are not being received at all destined for selective email addresses.

[Koldov]

Well OK, so with all my GMail security settings back on I tried a password reset this morning and the email just sailed through and landed in my inbox! Tried again and the same, email received, no problem!

 

W... T... F...

 

Here's the kicker.... With their permission, I tried to reset another user's password.... email went straight to quarantine!

 

Turned off the 'Protect against spoofing of employee names' and their email went through!

 

Going to turn it back on.... and see if now their email goes straight through every time as well....

[Koldov]

Do you think that any sort of O365/M365 'spoofing' protection actually stops the email being sent at all?

 

There is a section in the header that says:

 

google.com: domain of bounces+54321-824b-MYNAME=OURDOMAIN.co.uk@em1234.arbor-education.com

 

It would make sense if somewhere along the line, some sort of 'protection' is kicking in. O365 might intercept the mail earlier and stop it even entering the chain...?

 

The 'X-Gm-Auto-Quarantined: 1' line in the header appears to have been inserted, it obviously doesn't appear in the mails that get through, so when and where was it added? It's the only thing that jumps out between a bad header and a good one.

Edited June 24, 2025 by Koldov

[Koldov]

So, it might not help the OP or anyone else as it seems I'm the only one with this problem according to the lack of posts on here, or internet search hits (Arbor does have it as a known problem and have troubleshooting guides on their support pages, even though I've followed them and it hasn't helped).

 

Well, it looks like the fact that the email got through once means that even with the security settings back on, the password reset emails consistently get through for this user now.

 

I found one more thread that might explain it and mentions the added 'x-gm-autoquarantine: 1' entry into the header.

 

https://www.reddit.com/r/gsuite/comments/108c7vi/how_do_i_whitelist_emailsdomains_that_go_into_the/

 

"If they are getting quarantined as a result of safety settings (they will have x-gm-autoquarantine or something similar in the header) only way to bypass it is to have the recipient (user) add the sender to their contact."

 

https://www.youtube.com/watch?v=ICCwDiEuzjU

 

In the video he uses GAM I think, to add a domain wide contact. This allows the message to get through quarantine, or alternatively get into the inbox rather than spam and with no warning message and even after removing that contact it allows the message through. I'm not sure that will work in my scenario though as each email is sent to an individual, using an individual email address 'spoof' (I think... unless I can wildcard it somehow... or whitelist the domain, but it's not a big enough issue to warrant any more time).

 

I can only presume some sort of 'intelligent' filtering of these emails is happening and once allowed through, they become 'known' to the system and then appear to bypass the spoof filtering.

 

 

 

[mavhc]

What email address are these password reset emails coming from?

[Koldov]

In the header there is this line:

 

From: Name of My School <[email protected]>

 

I'm not well versed in the deciphering of email headers, but I know the 'from' can be altered, I also get a bit stuck when talking about header-from, envelope-from, etc... which I found out when trying to create a rule! Maybe I'm over complicating things...

 

Anyway I did add arbor-education.com to an approved senders list to bypass the spam filters, but maybe I have the terminology wrong in the rule? I also think this is quarantined by the Security Settings configuration so doesn't even get that far...

 

Authentication-Results: mx.google.com;

DKIM passes - @arbor-education.com

SPF passes - smtp.mailfrom="bounces+1234567-123b-USERNAME=SCHOOLDOMAIN@em1234.arbor-education.com";

DMARC passes - arbor-education.com

 

In the SPF pass it mentions the users name and removing the GMail security configuration setting about spoofing users allows the mail through, so although compelling evidence to me, I might be completely off-track...

 

 

[MYK-IT]

53 minutes ago, Koldov said:

In the header there is this line:

 

From: Name of My School <[email protected]>

 

I'm not well versed in the deciphering of email headers, but I know the 'from' can be altered, I also get a bit stuck when talking about header-from, envelope-from, etc... which I found out when trying to create a rule! Maybe I'm over complicating things...

 

Anyway I did add arbor-education.com to an approved senders list to bypass the spam filters, but maybe I have the terminology wrong in the rule? I also think this is quarantined by the Security Settings configuration so doesn't even get that far...

 

Authentication-Results: mx.google.com;

DKIM passes - @arbor-education.com

SPF passes - smtp.mailfrom="bounces+1234567-123b-USERNAME=SCHOOLDOMAIN@em1234.arbor-education.com";

DMARC passes - arbor-education.com

 

In the SPF pass it mentions the users name and removing the GMail security configuration setting about spoofing users allows the mail through, so although compelling evidence to me, I might be completely off-track...

 

When I did similar (e.g. to allow emails through) after analysing the message header (e.g. Message Header Analyzer) I used the Authentication-Results message header Contains , in your case, em1234.arbor-education.com 

 

Also may be worth checking any other 'sent from external' rules you have, as although the email form Arbor appears to come from your domain, it is treated as external.

Edited June 24, 2025 by MYK-IT

[Koldov]

I used the MX Toolbox Analyze Headers which is where I saw it passed all the usual tests.

 

DMARC Compliant
SPF Alignment
SPF Authenticated
DKIM Alignment
DKIM Authenticated

 

So the usual Arbor troubleshooting doesn't really apply as it's focused on those being the reasons it might fail to be sent/delivered or end up in spam/quarantine.

 

That's when I started digging deeper and as you say it is sent from an external server, but possibly 'spoofing' (a user in) our domain. I guess there's something GMail doesn't like about that, but it appears to be Safety Configuration setting that is on or off and I can't find a way around it as the other places I know to put allow rules (spam, phishing and malware)  don't trigger early enough in the chain. I need to find a way to tell GMail to allow it right at the top of the chain before it checks the Safety Configuration Settings I guess...

 

We don't have many rules set other than any that were default, most of the ones I've set are trying to allow things through!

 

I did try turning off Protect against domain spoofing based on similar domain names and Protect against inbound emails spoofing your domain, but neither of these allowed the emails through.

 

EDIT: I've created more quarantines and been through the 'Safety' settings and I've set Domain Spoofing and User Spoofing to their own individual ones.

I'll try to reset a different user's password again and see which one it ends up in and hopefully that will determine what Google thinks the problem is.

Edited June 24, 2025 by Koldov

[mavhc]

18 hours ago, Koldov said:

In the header there is this line:

 

From: Name of My School <[email protected]>

 

In which case it's 0 to do with your dmarc settings, or any of your dns based settings, they only affect your email, they exist to get fake email sent as you rejected

[Koldov]

Just an update and further apologies to @MYK-IT for hijacking the thread... 😬

 

This morning I tried resetting another user's Arbor password.

 

As predicted it ended up in my newly created 'User Spoof' quarantine...

 

 

The only setting I have that directs emails to this quarantine, is the following:

 

Apps > Google Workspace > Settings for Gmail > Safety > Spoofing and Authentication

 

 

So, in this setting where it specifies the 'email sender's name' isn't actually the 'from' as I think from the header, this is 'Name of My School <[email protected]>'

 

I'm confused... why does it think the email sender's name is in our Google Workspace Directory...?

 

Edited June 25, 2025 by Koldov

[mavhc]

perhaps because it's pretending to be Name of My School the system is detecting it as possible fraud, can't they just say "Arbor notification <password-reset@....>"?

[Koldov]

Yeah, I guess they have each school ring-fenced and set up to be individual obviously, so everything is kept 'per school' but even so, I don't think it would matter, as I can't get my head around why this seems specifically 'user' based detection and not 'domain' based detection though as it didn't send the email into my other quarantine which I created for the other domain spoofing settings.

 

That's what I don't understand, if it was triggering anything based on the domain/school name (in the 'from') it would be sent to my domain based spoofing quarantine, as that's the setting it would have used...?

 

EDIT: Searching the header in MXToolbox, the username is found in the following sections:

 

Delivered-To

ARC-Authentication-Results

Return-Path

Received-SPF

Authentication-Results

To

 

So, something in here is triggering Google...

 

It is definitely not in the 'From' section... this is as expected 'nameofschool <[email protected]>'

 

 

Edited June 25, 2025 by Koldov

[Koldov]

In the ' ARC-Authentication Results' and the basic 'Authentication Results' there is the line:

 

smtp.mailfrom="bounces+12345678-0ca2-username[email protected]"

 

Is Google picking up the smtp.mailfrom ...?

 

This is obviously different to the basic 'from'  in the header... and although the username is in the other sections I mentioned, this is the only place I can see 'from' and the 'username' together.

 

EDIT: Just to say that it is actually the user's name and the School's name...

Edited June 25, 2025 by Koldov

[Koldov]

Little bit of research...

 

smtp.from refers to the MAIL FROM command in the Simple Mail Transfer Protocol (SMTP). It's used to specify the sender's email address during an email transaction, essentially telling the mail server where to send bounce messages if the email cannot be delivered. This address is part of the email envelope, not the message header itself

 

https://serverfault.com/questions/518119/legitimate-reasons-smtp-mail-from-will-not-match-from-header-in-data

[mavhc]

They're putting the name of the user and the school in a from header, no wonder it's trigging fraud detection, tell them to stop doing that

[Koldov]

I think my problem here is that given the exponential rise of Arbor in the last couple of years and the fact that most people here must be on GMail or O365... nobody else seems to have this issue...

[sjatkn]

My school has had similar problems with students, particularly, not receiving password reset emails. We noticed that most of the ones suffering this had two email addresses, a usually personal one (often the parents) and a school one. If we removed the personal one then password reset emails came through.

 

I raised this with Arbor and the support person tested with and found that if someone has two email addresses with the one marked as default in second then the password resets emails did not get sent. I've not been told (yet) if there is a fix for this or if we just have to go through and find/remove non-default email addresses that appear before the default address.

 

If I get told how to fix it and it's something we need to do then I will try to remember to come back and update this thread.