Email Authentication based on Client Domain

[james35]

We want the FROM address set to our domain so that 'via Shipstation.com' does not appear on gmail. We also want to include your spf/senderId records in our spf/senderId records, have the email signed with our DKIM key and have the links use our subdomain instead of email.shipstation.com. Here's how this works on a few of the major ESPs: http://login.mg2mail.com/help/Content/Listrak_Manual/Branding%20Settings.htm https://mandrill.zendesk.com/hc/en-us/articles/205582387-How-to-Set-up-Sending-Domains https://sendgrid.com/docs/Glossary/email_authentication.html This will significantly improve deliverability and professional appearance. Best Regards, James Fredley VP of Marketing Technology FilterEasy

[dochin]

It looks like the other thread on this topic is locked.  Shipstation responded in May 2021 they're working on it.  Any ETA update?

[steve72]

Seriously Shipstation. How has this problem not been resolved?! The workaround to remove email address is not acceptable. Now the tracking emails come from shipstation.com and if the customer replies to that email they get a bounce back. Looks super unprofessional.

@SuperMgr-Sarah

[sales3]

It's been 6 years and we're still sending tracking numbers that are marked as spam. SPF and DKIM for shipstation's domain doesn't help us when the email is still "from" our own email address.  I would be happy with a from of "noreply@shipstation.com" and the the ReplyTo is our email - that alone would be an improvement for getting through spam filters.

[john16]

It seems that ShipStation is counting on this problem somehow resolving itself if ignored for long enough? C’mon. This is crazy. Fix it please… every other notification software we use has this capability.

[shipper7]

This would be very useful to not have the emails come from shipstation.  Any word on the progress of this proposal?

[info319]

We've been trying the suggested solution of sending from tracking@shipstation.com. But customers have still reported their tracking info going to spam, or not receiving it at all. I got curious and looked up ShipStation's DMARC records on Easydmarc:

https://easydmarc.com/tools/domain-scanner?domain=shipstation.com

Follow that link and you'll see at this time they get a 4/10 score, mostly because their DMARC is set to p=none. That means that scammers can send fake shipstation.com tracking emails with inpunity. No wonder our legit tracking emails are ending up in spam folders!

[am2]

We had to re-enable sending from tracking@shipstation.com (by removing our verified email from the store settings).  Ultimately as Shipstation haven't taken (or implemented this properly) email security seriously we had to fall back to using the shipstation default address as the risk to our own domain spam scores was significant.  

DMARC and SPF are industry standards...use them.

[thibaut]

This feature is critical for us as well!

It does not make any sense that the only available solution to make sure emails are delivered is to remove our own verified email address and re-enable emails being sent with tracking@shipstation.com.

We have been told this feature is being looking into but it seems it has been the case for more than 6 years now.

When can we expect a feature allowing us to send shipment notifications with an email address from our own domain?

[Shipping55]

I raised this again with support with their answer from “engineering” to use a none DKIM enabled email domain like gmail”

WTAF is that about? Here’s a corporate shipping tool saying sorry we let you you use your own from address but we can’t support the proper features so your domain is safe. It’s total crap it’s almost 2023! Active campaign, mail chimp, etc all support This. Either add this option OR the use of my own smtp sending servers now!

sounds like others I’ll have to drop the custom from address basically forever because they don’t seem to this this is a priority.

[GoFishMedia]

Good point @Shipping55! Providing SMTP access would work but without the necessary infrastructure or the willingness from all parties involved I am afraid that we are left with few other options.

I am not an expert on DMARC, SPF or DKIM and I welcome any knowledgeable person to correct any mistakes that I may make in my following statements:

Everyone, check out their DMARC policy:
easydmarc.com/tools/dmarc-lookup?domain=shipstation.com

v=DMARC1; p=none; pct=100; fo=1; ri=3600; rua=mailto:44bdd8b1@inbox.ondmarc.com,mailto:dmarc@shipstation.com; ruf=mailto:44bdd8b1@inbox.ondmarc.com;

Their policy is to take no action against non-authenticated emails. This tells me that they may have similar issues to what we have with services that they use, but their issue could always be somewhere else.

Now take a look at their SPF Records to find what services that they use to send their 3rd-party emails:
easydmarc.com/tools/spf-lookup?domain=shipstation.com

v=spf1 include:_spf.google.com include:smtp1.uservoice.com include:mail.zendesk.com ~all

You can also check the SPF records of their 3rd-party services, in bold above, to further investigate the issue.

Now check out this site that lists whether or not certain 3rd-party services are DMARC compliant:

dmarc.io/sources

We can see that they are not DMARC compliant and their 3rd party services are compliant except one. I suspect if we knew which service they used for sending our emails and investigated their 3rd-party service's 3rd-party services (and so on), along with how those services can implement DMARC compliance, some light may be shed on where the true issue may lie.

If emails are sent with google, DMARC compliance is possible but, again, would require a system and infrastructure to be implemented that is compatible with your system. Two possible systems are where either we give them access to our email servers, like @Shipping55 mentioned above, or where they can provide us with a public DKIM signature so we can add another DKIM record with a custom selector in our DNS settings.

This seems like a great business opportunity for someone to solve this problem for 3rd-party services that are unwilling or unable to provide DMARC compliance to their customers!

Sorry for the long winded post. I am sure a lot of you already knew this but I hope that I have at least provided some of you with valuable information for further research.

Good luck to on the journey to DMARC compliance!