Google apps + DKIM + shopify

Highlighted
Shopify Partner
5 1 4

I have the same issue. Any solution ?

0 Likes
Highlighted
New Member
7 0 0

Hi guys,

 

are you still struggling with DKIM / DMARC?

Today I set up my DNS settings for SPF, DKIM and DMARC for the domain of my first shop and apparently all checks succeed when I triggered an test order.

 

Currently I configured DMARC to use p=none (so that no action is taken when the check is failing) to only use rua/ruf mail addresses for monitoring because of all of the negative feedback here but I am wondering now why it seems to work for me ..

 

See for example the mail header of an order confirmation I tested today:

Authentication-Results: 
spf=pass (sender IP is 35.184.254.92)
smtp.mailfrom=****.shop; outlook.com; 

dkim=pass (signature was verified)
header.d=shopify.com;outlook.com; 

dmarc=pass action=none
header.from=****.shop;compauth=pass reason=100
Received-SPF: Pass (protection.outlook.com: domain of ****.shop designates
35.184.254.92 as permitted sender) receiver=protection.outlook.com;
client-ip=35.184.254.92; helo=smtp2.shopify.com;

Received: from smtp2.shopify.com (35.184.254.92) by
***.mail.protection.outlook.com (10.152.24.234) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.2979.27 via Frontend Transport; Sun, 10 May 2020 05:38:56 +0000


Or did I misinterpret something?

As I configured SPF / DKIM / DMARC there's also no black magic included.

 

Here are my DNS entries. I am using Microsoft 365 (Exchange) :

 

HostTTLTypePriorityValue
MX    
****.shop MX ****shop.mail.protection.outlook.com
SPF    
****.shop600TXT-spf1 include:spf.protection.outlook.com include:shops.shopify.com ~all
DKIM    
selector1._domainkey.****.shop3600CNAME selector1-****-shop._domainkey.****.onmicrosoft.com
selector2._domainkey.****.shop3600CNAME selector2-****-shop._domainkey.****.onmicrosoft.com
DMARC    
dmarc.****.shop3600TXT v=DMARC1; p=none; pct=100; rua=mailto:dmarc-rua-****@****.shop; ruf=mailto:dmarc-ruf-****@****.shop

 

Hope this helps.

 

Update:
Just tested again with dmarc p=quarantine on a few different addresses (GMX, private outlook.com, M365 Exchange) and the mails aren't getting blocked.

 

Best regards,
Maggi

0 Likes
Highlighted
Excursionist
24 0 20

@Maggi wrote:

Hi guys,

 

are you still struggling with DKIM / DMARC?

Today I set up my DNS settings for SPF, DKIM and DMARC for the domain of my first shop and apparently all checks succeed when I triggered an test order.

 

Currently I configured DMARC to use p=none (so that no action is taken when the check is failing) to only use rua/ruf mail addresses for monitoring because of all of the negative feedback here but I am wondering now why it seems to work for me ..

 

See for example the mail header of an order confirmation I tested today:

Authentication-Results: 
spf=pass (sender IP is 35.184.254.92)
smtp.mailfrom=****.shop; outlook.com; 

dkim=pass (signature was verified)
header.d=shopify.com;outlook.com; 

dmarc=pass action=none
header.from=****.shop;compauth=pass reason=100
Received-SPF: Pass (protection.outlook.com: domain of ****.shop designates
35.184.254.92 as permitted sender) receiver=protection.outlook.com;
client-ip=35.184.254.92; helo=smtp2.shopify.com;

Received: from smtp2.shopify.com (35.184.254.92) by
***.mail.protection.outlook.com (10.152.24.234) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.2979.27 via Frontend Transport; Sun, 10 May 2020 05:38:56 +0000


Or did I misinterpret something?

As I configured SPF / DKIM / DMARC there's also no black magic included.

 

Here are my DNS entries. I am using Microsoft 365 (Exchange) :

 

HostTTLTypePriorityValue
MX    
****.shop MX ****shop.mail.protection.outlook.com
SPF    
****.shop600TXT-spf1 include:spf.protection.outlook.com include:shops.shopify.com ~all
DKIM    
selector1._domainkey.****.shop3600CNAME selector1-****-shop._domainkey.****.onmicrosoft.com
selector2._domainkey.****.shop3600CNAME selector2-****-shop._domainkey.****.onmicrosoft.com
DMARC    
dmarc.****.shop3600TXT v=DMARC1; p=none; pct=100; rua=mailto:dmarc-rua-****@****.shop; ruf=mailto:dmarc-ruf-****@****.shop

 

Hope this helps.

 

Update:
Just tested again with dmarc p=quarantine on a few different addresses (GMX, private outlook.com, M365 Exchange) and the mails aren't getting blocked.

 

Best regards,
Maggi


 

 


@Maggi wrote:

Hi guys,

 

are you still struggling with DKIM / DMARC?

Today I set up my DNS settings for SPF, DKIM and DMARC for the domain of my first shop and apparently all checks succeed when I triggered an test order.

 

Currently I configured DMARC to use p=none (so that no action is taken when the check is failing) to only use rua/ruf mail addresses for monitoring because of all of the negative feedback here but I am wondering now why it seems to work for me ..

 

See for example the mail header of an order confirmation I tested today:

Authentication-Results: 
spf=pass (sender IP is 35.184.254.92)
smtp.mailfrom=****.shop; outlook.com; 

dkim=pass (signature was verified)
header.d=shopify.com;outlook.com; 

dmarc=pass action=none
header.from=****.shop;compauth=pass reason=100
Received-SPF: Pass (protection.outlook.com: domain of ****.shop designates
35.184.254.92 as permitted sender) receiver=protection.outlook.com;
client-ip=35.184.254.92; helo=smtp2.shopify.com;

Received: from smtp2.shopify.com (35.184.254.92) by
***.mail.protection.outlook.com (10.152.24.234) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.2979.27 via Frontend Transport; Sun, 10 May 2020 05:38:56 +0000


Or did I misinterpret something?

As I configured SPF / DKIM / DMARC there's also no black magic included.

 

Here are my DNS entries. I am using Microsoft 365 (Exchange) :

 

HostTTLTypePriorityValue
MX    
****.shop MX ****shop.mail.protection.outlook.com
SPF    
****.shop600TXT-spf1 include:spf.protection.outlook.com include:shops.shopify.com ~all
DKIM    
selector1._domainkey.****.shop3600CNAME selector1-****-shop._domainkey.****.onmicrosoft.com
selector2._domainkey.****.shop3600CNAME selector2-****-shop._domainkey.****.onmicrosoft.com
DMARC    
dmarc.****.shop3600TXT v=DMARC1; p=none; pct=100; rua=mailto:dmarc-rua-****@****.shop; ruf=mailto:dmarc-ruf-****@****.shop

 

Hope this helps.

 

Update:
Just tested again with dmarc p=quarantine on a few different addresses (GMX, private outlook.com, M365 Exchange) and the mails aren't getting blocked.

 

Best regards,
Maggi


 

Hi Maggi, we aren't struggling to set up DKIM/DMARC records. We've been waiting a decade or so for Shopify to add DKIM capability - that is, to allow us to generate DKIM keys signed with our own domain from within our Shopify store that we can then add to our DNS records. Shopify customers who didn't purchase their domains from Shopify are unable to do this.  We want our Shopify/store-generated outbound mail to be signed, and the signing domain to match the "from" domain in the mail headers.  This will improve deliverability, reduce the odds of our store emails winding up in SPAM or getting bounced, and also authenticates our emails so recipients know our email is legitimately coming from us. 

 

You want ALL emails representing your domain/brand to be fully authenticated, whether it's your Shopify store sending an Order Confirmation email, you replying to a customer's email, or sending out your Black Friday newsletter via SendGrid. To do this, you need a DKIM key and an SPF entry in your DNS records for every email service provider that sends email on behalf of your domain.

 

If every email sent from/on behalf of your domain includes a DKIM signature that matches the email's from address that matches against the sender info you've included in your SPF record and can be validated by one of the DKIM Keys in your DNS records, you have achieved what is called Full Alignment.

 

Your DMARC policy is a set of instructions for recipient mail servers, telling them what you would like them to do if they come across email purportedly from you but fails one or more of the above alignment checks. Setting up a DMARC policy in your DNS is like installing an alarm system in your home. This is a powerful tool that can block phishing and malware email masquerading as you, and increases mail servers' trust in your domain email.

 

In a similar fashion, an alarm system can thwart burglaries or even notify the authorities there's been a break-in attempt - but only if the system is activated, and activated properly.  Having the system off or in test mode is the equivalent of DMARC's policy "p=none". This is for monitoring only, for use while setting up and testing your DMARC policy before running it live. Mail servers will send a report to the RUA/RUF addresses listed in your DMARC policy if it comes across email failing alignment. This will give you a good idea of how well your SPF & DKIM records are working. If you start getting flooded by email reports of your legitimate emails failing authentication, you'll know your authentication setup isn't ready for primetime. "p=none" doesn't affect your mail deliverability one way or the other, but it also doesn't tell mail servers how to handle your emails that fail authentication. Leaving a DMARC policy set to "p=none" provides no security whatsoever, like installing an alarm system but never enabling it.  Since Shopify doesn't allow us to implement DKIM keys for our stores, "p=none" is the only DMARC policy we can safely use.

 

"p=quarantine" is phase II of implementing your email security policy, best put into action after you've repeatedly tested your DMARC policy under "p=none" and made the necessary adjustments that have ended the false-positive RUA/RUF reporting emails. With "p=quarantine", mail servers will continue to send you RUA/RUF reports of unauthenticated emails from your domain. Additionally, mail servers should complete delivery of unauthenticated emails - albeit to the recipient's SPAM/junk folder. Note: this also includes phishing emails or other fake emails winding up in the SPAM folder. Emails that pass authentication should go to the recipient's inbox as usual. 

 

"p=reject" is phase III, the goal of implementing DKIM/SPF & DMARC policy. In addition to the RUA/RUF reports sent to you, 'Reject' instructs mail servers to refuse/reject email purportedly coming from your domain if it fails authentication. Authenticated emails should go to the recipient's inbox as usual. This should thwart Spammers using your good (domain) name to send out malware, spoofs, etc. They will continue to try it, but since you have an ironclad SPF and DKIM setup and a DMARC policy telling mail servers to reject anything that doesn't seem legit, you're protecting your customers and your brand from abuse.

 

It's also worth noting that a DMARC policy is a REQUEST or a suggestion; mail servers are not required to follow the parameters in a DMARC record. This means that it's possible for email failing authentication with the policy of "p=reject" or "p=quarantine" can wind up in the Inbox, SPAM, or rejected. If a mail server has low or high confidence in your domain, or you have a long history of safely emailing your recipient, their mail server can override your published DMARC policy.  This explains how you could implement a policy of Quarantine or Reject, but your alignment failing email still get delivered to the Inbox.  If you check the email headers closely, you are likely to see terms like DKIM=FAIL, SPF=SOFTFAIL DMARC=FAIL, etc. Basically, your email should have wound up in SPAM (or been rejected), but the mail server had enough confidence to feel the email was legitimate, despite failing authentication. 

 

Say you identify all the ways you use yourdomain.com to send email. You use Outlook365 with yourdomain.com as your email provider, Shopify for your store at yourdomain.com, and SendGrid for yourdomain.com's bulk mailing needs.

Office365 supports SPF & DKIM

SendGrid supports SPF & DKIM

Shopify only supports SPF

Your SPF record includes Office365, SendGrid, and Shopify. You have DKIM keys for Office365 and SendGrid.

 

If you attempt to implement a DMARC policy, you'll get stuck with an either/or situation.

"p=none": mail servers attempt to authenticate your emails using SPF & DKIM, but decide what to do with your unauthenticated email based on their own policies. When you send email via Office365 or SendGrid, the email is fully aligned (SPF pass / DKIM pass). If Shopify sends an Order Confirmation email for your store, it will be considered partially aligned (SPF pass / DKIM fail) as there is no DKIM signature/key combo to validate Shopify sending for yourdomain.com.

 

"p=quarantine": mail servers attempt to authenticate your emails using SPF & DKIM, and are most likely to take action on unauthenticated emails based on your DMARC policy of "p=quarantine". When you send email via Office365 or SendGrid, the email is fully aligned (SPF pass / DKIM pass). If Shopify sends an Order Confirmation email for your store, it will be considered partially aligned (SPF pass / DKIM fail) as there is no DKIM signature/key combo to validate Shopify sending for yourdomain.com, and most likely will wind up in the SPAM folder.

 

"p=reject": mail servers attempt to authenticate your emails using SPF & DKIM, and are most likely to take action on unauthenticated emails based on your DMARC policy of "p=reject".  When you send email via Office365 or SendGrid, the email is fully aligned (SPF pass / DKIM pass). If Shopify sends an Order Confirmation email for your store, it will be considered partially aligned (SPF pass / DKIM fail) as there is no DKIM signature/key combo to validate Shopify sending for yourdomain.com, and will most likely be rejected or wind up in SPAM. 

 

 

In conclusion: Shopify does not support DKIM authentication, so the best we can get is partial alignment for Shopify store-related emails. This sucks, because implementing a DMARC 'Reject' policy is best for improving deliverability, confidence, and email security...but requires full alignment. Therefore, a Reject policy is not wise, as the risk of our store's emails winding up in SPAM/rejected is too great. Not only that, but it looks unprofessional and doesn't help our sending reputation if our store's emails aren't consistently delivered. The same holds true for a Quarantine policy.

 

The best chances we have of consistent deliverability is to implement a useless policy of "p=none", but this does nothing for email security or improving deliverability.

 

"p=none": most consistent in terms of delivery --> but no added security, no reputation improvement, no deliverability improvement

"p=quarantine/reject": overall the most secure, best to increase deliverability, and best way to improve domain's reputation --> but hurts the deliverability of our store's emails and looks unprofessional.

5 Likes
Highlighted
New Member
2 0 0

+1 for this this as an essential feature. 

 

Our shop relies largely on draft order invoices being generated and emailed to the customer for payment.  Obviously if they invoice goes to spam, they don't see it and they don't pay it.  

0 Likes
Highlighted
New Member
1 0 0

We are also having big time trouble loosing e-mail reception and reliability to this issue that Shopify does not resolve.
There is thousands of customers complaining about not getting certain e-mail notifications.

It is clear and obvious that Shopify will not implement DKIM keys, so...

Here is our solution to this:

We will migrate everything away from Shopify slowly but surely.
Our advisors are informed about this and they are as well tending to push their customers away from Shopify.

Thank you all in this thread for this very clear and precise discussion and specially THANKS TO Tara6, who gave an incredibly good summary on what it is all about.

0 Likes
Highlighted
New Member
2 0 0

+1 I think being able to set DKIM keys for domains that are not managed by Shopify is essential.

I would like to set up full alignment DKIM on my shop domain since a very long time, and the fact that Shopify does not support it is pretty disappointing.

Shopify please allow us to set a DKIM private key for linked domains.

0 Likes
Highlighted
New Member
2 0 0

Hi Daniel,

It is 2020 now... so 4 years passed. Any news on adding DKIM support for connected domains? I think it is a fairly important feature.

Regards,
Piotr

0 Likes