White Labeling DNS Records For Your Customers – Tips And Tricks

Many of our customers run large-scale digital marketing applications on top of Mailgun for their own customers. For example, Vero and Userfox are email service providers that built their awesome digital marketing automation apps on top of Mailgun — we’re their white label partner. Their customers might not even know that their private label is built on top of Mailgun, and that is fine for us! 

White label products and solutions are common in just about any market, from emails to grocery stores, and it’s easy to see why. Having another company provide a robust infrastructure and back-end to build on allows you to focus more on your company’s brand, products, and business, rather than building a complex solution in-house. It’s exactly like when a store brand uses the same generic product produced by a generic brand, just under their own label. Plus, it’s cost-effective to use a white label service, and everyone loves saving money.

We want our customers to control the relationship with their own customers via their brand name, not ours.

That means providing a variety of white label solutions to better utilize our services under their own branding. In doing this, when a customer searches for something related to their own product in a search engine, companies like Vero and Userfox pop up as a result, and not Mailgun. Which brings us to today’s tip.

White labeling SPF records

SPF stands for Sender Policy Framework. It is a method to prevent sender address spoofing by verifying sender IP addresses. Basically, when a sender adds an SPF text record to their domain (say, example.com), they are authorizing an email service provider, like Mailgun, to send emails from @example.com. Non-authorized IPs will not be permitted to send from @example.com. Without this record in place, receiving ESPs like Gmail and Yahoo are more likely to flag the email as spam.

An SPF for Mailgun record looks like this

v=spf1 include:mailgun.org ~all

Notice that the record includes mailgun.org. Some application providers don’t want to expose to their own customers that they are using Mailgun via this SPF record. And they don’t have to thanks to SPF record chaining.

An example of SPF record chaining

Imagine you’ve built the world’s most awesome CRM system — awesome-crm.com — and you allow your customers to email their contacts directly through your system. You want them to be able to white label their own emails so that they use their own domain instead of awesome-crm.com for sending. Easy. You can just create a custom domain for them in your Mailgun account and provide your own customer an SPF string that includes awesome-crm.com instead of mailgun.org. At the same time, you will set up your own SPF record that points to mailgun.org, it’s like a chain.

Assuming your customer owns example.com:

• TXT record for example.com:

   v=spf1 include:awesome-crm.com ~all

• TXT record for awesome-crm.com:

   v=spf1 include:mailgun.org ~all

And there you have the end product! The transitive property means that your customer’s SPF record points to Mailgun, even though they think it is only pointing to you.

PROFIT!

Happy emailing,

The Mailgunners