whitelabeling-spf-dkim

How whitelabelling boosts your email security setup

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. 

PUBLISHED BY

Joshua Harris

30 Jun. 2020

SHARE ARTICLE:

Categories

Recent Posts

VIEW ALL
Certificates

TLS certificates are changing: What you need to know

Red Sift

Executive summary: TLS certificates are about to get significantly shorter-lived. Starting 15 March 2026, newly issued public-trust certificates will max out at 200 days—and just three years later, that lifespan drops to 47 days. Backed by Google, Apple, and Mozilla, this shift aims to make the web safer through fresher data, faster failover, and…

Read more
DKIM

The hidden threat: How misconfigured DKIM enables replay attacks

Red Sift

Email authentication isn’t just an IT concern. It protects your brand and customers. A single misstep can let attackers spoof your domain, send phishing emails, and destroy customer trust. One of the most dangerous methods? The DKIM replay attack. In this post, we’ll break down how undersigned DKIM keys and related misconfigurations open your…

Read more
BIMI

Why DMARC and BIMI are a business priority

Jack Lilley

Email threats aren’t slowing down, and neither should your authentication strategy. In our recent joint webinar with Marigold, “From DMARC to BIMI: Navigating the New Email Authorization Landscape,” we broke down what today’s evolving standards mean for both security and marketing teams—and how to take action now with our free Red Sift Investigate tool.…

Read more
ASM

Zoom stops zooming: Why active monitoring is essential

Billy McDiarmid

​On April 16, 2025, Zoom experienced a significant global outage that disrupted video conferencing services and access to its website for thousands of users, as well as their corporate email for all their employees. It was quickly identified as a domain name registration status problem. Despite being a critical name for Zoom, somehow, the…

Read more