Iām forwarding DMARC reports to a centralized Tape app within a customerās organization, using the āPublic email addressā functionality. These emails are routed through the companyās main email server.
The server logs indicate that the emails are successfully sent to Tape, with detailed confirmations of delivery. However, the messages are not appearing in the app.
Interestingly, if I send an email directly from my personal address to the app, it works as expected. This suggests that the issue might be specific to how the messages are processed when sent via the companyās mail server.
Itās confusing that the server log reports successful delivery, yet the app does not display the emails. Iād appreciate any help in identifying where the discrepancy lies.
Can you send the email to your email, and then forward to the public tape email. Just to see if that works.
This will help troubleshoot and potentially provide a workaround until everything is resolved.
I have not looked at a public email address and tape and quite some time and Iām on my phone so Iām going for memory. I wonder If there are any characters in the tape email address that the server is stripping out?
Whatās puzzling is that it worked when I initially set it up at the beginning of 2025. It stopped functioning around May 2025. Thatās why I donāt believe the issue is related to the email format or the attachment itself. Also, when I forward the same email to myself, I can then send it to Tape without any issues.
Thatās interesting. Do you have access to a different domain on the same server? Try sending from there to further confirm itās not isolated to the original domain and Tape.
I hate chasing email bugs because of all the moving parts.
That does indeed sound like strange behavior, especially since nothing was changed on your end and it suddenly stopped working. Also, thanks a lot, @1F2NS, for jumping in and helping narrow things down!
Weāll also do a more detailed analysis on our end. We actually havenāt touched anything in our internal email modules or infrastructure recently either, which makes this all the more puzzling. But as we all know, email reception can be quite tricky - there are a lot of moving parts involved, and itās often unclear what exactly causes issues like this.
As @1F2NS suggested, weāll dig into the details and follow up here as soon as we know more.
SMTP error from remote server for RCPT TO command, host: inbound-smtp.eu-west-1.amazonaws.com (54.155.140.59) reason: 550 5.7.1 IP address blacklisted by recipient
We have this issue now also with a client. There needs to be some whitelisting maybe? The application stops working, if we canāt rely on mails to arrive in the application. Could you disable the SPAM checking as an quick solution? There shouldnāt be much spam anyways with this kind of āobfuscatedā E-Mail addressesā¦
Hi Rico, @Kollaborateur,
did you forward (forwarding address is sender) or reroute (original address remains sender) to the tape email address?
In our case its rerouted. So the original sender remains intakt, gets blocked by the TapeApp AWS Spam filter. The Mail Server, that rerouted the mail gets the bounce information. Its error message arrives in the same inbox, gets rerouted to the TapeApp and gets accepted (not blocked by Spam Filter in TapeApp AWS).
Thanks a lot for the report and sorry for the issue. Weāve already started the analysis. So far, AWS has always handled this reliably, and weāve had very few reports of emails not coming through. But youāre right ā whitelisting might indeed be the best solution here.
Thanks as well for sharing the detailed information via DM thatās really helpful. Weāll use it to make sure the emails are delivered as quickly as possible. Weāll keep you updated as soon as we have the first fixes in place.
Having said that, whitelisting would probably not work for scenarios like rerouting Support requests to an Tape App. The good thing is to keep the senders address as sender, instead of the forwarding address. While the sender doesnāt know our app address.
If its possible to deactivate the spam checking, I would prefer this. The App address is obfuscated enough and if its every getting spammed, we could assign a refreshed address to the app.
For everyone else interested - @Tim and @Leo applied a hotfix, where we white listed some involved mail server IPs and the issue was solved. Team Tape now thinks about a more general solution for this issue.
itās reroute for us as well ā at least with the project where we first realized thereās an issue. The main problem is that itās very hard to monitor or even detect when emails are being blocked. In our case, weād essentially have to check the server logs daily and compare them against the emails that actually reached the Tape app in order to figure out which ones were blocked.
