Hi!
I have 2 email addresses configured on my account on gitlab.com which I will call A and B.
A is an email on a domain that I own.
B is my gmail address.
When A is set as my notification email, I don’t receive any emails. There is also nothing in the mail-server logs. All other emails do arrive without problems (even the emails of this forum!). When B is set as my notification email, everything works as expected.
Gitlab could potentially be using an email reputation service, based on your IP or domain name, and such you aren’t getting it because of poor reputation. Common when running your own email service, especially if it has only been set up, or isn’t using certain configurations like SPF, DKIM, etc, etc. Also worth using mxtoolbox.com to make sure you aren’t an open relay and also to address any concerns after using mxtoolbox to scan your server for problems.
Gmail being google, has correct configuration for SPF, DKIM, etc, and so this is most likely why it’s trusted, and why your emails arrive in comparison to your own domain/server.
I’m not using my own mail servers so that shouldn’t be the problem. I contacted the admins of the mail servers and they told me other gitlab.com mails are arriving, just not mine.
It used to work, because I verified the email address.
So can you clarify address email A which you said is a domain you own. If it is yours and you receive email on it then you have a mail server. Or you are using shared hosting which means it is a mail server shared by lots of other users or domains which will then mean it has a poor reputation since anyone could abuse it quite easily. Other customers of that shared service for example.
Difficult to solve your problem unless you provide more detail but the fact it used to work and now doesnt tells me that it has a poor reputation and therefore blocks you from receiving.
I suggest you ask those admins to check the logs and reputation of the server. We cannot help you with that and since we arent gitlab employees we cant help from that side either as this is a community forum.
Reputation normally doesn’t matter in the sender direction, only receivers normally block emails based on reputation. Why would gitlab even do that? There is no benefit at all.
Anyway, here are the mx records:
example.com. 86400 IN MX 20 smtp.ulyssis.student.kuleuven.be.
example.com. 86400 IN MX 50 CAVin01.kuleuven.be.
example.com. 86400 IN MX 50 CAVin03.kuleuven.be.
example.com. 86400 IN MX 10 CAVin.kuleuven.be.
example.com. 86400 IN MX 50 CAVin02.kuleuven.be.
I’m asking this question on the community forum, since there is no way to contact anyone from gitlab: Support
I disagree with that statement, I’ve ran email servers and gateways for 15+ years configured personally by myself and if I wish to protect my users from sending emails to untrusted domains or IP addresses I can configure my email server to do so. It stops them from responding to such emails when they might be nefarious emails. So there definitely is a benefit in doing it. Whether you agree with it or not, is a totally different matter. I can also for example completely drop emails from domains that have misconfigured SPF or DKIM records. I have a right to do that purely because it should have been configured correctly in the first place. The onus is on the person who misconfigured that domain to ensure it’s configured correctly in the first place. The blame cannot be put on me for rejecting it, when my system behaves properly. If it was configured properly, then I would have received them. It’s called reputation and you guarantee it by configuring your server correctly, ensuring it’s not an open relay, ensuring it cannot be abused by other users, ensuring it hasn’t been compromised and isn’t sending spam.
As for your MX records, example.com isn’t a domain you own, therefore that data isn’t real. Only real MX record data or IP addresses allow anyone to verify whether is is trusted or not. That said, as I wrote earlier, rather than post it - check it yourself on mxtoolbox.com both your domain name and the IP address that your MX record resolves to.
Yes and I realise you are asking this question on the community forum since you cannot get support directly from Gitlab. But like I said, we cannot check the email server logs for Gitlab since we are not administrators of it. Only the Gitlab employees are. I suppose you can hope that one of the Gitlab Team does appear here, but based on the amount of people who have already posted such questions about not receiving emails and their posts not being replied to means yours is also unlikely to get any.
As I said, you need to check the email server (even if that means asking the administrators if you cannot do it yourself), to check it’s logs to see if any connection attempts have been made or not. If not, that means the connection has not been allowed, and is being blocked like I said it was, most likely similar to what I posted - lack of reputation and trust.
Ok, that’s a valid use case. But why would gitlab do such a thing, since their smtp servers aren’t public? Anyway I can configure SPF, which I will do, but I can’t configure DKIM since we don’t control the SMTP servers.
I know. I replaced the domain with example.com… I’d like to keep my privacy and not post my domain and email addresses on a random forum. So yes the MX records are real.
I emailed the administrators of the KU Leuven, and they told me, as I said before, that they did not receive any email from gitlab.com to my email address. If there was anything send, they would’ve seen it. There are however emails coming through for other email addresses.
You don’t need to configure it, I was just giving some examples of when email failures can occur, especially when misconfigured. If you do configure it, just be careful and ensure it is correct.
So I submitted a ticket anyway. although they supposedly don’t give any support.
It looks like a suppression had been placed in our system on your email address (xxx@xxx.xx) for gitlab.com emails, so no further emails from that system would have reached you.
I’ve cleared that suppression for you at this time.
It is fixed now. 