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.
