Email Authentication for Senders with Bring-Your-Own-Device Policies

31 October 2026 · DMARC Engine · 10 min read

The Authentication Challenge with BYOD

The bring-your-own-device (BYOD) policy poses significant challenges for email authentication, as personal devices often lack the standardised configuration and control found in company-managed equipment. A common pattern is for users to send emails from their personal devices, which may not be configured to use the company's email servers, thus bypassing standard email authentication mechanisms.

example.com. IN TXT "v=spf1 include:_spf.example.com -all"

This can lead to emails being sent with the company's domain, but without proper authentication, causing receivers to flag them as potentially spam or reject them altogether. Receivers typically use a combination of SPF, DKIM, and DMARC to verify the authenticity of emails, and emails sent from personal devices may fail these checks.

selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+ytH6HHv+7Nd9KvO9Yi3kg5y2P2m0lIwLl6j7mJwQb9n0Z0x8T4JBP6+Z6HrrVdK3jbEj9pdZTQOc1nY1x+6z4J0/1aKoQw0j9w+Kt3mZr2FQ8tT3P5vX5xj9xW5tT3P5xj9xW5tT3P5xj9xW"

A hosted or managed setup may handle this by providing a standardised email client configuration for personal devices, but this may not be feasible or desirable for all organisations.

Warning:
organisations should be cautious when implementing email authentication for BYOD policies, as overly restrictive settings can lead to legitimate emails being blocked, while overly permissive settings can leave the organisation vulnerable to spoofing attacks.

The aggregate reports will show the authentication results for emails sent from personal devices, allowing organisations to identify and address any issues. However, this requires careful analysis and monitoring to ensure that the email authentication settings are effective and not causing unintended consequences.

Assessing Current Email Infrastructure

When implementing email authentication for senders with bring-your-own-device (BYOD) policies, it is crucial to assess the current email infrastructure. This involves examining the existing DNS records, email services, and devices used by senders. A common pattern is for organisations to have a mix of managed and unmanaged devices, which can complicate the authentication process.

The first step is to identify all the domains used by senders, including any subdomains. For each domain, the existing DNS records should be reviewed, particularly the SPF, DKIM, and DMARC records. For example, a domain may have an SPF record like this:

example.com. IN TXT "v=spf1 include:_spf.example.com -all"

This record specifies that the domain example.com includes the SPF record of _spf.example.com and rejects all other senders.

The aggregate reports will show which senders are authenticating emails on behalf of the domain, and which authentication mechanisms are being used. Receivers typically provide these reports, which can help identify potential issues with the current infrastructure. A hosted or managed setup may handle these reports differently, so it is essential to check the specific setup.

A list of devices and email services used by senders should be compiled, including any personal devices. This list should include:

* Email clients used, such as Microsoft Outlook or Mozilla Thunderbird
* Devices used, such as desktops, laptops, or mobile devices
* Email services used, such as Gmail or Outlook.com

Note: It is essential to consider the trade-offs between security and usability when assessing the current email infrastructure. Implementing strict authentication policies may improve security but may also cause issues with legitimate emails being blocked.

The DNS records for each domain should be reviewed to ensure they are correctly configured. For example, a DMARC record like this:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:aggregate@example.com"

This record specifies that the domain example.com has a DMARC policy of none, and aggregate reports should be sent to aggregate@example.com.

The assessment of the current email infrastructure is critical in determining the best approach to implementing email authentication for senders with BYOD policies. By understanding the existing DNS records, email services, and devices used by senders, organisations can make informed decisions about how to improve email authentication and prevent spoofing.

Configuring SPF for Personal Devices

Configuring SPF for personal devices is a crucial step in email authentication for senders with bring-your-own-device (BYOD) policies. The primary challenge is that personal devices often have dynamic IP addresses, which can change frequently, making it difficult to maintain an accurate SPF record. A common pattern is for organisations to use a third-party email service provider, which can simplify the process of configuring SPF.

To configure SPF for personal devices, senders need to publish an SPF record that includes the IP addresses of the devices. However, this can be impractical, as the IP addresses may change frequently. A more practical approach is to use a mechanism that allows devices to authenticate with the email service provider, such as a mail user agent (MUA) that supports SPF authentication. For example, the following SPF record snippet includes the IP addresses of a range of devices:

v=spf1 include:_spf.example.com ip4:192.0.2.1/24 -all

In this example, the include mechanism is used to include the SPF record of the email service provider, _spf.example.com, and the ip4 mechanism is used to specify the IP address range of the devices.

A hosted or managed setup, such as Google Workspace or Microsoft 365, typically handles SPF configuration automatically, using a mechanism such as SPF authentication or domain keys. For example, Google Workspace uses a mechanism called "SPF authentication" to authenticate devices, which eliminates the need for senders to publish an SPF record. However, senders may still need to configure SPF for devices that are not using the hosted or managed setup.

v=spf1 include:_spf.google.com ip4:198.51.100.1/24 -all

In this example, the include mechanism is used to include the SPF record of Google Workspace, _spf.google.com, and the ip4 mechanism is used to specify the IP address range of the devices.

When configuring SPF for personal devices, senders should be aware of the trade-offs between security and usability. A strict SPF policy can help prevent spam and phishing attacks, but it may also block legitimate emails from devices that are not configured correctly. A more permissive SPF policy can allow more emails to be delivered, but it may also increase the risk of spam and phishing attacks.

Warning: Senders should not use the +all mechanism in their SPF record, as this can allow spammers to send emails that appear to come from the sender's domain. Instead, senders should use the -all mechanism, which specifies that emails from IP addresses that are not included in the SPF record should be rejected.

Implementing DKIM for BYOD Emails

Implementing DomainKeys Identified Mail (DKIM) for bring-your-own-device (BYOD) emails requires careful consideration of the trade-offs between security, complexity, and usability. A common pattern is for organisations to use a third-party email service provider to manage their DKIM keys, which simplifies the process of generating and rotating keys. However, this approach may not be suitable for all organisations, particularly those with strict security requirements.

default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+yt3WRxWYTFuFZp2MonY1Hh0bXoVQqFz+9s4cT1m0xRrXf8ZT8k8kzEkosjHjhlJXWAqWb1y9H1x1JYpHt3JLlXCKd5os9JHJrK3hJ0J5T3Ij1u7lKU1XgU4HQHdX6x6prNzTtY3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3"

When implementing DKIM for BYOD emails, organisations should publish their DKIM public key in a DNS TXT record, as shown above. The default._domainkey.example.com record specifies the DKIM version, key type, and public key. Receivers typically use this record to verify the DKIM signature of incoming emails.

import dkim

# Generate a DKIM signature
signature = dkim.sign(
 message="Hello, world!",
 selector="default",
 domain="example.com",
 privkey="path/to/private/key"
)

To generate a DKIM signature, organisations need to use a private key, which should be stored securely. A hosted or managed setup may provide a web interface for generating and managing DKIM keys, which can simplify the process. However, organisations should ensure that they have control over their private keys and can rotate them as needed.

selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+yt3WRxWYTFuFZp2MonY1Hh0bXoVQqFz+9s4cT1m0xRrXf8ZT8k8kzEkosjHjhlJXWAqWb1y9H1x1JYpHt3JLlXCKd5os9JHJrK3hJ0J5T3Ij1u7lKU1XgU4HQHdX6x6prNzTtY3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3"
selector2._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+yt3WRxWYTFuFZp2MonY1Hh0bXoVQqFz+9s4cT1m0xRrXf8ZT8k8kzEkosjHjhlJXWAqWb1y9H1x1JYpHt3JLlXCKd5os9JHJrK3hJ0J5T3Ij1u7lKU1XgU4HQHdX6x6prNzTtY3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3Y3"

Organisations may need to use multiple DKIM selectors, each with its own public key, to support different email clients or

DMARC and Aggregate Reporting for BYOD

A common pattern is for senders with bring-your-own-device (BYOD) policies to initially focus on configuring SPF and DKIM, then later implement DMARC to monitor and enforce authentication. When setting up DMARC, it is crucial to consider the impact of personal devices on aggregate reporting. The aggregate reports will show authentication results from various sources, including personal devices, which can make it challenging to identify and troubleshoot issues.

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:aggrep@example.com"

Receivers typically send aggregate reports to the specified email address, which can be hosted on the sender's domain or a managed setup. A hosted or managed setup may handle these reports differently, so it is essential to understand how they will be processed and presented. For instance, some managed setups may provide a web-based interface to view and analyse aggregate reports, while others may require manual processing of the email reports.

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:aggrep@example.com; ruf=mailto:forensic@example.com"

The forensic reports, specified by the ruf tag, can provide more detailed information about authentication failures, which can be helpful in identifying and addressing issues related to personal devices. However, these reports can be large and may contain sensitive information, so it is essential to consider how they will be handled and stored.

Warning:
When implementing DMARC, it is vital to start with a monitoring-only policy (p=none) and gradually move to a more restrictive policy (p=quarantine or p=reject) to avoid inadvertently blocking legitimate emails from personal devices. This approach allows senders to assess the impact of DMARC on their email infrastructure and make necessary adjustments before enforcing a stricter policy.

Operational Considerations and Trade-offs

When implementing email authentication for senders with bring-your-own-device policies, several operational considerations and trade-offs must be taken into account. A common pattern is for organisations to initially focus on configuring SPF, as it is often the simplest to set up, with a record such as:

v=spf1 include:_spf.example.com -all

However, this can lead to issues if the organisation has a large number of personal devices sending emails, as each device may need to be individually added to the SPF record.

A list of key considerations includes:

• the administrative overhead of managing SPF records for personal devices
• the potential impact on deliverability if DKIM signing is not implemented correctly
• the need for ongoing monitoring of DMARC aggregate reports to identify potential issues

import dns.resolver

# example of querying DMARC record for a domain
answers = dns.resolver.resolve('_dmarc.example.com', 'TXT')
for rdata in answers:
 print(rdata.to_text())

Note: when using a hosted or managed setup, the provider may handle some of these operational considerations, such as managing SPF records or monitoring DMARC aggregate reports, which can simplify the process for organisations.

Monitoring and Adjusting Authentication Settings

A common pattern is for senders to set up their authentication settings, such as SPF and DKIM, and then not revisit them until issues arise. However, monitoring and adjusting these settings is crucial, especially in a bring-your-own-device (BYOD) environment. Receivers typically use DMARC aggregate reports to inform senders about authentication issues, and these reports can be used to identify problems with SPF or DKIM configurations.

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:aggregatereports@example.com"

The aggregate reports will show which sources are authenticating correctly and which are not, allowing senders to adjust their authentication settings accordingly. For example, if a large number of emails from personal devices are failing DKIM authentication, it may be necessary to adjust the DKIM selector or key size. In a hosted or managed setup, the provider may handle some of these adjustments automatically, but it is still important for senders to monitor their aggregate reports and make adjustments as needed.

import dns.resolver

answers = dns.resolver.resolve("_dmarc.example.com", "TXT")
for rdata in answers:
 for txt_string in rdata.strings:
 print(txt_string)

Tip: Regularly reviewing DMARC aggregate reports can help identify potential issues before they become major problems, such as a large-scale phishing attack using a sender's domain.

Check your own domain

• Free DMARC checker
• Hosted DMARC

Related reading