Gmail

[pipedream-component-development]

App

Gmail

Summary:

Gmail New Attachment trigger not executing when a new attachment is received via a gmail alias, but works correctly with direct mail.

Details:

I built a flow to trigger off a gmail new-attachment that is received at systems@magicspoon.com daily at 12:00PM UTC. Currently, I deployed 3x triggers to test the flow but none of them successfully trigger off of the target email.

-gmail trigger 12:10 PM UTC
-google developer app - 12:10 UTC
-gmail trigger 1-minute intervals

I can trigger all 3x triggers if I recreate the target email+excel file and send to systems@magicspoon.com directly from my private email, but the true target email is delivered from an external domain ( rjw.reports@rjwgroup.com)-> a magic spoon gmail alias (ops-reports@magicspoon.com) -> the email address connected with my pipedream integration (systems@magicspoon.com). Again, if i send the same email/excel file from my personal email -> systems@magicspoon.com, all triggers work as expected.

Based on the trigger logs, the gmail integration appears to recognize the "new attachment event" emission, but fails to trigger the flow. I think it is an issue with how the integration handles the inbound event via gmail alias.

I've attached the exact target email that I expect to trigger this flow.

Flow: https://pipedream.com/@magicspoon/projects/proj_1js3ZVe/rjw-open-closed-order-report-email-google-sheets-p_NMCJPZ8/inspect

Source ID: dc_XauXxWY

From gmails help page on gmail alias:
"you'll find "via" and a website name next to the sender's name if:

The domain it was sent from doesn't match the domain in the "From:" address. For example, you got an email from john.smith@gmail.com, but it could've been sent through a social networking site and not Gmail.
The email was sent to a Google Group from a domain that has a "p=reject or p=quarantine" DMARC policy."

Screenshots:

[jcortes]

Hi @andrewjschuang @sergioeliot2039 @sergio-eliot-rodriguez do you know the user who is reporting this issue? I created my own alias email to try to reproduce the error but seems it's working as expected. I could't reproduce it!
Perhaps the email is getting filtered to spam?

[andrewjschuang]

Yes @jcortes, please follow up in this Slack thread

[jcortes]

After sending some messages to the user via slack, last conclusion from the user is:

Update on this-- I added the sender email to my contact list & it looks like the DMARC test passed this morning. I'll need to wait a day to test if it is working well.
Honestly, the best fix might just be to add a comment to the user-guide to ensure inbound attachments are coming from known email addresses

So we are going to be waiting if this solution works. If that's true, we will add the alert text in the component to make things more clear for the user!

Update

Latest response from the use was:

It looks like it did not-- still not auto-triggering the flows from Gmail unfortunately

So the issue persist so we still need to keep investigating about it!

Hi @vunguyenhung can you please give me a hand here trying to replicate the issue?

[vunguyenhung]

Hey @jcortes and team,

I believe the root cause is related to DMARC settings. Here's the breakdown:

• When emails are sent via a Gmail alias, a "via" indication appears if the actual sending domain (e.g., rjw.reports@rjwgroup.com) differs from the alias domain (e.g., ops-reports@magicspoon.com). This discrepancy triggers DMARC checks.
• If the sender's DMARC policy is strict (e.g., set to reject or quarantine emails that don't align with the expected SPF/DKIM settings), the forwarded or alias-handled email may not be fully trusted. As a result, even though the Gmail integration logs the event, the workflow might not be triggered.

Since DMARC policy and verification are managed externally to Pipedream, modifying our code is unlikely to resolve the issue.

On the Pipedream side, I agree with the customer's suggestion:

Honestly, the best fix might just be to add a comment to the user-guide to ensure inbound attachments are coming from known email addresses.

For the customer, I recommend setting up an auto-forwarding rule so that emails sent to the alias are forwarded directly to the target inbox. This should help bypass the DMARC complications associated with the alias setup.

[GTFalcao]

From @vunguyenhung 's comments above, I think adding an "info" alert prop makes sense for this one. Can add a link to documentation on this or even to this issue, for additional context.