DMARC fail

[sqr]

Regarding a domain.square.site (i.e. Weebly), I can't seem to find any supporting documentation explaining the needed DNS changes so that mail sent from there doesn't go to Spam. This involves SPF and DKIM (which according to headers inexplicably do pass, but shouldn't be absent the DNS changes), and DMARC (which does not).

Order emails go "to" the Weebly "Owner" account and come "from" the email listed in Store Information. That "from" address is one of ours, of course, and since emails are being sent from another provider (Weebly uses SendGrid), that's considered spoofing the sender, and such mails go to Spam.

I could go into further details, but I'd just like to be pointed to where what I'm discussing is explained. It must be somewhere, since I see no option of NOT sending "from" one of our addresses as opposed to one of yours (with some exceptions, like the Contact Form).

I don't want to contact support about this since this should be a public discussion to at least get something on this topic into the record.

[AdamB]

Welcome to Seller Community and thanks for your post, @sqr.

We don't currently have any documentation specifically about adding a SPF and DKIM records to your domain. For the former, this usually works for most domains:

v=spf1 a mx include:_spf.google.com include:sendgrid.net ~all

I have Google in the record because so many people use G Suite for their domain email.  If other sellers have set up SPF and DKIM records I'd love to see what they are using, though!

[sqr]

Sure, I can try adding the Sendgrid part tp SPF, but I hadn't tried that before because the header shows that it's already passing, even though that should be impossible:

Authentication-Results: spf=pass (sender IP is 167.89.70.168)
smtp.mailfrom=promote.weebly.com; ourdomain.ca; dkim=pass (signature was
verified) header.d=weebly.com;ourdomain.ca; dmarc=fail action=none
header.from=ourdomain.ca;compauth=fail reason=601

I don't know if you have access to an Order email, but I'd love to see your pass/fails for those three. Normally, only SPF *or* DKIM need to pass for DMARC to pass, so that's why I'm doubly confused by the above.

[sqr]

Tested, and it made no difference.

[sqr]

Maybe this is something for the Weebly side. I guess I'll try there, though they'll say to try here.

[AdamB]

They shouldn't need to pass you back here since this is definitely a question that falls within the Weebly realm. They might need to escalated this to their Advanced Support team for further investigation.

[sqr]

I called their support and spoke to someone who was definitely not Advanced, but it was as far as I could get. She would put me on hold and talk to "engineers" herself. That went back and forth a couple times, like I was a customer in a used car dealership, but the end result is that she was told that they don't yet support delivering customer's emails in the correct way to avoid this problem but will take it as a feature request.

I don't believe it, but I did get a fantastic deal on the undercoating.

[pettytheft]

What is the status of correcting this?????  I can’t not believe in 2022 this HAS STILL NOT BEEN FIXED!

Until Square/Weebly support properly reviews and supports ALL CUSTOMER EMAIL WILL continue to fail and customers will NOT receive their Order confirmation emails or any other emails.  IT WILL NEVER WORK

We need the proper SPF entry to add for Square to authenticate sending email as our custom domain.  OTHERWISE IT IS THE SAME AS ALL SPAM SENT 

https://docs.sendgrid.com/ui/account-and-settings/spf-records

PLEASE TAKE THIS SERIOUSLY.

[sqr]

@pettytheft 

Who knows, but I found this thread, which is interesting:

https://community.weebly.com/t5/Domains/I-need-to-add-and-SPF-records-and-a-DMARC-record/m-p/244084#...

As you can see there, I once again struck out with support. Maybe you'll have better luck. I hope the person in the thread responds though.

It's interesting that until recently we apparently could have taken care of this in that forum....

[pettytheft]

Until Square support properly reviews and supports this will continue to fail and customers will NOT receive their Order confirmation emails.

We need the proper SPF entry to add for Square to authenticate sending email as our custom domain.

https://docs.sendgrid.com/ui/account-and-settings/spf-records

This is a SQUARE SUPPORT issue.

[sqr]

Yes, and good to see some notice of this thread. It's mystifying how this apparently is still a thing, though I'm not excluding the possibility of some action on this somewhere in the last several months since I haven't been pursuing it in that time.

[sqr]

Just to update, I spoke with Square's critical partner when it comes to sending emails (SendGrid) about this, and after looking at one of the email headers in question they said:

"They'd [Square] have to authenticate the domain in our [SendGrid] platform and provide you [the customer] the records, so you [the customer] can post them in your DNS host."

So, nothing shocking there. It's just that Square never set things up to be able to actually generate those DKIM records to be able to provide to us (or any other Square customer--this problem is not unique to us). This should be a self-service section of Square's site. I put in a feature request with Square about this, so maybe one day.

Until that happens, this problem is doomed to repeat ad infinitum for anyone using Dmarc, which I'm thinking is a lot of customers.

[IVOCAN]

We also have noticed the same problem that both merchant and customer emails are failing at DMARC and despite best efforts to populate what we think are the right values in SPF messages continue to get diverted to SPAM.

Has anyone had success with this?

Also can anyone confirm if this is isolated to aliases at Google Workspace only, or does it also affect regular mailboxes as the sender?