Issues with email to app when forwarding an email

🔧 Bugs & Issues
1

Hi team,

I reported this last year already but the issue is still occurring and I can’t figure out why it isn’t working reliably.

We send emails with attachments that need to be processed in Tape to an address that forwards these emails unchanged to a Tape app, using the app’s public email address. The idea is:

  • Users send emails to process_step_1@example.com instead of a long, complex Tape app email.
  • If we ever need to change the Tape app, we can keep the forwarding address and update only the destination.

This setup works fine for me, for most users, and for all test cases I’ve created.

However, for one specific user it fails intermittently and I can’t identify a pattern.

  • Their email reaches the forwarding address.
  • It is forwarded as expected.
  • But it never appears in Tape.

The attached screenshot is from today, showing an example where the email was forwarded but never showed up in the Tape app.

Could you help me understand why emails from this user are not being consistently processed in Tape, and what we can do to debug this further?

image
image2708Ă—1256 197 KB

image
image888Ă—1192 101 KB

3 Likes
2

@Leo can you help here?

1 Like
3

Hi @Kollaborateur,

thank you very much for the detailed report and for sharing the delivery report screenshotsđź’Ż

Of course, we can help here. We’ll investigate this in detail and get back to you directly with our findings, ideally already with the solution.

Thanks again for reporting this and for providing the extra details. Wishing you a great weekend.

Best,
Leo

4

Hi @Kollaborateur,

the Tape team performed some log-forensics, and we were able to trace this down to a particular rejected email pattern. Even though your screenshot only contains a redacted sender email address, it matches what we see and we could correlate via the timestamp :eyes:

So far, this appears like an overly strict validation inside our inbound email pipeline. Our logs only show this error happening once a month though - does that match your observation?

Logs:

2026-04-03 07:29    p***@****.de	dropped — spfCheckFailed:true, dkim/dmarc/spam/virus all false
2026-05-03 08:04	p***@****.de	dropped — same
2026-06-03 05:29	p***@****.de	dropped — same
2026-06-03 08:59	p***@****.de    (resend "FW:")	dropped — same
2026-07-03 05:48	p***@****.de	dropped — matches your screenshot exactly (07:48 CEST)

This also matches your original report a while back:

Root cause: in this case, Tape rejected due to an SPF failure, which could never pass for a forwarding scenario like this (forwarder relaying the message unchanged). SPF check is not reasonable in this case, and overly strict.

Heads up: We adjusted the check for such scenarios, will you retry via the same “FW:” resend you already performed in June? Waiting until the next due date (seems like that will be August 3rd) would be more inconvenient :mailbox: :ship:

Happy weekend
Tim