It should have been a simple task – setting up my hey.com email address to forward to my gmail.com account. The actual setup was very easy and initial testing showed everything was working as it should.
But a couple of days later I logged back into my hey.com web account to check something and noticed there were a few emails from the HEY Postmaster – [email protected] – informing me that “HEY – We were not able to forward your email” – looking at the full notification message, Gmail thought these emails were likely unsolicited mail so was blocking them.
It wasn’t every email, it was just a few that were being blocked.
The Postmaster Message From Gmail
host aspmx.l.google.com[18.104.22.168] said: 550-5.7.1 [22.214.171.124 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. Please visit 550-5.7.1 https://support.google.com/mail/?p=UnsolicitedMessageError 550 5.7.1 for more information. l10si39595810jak.33 – gsmtp (in reply to end of DATA command)
The hey.com support team concluded that the problem was with the content of the emails looking like SPAM – I wasn’t convinced it was just the content as I have received these types of emails previously in Gmail without issue.
My next move was to add my @hey.com email address to my safe list in Gmail and also setup a rule to never send the emails to SPAM, I tested again and it made no difference, emails were still being rejected.
I have worked in email delivery for close to 20 years and I had a hunch something wasn’t quite right here. So I decided to dig a little deeper and setup hey.com to forward emails to my [email protected] email address, I waited a few days and logged in to my @hey account and saw the now familiar postmaster emails.
This time the rejection emails were different. It now seems to be a DMARC issue.
The Postmaster Message from iCloud
host mx01.mail.icloud.com[126.96.36.199] said: 554 5.7.1 Your message was rejected due to xxxx’s DMARC policy. See https://support.apple.com/en-us/HT204137 for info (in reply to end of DATA command)
After more research and testing I think I have found the problem!
I compared emails that had forwarded with those that hadn’t – I then compared the original senders DMARC and SPF records and think the issue lies with hey.com blocking email tracking – I can not be 100% sure due to not knowing what they do to prevent the email tracking from working, but my worry is that whatever they are doing is breaking the DKIM signature, which in turn is causing the receiving server of the forwarded email to obey the p=reject command in the DMARC records.
All the emails that were being rejected by both Gmail and iCloud had tracking detected and stopped by hey.com – all of the emails also had valid DMARC records with p=reject and all were DKIM signed. Coincidence maybe?
Paul O'Brien Newsletter
Join the newsletter to receive the latest updates in your inbox.