DMARC Reports: Debunking Privacy Myths and Minimizing Risk

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is an essential email authentication protocol designed to protect your domain from being used in phishing and spoofing attacks. 

One of DMARC’s core features is its ability to generate reports that provide valuable insights into who is sending emails on behalf of your domain. However, some organizations are hesitant to enable DMARC reporting due to concerns about sharing potentially sensitive data with third parties. This article aims to dispel misconceptions about DMARC reporting, clarify what information is actually shared, and provide practical guidance on how to minimize privacy risks.

Understanding DMARC Reports

DMARC generates two types of reports:

1. Aggregate Reports (RUA) - These reports provide a high-level overview of email authentication results, including metadata such as sending IP addresses, domain alignment, and the DMARC policy applied. They are sent to the address specified in the "rua" tag of your DMARC record.
2. Forensic Reports (RUF) - These reports, also known as failure or message-specific reports, contain more detailed information, including message headers, and in some cases, subject lines and content. They are sent to the address specified in the "ruf" tag.

Who Generates the Reports?

A common misconception is that sending DMARC reports involves your email server transmitting data to third parties. In reality, it is the receiving email server that generates these reports. When your domain sends an email to another server (like Gmail or Outlook), that server checks your DMARC policy and, if configured, generates a report based on the result of that check. Therefore, your organization has no control over whether a receiving server generates these reports once your policy requests them.

Aggregate vs. Forensic Reports

While both report types serve to increase visibility into your domain’s email traffic, they differ significantly in terms of privacy implications:

Aggregate Reports (RUA)

• Generated regardless of DMARC outcome (pass or fail).
• Contain only metadata and no email content, making them relatively safe from a privacy perspective.
• Typically sent daily and in XML format.

Forensic Reports (RUF)

• Generated only when a message fails DMARC checks.
• May include potentially sensitive information, such as message headers and even parts of the email body.
• Not all receiving servers generate forensic reports—many have opted not to, due to privacy and compliance concerns.
• The default behavior is to generate forensic reports only on DMARC failures.

Minimizing Privacy Risks

The best way to mitigate privacy risks is to limit which reports you request in your DMARC policy:

1. Exclude Forensic Reports (RUF) - Simply omit the "ruf" tag from your DMARC record to ensure no forensic data is collected or shared.

   Example DMARC record without RUF:

   v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com
   

2. Use Trusted Email Reporting Services - If you do use RUF, consider configuring it to send to a trusted third party or internal system that is designed to securely manage sensitive data.

3. Review Privacy Policies of Receiving Servers - Understand that the vast majority of servers do not generate forensic reports at all, and those that do typically redact or minimize content to protect privacy.

Final Thoughts

For organizations new to DMARC, the potential risks around RUF reports can seem daunting. However, the reality is that the vast majority of DMARC data shared is aggregate metadata that poses little to no risk of exposing sensitive content. By configuring your DMARC record carefully and opting only for RUA reports, you can significantly minimize your privacy exposure while still gaining valuable insights into email authentication.

Have questions or need more guidance on implementing DMARC? Reach out to a trusted expert to ensure your email domain is protected while maintaining privacy best practices.

Understanding the Public Suffix List: The Unsung Hero of Domain Management

The Public Suffix List (PSL) is one of those critical internet infrastructures that works silently in the background, yet few understand its purpose or importance. For those working in web development, security, or domain management, understanding the PSL can provide valuable insights into how browsers, email clients, and other applications make critical security decisions. This article explores the origins, purpose, and practical implications of this essential internet resource.

The Origins: When the DNS Hierarchy Got Complicated

In the early days of the internet, the domain name system was relatively simple. You had a handful of top-level domains (TLDs) like .com, .org, and .net, and organizations would register their domains directly under these TLDs. The boundary between the registrable part of a domain and its TLD was clear.

However, as the internet expanded globally, country-code TLDs (ccTLDs) emerged with their own registration policies. Some countries, like the UK (.uk) and Australia (.au), adopted a second-level hierarchy where organizations typically registered domains at the third level (e.g., example.co.uk or example.com.au). Suddenly, the clear boundary between registrable domains and "public" suffixes became blurred.

This ambiguity created a significant problem: how could software determine where the organizational boundary of a domain lies? Without this knowledge, critical security features like cookie handling could become vulnerable.

The Problem: Cookie Management and Security

The most pressing issue that led to the creation of the PSL was cookie security. Consider a site like example.com that sets a cookie. Browsers needed to prevent sites like malicious.example.com from accessing that cookie, as they are different organizational entities. However, in cases like example.co.uk and malicious.co.uk, both domains should be treated as distinct organizations despite sharing more domain components.

Without a standardized way to determine these boundaries, browsers had to rely on simplistic rules (like allowing cookies to be shared across subdomains) that created security vulnerabilities. In countries with multi-level TLDs, this problem was even more acute.

Mozilla's Solution: The Public Suffix List

In 2007, Mozilla recognized this problem and created the Public Suffix List—a community-maintained list of "public suffixes." A public suffix is essentially a domain under which internet users can directly register names. The PSL helps software distinguish between public suffixes and private domains.

For example, the PSL indicates that:

• .com is a public suffix
• .co.uk is a public suffix
• .github.io is a public suffix
• example.com is not a public suffix (it's an organisation level domain under .com)

What TLD+N Actually Means

To understand the PSL's impact, it helps to understand domain hierarchy terminology:

• TLD: The Top-Level Domain (e.g., .com, .org)
• TLD+1 (or eTLD+1): The TLD plus one level, which represents the "effective" registrable domain (e.g., example.com) - sometimes referred to as organisation level domain.
• TLD+2: The registrable domain plus one level, typically a subdomain (e.g., blog.example.com)

What makes this complex is that the "effective" TLD (eTLD) might include multiple parts. For instance:

• In example.com, the eTLD is .com
• In example.co.uk, the eTLD is .co.uk
• In example.github.io, the eTLD is .github.io

The PSL helps determine what counts as the effective TLD in any given domain.

PSL Additions and Removals: What They Mean

When a domain is added to the PSL:

• It becomes treated as a public suffix
• Subdomains immediately under it are considered separate registrable domains
• Cookies set by one subdomain can't be accessed by another subdomain
• SSL certificates must be issued separately for each subdomain
• Email sender policies may be evaluated differently

For example, when github.io was added to the PSL, alice.github.io and bob.github.io became treated as separate security contexts, just like alice.com and bob.com would be.

When a domain is removed from the PSL:

• It's no longer treated as a public suffix
• Subdomains are considered part of the same security context
• Cookies may be shared across previously separated domains
• Wildcard SSL certificates might cover more subdomains
• Security policies may need reconfiguration

Who Maintains the PSL?

The PSL was originally created by Mozilla and is still primarily maintained by them, though it has become a community effort. The list itself is hosted as an open-source project on GitHub (https://github.com/publicsuffix/list).

Mozilla remains the steward of the project, but contributions come from a wide range of organizations and individuals with interests in domain policy and web security.

The Approval Process

The process for adding or removing domains from the PSL involves:

1. Submission: Creating a pull request on GitHub with the proposed change
2. Justification: Providing evidence that the domain operates as a public suffix where third parties can register domains
3. Review: Community and maintainer assessment of the request
4. Implementation: Merging the change if approved
5. Distribution: Updates are periodically released and adopted by consuming applications

For a domain to be added, it typically needs to demonstrate that:

• It allows third-party domain registration (or subdomain allocation)
• Different entities control different subdomains
• There's a legitimate need for security isolation between subdomains

The review process focuses on preventing abuse, as being in the PSL can confer certain advantages (particularly for cookie access and storage quotas).

Applications and Protocols Relying on PSL

The PSL has become a critical component for numerous systems:

Browsers:

• Cookie management (the original use case)
• Local storage limitations
• Security origin determination
• HSTS (HTTP Strict Transport Security) propagation

Certificate Authorities:

• Validation of domain control
• Issuance policies for wildcard certificates
• Name constraints enforcement

Email Systems:

• DMARC and SPF policy evaluation
• Determining organizational boundaries for anti-spoofing
• Email authentication alignment checks

Security Tools:

• Same-origin policy enforcement
• Cross-origin resource sharing (CORS) decisions
• Content Security Policy (CSP) implementation

Web Frameworks:

• Domain validation
• Routing decisions
• Security headers configuration

The degree of reliance varies, but cookie security remains the most critical application. Some systems implement their own version or modification of the PSL, creating occasional inconsistencies between applications.

Tools for Working with the Public Suffix List

For those looking to integrate PSL functionality into their own applications, several tools and APIs are available. One particularly useful resource is the publicsuffixlist-api project on GitHub. 

This open-source API provides a convenient way to query and interact with the Public Suffix List programmatically, making it easier to implement PSL-based domain validation and security features in your own applications. The API offers simple endpoints for checking domain status, determining effective TLDs, and validating domain structures—all while staying synchronized with the official PSL. 

For developers working on domain management tools, security applications, or web frameworks, this API can significantly simplify the process of correctly implementing PSL-based logic without having to maintain your own parsing and update mechanisms.

Implementation Challenges

Despite its importance, PSL integration isn't perfect:

• Applications may use outdated versions of the list
• Some implementations have bugs or misinterpretations
• The list requires regular updates as the domain landscape changes
• Edge cases exist that the PSL doesn't fully address

Conclusion

The Public Suffix List represents a community solution to a complex problem in internet infrastructure. While invisible to most users, it plays a crucial role in maintaining security boundaries online. For technical professionals working with domains, understanding the PSL provides valuable context for security decisions, application development, and domain strategy.

As the web continues to evolve, the PSL remains a living document that adapts to new domain structures and registration policies. Being aware of its existence and function is increasingly important for anyone working with web technologies at an intermediate to advanced level.

Bridging the Gap: Enforcing TLS 1.3 for Legacy On-Premises Devices in Email Delivery

In the world of email delivery, security is paramount. As protocols and standards evolve, staying up-to-date with the latest encryption methods is essential to protect sensitive information. TLS 1.3, the latest version of the Transport Layer Security protocol, provides enhanced security and performance compared to its predecessors. However, not all systems are ready to make the leap, especially legacy on-premises devices that only support plaintext or outdated protocols like TLS 1.1.

This creates a dilemma for businesses: How do you ensure secure email delivery while maintaining compatibility with older devices? In this article, we’ll explore the problem, propose a solution, and provide a configuration guide for stunnel, a tool that can bridge the gap between legacy devices and modern, secure communication.

The Problem: Legacy Devices and Modern Security Standards

Many organizations rely on older devices that lack support for modern encryption standards. These devices may only support:

• Plaintext communication, which is highly insecure and vulnerable to interception.
• Outdated encryption protocols like TLS 1.1, which are no longer considered safe.

At the same time, email relay services like Mimecast require secure communication, with a preference for TLS 1.2 or TLS 1.3. This creates a compatibility issue: legacy devices are unable to connect securely to email smarthosts without additional intervention.

The Solution: Stunnel as a Secure Proxy

To solve this problem, we can use stunnel, a lightweight tool designed to act as a secure proxy. Stunnel allows us to:

1. Accept plaintext or older TLS connections locally from legacy devices.
2. Securely encrypt and enforce TLS 1.3 for outgoing connections to Mimecast.

This approach ensures that even older devices can continue to function while protecting your data during email delivery over the internet. Below, we’ll walk you through a step-by-step guide to configure stunnel for this purpose.

Step-by-Step Configuration

Here’s how to configure stunnel to accept plaintext connections locally and enforce TLS 1.3 when sending emails to Mimecast’s outbound SMTP servers (xx-smtp-outbound-1.mimecast.com and xx-smtp-outbound-2.mimecast.com).

1. Install Stunnel

First, install stunnel on your server. On a Linux-based system, you can install it using the following commands:

sudo apt update
sudo apt install stunnel4

2. Generate a Stunnel Certificate

Stunnel requires a certificate for secure communication. You can generate a self-signed certificate by running:

openssl req -new -x509 -days 365 -nodes -out stunnel.pem -keyout stunnel.pem
chmod 600 stunnel.pem

Move the stunnel.pem file to a secure location, such as /etc/stunnel/.

3. Configure Stunnel

Create a configuration file for stunnel. Name it stunnel.conf and place it in /etc/stunnel/. Here’s an example configuration tailored for Mimecast:

# Stunnel Configuration

# Use the generated certificate
cert = /etc/stunnel/stunnel.pem

# Enforce TLS 1.3 for outgoing connections
sslVersion = TLSv1.3

# Debugging (set to 5 for detailed logs during troubleshooting)
debug = 3
output = /var/log/stunnel.log

# Service 1: Connect to Mimecast's primary SMTP server
[xx-smtp-outbound-1]
client = yes
accept = 127.0.0.1:2525  # Local port for plaintext connections
connect = xx-smtp-outbound-1.mimecast.com:587

# Service 2: Connect to Mimecast's secondary SMTP server
[xx-smtp-outbound-2]
client = yes
accept = 127.0.0.1:2526  # Local port for plaintext connections
connect = xx-smtp-outbound-2.mimecast.com:587

4. Start Stunnel

Enable and start the stunnel service:

sudo systemctl enable stunnel4
sudo systemctl start stunnel4

To verify that stunnel is running and listening on the specified ports (2525 and 2526), use the following command:

sudo netstat -tuln | grep stunnel

5. Update Your Devices

Configure your legacy on-premises devices to send emails to 127.0.0.1 on ports 2525 (for the primary server) or 2526 (for the secondary server). These local connections will be forwarded by stunnel to Mimecast with TLS 1.3 encryption.

6. Test the Configuration

To ensure everything is working as expected, you can test the local connection using telnet:

telnet 127.0.0.1 2525

Once connected, send a test email through your legacy device or email client configured to use the stunnel proxy. Verify that the email is successfully delivered.

Why Choose Stunnel?

Using stunnel provides several key benefits:

• Compatibility: Legacy devices can continue to use plaintext or older TLS protocols without modification.
• Security: Outgoing connections to Mimecast are encrypted with TLS 1.3, ensuring compliance with modern security standards.
• Simplicity: Stunnel is lightweight, easy to configure, and doesn’t require significant changes to your infrastructure.

Final Thoughts

In today’s cybersecurity landscape, it’s critical to balance compatibility with legacy systems and modern security requirements. Tools like stunnel provide an elegant solution, enabling you to secure your email delivery while accommodating older devices.

By following the steps outlined in this article, you can enforce TLS 1.3 for your email delivery via Mimecast, ensuring both security and compliance. If you have any questions or run into challenges with this setup, feel free to leave a comment below or reach out—we’re here to help!

Let’s keep email delivery secure, reliable, and future-proof.

Strengthening Email Security: Understanding SMTP-DANE and DNSSEC

In today’s digital world, email remains a primary business communication tool, but it’s also one of the biggest targets for cyber threats. As email-based attacks become more sophisticated, organizations need to adopt security measures that protect communications from interception and impersonation. Two critical technologies that enhance email security are DNSSEC (Domain Name System Security Extensions) and SMTP-DANE (DNS-based Authentication of Named Entities for SMTP).

While these terms may sound technical, understanding them is key to explaining their value to customers. This guide will break them down in a clear and practical way.

---

What is DNSSEC?

The Domain Name System (DNS) acts as the internet’s phonebook, translating human-friendly domain names like example.com into numerical IP addresses. However, traditional DNS lacks built-in security, making it vulnerable to threats like DNS spoofing, which can redirect users to fraudulent websites.

DNSSEC (Domain Name System Security Extensions) was developed to prevent these attacks. It verifies the authenticity and integrity of DNS records by using digital signatures, ensuring that when someone looks up a website or email server, they are getting the real, untampered result.

Key Business Benefit: Prevents cybercriminals from manipulating DNS records to launch phishing attacks or intercept communications.

---

What is SMTP-DANE?

While DNSSEC secures domain lookups, SMTP-DANE (DNS-based Authentication of Named Entities for SMTP) builds on this security to protect email communication. It ensures that emails are delivered securely to the intended recipient’s mail server, reducing the risk of interception.

The Problem SMTP-DANE Solves

Most email servers rely on STARTTLS, a protocol designed to encrypt emails during transit. However, this system has a major weakness: it does not verify the authenticity of encryption certificates. Attackers can exploit this gap through downgrade attacks or man-in-the-middle attacks, where they strip away encryption and intercept sensitive emails.

How SMTP-DANE Works

SMTP-DANE solves this problem by using TLSA records stored in DNSSEC-protected DNS entries. These records verify the legitimacy of a recipient’s email server certificate before sending an email, ensuring it is delivered securely.

Key Business Benefit: Prevents cybercriminals from intercepting or tampering with email communication by ensuring encryption certificates are legitimate and enforced.

---

Why DNSSEC and SMTP-DANE Work Together

While DNSSEC and SMTP-DANE serve different functions, they are complementary:

• DNSSEC secures the DNS system, preventing attackers from manipulating DNS records.
• SMTP-DANE secures email transport, ensuring encryption certificates cannot be faked or bypassed.

SMTP-DANE cannot function without DNSSEC, making them a critical pair for businesses that want to secure both web traffic and email communication.

---

Why Businesses Should Care About SMTP-DANE

Adopting SMTP-DANE isn’t just about technical security—it has direct business benefits that resonate with sales teams and customers alike:

1. Protects Business Reputation
   Prevents email spoofing and impersonation, reducing the risk of phishing attacks that can damage brand trust.

2. Strengthens Customer Relationships
   Ensures customers receive genuine, secure emails from your business, reducing the risk of fraud and increasing confidence in communications.

3. Enhances Compliance Readiness
   Many industries, including finance and healthcare, have strict security requirements. SMTP-DANE helps businesses align with evolving regulations.

4. Reduces Cybersecurity Risks
   Lowers the risk of email interception, protecting sensitive business and customer data from prying eyes.

5. Future-Proofs Email Security
   As cyber threats evolve, businesses that implement SMTP-DANE position themselves ahead of security challenges.

---

Industries & Regions Leading Adoption

Certain industries and regions have been early adopters of DNSSEC and SMTP-DANE due to their heightened security needs:

Industries Benefiting the Most:

• Financial Services: Protects customer transactions and prevents banking fraud.
• Healthcare: Safeguards sensitive patient data and ensures compliance with regulations like GDPR and HIPAA.
• E-Commerce: Secures customer information, preventing email-based fraud.
• Government & Defence: Protects classified communication from cyber threats.

Regions Leading the Way:

• APAC (Asia-Pacific): Countries like Australia and Singapore have been strengthening cybersecurity regulations, making technologies like SMTP-DANE increasingly relevant.
• Europe: Driven by GDPR and strict data protection laws, many organizations have already adopted DNSSEC and SMTP-DANE.
• United States: The U.S. government mandates DNSSEC for federal domains, pushing adoption in both the public and private sectors.

---

Final Thoughts

Email security is no longer just a technical concern—it’s a business necessity. SMTP-DANE, backed by DNSSEC, ensures that organizations can confidently send and receive emails without fear of interception or impersonation.

For sales professionals, understanding these technologies provides a valuable differentiator when discussing security solutions with customers. By framing the conversation around trust, brand protection, and compliance, businesses can see SMTP-DANE not as an optional upgrade, but as an essential tool in today’s threat landscape.