There’s a use case that we see developers implementing or asking about frequently, especially when building B2B apps. The service wants or needs to send emails on behalf of their customers. The sender wants these emails to appear as if they are coming from their client rather than the service itself.
For example, consider a service that manages bookings for hotels. Each hotel wants to send updates, via emails generated by the booking service, to the people who are making the transactions. The end-user doesn’t even know that the booking service is involved, and both the hotel and the service provider want to keep things that way.
In the past, this hasn’t been a big problem. The service provider would just set the “from” address to the customer’s email address and send the email. This email might be hosted on the customer’s domain (e.g. example.com) or it might be an outlook.com or gmail.com address. But there’s a big imminent problem with this use case because it's going to stop working entirely no matter what ISP you are sending to.
Why? It turns out that sending email from a domain that you don’t control is a tactic employed by spammers and especially by phishers. If a phisher is going to successfully convince someone to click the link in their fake eBay password reset email, they need to make that email look like it’s coming from eBay.
That’s where DMARC comes in. We won’t go into how email authentication works here, but the short version is that DMARC allows the owner of the domain to decide what receiving email servers should do with messages that appear to be from that domain, but are not.
If you’re sending from gmail.com, outlook.com, or some other third party domain that neither you nor the customer on whose behalf you’d like to send control, I have bad news. You’re going to have to find a new way. Starting very soon, those messages are never going to get delivered. Both Google and Microsoft are planning to implement this policy very soon, and Yahoo has already made the change.
If you’re sending on behalf of a domain that your customer controls, you have more options. You can ask the customer to alter their DNS records. They’ll need to add both SPF and DKIM records that effectively say “allow the server with the IP address of xx.xx.xx.xx to send emails that appear to originate from example.com.”
If you have sophisticated clients, this might not be that difficult. But if you have to explain what DNS is, help the customer find out what their current registrar is, and how to make those updates, you have to be prepared for a good amount of support overhead. We know this from our own personal experience when we ask customers to complete sender authentication for their SendGrid accounts.
Another possibility is to resell DNS services in addition to the email service that you’re offering. In this case, you’ll be able to update the records directly for the customer, even via an API if you choose a service like DNSimple. Of course, if your customer already has a website and domain, migrating things over will still require support overhead.
Although we don't know when the Gmail and Microsoft will officially stop allowing third-party sending without domain control, it's best to prepare to keep your delivery rates as high as possible. For more insight on how to reach the inbox, check out our 2022 Email Deliverability Guide.
