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:
Please make sure emails are sent from your primary G Suite domain, not an alias
If you’re using Google Forms: Please make sure to use to use the Google Forms integration we recommend in our Guide (Web Forms & Asana • Asana Product Guide) as other integration may not work.
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 (Asana Support - Help Center • Asana) who will be able to assist you further.
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.
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.
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.
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.
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: Send emails from a different address or alias - Gmail Help
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: Change your primary domain for Google Workspace - Google Workspace Admin Help
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?
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!
Looks like the issue is SPF and DKIM records need to be configured in DNS. The G Suite Toolbox Check MX Tool Check MX: Check MX and SPF Records. will check your domain and provide links to create the records for GSuite.
@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.
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.
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.
I’d surely say this security update is not doing any good for the Asana community. Many frowning faces up here… The following is a part of parsed info of incoming emails received by GMail from SendGrid on behalf of one of our servers.
SPF: PASS with IP xxx.xxx.xxx.xxx
DKIM: 'PASS' with domain ourdomain.net
DMARC: 'PASS'
Everything is legitimate, all checks pass, but Asana rejects this email because SendGrid’s envelope-from email address is something other than the from email address.
It used to work though, even months after the alleged update - for us, most recently on 08/08/2018 , that’s 5 months after this post was created (and thus certainly had to be after the update was implemented in its initial form).
The community has proposed solutions to this ridiculously strict policy you’re pursuing. A lot of people don’t even have access, nor can influence the envelope-from sent by their outgoing servers or services. It may not affect only all of the “private” outgoing email servers, you’re forcing the email sending services to allow such modifications… which I presume not all of them have implemented.
Let me outline the possibilities:
SPF passes: Asana should accept the email and ignore the envelope (SPF does the security for you)
domain whitelisting: @sendgrid.netenvelope-from email is allowed for @ourdomain.netfrom email
IP based whitelisting: if the email sender’s IP is whitelisted for me, allow it
if all else fails, your implementation (same envelope-from and from emails) allows the email
Please keep us in the loop! If this is something you can propose for your development team to implement, we’re all for it If not, can you direct me to the right place where one can propose a change request?
Welcome to the Forum @Damijan and thank you for sharing this detailed feedback with us; I can appreciate this is not an easy situation.
While I’m not replying to every comment, rest ensured that I’m keeping a close eye on the situation and will make sure to update this thread as soon as I have an update on our end. While I don’t believe we’re planning to make any changes to this process in the near future, we will keep the options you have outlined above, for future improvements.
If you’re still running into trouble following this update, please reach out to our support specialist who will be able to provide you with a more tailored assistance. To reach out to our support team, simply follow the steps in this post.
Is there a workaround for Office 365 yet? Seems some of our webmail users are running into this problem, even though when I analyze their headers, they match Sender to Return-Path.
If not, can you direct me to the right place where one can propose a change request?