Do you have any additional repro steps? Mail config will be specific to the Phab/Phorge install. If this is specific to our Phorge installation, yeah... it's sucky. We self-host our email server and that means we're subject to all of the arcane and mystic requirements there. As far as we can tell, it's set up as correctly as is possible (SPF, DKIM, DMARC all configured correctly; domain is old enough that it doesn't negatively impact our trust scores; etc.). (A current spam test result for reference.)

Unfortunately, outlook.com emails have not historically played nice with our setup. Short of migrating to a managed email service, this is probably going to remain an issue on this instance for a while.

Manual verification is always possible, however. A user with ssh access to the server or VM hosting the Phorge instance can always ./bin/auth verify <user@example.com> to work around the issue.

I can confirm as well that I have never received an email from phorge / phabricator on my email which isn't "outlook.com" but is an office 365 email account

This is likely related more to the configuration of the email server. Outlook is very picky, and as far as I know, checks the headers for all of the following:

• Proper SSL certificates on the email domain
• Email sent from same domain as reported by the email server configuration
• Sent via authorized SMTP account
• DKIM keys
• SPF (actually, not sure, but it's easy to add while adding DKIM)

We had a similar issue with Microsoft email on our own custom mail server. Microsoft delivers mail for several domains from the same email service, so this similarly affects email from outlook.com, hotmail.com, live.com and msn.com. See https://postmaster.live.com/pm/policies.aspx for details.

The way we cleared the issue was ultimately to email their delivery team and get them to unblock our mail server in addition to doing all the steps on their policy page (which are roughly in line with what you would do to setup a legitimate email server regardless). I don't believe this is a phorge/phabricator issue.

A few months back this story came up on hackernews which seems relevant. There might be things in there we can attempt to appeal to Microsoft to allow emails from this Phorge instance to go through

https://www.nerd-quickies.net/2020/10/20/microsoft-silently-dropping-emails-a-sad-but-true-story/
https://news.ycombinator.com/item?id=27980192

I just checked the emails I receive to my gmail account and noticed that the emails seem to be from the secure.phorge.dev domain. Should those be received from we.phorge.it instead? I was in the process of filling out an issue form for Microsoft and noticed this discrepancy. Could that cause issues like this?

In T15059#1654, @speck wrote:

I just checked the emails I receive to my gmail account and noticed that the emails seem to be from the secure.phorge.dev domain. Should those be received from we.phorge.it instead? I was in the process of filling out an issue form for Microsoft and noticed this discrepancy. Could that cause issues like this?

Regarding that there is T15036: Phorge upstream mail should not use @upstream.phorge.dev addresses as an existing task.

In T15059#1654, @speck wrote:

I just checked the emails I receive to my gmail account and noticed that the emails seem to be from the secure.phorge.dev domain. Should those be received from we.phorge.it instead? I was in the process of filling out an issue form for Microsoft and noticed this discrepancy. Could that cause issues like this?

That one's on me... Set it up with the old domain and haven't circled back to update it yet. It shouldn't cause any issues in terms of message deliverability that I can think of at least. I think we'll need @deadalnix to update DNS if we want to move the email domain over

I had experience with emails from my self-hosted mailserver not reaching Microsoft-hosted mailboxes. As far as I remember, their SMTP replies to "suspicious" mail servers with a message that includes a link to some sort of a form which the mail admin should fill out. That worked for me - might need to dig through the server logs to see the link though.

Alright, I've just went through a similar process - they apparently have changed their process a little but there still is a form to fill out: https://support.microsoft.com/en-us/getsupport?oaspworkflow=start_1.0.0.0&wfname=capsub&productkey=edfsmsbl3 (you need a Microsoft Account to fill it out, but they'll contact you on the contact email you give in the form)

This will let them know something's wrong, and they'll do an automated check as for why emails aren't getting delivered, and relay the information back. But you definitely should go dig through postfix's logs (or whatever MTA Phorge uses) for replies from office365/outlook mailservers for any errors or alternative solutions (and try those first).

They also have some SDNS and JMRP systems that should provide feedback to whoever's the postmaster whenever their emails arrive at their mailservers and get classified as spam. But those are set up in a way that the IP ranges provided for monitoring need to be verified by their postmaster/abuse contact (which is likely to be the ISP's/hosting's contact, rather than one we control) - I'm sent an email asking if there's a way around that limitation, and will relay news here.

FYI, I believe I'm encountering similar issues. Our organization just switched to a new email domain hosted on Microsoft 365 and when attempting to add the new email address to my account on this installation, I do not receive an email with the confirmation link.

It is almost certainly due to some DNS config. Modern email provider expect a ton of different config in there, and they are quite tricky to get right.

Untagging Phorge since this is a well-known wide group of issue related to Outlook itself or the SMTP server, and 99.999% not related in any way to Phorge itself. Make sure that your configuration is consistent. Make sure that your sender From: is the same as your SMTP username. Make sure you contacted Outlook for delivery troubleshooting info.

@Labricator can you please clarify if you are talking about your own installation, or this specific we.phorge.it installation? I ask this since you mentioned "Phabricator" and not "Phorge"

Maybe relevant, from my Postfix logs:

May  8 14:33:57 gargantua postfix/smtpd[19591]: warning: hostname secure.phorge.dev does not resolve to address 198.74.57.92
May  8 14:33:57 gargantua postfix/smtpd[19595]: warning: hostname secure.phorge.dev does not resolve to address 198.74.57.92
May  8 14:33:58 gargantua postfix/smtpd[19597]: warning: hostname secure.phorge.dev does not resolve to address 2600:3c03::f03c:92ff:fef0:e481
May  8 14:33:58 gargantua postfix/smtpd[19592]: warning: hostname secure.phorge.dev does not resolve to address 2600:3c03::f03c:92ff:fef0:e481
May  8 14:33:58 gargantua postfix/smtpd[19590]: warning: hostname secure.phorge.dev does not resolve to address 2600:3c03::f03c:92ff:fef0:e481

And my spam filter says:

X-Spam-score: 1.5
X-Spam-hits: BAYES_50 0.8, ME_SENDERREP_NEUTRAL 0.001,
  RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001,
  RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001, RDNS_NONE 0.793,
  SPF_HELO_PASS -0.001, SPF_PASS -0.001, LANGUAGES en, BAYES_USED user,
  SA_VERSION 3.4.6
X-Spam-source: IP='198.74.57.92', Host='noreverse', Country='US', FromHeader='dev',
  MailFrom='dev'

Just like valerio.bozzolan's log, my spam filter is complaining (or penalizing) for lack of PTR record. But when you do PTR query on the IP, we see the correct secure.phorge.dev: the problem is that A record which is hiding behind Cloudflare ™️ which therefore makes secure.phorge.dev A record != 198.74.57.92 PTR record. (EDIT 2024-05-10T22:47:00Z: this has since been fixed.)

Also note my spamfilter complaining about RPBL_BLOCKED: it seems like (when you query mxtoolbox) the server IP is blocked by SORBS.

X-Spam-known-sender: no
X-Spam-sender-reputation: 500 (none)
X-Spam-score: 0.8
X-Spam-hits: BAYES_50 0.8, ME_SENDERREP_NEUTRAL 0.001,
  RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001,
  RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001, SPF_HELO_PASS -0.001,
  SPF_PASS -0.001, LANGUAGES en, BAYES_USED user, SA_VERSION 3.4.6
X-Spam-source: IP='198.74.57.92', Host='secure.phorge.dev', Country='US',
  FromHeader='dev', MailFrom='dev'
X-Spam-charsets: plain='utf-8'

At least my mailserver stopped complaining about PTR record, but it is still reporting about being blocked @ somewhere. Seems like the SORBS: