Whitelabelling is essentially the act of removing the vendor-specific information from emails so that the authentication ties together to give a DMARC pass.
You can think of it like branded items within a supermarket, in that some will be clearly identifiable from an organization such as “Daisy’s Farm Cheddar”, whereas others have this information removed like “Supermarket Value Cheddar”.
How does this tie into Email Security?
DMARC is the key to email security and whitelabelling is an essential component of this. For your emails to pass DMARC, the email must first pass either SPF or DKIM protocols. The domains used in those checks must then align with the “From:” (The main sending domain that the user will see).
In an email, whitelabelling is either changing the “Return-Path” (the domain against which SPF is checked against), or “DKIM Signing Domain” (the domain where the public DKIM key is stored) of the emails so that they point to your DNS rather than that of the vendor. This effectively removes the brand information from the authentication.
By whitelabelling the email, you therefore change the relevant information from “Emailprovider.com” to “Yourdomain.com”, and you will get a DMARC alignment pass, provided the “From:” was “Yourdomain.com”.
So, where’s the problem?
While many sending services support whitelabelling, either by having the user add the DNS information in the initial set up or if it can be enabled separately, not all sending services do. Some of these sending services do not give you any options to make your emails DMARC compliant, meaning that whatever domain these emails are sent from cannot be moved into a DMARC reject policy. By using email services that don’t support whitelabelling, you are therefore leaving your domain open to the threat of imitation and spoofing attacks.
What can I do?
Our advice is simple: Only use services that support DMARC-compliant authentication.
Although different setups and circumstances may provide barriers for you to do this, such as current partnerships or existing contracts forcing you to use a certain service, when this is not the case, it is better to utilise a service that will allow you to enable DMARC protection.
How can I know if a service supports whitelabelling?
This is the tricky bit as not all senders use the same terminology, whilst some may support the feature but with minimal documentation to help you. The best thing is to ask when you’re trialing a new email sender – just make sure to email support or use the live chat to ask the following question:
Will my emails sent on behalf of mydomain.com support DMARC compliant authentication?
Their response will point you in the right direction.
What if I’m already with a sender that doesn’t support whitelabelling?
Our advice for protecting yourself while using sending services that don’t support whitelabelling would be:
Option 1
Relay the traffic through a gateway that supports DKIM signing.
Option 2
Separate the traffic off to a subdomain. Your traffic will remain unauthenticated but the separate subdomain can have its own DMARC policy. This means you can still protect thetop-levell domain and other subdomains.
Option 3
Change the “From:” to that of the service provider. This will not assist in authenticating the traffic but it will mean the traffic follows their DMARC policy instead of yours. The benefit of this is that you can now work on the remaining services and get to a protection policy, but do be aware that you will lose visibility on the traffic.
Option 4
Change providers! At the end of the day, keeping both yourselves and customers secure is the main priority. If a sending service is preventing you from reaching a policy of p=reject, then they are not providing a safe and reliable service.
Make sure you use OnDMARC’s Knowledge Base to first check your sender against our extensive list of over 400 sending services, or contact us below where we’ll be happy to answer any questions you may have about email security.
