Hi folks, I’m in need of rescue from Gmail jail …
Today, an “account-confirmation” email sent from my website via SMTP(NodeMailer) was rejected by Gmail, suspected spam. A follow-up I manually sent via RoundCube was likewise rejected.
Gmail’s message: “host gmail-smtp-in.l.google.com[108.177.15.26] said:
550-5.7.1 [161.97.70.54 12] Our system has detected that this message
is 550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to
Gmail, 550-5.7.1 this message has been blocked.”
I’m now pursuing resolution at Gmail Postmaster Tools which is asking for “Enter the domain used to authenticate your mail with SPF or DKIM.” - but I barely understand the question 
should I enter the box.nnn.nnn name of the MiaB instance, or the alias I’m sending these emails from?
This happened also some weeks ago with a customer’s Hotmail address.
Is this a common issue, are there measures we can take to improve deliverability?
We send a very small volume of emails, never unsolicited.
Thanks for any help, insights 
Craig.
If this is happening with mail sent from other IP addresses, and especially with transactional mail, you need to make sure you are following all of the rules there, especially with having “unsubscribe” links in every message.
@openletter Thanks for your input. This has happened with mail sent via SMTP (587) from a website whose IP is not the same as my MiaB, and also with mail sent straight from MiaB/Roundcube.
Following instructions at Gmail Postmaster Tools, I added a TXT record and a CNAME record - details provided by Google) to the DNS for the domain in question (an alias in my MiaB). Google then confirmed that the domain - actually my ownership of it - was confirmed. I then tested again using a Gmail address I own, but the result was the same - bounced back as suspected spam.
So, in Gmail, I whitelisted the sending email address and tried again. That worked fine.
There is no need for the user to unsubscribe - this is simply a “confirm your email address” message sent at signup time. Here it is:
Email registration at HeadsUp.social
Please click [HERE](https://headsup.social/confirmemail?ts=< random GUID >) to confirm your email address.
Best regards,
Support
The issue may be centered on the fact that there’s a link to click, but there’s nothing unusual about that.
SInce we absolutely do not send unsolicited email, have no newsletter or anything of that ilk, any “unsubscribe” link I could put in a footer would need to go to a nonsense controller which does nothing but return a 202 response - it certainly couldn’t send an email confirming a fake unsubscribe op.
Since asking new users signing up to whitelist our support address before proceeding is ridiculously clumsy, I’m hoping to find out how (if it’s even possible) to maximally verify the MiaB installation such that all receivers like Hotmail and Gmail do not mark our mails as spam.
You may not feel it is technically necessary to have an unsubscribe link in your messages, the administrators at the large mail server companies disagree. This is why when you use the newsletter evaluation tools they will downgrade you and inform you that you do not provide unsubscribe links and to add them.
Once your domain is on their spammer list, it will not matter which IP address sends on behalf of the domain.
Gmail provides unique spam protection for every user. So an email that inboxes for one user may go to spam for another.
It seems like when Google fist launched Postmaster Tools it was actually useful for inboxing with Google, but it seems like nearly everyone is now reporting that it doesn’t seem to do anything, other than I suspect provide Google with some sort of useful metadata to add to some surveillance database some place and send their own spam to the admin email address.
lol, we should do lunch, my treat, you express suspicions very similar to my own
So I’ve just googled for email newsletter evaluation tools and found quite a bit of new reading. I’ll dig into that and see where it takes me.
The “unsubscribe” link makes perfect sense as you present, even if it does absolutely nothing at my end. Can’t really do any harm, and the current state of affairs could not be worse, so I’ll most likely do it.
Thanks again!
I know that many people will turn to using an external SMTP service, and I understand this, but the issue with using these is that the email must arrive at the SMTP server unencrypted, so this spambox mitigation technique adds an additional vector for attacks against your users. In effect, Google, Microsoft, Yahoo, et al, are working to make email yet less secure.
As it happens, pretty much all of the spam that reaches my inbox is from Google, Microsoft, Yahoo, et al, yet they are never on blacklists.
Point taken - I think I might use a different approach to verifying users as actual people since we don’t actually need their email addresses for anything. That would sidestep the SMTP part of the issue.
Still, an email sent manually from my Roundcube was also rejected by the same customer’s Gmail account - that remains somewhat distressing.