Hi! For your emails to pass your DMARC policy, only SPF or DKIM needs to pass. Having said that, we should be passing both. On initial read, it looks like this may possibly be an issue with with the reporting you’re receiving, but I’d want to rule that out and I am happy to troubleshoot this with you. If you’ve setup our authentication records, the SPF check should be on a unique subdomain of your domain (will look something like mailer_xyz.yourdomain_.com) that we’ve created and managed, that should be counting towards passing your DMARC policy.
Can you let me know which mail provider you are using to send yourself test emails (i.e. are you sending test emails to a Gmail account? Outlook account?)? Asking so that I can walk you through examining the live email headers to see if they are passing or failing your DMARC policy.
Hi SGM411, thank you for reaching out. Do you have a DMARC policy in place yet? If you’ve authenticated and have a DMARC policy in place, you should have not experienced any changes to how your emails are being sent out. None of our merchants should be experiencing emails not being sent from our platform under any circumstance. I can look into your shop specifically if you can share the Primary for Online Store domain listed under /settings/domains.
starting Jan 24 (we made zero changes on our end): our customers getting confirmation emails from store@shopifyemail.com
so much for telling us Feb 1 was the deadline when y’all actually flipped the switch without telling us or giving us any warning on Jan 24…
chatting with support is a total waste of time
can’t find anywhere published on shopify support pages where shopify admits they only support 1024 DKIM
can’t even get a straight answer on shopify SFP record…what is it?
p.s. advising folks that either SPF or DKIM is irresponsible and it also doesn’t follow any of the outside-source support links that shopify’s support pages link to
Thank you for sharing this. Glad to see that in your tests that everything seems to be passing when you check the headers. Mailbox providers check the SPF record against the Return-Path domain, not the sending IP. However, if it’s important for you that the reports are showing a pass (will not have any impact to your actual email deliverability), you may be able to achieve that by added include:sendgrid.net (instead of include:mailer.shopify.com). Let me know if that works!
That there is a DMARC policy that passes verification checks (i.e. check your DMARC record using a free tool) on yourdomain.com
One of those 4 CNAME records we ask you to input will create a subdomain such as mailer123.yourdomain.com and we manage the SPF record on that so it passes the DMARC policy you set for yourdomain.com. So no additional SPF record needs to be setup or managed for yourdomain.com unless your other email providers (i.e. Klayvio, Google Workspace, etc.) require that you do.
I’m surprised that the support did not know anything about what is the correct spf record. They even suggested to remove the entire record, which is wrong and could cause issues.
are you sure that you verified the records in shopify. coming from mailer shopify is usually a sign that dns was not setup and that domain was not authenticated?
yes that looks good. instead of a test email, if you go to website and reset password do you also get it sent from mailer shopify? also, can you double check that your from email address in shopify settings → notifications → from is the same domain as what you worked on for dns?
I went through customers section in the notifications and sent emails to my test emails and they are from the correct sender email that is shown in the settings → notifications → Sender email.
It is still puzzling why the spf report records show fail, but the spf in the actual email shows success.
Yes, authentication was already successful and in place prior to shopify “flipping the switch” on Jan 24 instead of Feb 1 like they had told us (see our prior messages about how shopify started sending from store@shopifyemail.com on Jan 24 even though we had our own email in place w/successful authentication and it had been working perfectly up until Jan 24…when shopify pulled the rug out from under us with zero notice…shopify had been telling us feb 1 was the deadline but apparently y’all did it on Jan 24 as another “surprise” update without telling us, your paying customers, and leaving us over a barrel…still haven’t gotten any explanation let alone apology and especially recompense for this…totaly fail, shopify…total fail
we’ve got everything in place to deploy our DMARC EXCEPT for shopify’s spf record – can’t get a straight answer form support and even shopify’s comments here in community are contradicting and misleading. Is shopify’s SPF record mailer.shopify.com or spf.constantcontact.com or both…and/or additional IP addresses? We’re guessing y’all are still guessing…telling folks one thing and then when that doesn’t work or doesn’t work completely, adding more (but in the meantime, leaving customers in lurch yet again while we search for answers). Super disappointed in shopify’s support pages and support staff chat on all this – definitely shows shopify not ready and using customers as guinea pigs (yet again). Will you answer our question about SPF and also update your support pages with this info?
The spf policy in DMARC record is set to strict - aspf=s. Thus the identifier header and the spf domain should match for the spf policy to pass.
Looking at the DMARC records, my identifier is .com, while the spf domain is mailer1ud..com. Thus the failure of the spf policy.
In my DNS records, I have a CNAME mailer1ud with value .p112.email.myshopify.com, that is automatically created by shopify when the domain was linked and auth to the shop. I suspect this is what is causing the spf domain to show as mailer1ud..com.
I’m not sure how to fix that, unless I change the spf policy in the DMARC to relaxed.
@juenology is there a way for the MailFrom Domain to match the Header From Domain?
Coz all mails sent from shopify have the
MailFrom Domain: mailer1ud..com
Header From Domain:.com
Meaning we can’t use aspf=s, but only aspf=r in the DMACR record.
I spent 3h with the GoDaddy support and they say its not possible on their end. Took them 2h to understand the issue. Support is getting rly bad these days.
Imo, all these things needs to be documented by shopify, instead of everyone figuring it out their own.
