Recent email security update. How to fix “We couldn’t process your email”

email-to-asana

#1

As some of you might have already noticed, we have recently made some updates to our email security protocols in order to strengthen account security. The idea behind this security update is to prevent people from spoofing your email address and creating tasks in your Organisation/Workspace without your permission. Please note that this issue is only affecting emails sent to Asana; emails sent from Asana (such as reminders or notifications) are not affected!!

Let me give you a little bit of context: when sending an email to Asana, the email has in fact two addresses: the address that it says it’s from, and a second address that it’s really from (the “envelope-from”). Note that every email provider uses their own terminology here, so these two addresses might be named differently depending on your chosen email provider. Asana used to accept all emails, even if the address that the message says it’s from didn’t match the address it was really from.

This is no longer the case – if the two addresses are not matching, you will receive the following message: “We couldn’t process your email because it was sent by notyouremail.org, but your email domain is supercoolcompany.com. », and in order to fix this, you’ll need to re-configure your mail server so that the domain of the envelope address matches the domain of the from address. You might additionally have to update the domain settings in order to give this server permission to send emails on behalf of this domain.

Unfortunately this is not something we can modify on our end, but we have listed some resources below that you might find helpful to reconfigure your email server:

  • If you’re using a G Suite alias: We’re currently working on a solution (I will make sure to edit the post as soon as we have some updates). In the meantime, we would recommend the following:
  1. Please make sure emails are sent from your primary G Suite domain, not an alias
  2. Swap the primary domain and the alias around.

As you can see from above, there isn’t one solution to this problem; most of the resources listed above should help you in solving this problem but if you have any questions or if you need some additional assistance, please reach out to our support team (https://asana.com/support) who will be able to assist you further.


X@mail.asana.com stopped working for forwarding tasks due to gmail POP account error
Email sent from own domain through gmail
Email-to-task from another domain (to multiple tasks)
Create task via email not working (JotForm)
New user, having trouble with task creation notification emails to project members
Add by email restrictions
#2

Thanks Marie this is very clear!


#3

I’ve been in contact with iPage several times, copy/pasting your recommendations, but they keep telling me that Asana has blacklisted their email server and request that I ask Asana to whitelist it. Other than that, there is nothing they can do.


#4

Thanks, Marie. I use a G Suite alias for business purposes and when sending emails outside the team always bcc x@mail.asana so that I can create a follow-up task for myself. I’ve found this to be more efficient than using the Asana for Gmail integration.
Hoping you’ll find a solution to the G Suite Alias soon.
Thanks.


#5

Yep, this is the bane of the problem. Asana should create a whitelisting feature rather than making us go search through some silly settings which we may/may not have access to(i.e. SMTP server details). Asana is at fault here not providers they have listed.


#6

Are there any updates on this for G Suite users? The solutions proposed aren’t really viable.

Frankly, this issue has created issues for several members of our team and it’s been nearly a month. I’m surprised Asana has not reverted this pending having a solution on hand for those folks, or allowing workspace owners to opt-out of this.


#7

Hi @Doug_Lloyd and thanks for following up on this! I completely understand the frustration around this recent update, but it had to be done in order to guarantee security standards for our users (You can refer to my first post in this thread to understand the context behind this security update).

Most GSuite users are encountering an issue because they have changed their domain and added their new domain as a “domain alias”. So when emailing to Asana from the Google domain alias, our system rejects the email because the “envelope-from” still shows the primary domain for G Suite, not the alias.

Unfortunately, since the issue is directly linked to your Google domain, this is not something we can fix on our hand, but I’m more than happy to recap the steps that other GSuite users have used to resolve the problem:

  • First thing, make sure that all emails sent to Asana are sent from the primary domain in GSuite, not one of the domain aliases. You can verify that by clicking on the “From” line of the email you are sending. You can also refer to this support article from Google if you need to: https://support.google.com/mail/answer/22370?hl=en

  • The second option is to change your primary domain in G Suite altogether. If the domain alias is a new email domain that the company is using, you should probably make that the new primary domain and keep the old one as a domain alias instead if they need it. Here is more information from Google support on how you can do that: https://support.google.com/a/answer/7009324?hl=en

Hope this helps! Have a great weekend!


#8

Hi,

I have Office365 with a shared mailbox called support@ and I was hoping to send support tickets from my web forms to support@ and then forward onto my asana project email. However I receive the same error reported here.

Is this part of the same problem or something else?

Thanks, Damien


#9

Hi, I use GSuite and I’m emailing from the Primary Domain and still getting this error. Has anyone using GSuite been able to resolve this? Many thanks for your help!


#11

Looks like the issue is SPF and DKIM records need to be configured in DNS. The G Suite Toolbox Check MX Tool https://toolbox.googleapps.com/apps/checkmx/ will check your domain and provide links to create the records for GSuite.


#12

@Marie I don’t think you are listening to your user base. Why not allow users to simply “whitelist” a domain alias if it suits their situation? Surely if the user whitelisted the combination of their “GSuite Domain + Domain Alias” that would overcome the security issues you are trying to protect them from? This is incredibly frustrating. The tool is amazing, but this ‘upgrade’ has in fact ‘downgraded’ the usability of the tool for those who use GSuite and multiple email addresses.


#13

Any updates here? In the process of implementing asana across a large company (which is already a struggle culturally), and this is REALLY not helping with morale.


#14

Wouldn’t it be easier if Asana users can add their alternative e-mail address(es) to their profile and/or whole domain’s to the company profile?


#15

any updates?


#16

We use automation services that do not allow us to configure this option… our systems are now broken.

This sucks :frowning:


#17

There is nothing with the SPF or email RFCs which states that envelope senders and from addresses must match and there are plenty of reasons why they would not match.

Why on earth has it been implemented this way?

Our system generates emails with differing From and Return-Paths because of how we handle system bounces vs legitimate replies. SPF is incidentally configured for both, and configured correctly (as is DKIM and DMARC) and we still fall foul.

What are our options?