Gmail blocking email from address

Is Gmail about to make our email aliases useless?

Tonight I sent two emails from, and they were both blocked since some google server considered my message to be “likely unsolicited mail”. When resending via the same ISP, but using another email address whose domain has an SPF record, they seem to have made it to the recipents.

I can’t recall I have seen this before. Has Gmail been more restrictive recently? Or has ended up in some blacklist?

Anyone else who have stumbled upon this problem?

It’s of course not possible to manage an SPF record for, but maybe some other authentication method is available (have never used anything beyond SPF).


That is really frustrating, @gunnarhj - let me talk to IS and they can see if there is indeed a denylist we are on, or if it’s something else and we can work around it.

Also, @teward is this related to issues you were having with aliased mail previous, or issues that you saw?

1 Like

I just put in a ticket - it’s EOW which means I might not hear back until early next week, but I’ll keep following up on this!


Thanks @madhens. I can’t tell for sure that it’s not just me, but I thought it’s worth looking into.


I use my alias with the Gmail box and to date I have not encountered any problem


If you have registered that address as an alias at your Gmail account, your situation differs from mine. Then you actually send mails from Gmail.

My situation is that I use my address when sending from Thunderbird via the SMTP server of my ISP. I don’t have a Gmail account. But yesterday two mails sent to Gmail accounts were not delivered.


I have run into “likely unsolicited” bounced emails when my ISP’s common mailserver IP address gets listed as a spam source/relay.

I suspect your SPF record made the difference.

In this case, since it was an ISP issue, the solution was to open a ticket with the ISP. That particular ISP apparently rented to spammers somewhat regularly, so it happened often…we changed ISPs. The other solution was to obtains a separate IP address for our mailserver so it wouldn’t be associated with the spammy source.


Thanks so much for the reply, @ian-weisser! @gunnarh if you do this and it helps fix your issues please let us know and I’ll update the ticket. :slight_smile:

Is there any documentation on setting up e-mail addresses that we could add to/revise? If not, maybe this would be a good topic!


To test @ian-weisser’s theory that the problem may lie with my ISP, I just sent three similar test messages to a Gmail recipient but from different addresses:


    That one bounced (again).

  2. is an alias just like, and also without an SPF record that authorizes the SMTP server of my ISP. But unlike the message from this one passed.


    That’s a real address with an inbox and with an SPF record that authorizes the SMTP server of my ISP. The message from that address passed too.

Since the message from was not bounced, I still have a reason to fear that the problem lies with the domain and Gmail rather than the reputation of my ISP. And @madhens: I think this piece of info is relevant input to the ticket.

Getting in touch with my ISP is a cumbersome exercise which I’m going to wait with for now. If I’d contact the support, they would just tell me: “please use your address”. And that’s obviously not the solution I’d like to see. If I’d contact somebody who understands the issue, they would probably ask for evidence that the problem lies with them. And at this time I’m short of such evidence.


I confirm, for the 3 tests messages: I never got version1; I got version 2; I got version 3

1 Like

Thanks for such good due diligence, Gunnar! I will update IS with this information.

1 Like

Thanks @dsmythies!

Also, below please find the source of the Delivery Status Notification message I got for the bounced message. @madhens: That may also be useful for the ticket (or not).

From - Mon Mar 28 22:23:24 2022
X-Account-Key: account2
X-UIDL: 000704e952d96275
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <MAILER-DAEMON>
Received: from ( [])
	by (8.15.2/8.15.2/Debian-10) with ESMTP id 22SKLXb2012597
	for <>; Mon, 28 Mar 2022 22:21:34 +0200
Received: from ( [])
	by (Postfix) with ESMTP id AFDC71A2A81
	for <>; Mon, 28 Mar 2022 20:21:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=tssemail; t=1648498888; 
X-RG-Rigid: 61A898DD06E4D80B
X-Originating-IP: [::1]
X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedvvddrudehjedgudeglecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfvgffnkfetufghpdggtfgfnhhsuhgsshgtrhhisggvpdfqfgfvnecuuegrihhlohhuthemuceftddtnecupfhothhifhhitggrthhiohhnucdluddttddttddmnecujfgurhephffuvfffkfggtgesphdttdertddtjeenucfhrhhomhepofgrihhlucffvghlihhvvghrhicuufgvrhhvihgtvgcuoefotefknffgtfdqffetgffoqffpsehtvghlihgrrdgtohhmqeenucggtffrrghtthgvrhhnpeejtefhfeeuudejjeduueetteevleeigfdvheeiffeuleefhfeutedtgefffedvheenucffohhmrghinhepghhoohhglhgvrdgtohhmnecukfhppeemmedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghlohepthhsvddtuddqshhmthhpohhuthejiedruggutgdrthgvlhhirghsohhnvghrrgdrnhgvthdpihhnvghtpeemmedupdhmrghilhhfrhhomhepoeeqpdhnsggprhgtphhtthhopedupdhrtghpthhtohepghhunhhnrghrhhhjsehusghunhhtuhdrtghomh
X-RazorGate-Vade-Verdict: clean 10000
X-RazorGate-Vade-Classification: bounce
Received: by (5.8.716) id 61A898DD06E4D80B for; Mon, 28 Mar 2022 22:21:27 +0200
From: Mail Delivery Service <>
Subject: Delivery Status Notification
Date: Mon, 28 Mar 2022 22:21:27 +0200
Message-ID: <>
X-CP-Transaction-ID: 61A898DD06E4D800
MIME-Version: 1.0
Content-Type: Multipart/Report; report-type=delivery-status; boundary="========/61A898DD06E4D800/"

This multi-part MIME message contains a Delivery Status Notification.
If you can see this text, your mail client may not be able to understand MIME
formatted messages or DSNs (see RFC 2045 through 2049 for general MIME
information and RFC 1891 through 1894 for DSN specific information).

Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

 - These recipients of your message have been processed by the mail server:; Failed; 5.3.0 (other or undefined mail system status)

    Remote MTA network error

 - SMTP protocol diagnostic: 550-5.7.1 [      12] Our system has detected that this message is\r\n550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail,\r\n550-5.7.1 this message has been blocked. Please visit\r\n550-5.7.1\r\n550 5.7.1  for more information. p9-20020a2e9a89000000b0024952f7bd13si17651075lji.622 - gsmtp

Content-Type: Message/Delivery-Status

Reporting-MTA: dns;
Received-from-MTA: dns; [] (
Arrival-Date: Mon, 28 Mar 2022 22:21:27 +0200

Final-Recipient: rfc822;
Action: Failed
Status: 5.3.0 (other or undefined mail system status)
Remote-MTA: dns;

Content-Type: Message/RFC822

Return-Path: <>
Received: from [] ( by (5.8.716) (authenticated as u87648615)
        id 61A898DD06E4D800 for; Mon, 28 Mar 2022 22:21:27 +0200
Message-ID: <>
Date: Mon, 28 Mar 2022 22:21:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Content-Language: en-US
To: Doug Smythies <>
From: Gunnar Hjalmarsson <>
Subject: Test message I
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Doug!

Due to my email problem I mentioned the other day, I sent three test 
messages to you with similar content but from different email addresses. 
Hope you don't mind.

This one from



IS has this information and they’re getting it to someone who might be in the best position to figure out what’s going on.


I noticed a comment on the issue in this email message:

@rbasak: Do you possibly have relevant info to add to this topic and pass on to IS? Or does IS already have the full picture?

I think if it was Gmail that was blocking, many of us would have noticed.
I write to other Gmail addresses and they have always received my e-mails.


Sorry, I’m not sure I have much I can add. The Canonical IS ticket (access is limited I think) is #136362. This is the one I raised when I first received a very large number of bounce notifications to ubuntu-devel-owner@. It was closed after adjustments were made. Today I got a very large number of unsubscribe notifications to ubuntu-devel-owner@ and reopened the ticket.

That’s all I know really. It seems to me that there’s a problem with traffic being accepted by Gmail, resulting in bounces and automatic unsubscribes. But I don’t actually know that for certain. I haven’t investigated in any detail at all, leaving that for Canonical IS.


Thanks @rbasak, that’s still useful. Myself have observed that they seem to bounce any message from addresses (unless they happen to be sent from some Gmail account). If that’s generally true, I suppose it explains the problem you have seen with the lists.

Just wanted to provide an update. Evidently there was a recent change in how Gmail handles authentication, which either requires SPF or DKIM. The fixes required to solve this will require prioritization by IS management, and this issue has just been escalated.

Evidently, Debian has been using per-user DKIM keys, but according to the support staff, this is dangerous as it means anyone with an at-ubuntu e-mail address could impersonate another. Naturally, the staffer feels this is not a good solution, and I agree.

Thanks again for bringing this up, and we’ll keep you and everyone updated!


Both - the alias problem exists currently to GMail recipients, but it also is wider than just one recipient, because I use MS365 to run my email (yes i know, I’m paying Microsoft for my email, but I’d rather them absorb the security part.)

MS365 won’t let me send as aliases not in the MS365 domain. Barring that, I route my outgoing mail via my (now otherwise dead) SMTP server when I ran my own email myself.

IS needs to set up SMTP for us with emails (hint: i think they’re already working on this?), complete with DKIM sigs and SPF records, and Google needs to make sure they update things.

FYI though: all “aliases” routed through “random mail servers” have always been on the “More heavily regulate this traffic” behaviors list. At GMail, at my own mail gateway, etc. because it’s much easier to spoof until we get an SMTP set up and using SPF, DKIM sigs, and a valid DMARC record.


That sounds as an ideal solution.