19 July 2026 · DMARC Engine · 38 min read
Introduction to Email Authentication for Multi-Brand Companies
Email authentication is a critical aspect of email deliverability, particularly for multi-brand companies that rely heavily on email to communicate with their customers, partners, and stakeholders. The process of email authentication involves verifying the identity of the sender to prevent spam, phishing, and other types of email abuse. For companies with multiple brands, implementing email authentication protocols such as DMARC, SPF, and DKIM can be a complex task, requiring careful planning and execution to ensure seamless communication across all brands.
To illustrate the complexity of email authentication for multi-brand companies, consider a scenario where a company, let's call it "Example Inc", owns several brands, including "Brand A", "Brand B", and "Brand C". Each brand has its own website, email marketing campaigns, and customer engagement strategies. Without proper email authentication, emails sent from these brands may be flagged as spam or rejected by recipient mail servers, resulting in lost business opportunities and damage to the company's reputation.
For instance, if "Brand A" sends a marketing email to its subscribers, the recipient's mail server may check the email's SPF record to verify the sender's identity. If the SPF record is not properly set up, the email may be rejected or flagged as spam, even if it is a legitimate email. A typical SPF record snippet may look like this:
v=spf1 a mx ip4:192.0.2.1 include:_spf.example.com -allThis record specifies the IP addresses and mail servers that are authorised to send emails on behalf of "Brand A". However, if "Brand A" uses a third-party email service provider, the SPF record may need to be updated to include the provider's IP addresses, adding an extra layer of complexity to the email authentication process.
DKIM is another email authentication protocol that uses digital signatures to verify the authenticity of emails. A DKIM signature is added to the email header and contains a unique key that can be verified by the recipient's mail server. For multi-brand companies, managing DKIM keys and signatures can be a challenge, particularly if each brand has its own email infrastructure. A sample DKIM record may look like this:
k1._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+yt4roVMLw9mMqSsJNbXHj1HJH8HnK79HxQjNVpN3Q2Z7T8Q8w9T5kP4O9V6YH6QJ4r2JzHTirxQj2qnVH3Qj2nJH8HnK79H"This record specifies the DKIM key and selector for "Brand A", which can be used to verify the authenticity of emails sent by the brand.
DMARC is a protocol that builds on SPF and DKIM to provide an additional layer of email authentication and reporting. It allows email senders to specify which email authentication protocols to use and how to handle emails that fail authentication. For multi-brand companies, DMARC can help to prevent email spoofing and phishing attacks, while also providing valuable insights into email delivery and authentication issues. A sample DMARC record may look like this:
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1"This record specifies the DMARC policy for "Brand A", including the reporting email addresses and the percentage of emails to which the policy applies.
In the context of multi-brand companies, email authentication protocols such as DMARC, SPF, and DKIM require careful planning and execution to ensure that all brands are properly authenticated and that emails are delivered to the intended recipients. This involves setting up and managing multiple SPF and DKIM records, as well as configuring DMARC policies to handle emails that fail authentication. Also, companies must ensure that their email infrastructure is compatible with these protocols and that they have the necessary resources and expertise to manage and troubleshoot email authentication issues.
The colour and branding of each email campaign can also play a crucial role in email authentication, as companies must ensure that their emails are consistent with their brand identity and do not appear to be spoofed or phishing emails. For example, if "Brand A" uses a specific colour scheme and logo in its email campaigns, the company must ensure that these elements are consistent across all emails sent by the brand, to avoid raising suspicions among recipients.
To optimise email deliverability and authentication, multi-brand companies must also consider the centre of their email infrastructure, including their email service providers, marketing automation platforms, and customer relationship management systems. This involves ensuring that all systems are properly configured to support email authentication protocols and that emails are properly formatted and authenticated before they are sent to recipients.
In short, email authentication is a critical aspect of email deliverability for multi-brand companies, requiring careful planning and execution to ensure that all brands are properly authenticated and that emails are delivered to the intended recipients. By understanding the complexities of email authentication and implementing protocols such as DMARC, SPF, and DKIM, companies can help to prevent email spoofing and phishing attacks, while also improving email deliverability and reputation. In the next section, we will delve deeper into the basics of DMARC, SPF, and DKIM, and explore how these protocols can be used to improve email authentication and deliverability for multi-brand companies.
Understanding DMARC, SPF, and DKIM: The Basics
To grasp the complexities of implementing DMARC, SPF, and DKIM in multi-brand companies, it is essential to understand the fundamentals of each protocol. Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a protocol that helps prevent email spoofing by verifying the authenticity of an email message. It does this by aligning the domain in the 'From' header of an email with the domain used to authenticate the email, using either the Sender Policy Framework (SPF) or DomainKeys Identified Mail (DKIM).
DMARC relies on SPF and DKIM to function, so let's start with SPF. The Sender Policy Framework (SPF) is a protocol that allows domain owners to specify which mail servers are authorised to send emails on their behalf. This is done by publishing a TXT record in the domain's DNS, which lists the IP addresses of mail servers that are allowed to send emails for that domain. For example, the SPF record for example.com might look like this:
example.com. IN TXT "v=spf1 mx ip4:192.0.2.1 include:_spf.example.net -all"In this example, the SPF record states that emails sent from the mail exchange servers (mx) of example.com, the IP address 192.0.2.1, and any servers included in the _spf.example.net record are authorised to send emails on behalf of example.com. The -all at the end of the record indicates that any emails sent from servers not listed in the record should be rejected.
DomainKeys Identified Mail (DKIM) is another protocol used to authenticate email messages. It works by adding a digital signature to the email header, which is then verified by the recipient's mail server. This digital signature is generated using a private key, and the corresponding public key is published in the domain's DNS as a TXT record. For instance, the DKIM record for example.com might look like this:
default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+yt3SR8jDxjTHr1F6lG3HM9PLT8yTMrT" In this example, the DKIM record states that the default public key for example.com is an RSA key, and the key itself is a long string of characters starting with MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+yt3SR8jDxjTHr1F6lG3HM9PLT8yTMrT.
When an email is sent, the sender's mail server generates a digital signature using the private key, and adds it to the email header. The recipient's mail server can then verify this signature by looking up the public key in the domain's DNS and using it to decrypt the signature. If the signature is valid, the email is considered authenticated.
DMARC builds on these two protocols by allowing domain owners to specify what actions should be taken when an email fails SPF or DKIM authentication. This is done by publishing a TXT record in the domain's DNS, which includes the DMARC policy. For example, the DMARC record for example.com might look like this:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1"In this example, the DMARC record states that the policy for example.com is to reject any emails that fail authentication (p=reject), and to apply this policy to 100% of emails (pct=100). The record also specifies that aggregate reports should be sent to dmarc@example.com (rua=mailto:dmarc@example.com), and that failure reports should be sent to the same address (ruf=mailto:dmarc@example.com). The fo=1 at the end of the record indicates that failure reports should be generated for all emails that fail authentication.
By understanding how DMARC, SPF, and DKIM work together, multi-brand companies can begin to implement these protocols to protect their brands and prevent email spoofing. However, implementing these protocols in a multi-brand environment can be complex, and requires careful planning and configuration to ensure that emails are properly authenticated and delivered to recipients.
In a multi-brand environment, each brand may have its own domain, and may use different mail servers to send emails. This can make it challenging to implement DMARC, SPF, and DKIM, as each domain must have its own set of DNS records and authentication policies. For example, a company that owns the domains example.com, example.net, and example.org may need to publish separate DMARC, SPF, and DKIM records for each domain, and may need to configure each domain to use different mail servers or authentication policies.
To illustrate this, consider a company that has two brands, example.com and example.net. The company uses a single mail server to send emails for both brands, but wants to implement DMARC, SPF, and DKIM to protect each brand. The company would need to publish separate DMARC, SPF, and DKIM records for each domain, such as:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1"
_dmarc.example.net. IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@example.net; ruf=mailto:dmarc@example.net; fo=1"The company would also need to configure each domain to use the same mail server, and to ensure that the mail server is properly configured to authenticate emails using SPF and DKIM. This can be a complex and time-consuming process, especially for companies with many brands and domains.
Despite the challenges, implementing DMARC, SPF, and DKIM is essential for protecting brands and preventing email spoofing. By understanding the basics of each protocol, and by carefully planning and configuring their implementation, multi-brand companies can ensure that their emails are properly authenticated and delivered to recipients, and that their brands are protected from spoofing and phishing attacks.
Challenges of Implementing DMARC, SPF, and DKIM in Multi-Brand Environments
Implementing DMARC, SPF, and DKIM in a multi-brand environment can be a complex task, posing several challenges for organisations. One of the primary challenges is managing multiple domains and subdomains, each with its own set of email authentication requirements. For instance, a company like Virgin Group, with its diverse portfolio of brands, including Virgin Media, Virgin Atlantic, and Virgin Mobile, would need to ensure that each brand's domain is properly configured for DMARC, SPF, and DKIM.
This can be a time-consuming process, particularly if the organisation has a large number of domains and subdomains to manage. Each domain would require its own set of DNS records, including a DMARC record, an SPF record, and a DKIM record, which can be prone to errors if not properly configured.
To illustrate this point, consider a company with two brands, brand1.com and brand2.com, each with its own subdomain for email, email.brand1.com and email.brand2.com. The DMARC record for brand1.com might look like this:
v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@brand1.com; ruf=mailto:dmarc@brand1.com; fo=1While the DMARC record for brand2.com might be slightly different, reflecting the unique requirements of that brand:
v=DMARC1; p=none; pct=100; rua=mailto:dmarc@brand2.com; ruf=mailto:dmarc@brand2.com; fo=1As you can see, each brand's DMARC record has its own unique settings, which can make management more complicated, especially in a multi-brand environment.
Another challenge organisations may face is ensuring that all email services used by each brand are properly authenticated. This can include email marketing platforms, customer support software, and other cloud-based services that send email on behalf of the organisation. For example, if brand1.com uses Mailchimp for email marketing, and brand2.com uses Constant Contact, each of these services would need to be properly configured to authenticate email using SPF and DKIM.
This can be a complex process, particularly if the organisation has a large number of email services to manage. The SPF record for brand1.com might include Mailchimp's servers, like this:
v=spf1 include:_spf.mailchimp.com -allWhile the SPF record for brand2.com might include Constant Contact's servers:
v=spf1 include:spf.constantcontact.com -allIn addition to managing multiple domains and email services, organisations may also face challenges related to DKIM key management. DKIM uses a pair of keys, a public key and a private key, to authenticate email. The public key is published in the organisation's DNS records, while the private key is used by the email service to sign outgoing email. Managing these keys can be complex, particularly in a multi-brand environment where each brand may have its own set of DKIM keys.
For example, if brand1.com uses a 2048-bit DKIM key, and brand2.com uses a 1024-bit DKIM key, each of these keys would need to be properly managed and rotated on a regular basis to ensure email authentication remains secure.
To make matters more complicated, some email services may require the use of a specific DKIM selector, which can be used to identify the DKIM key used to sign email. For instance, Mailchimp might require the use of a DKIM selector like mailchimp, while Constant Contact might require the use of a DKIM selector like constantcontact. The DKIM record for brand1.com might look like this:
k1._domainkey.brand1.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4m5vKm8xY2n5xY8xY8xY8xY8xY8xY8xY8xY8xY8xY8xY"While the DKIM record for brand2.com might look like this:
k2._domainkey.brand2.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4m5vKm8xY2n5xY8xY8xY8xY8xY8xY8xY8xY8xY8xY"As you can see, managing DKIM keys and selectors can be a complex task, particularly in a multi-brand environment.
Finally, organisations may also face challenges related to monitoring and troubleshooting email authentication issues in a multi-brand environment. With multiple domains and email services to manage, it can be difficult to identify and resolve email authentication issues in a timely manner. For example, if brand1.com is experiencing issues with DMARC authentication, the organisation may need to review the DMARC record for brand1.com, as well as the SPF and DKIM records, to identify the source of the issue.
This can be a time-consuming process, particularly if the organisation has limited resources and expertise in email authentication.
To overcome these challenges, organisations can take a number of steps, including implementing a centralised email authentication management system, providing training and support for staff, and regularly monitoring and troubleshooting email authentication issues. By taking these steps, organisations can help ensure that their email authentication is properly configured and managed, reducing the risk of email spoofing and phishing attacks.
In the next section, we will provide a step-by-step guide to setting up DMARC for multi-brand companies, including tips and best practices for managing multiple domains and email services.
Setting Up DMARC for Multi-Brand Companies: A Step-by-Step Guide
Setting up DMARC for multi-brand companies can be a complex process, requiring careful planning and organisation to ensure that all brands are properly authenticated and aligned with the company's overall email strategy. To begin, it is essential to understand the basics of DMARC and how it interacts with SPF and DKIM. DMARC, or Domain-based Message Authentication, Reporting, and Conformance, is a protocol that allows domain owners to specify which email senders are authorised to send emails on their behalf, and what actions should be taken when unauthorised emails are received.
For a multi-brand company, the first step in setting up DMARC is to identify all of the domains and subdomains that will be used to send emails. This includes not only the primary domain for each brand, but also any subdomains that may be used for specific marketing campaigns or customer communications. For example, a company with two brands, "ColourCo" and "FashionForward", may have the following domains and subdomains:
* colourco.com
* fashionforward.com
* marketing.colourco.com
* sales.fashionforward.com
* blog.colourco.com
* newsletter.fashionforward.com
Once all of the relevant domains and subdomains have been identified, the next step is to create a DMARC record for each one. A DMARC record is a type of DNS record that specifies the DMARC policy for a particular domain or subdomain. The record is typically formatted as follows:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:example@example.com; ruf=mailto:example@example.com; fo=1"In this example, the DMARC record is for the domain "example.com", and it specifies the following policies:
* v=DMARC1 indicates that this is a DMARC version 1 record
* p=none indicates that the domain owner does not want to apply any specific policy to unauthorised emails
* pct=100 indicates that the policy should be applied to 100% of emails
* rua=mailto:example@example.com specifies the email address that should receive aggregate reports about DMARC failures
* ruf=mailto:example@example.com specifies the email address that should receive failure reports about DMARC failures
* fo=1 indicates that the domain owner wants to receive failure reports in a format that is compatible with the DMARC failure reporting specification.
For a multi-brand company, it is generally recommended to start with a p=none policy, which allows the company to monitor DMARC failures without applying any specific policy to unauthorised emails. This can help the company to identify any potential issues with its email authentication setup, and to make adjustments as needed before moving to a more restrictive policy.
After creating the DMARC records, the next step is to publish them in the DNS. This can typically be done using a DNS management tool, such as the one provided by the company's domain registrar. For example, to publish a DMARC record using the DNS management tool provided by GoDaddy, the company would follow these steps:
1. Log in to the GoDaddy DNS management tool
2. Select the domain for which the DMARC record should be published
3. Click on the "Add" button to create a new DNS record
4. Select "TXT" as the record type
5. Enter the DMARC record in the "Value" field
6. Click on the "Save" button to publish the record
Once the DMARC records have been published, the company can begin to monitor DMARC failures and adjust its email authentication setup as needed. This can involve reviewing aggregate reports and failure reports, and making adjustments to the SPF and DKIM records to ensure that all authorised email senders are properly authenticated.
It is also important to note that DMARC is not a one-time setup process, but rather an ongoing process that requires regular monitoring and maintenance. This can involve regularly reviewing DMARC reports, updating SPF and DKIM records as needed, and adjusting the DMARC policy to ensure that it remains aligned with the company's overall email strategy. For example, a company may need to update its SPF record to include new IP addresses or domains, or to adjust its DKIM record to use a new selector or private key.
In addition, multi-brand companies may need to consider the use of subdomains and separate DMARC records for each brand. This can help to ensure that each brand is properly authenticated and aligned with the company's overall email strategy, while also providing greater flexibility and control over email authentication. For example, a company with two brands, "ColourCo" and "FashionForward", may use separate DMARC records for each brand, as follows:
_dmarc.colourco.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:example@colourco.com; ruf=mailto:example@colourco.com; fo=1"
_dmarc.fashionforward.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:example@fashionforward.com; ruf=mailto:example@fashionforward.com; fo=1"This can help to ensure that each brand is properly authenticated and aligned with the company's overall email strategy, while also providing greater flexibility and control over email authentication.
Overall, setting up DMARC for multi-brand companies requires careful planning and organisation, as well as an ongoing commitment to monitoring and maintenance. By following the steps outlined above, and by regularly reviewing and adjusting the DMARC setup as needed, companies can help to ensure that their emails are properly authenticated and delivered to the inbox, while also protecting their brands and customers from email-based threats.
Configuring SPF for Complex Brand Structures
Configuring SPF for complex brand structures can be a daunting task, particularly for multi-brand companies with numerous domains, subdomains, and email service providers. A well-configured SPF record is crucial to prevent spam filters from flagging emails as spam, and to protect a company's brand reputation.
To start with, it is essential to understand the basics of SPF. SPF, or Sender Policy Framework, is a protocol that allows domain owners to specify which IP addresses are authorised to send emails on their behalf. This is done by creating a TXT record in the domain's DNS, which lists the authorised IP addresses.
For example, a company called Example Ltd, with the domain example.com, may have an SPF record that looks like this:
example.com. IN TXT "v=spf1 ip4:192.0.2.1 ip4:198.51.100.1 include:_spf.example.net -all"In this example, the SPF record specifies that the IP addresses 192.0.2.1 and 198.51.100.1 are authorised to send emails on behalf of example.com. The include:_spf.example.net directive allows emails sent from the _spf.example.net domain to be authorised as well. The -all directive at the end specifies that any IP address not listed in the SPF record should be rejected.
However, for multi-brand companies, the situation can be more complex. Let us consider a company called XYZ Corporation, which owns several brands, including XYZ Bank, XYZ Insurance, and XYZ Retail. Each brand has its own domain, such as xyzbank.com, xyzinsurance.com, and xyzretail.com.
To configure SPF for XYZ Corporation, we need to create separate SPF records for each brand domain. For example, the SPF record for xyzbank.com may look like this:
xyzbank.com. IN TXT "v=spf1 ip4:203.0.113.1 ip4:203.0.113.2 include:_spf.xyzcorp.net -all"The SPF record for xyzinsurance.com may look like this:
xyzinsurance.com. IN TXT "v=spf1 ip4:203.0.113.3 ip4:203.0.113.4 include:_spf.xyzcorp.net -all"And the SPF record for xyzretail.com may look like this:
xyzretail.com. IN TXT "v=spf1 ip4:203.0.113.5 ip4:203.0.113.6 include:_spf.xyzcorp.net -all"As we can see, each brand domain has its own set of authorised IP addresses, as well as an include directive that allows emails sent from the _spf.xyzcorp.net domain to be authorised.
One of the challenges of configuring SPF for complex brand structures is ensuring that all authorised IP addresses are included in the SPF record. This can be a time-consuming process, particularly if the company has a large number of email service providers and domains.
To optimise the SPF configuration process, it is essential to maintain a centralised list of all authorised IP addresses and email service providers. This list should be regularly updated to reflect any changes to the company's email infrastructure.
Another challenge is ensuring that the SPF record is not too long. SPF records have a limit of 255 characters, which can be a problem for companies with a large number of authorised IP addresses. To overcome this limitation, companies can use the include directive to reference other SPF records, as we saw in the example above.
For instance, instead of listing all the authorised IP addresses for xyzbank.com, xyzinsurance.com, and xyzretail.com in separate SPF records, we can create a single SPF record that includes all the authorised IP addresses, like this:
_spf.xyzcorp.net. IN TXT "v=spf1 ip4:203.0.113.1 ip4:203.0.113.2 ip4:203.0.113.3 ip4:203.0.113.4 ip4:203.0.113.5 ip4:203.0.113.6 -all"We can then reference this SPF record in the SPF records for each brand domain, like this:
xyzbank.com. IN TXT "v=spf1 include:_spf.xyzcorp.net -all"
xyzinsurance.com. IN TXT "v=spf1 include:_spf.xyzcorp.net -all"
xyzretail.com. IN TXT "v=spf1 include:_spf.xyzcorp.net -all"This approach simplifies the SPF configuration process and makes it easier to manage a large number of authorised IP addresses.
In addition to maintaining a centralised list of authorised IP addresses and using the include directive to reference other SPF records, companies can also use SPF record generators to help configure their SPF records. These tools can help ensure that the SPF record is correctly formatted and includes all the necessary IP addresses.
To centre the SPF configuration process, companies should designate a single team or individual to be responsible for managing the SPF records. This team or individual should have a deep understanding of the company's email infrastructure and be able to ensure that all authorised IP addresses are included in the SPF record.
By following these best practices, companies can ensure that their SPF records are correctly configured, which will help to prevent spam filters from flagging emails as spam and protect the company's brand reputation.
In the next section, we will discuss DKIM implementation for multi-brand companies, including best practices for generating and rotating DKIM keys, and how to configure DKIM for multiple domains and email service providers.
DKIM Implementation for Multi-Brand Companies: Best Practices
Implementing DomainKeys Identified Mail (DKIM) for multi-brand companies can be a complex task, requiring careful planning and execution to ensure seamless authentication across all brands. DKIM is a crucial component of email authentication, as it allows senders to associate a domain name with an email message, thereby enabling receivers to verify the message's authenticity. For multi-brand companies, the challenge lies in managing multiple domains, subdomains, and email streams, while maintaining a high level of DKIM authentication.
To begin with, it is essential to understand the basics of DKIM implementation. DKIM uses a pair of keys, one public and one private, to authenticate email messages. The private key is used to sign the email, while the public key is used by the receiver to verify the signature. The public key is published in a DNS record, typically in the format of a TXT record. For example, the DKIM public key record for a domain example.com might look like this:
selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+yt1OiAaJxGv4HjHmJYHvVq5Lj6Yr0j6JtLb7+0b3i4lIcL9xH6Jb1i3j6JtLb7+0b3i4lIcL9xH6Jb1i3j6JtLb7+0b3i4lIcL9xH6Jb1i3j6JtLb7+0b3i4lIcL9xH6Jb1i3"In a multi-brand environment, it is common to have multiple domains and subdomains, each requiring its own DKIM setup. To simplify the process, companies can use a single DKIM key pair across all domains, or use separate key pairs for each domain. The choice between these approaches depends on the company's specific requirements and infrastructure.
One best practice for DKIM implementation in multi-brand companies is to use a consistent naming convention for DKIM selectors. A DKIM selector is a string of characters that is used to identify the DKIM key pair. For example, a company might use a selector like mail1 for its primary email stream, and mail2 for its secondary email stream. Using consistent naming conventions helps to simplify the management of multiple DKIM key pairs.
Another best practice is to rotate DKIM keys regularly, to minimise the risk of key compromise. Key rotation involves generating a new DKIM key pair, and updating the DNS record to point to the new public key. This process should be done periodically, ideally every 6-12 months, to ensure the security of the DKIM authentication.
When implementing DKIM for multiple brands, it is also essential to consider the use of subdomains. Subdomains can be used to separate email streams for different brands, or to create a hierarchical structure for email authentication. For example, a company might use the subdomain brand1.example.com for its primary brand, and brand2.example.com for its secondary brand. Each subdomain would require its own DKIM setup, with a separate DKIM key pair and DNS record.
To illustrate this, let's consider an example of a multi-brand company with two brands, Brand A and Brand B. The company uses the domain example.com for its primary brand, and the subdomain brandb.example.com for its secondary brand. The DKIM setup for example.com might look like this:
mail1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+yt1OiAaJxGv4HjHmJYHvVq5Lj6Yr0j6JtLb7+0b3i4lIcL9xH6Jb1i3j6JtLb7+0b3i4lIcL9xH6Jb1i3j6JtLb7+0b3i4lIcL9xH6Jb1i3"The DKIM setup for brandb.example.com might look like this:
mail2._domainkey.brandb.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+yt1OiAaJxGv4HjHmJYHvVq5Lj6Yr0j6JtLb7+0b3i4lIcL9xH6Jb1i3j6JtLb7+0b3i4lIcL9xH6Jb1i3j6JtLb7+0b3i4lIcL9xH6Jb1i3"In this example, the company uses separate DKIM key pairs for each brand, with a separate DNS record for each subdomain.
In addition to these best practices, it is also essential to monitor DKIM authentication regularly, to ensure that email messages are being authenticated correctly. This can be done using tools like DMARC aggregate reports, which provide detailed information on email authentication results. By monitoring DKIM authentication, companies can identify issues and take corrective action to optimise their email authentication setup.
In short, implementing DKIM for multi-brand companies requires careful planning and execution, with a focus on consistent naming conventions, key rotation, and subdomain management. By following these best practices, companies can ensure seamless DKIM authentication across all brands, and protect their email streams from spoofing and phishing attacks. The use of DKIM, in combination with SPF and DMARC, provides a robust email authentication setup that can help to build trust with recipients, and improve the overall deliverability of email messages.
Managing Multiple Brands with Subdomains and Separate DMARC Records
For multi-brand companies, managing email authentication can become complex, particularly when each brand has its own subdomain. A common approach to simplify this process is to use separate DMARC records for each subdomain. This allows for more granular control over email authentication and reporting, which can be crucial for identifying and mitigating potential issues on a brand-by-brand basis.
When implementing DMARC for multiple brands under subdomains, it's essential to understand how DMARC records are structured and how they interact with SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). A DMARC record is a type of DNS record that specifies the policy for email authentication. It tells receiving email servers what to do with emails that fail authentication. For example, a basic DMARC record might look like this:
_vouch.dmarc.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:auth-reports@example.com; ruf=mailto:auth-failure@example.com; fo=1" In this example, example.com is the domain, and the record specifies that all emails should be authenticated, with reports sent to auth-reports@example.com for aggregate data and auth-failure@example.com for failure reports.
For a multi-brand company with subdomains, each subdomain might have its own DMARC record. For instance, if example.com owns the brands brand1 and brand2, each could have a subdomain (brand1.example.com and brand2.example.com) with its own DMARC record. This setup allows for separate reporting and policies for each brand, which can be particularly useful for troubleshooting and for brands that have different email sending practices.
Subdomain DMARC Records
Setting up DMARC records for subdomains involves creating a DMARC record for each subdomain. This process is similar to setting up a DMARC record for the top-level domain, but you specify the subdomain in the record name. For example, for brand1.example.com, the DMARC record might be named _vouch.dmarc.brand1.example.com.
Here's an example of what the DMARC record for brand1.example.com might look like:
_vouch.dmarc.brand1.example.com. IN TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:brand1-auth-reports@example.com; ruf=mailto:brand1-auth-failure@example.com; fo=1" And for brand2.example.com:
_vouch.dmarc.brand2.example.com. IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:brand2-auth-reports@example.com; ruf=mailto:brand2-auth-failure@example.com; fo=1" In these examples, brand1 and brand2 have different policies (quarantine and reject, respectively), and they receive their reports at separate email addresses. This allows the company to manage the email authentication for each brand independently, which can be beneficial for brands with different risk tolerances or email practices.
SPF and DKIM for Subdomains
When using separate DMARC records for subdomains, it's also important to consider SPF and DKIM. SPF records list the IP addresses that are authorised to send email on behalf of a domain or subdomain. For multi-brand companies, having separate SPF records for each subdomain can help ensure that only authorised senders are allowed to send emails for each brand.
DKIM, on the other hand, involves adding a digital signature to emails, which can be verified by receiving email servers to ensure the email was not tampered with during transit. For subdomains, it's possible to use the same DKIM key for all subdomains or to generate separate keys for each. Using separate keys can provide an additional layer of security but also increases complexity.
Best Practices for Multi-Brand DMARC Management
To effectively manage DMARC for multiple brands with subdomains, several best practices should be followed:
- Monitor Reports Closely: Regularly review DMARC reports for each subdomain to identify any authentication issues or potential spam attempts.
- Use Separate Policies: Tailor DMARC policies to the specific needs of each brand, considering factors like risk tolerance and email usage patterns.
- Implement SPF and DKIM: Ensure that SPF and DKIM are correctly set up for each subdomain to prevent unauthorised email sending and to protect the brand's reputation.
- Keep Records Up to Date: Regularly update DMARC, SPF, and DKIM records as necessary to reflect changes in email infrastructure or sending practices.
- Test Thoroughly: Before deploying DMARC policies, test them in a monitoring mode to ensure they do not inadvertently block legitimate emails.
By following these best practices and using separate DMARC records for each subdomain, multi-brand companies can effectively manage email authentication, reduce the risk of spam and phishing, and protect their brands' reputations. This approach requires careful planning and ongoing monitoring but offers significant benefits in terms of security and brand integrity.
Monitoring and Troubleshooting DMARC, SPF, and DKIM for Multi-Brand Companies
Implementing DMARC, SPF, and DKIM for multi-brand companies can be a complex task, and monitoring and troubleshooting these email authentication protocols are crucial to ensure their effectiveness. A well-planned monitoring and troubleshooting strategy helps to identify and resolve issues quickly, reducing the risk of email delivery problems and protecting the company's reputation.
To start monitoring DMARC, SPF, and DKIM, it is essential to understand the types of reports and data that are available. DMARC, for example, provides aggregate and forensic reports that offer insights into email authentication results. Aggregate reports provide a summary of email authentication results, including the number of emails that passed or failed DMARC, SPF, and DKIM checks. Forensic reports, on the other hand, provide detailed information about individual emails that failed DMARC checks, including the sender's IP address, email headers, and authentication results.
Here is an example of a DMARC aggregate report:
<feedback>
<version>1.0</version>
<report_metadata>
<org_name>example.com</org_name>
<email>postmaster@example.com</email>
<extra_contact_info>https://example.com/dmarc</extra_contact_info>
<report_id>1234567890</report_id>
<date_range>
<begin>2022-01-01T00:00:00Z</begin>
<end>2022-01-07T23:59:59Z</end>
</date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>reject</p>
<sp>reject</sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>192.0.2.1</source_ip>
<count>10</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<row>
<source_ip>192.0.2.2</source_ip>
<count>5</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
</record>
</feedback>This report shows that the domain example.com has a DMARC policy that rejects emails that fail DMARC checks, and it provides information about the number of emails that passed or failed DMARC, SPF, and DKIM checks from specific IP addresses.
SPF also provides a way to monitor and troubleshoot email authentication results. SPF uses a DNS record that lists the IP addresses that are authorised to send emails on behalf of a domain. Here is an example of an SPF record:
example.com. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 include:_spf.example.net -all"This record specifies that the IP addresses 192.0.2.1 and 192.0.2.2 are authorised to send emails on behalf of example.com, and it also includes the SPF record of _spf.example.net. The -all directive at the end of the record specifies that emails from IP addresses that are not listed in the record should be rejected.
DKIM also provides a way to monitor and troubleshoot email authentication results. DKIM uses a digital signature that is added to the email header to verify the authenticity of the email. Here is an example of a DKIM record:
default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCqGKukO1De7zhZj6+H0qtjTkVxwTCpvKe4eCZ0FPqri0cb2JZfXJ/DgYSF6vUpwmJG8wVQZKjeGcjDOL5UlsuusFncCzWBQ7RKNUSesmQRMSGkVb1/3j+skZ6UtW+5u09lHNsj6tQ51s1SPrCBkedbNf0Tp0GbMJDyR4e9T04ZZwIDAQAB"This record specifies the public key that is used to verify the DKIM signature of emails sent from example.com.
To troubleshoot DMARC, SPF, and DKIM issues, it is essential to have a good understanding of the email authentication process and the types of errors that can occur. One common issue is the alignment of the SPF and DKIM records with the domain's DMARC policy. For example, if the DMARC policy is set to reject emails that fail DMARC checks, but the SPF record is not aligned with the DMARC policy, emails may be rejected unnecessarily.
Another common issue is the use of subdomains and separate DMARC records. If a company uses subdomains for different brands or services, it is essential to ensure that each subdomain has its own DMARC record that is aligned with the company's overall DMARC policy. For example, if a company has a subdomain for its marketing department, the DMARC record for that subdomain should be aligned with the company's overall DMARC policy to ensure that marketing emails are authenticated correctly.
To centre the monitoring and troubleshooting efforts, it is essential to have a clear understanding of the company's email infrastructure and the types of emails that are being sent. This includes understanding the different email services and applications that are used, such as marketing automation platforms, customer relationship management systems, and email service providers. It is also essential to have a good understanding of the company's network infrastructure, including the IP addresses and domains that are used to send emails.
In addition to understanding the company's email infrastructure, it is also essential to have the right tools and resources in place to monitor and troubleshoot DMARC, SPF, and DKIM issues. This includes using DMARC analysis tools to monitor DMARC reports and identify issues, as well as using email authentication testing tools to test the alignment of SPF and DKIM records with the domain's DMARC policy.
It is also essential to have a good understanding of the colour coding used in DMARC reports to identify issues. For example, a red colour may indicate a failed DMARC check, while a green colour may indicate a passed DMARC check. By using these tools and resources, companies can optimise their email authentication setup and ensure that their emails are delivered correctly to the recipient's inbox.
To organise the monitoring and troubleshooting efforts, it is essential to have a clear plan in place that outlines the steps that need to be taken to identify and resolve issues. This includes setting up a system to monitor DMARC reports and identify issues, as well as setting up a process to troubleshoot and resolve issues quickly. It is also essential to have a good understanding of the company's email authentication policies and procedures, including the DMARC policy, SPF record, and DKIM record.
By having a clear plan in place and using the right tools and resources, companies can ensure that their email authentication setup is optimised and that their emails are delivered correctly to the recipient's inbox. This can help to improve the company's reputation and reduce the risk of email delivery problems.
In the case of a multi-brand company, it is essential to ensure that each brand has its own DMARC record and that the DMARC records are aligned with the company's overall DMARC policy. This can help to ensure that emails sent from each brand are authenticated correctly and that the company's reputation is protected.
For example, a company that owns several brands, such as a retail company that owns several clothing brands, may need to set up separate DMARC records for each brand. This can help to ensure that emails sent from each brand are authenticated correctly and that the company's reputation is protected.
To set up separate DMARC records for each brand, the company can use subdomains for each brand. For example, the company can use the subdomain brand1.example.com for the first brand, brand2.example.com for the second brand, and
Case Studies: Real-World Examples of Successful DMARC, SPF, and DKIM Implementation
Implementing DMARC, SPF, and DKIM for multi-brand companies can be a complex task, requiring careful planning and execution to ensure seamless email authentication across all brands. To illustrate the process and its benefits, let us examine a few real-world examples of successful implementation.
A large retail company, operating multiple brands across the globe, faced significant challenges in protecting its email ecosystem from spoofing and phishing attacks. With over 20 brands under its umbrella, the company needed a robust email authentication system that could be easily managed and monitored. The company decided to implement DMARC, SPF, and DKIM across all its brands, using a centralised management system to oversee the process.
The first step was to set up DMARC records for each brand, with a policy of "none" to begin with, allowing the company to monitor and gather data on email authentication without affecting email delivery. The DMARC record for one of the brands, for example, looked like this:
_dmarc.brand1.example.com. IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc@brand1.example.com; ruf=mailto:dmarc@brand1.example.com; fo=1"This record specified the DMARC version, policy, and percentage of emails to which the policy applied, as well as the email addresses for receiving aggregate and forensic reports.
Next, the company configured SPF records for each brand, including all the IP addresses and domains that were authorised to send emails on behalf of the brand. For instance, the SPF record for another brand looked like this:
brand2.example.com. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 include:_spf.brand2.example.com -all"This record listed the IP addresses of the company's email servers and included a reference to the brand's own SPF record, which contained additional authorised IP addresses and domains.
DKIM implementation was also crucial, as it allowed the company to sign its emails with a digital signature that could be verified by recipient email servers. The company generated a DKIM key pair for each brand and configured its email servers to sign outgoing emails with the corresponding private key. The public key was then published in a TXT record, like this:
selector1._domainkey.brand3.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+yt3SR3+D6+4W9JZ5Uz6H6JNQjB4H5FBbZuyVqxrjF7isWDm9ZOrZzXyE6ZnJL4hDlVCLaYnXXJNq7h8x4P8J2Q+Xm2l4jQJzBc7KQyKcRc4l9wQx+gZK4j4j4j4j4j4j4j4j4j4j4j4j4j4j4j4j4j4j4j"With DMARC, SPF, and DKIM in place, the company was able to monitor email authentication and detect potential spoofing and phishing attacks. The company's security team could analyse the DMARC aggregate and forensic reports to identify unauthorised email sources and take corrective action.
Another example is a media company that operates several news websites and online publications. The company wanted to protect its brands from email spoofing and phishing attacks, while also ensuring that its emails were delivered to subscribers' inboxes. The company implemented DMARC, SPF, and DKIM across all its brands, using a combination of cloud-based email services and on-premise email servers.
The company's DMARC implementation involved setting up a centralised DMARC record that applied to all its brands, with a policy of "quarantine" to divert unauthenticated emails to the spam folder. The company also configured SPF records for each brand, including the IP addresses of its cloud-based email services and on-premise email servers. DKIM implementation involved generating a DKIM key pair for each brand and configuring the email servers to sign outgoing emails with the corresponding private key.
The results were impressive, with a significant reduction in email spoofing and phishing attacks, and improved email deliverability across all brands. The company's security team could monitor email authentication and detect potential threats in real-time, using the DMARC reports and analytics tools.
In addition to these examples, many other multi-brand companies have successfully implemented DMARC, SPF, and DKIM to protect their email ecosystems from spoofing and phishing attacks. A financial services company, for instance, implemented DMARC, SPF, and DKIM across its multiple brands, using a combination of on-premise email servers and cloud-based email services. The company's DMARC implementation involved setting up a centralised DMARC record that applied to all its brands, with a policy of "reject" to block unauthenticated emails.
The company also configured SPF records for each brand, including the IP addresses of its on-premise email servers and cloud-based email services. DKIM implementation involved generating a DKIM key pair for each brand and configuring the email servers to sign outgoing emails with the corresponding private key. The results were significant, with a reduction in email spoofing and phishing attacks, and improved email deliverability across all brands.
These case studies demonstrate the importance of implementing DMARC, SPF, and DKIM for multi-brand companies, to protect their email ecosystems from spoofing and phishing attacks, and ensure seamless email authentication across all brands. By following best practices and using the right tools and technologies, companies can ensure that their emails are delivered to subscribers' inboxes, while also protecting their brands from email-based threats.
To optimise the implementation process, companies should start by assessing their email infrastructure and identifying the domains and IP addresses that need to be included in the DMARC, SPF, and DKIM records. They should also consider using a centralised management system to oversee the implementation process and monitor email authentication across all brands. Regular monitoring and analysis of DMARC reports and analytics tools can help companies detect potential threats and take corrective action to protect their email ecosystems.
In terms of colour coding and organisational structure, companies can use a variety of tools and techniques to manage their DMARC, SPF, and DKIM records, including spreadsheets, diagrams, and flowcharts. They can also use a centre of excellence approach, where a central team is responsible for overseeing the implementation process and providing guidance and support to other teams across the organisation.
By taking a proactive and organised approach to email authentication, multi-brand companies can protect their email ecosystems from spoofing and phishing attacks, and ensure seamless email authentication across all brands. This can help to build trust with subscribers, improve email deliverability, and reduce the risk of email-based threats. With the right tools and technologies in place, companies can optimise their email authentication processes and achieve a high level of security and compliance.