This document gives an overview of the Mailhardener Information Security Management System (ISMS). One of the core principles of Mailhardener is transparency towards customers, of which information security should not be an exception. As a result this document is likely more detailed than what is typically seen in a security statement.
This document should address any questions or concerns that organizations looking to implement Mailhardener may have. However, if you have additional questions, please contact us at security@mailhardener.com
This document is subject to change. Mailhardener continuously works on improving its information security management system (ISMS) for improved security, introduction of new or improved services, changes in the security landscape, updated best practices or customer concerns.
Mailhardener is an email hardening platform used to monitor and harden email infrastructure for fraud prevention, deliverability improvement, third-party sender compliance and secure (encrypted) email delivery enforcement. Additional hosting services are offered for MTA-STS policy hosting, BIMI asset hosting and SPF policy hosting.
Mailhardener is operated by Mailhardener B.V., registered at the Dutch Chamber of Commerce with registration number 92907814. For more information: see https://www.mailhardener.com/legal/mailhardener-vendor-information
Mailhardener is an EU company, subject to, adhering to and compliant with European GDPR legislation.
Mailhardener is designed to store minimal data, only when functionally necessary. By design, Mailhardener does not process third-party PII. DMARC reports are designed to never contain PII, possibly except for DMARC failure (also known as ‘forensic’, or ‘ruf’) reports, which are disabled by default in the Mailhardener suite.
All data is exclusively stored on infrastructure operated by Mailhardener. All Mailhardener services are hosted in Amsterdam, the Netherlands. All data is encrypted at rest, all transport is exclusively performed using encrypted connections.
All Mailhardener services are designed for resilience, but also in such a way that prolonged service outages shall not affect email delivery for customer domains.
Automated procedures are used to create backups, which are encrypted and stored both on-site and off-site. Automated procedures are used to test recovery of backups. A Disaster Recovery plan is documented and periodically practiced. A Business Continuity plan is documented and periodically revised.
Mailhardener employees can access customer data on a need to know basis, principle of least privilege. All Mailhardener employees are required to use SSO with 2FA.
Mailhardener operates following industry best practices and guidelines. An extensive ISMS (Information Security Management System) is in place, and being improved upon continuously. Mailhardener operates following ISO27001 guidelines, for which Mailhardener is currently awaiting accreditation.
If enabled for a domain, Mailhardener receives, processes and enriches reports in the following formats:
DMARC aggregate reports (rfc7489), also known as ‘rua’, or simply ‘DMARC reports’ may be sent by receiving email services who receive email that is sent on behalf of the monitored domain (outbound email). DMARC aggregate reports contain information on email sent on behalf of the domain, as interpreted by the receiver. DMARC aggregate reports contain the sending MTA IP-address and email volume over a specified time period, as well as the DMARC verdict (the disposition) as determined by the receiver. Additional information on the applied authentication methods (SPF, DKIM) and subsequent verification results may be included in the reports. DMARC aggregate reports do not contain PII by design.
The XML structure of a DMARC aggregate report is defined in rfc8460, and typically contains:
DMARC (rfc7489) failure reports, formerly known as ‘forensic reports’ and also known as ‘ruf’ reports may be sent by a receiver if email sent on behalf of the domain was received but failed to authenticate by either SPF or DKIM. A DMARC failure report may contain a verbatim copy of the original email message, and may thus contain PII such as, but not limited to, the sender email address, the receiver email address, the email subject and the email body. Due to the potential privacy impact that DMARC failure reports pose, DMARC failure reports are not enabled by default in the Mailhardener email hardening suite. A domain administrator may enable DMARC failure reports to be processed by Mailhardener if the privacy impact is acceptable within the organization. Also, due to the potential privacy impact there are very few DMARC reporters that actually send DMARC failure reports. DMARC failure reports are therefore very rare, even when enabled for a domain they may never be received.
DMARC failure reports do not have a formal format, but typically contain:
SMTP TLS aggregate reports (rfc8460) may be sent by sending email services who deliver email to the domain (inbound email). An SMTP TLS report contains TLS session results for email delivered to the domain over a specified time period. An SMTP TLS report contains the number of successful and unsuccessful TLS sessions with the inbound email exchange (MX) of the domain, as well as failure details. Failures may contain information on the MTA (SMTP STARTTLS), MTA-STS (rfc8461) and DANE (rfc7672). SMTP TLS reports do not contain PII by design.
The JSON structure of SMTP TLS reports is defined in rfc8460, and typically contains:
Mailhardener is designed with minimal data storage principles. Following GDPR guidelines, Mailhardener only stores information that is required for functional or legal compliance.
Mailhardener stores the following customer data:
All data (except encrypted off-site backups, see below) is exclusively being stored on servers operated by Mailhardener. The servers are physically located in the NorthC datacenter in Amsterdam, the Netherlands. Our hosting partner is TransIP.
NorthC Datacenters (NorthC Group B.V.)
Purpose: Data center operator
Country: Netherlands
Location: Amsterdam, the Netherlands
Accreditations: ISO 27001, ISO 9001, ISO 14001, PCI DSS, NEN 7510, ISAE 3402 type-II assessed
Attestation: https://www.northcdatacenters.com/en/about-us/certifications/
Website: https://www.northcdatacenters.com/
TransIP (team.blue nl B.V.)
Purpose: hosting partner
Country: the Netherlands
Accreditations: ISO 27001:2013,ISO 9001:2015, NEN 7510:2017
Attestation: https://www.transip.eu/legal-and-security/certifications/
Website: https://www.transip.nl
Backups are copied off-site, which is handled by our encrypted backup service provider Tarsnap. Tarsnap uses Amazon S3 storage locations.
Tarsnap Backup Inc.
Purpose: backup service provider
Country: USA
Website: https://www.tarsnap.com
Report data (DMARC, SMTP TLS) are stored for a minimum period depending on the subscription tier, for details see: https://www.mailhardener.com/legal/service-level-agreement
User account information is retained for as long as the user-account exists. Removal of a user account will automatically destroy any related information (name, email address, audit information).
Customer information is retained for as long as the customer environment exists. After the account is closed the customer details will be removed after 30 days, or for as long as there are unpaid invoices. The Dutch tax authorities require organizations to store financial information (customer details, invoices, transactions) for a minimum of 10 years.
Backups are retained for 7 days. Encryption keys for backups are rotated every 90 days and removed after 7 days. (see chapter: backups)
Following industry best practices Mailhardener exclusively uses TLS certificates with a short lifespan, currently using a maximum lifetime of 90 days. This applies for certificates used by Mailhardener services, as well as MTA-STS certificates the Mailhardener may manage. Upon renewal of the certificates new cryptographic keys are always re-generated, old keys are retained for a maximum of 7 days for disaster recovery purposes (certificate rollback).
For the ‘Mailhardener for MSP’ product, Mailhardener may process third-party personally identifiable information (PII) in case the MSP creates user-accounts for their customers. The MSP may do so to allow their customer to access their own isolated Mailhardener environment. This may be performed automatically via integration with Professional Services Automation (PSA) software. In case third-party user accounts are created Mailhardener stores the name, email address and login credentials of the third-party user.
For regular (non-MSP) customers, Mailhardener does not process third-party data by design. In GDPR terms Mailhardener is not considered a sub-processor, nor does Mailhardener use data sub-processors.
For functional and legal purposes Mailhardener does share first-party (customer) data with the following parties:
Stripe, Inc.
Country: USA
Purpose: billing, payment processing
Data shared: customer organization details including organization name, address, VAT number, email address, payment accounts
Accreditation: PCI-DSS, SOC-2
Attestation: https://docs.stripe.com/security
Website: https://www.stripe.com
Moneybird B.V.
Country: Netherlands
Registration: 58209344
Purpose: financial administration
Data shared: customer organization details including organization name, address, VAT number, invoices.
Accreditations: ISO27001
Attestation (Dutch): https://www.moneybird.nl/blog/moneybird-is-iso-27001-gecertificeerd/
Website: https://www.moneybird.com
Sentry, Inc.
Country: USA
Purpose: error/exception tracking
Data shared: error events.
Events are always scrubbed of any potential PII, including (but not limited to): IP-addresses, email address, username, passwords, payment information.
Accreditations: ISO27001, SOC-2
Attestation: https://docs.sentry.io/security-legal-pii/security/soc2/
Website: https://www.sentry.io
Google LLC
Country: USA
Purpose: Google Workspace (office email, office software)
Data shared: emails that are sent to or from Mailhardener employees
Accreditations: ISO/IEC 27001, SOC-2, etc.
Attestation: https://cloud.google.com/compliance
Website: https://workspace.google.com
HubSpot, Inc.
Country: USA
Purpose: Sales activity management
Data shared: emails exchanged between customers and the Mailhardener Sales team.
Name and email address of customers or potential customers.
Accreditations: ISO27001, SOC-2
Attestation: https://legal.hubspot.com/security
Website: https://www.hubspot.com
Customer data can be accessed exclusively through the Mailhardener API, whether it is used by customers via the Mailhardener Dashboard, or by Mailhardener employees for administrative tasks.
The Mailhardener is the primary and exclusive means of access to customer data.
The Mailhardener API information security features are:
Following industry best practices Mailhardener exclusively uses TLS certificates with a short lifespan, currently using a maximum lifetime of 90 days. Upon renewal of the certificates new cryptographic keys are always re-generated.
TLS certificates are provisioned and renewed using automated processes, ensuring that no human handling of key material is needed.
Validator ratings:
Database backups are automated and created daily (once per 24 hours). The backup system is designed to never require handling of data by a human. Newly created backups are always encrypted and compressed, then copied to at least two different physical storage instances within the datacenter. Additionally, an encrypted backup is uploaded to an off-site storage facility. Backups are retained for a maximum of 7 days.
Every backup file is also automatically tested by importing it into an ephemeral (temporary) database instance. After importing is complete, an automated integrity check is performed to ensure the backup file was successfully imported and complete. The temporary database instance is always destroyed after use. This process happens within an isolated server instance in the same datacenter.
Backups are exclusively distributed via network medium, using encrypted transport on top of the already encrypted backup archive where applicable. Backups are never copied to or distributed using portable storage mediums (for example: USB-sticks).
For disaster recovery reasons a copy of the backup encryption key is stored off-site in an encrypted archive, requiring a physical hardware security key to decrypt. The backup encryption key is used during disaster recovery simulations, see chapter ‘disaster recovery’.
In order to access any customer data via the Mailhardener API, authorization is always required. Mailhardener currently support authorization via the following mechanisms:
Mailhardener supports password authentication with optional TOTP 2nd-factor authentication. Passwords are exclusively stored in hashed form, and include a ‘salt’. Hashing strength is performed conforming to the OWASP guidelines, and re-evaluated periodically. Mailhardener customers can enforce 2FA for their environment, optionally requiring 2FA only for selected access levels. It is possible for Mailhardener customers to enforce SSO, thus effectively disable/prevent password authentication
Mailhardener supports SSO login using OpenID Connect. Supported identity providers are:
Mailhardener customers can enforce SSO login (denying password login) if preferred. SSO can be further secured using TOTP 2nd-factor authentication. Users using password authentication can migrate to SSO by logging in once using the SSO provider, the account will then automatically be migrated.
For machine-2-machine API access Mailhardener supports authentication using OpenAuth 2.0, using the ‘client credentials’ flow. Client credentials can be managed by the customer via the Mailhardener Dashboard application.
The Mailhardener Dashboard is the primary application used by Mailhardener customers to access data and manage their account. The Mailhardener Dashboard application exclusively accesses data through the Mailhardener API. See chapter: data transport.
The Mailhardener dashboard is a web-based application, designed to be accessible via any modern browser.
The Mailhardener Dashboard application security features consist of (but is not limited to):
Mailhardener offers MTA-STS (Mail Transfer Agent Strict Transport Security) policy hosting service which allows customers to easily adopt the MTA-STS (rfc8461) standard to protect domains against man-in-the-middle attacks that could allow for TLS downgrade attacks or DNS rerouting.
MTA-STS augments the domain by publishing a policy file that contains the inbound email (MX) hostnames, alongside a TLS requirement policy (the ‘mode’) using an HTTP-over-TLS (HTTPS) transport medium. An MTA-STS assertion record is placed in the DNS to signal senders that the domain uses MTA-STS, the assertion record is also used for cache-invalidation of the policy file.
For Mailhardener to host the MTA-STS policy file, two CNAME records are to be placed in the DNS zone of the domain. This allows Mailhardener to control the DNS assertion record, as well as host the HTTPS service required to serve the policy file. When the CNAME records are detected, Mailhardener will provision the MTA-STS policy service for the domain, which does require a TLS PKI certificate. Mailhardener will automatically provision and manage the required TLS certificate for the customer domain at ‘mta-sts.[domain]’. Mailhardener cannot create, manage or otherwise influence the certificates that may exist for the domain root, or subdomains/labels other than ‘mta-sts’.
The Mailhardener MTA-STS policy hosting service features:
Mailhardener offers BIMI asset hosting. BIMI assets include the verified mark certificate (VMC) and the organization mark (logo) in SVG format. Customers can upload their VMC via the Mailhardener dashboard. VMC files do not contain private key material and are considered safe to distribute. Mailhardener automatically extracts the embedded mark (SVG logo file) from the VMC after uploading, and hosts both the VMC and SVG with binary equivalence, as required per the BIMI standard.
The Mailhardener BIMI asset hosting service features:
All Mailhardener services are designed with availability and redundancy in mind. Each of the customer facing services (API, reporting endpoints, MTA-STS hosting, BIMI asset hosting, Mailhardener Dashboard, in- and outbound SMTP services) are hosted on at least two different physical instances, and are load-balanced. All services are accessible via both IPv4 and IPv6.
Software updates and deployments are performed in a ‘staggered’ procedure, ensuring no or minimal downtime and adequate rollback possibilities.
Mailhardener MTA-STS policy hosting service is designed with minimal impact in mind in event of a catastrophic failure of the service. The Mailhardener MTA-STS service features an extended cache lifetime of 2 weeks (604800 seconds), conforming with industry and governmental guidelines.
For more information on service availability please refer to the Mailhardener Service Level Agreement (SLA): https://www.mailhardener.com/legal/service-level-agreement
In order to reduce and mitigate vulnerabilities, the Mailhardener infrastructure is designed with the following principles:
Mailhardener IT administrators are responsible for keeping system software up-to-date in order to mitigate security vulnerabilities (see chapter: vulnerability management), ensure compatibility and to retain vendor support.
The patch management policy is as follows:
Mailhardener organizes periodic penetration testing ('pentesting') sessions where members of the software development team, and IT administrators are challenged to test the Mailhardener software for vulnerabilities.
Mailhardener also encourages customers and potential customers to perform their own penetration testing.
Mailhardener operates a vulnerability disclosure program for security researchers to responsibly disclose any vulnerability found or concern they may have.
If you discover a security or privacy vulnerability, please disclose this responsibly via security@mailhardener.com.
Mailhardener is a SaaS vendor, as such, IT disaster recovery and business continuity are tightly coupled, see chapters 'disaster recovery' and 'service continuity' for more information.
Mailhardener is designed with automation as a primary objective for both competitiveness and business continuity. As a result, Mailhardener is capable of sustained operation with minimal human resources or human intervention.
All processes are designed so that Mailhardener employees can work efficiently from any physical location, minimizing reliance on location availability. As part of good security practice and business continuity, no software, documents or other digital assets are required by Mailhardener employees to perform day-to-day tasks, so that in the event of loss, damage or malfunction of a device the impact on business continuity shall be minimal.
Mission-critical systems are always designed with redundancy as a primary requirement. Redundancy is designed and periodically assessed for physical availability properties (hardware, geographic location, etc.), logical availability properties (software, service failover, etc.), and administrative accessibility (accounts, responsibilities, etc.). Periodic assessments are made to identify and remove any single-point-of-failure in equipment, infrastructure design, human resources, access management, payment account, suppliers or any other reliance that may lead to service disruption.
Mission-critical infrastructure is designed so that the failure or any single instance shall not lead to loss of service, or loss of data. Software processes are continuously monitored by automated systems, and restarted in case of unresponsiveness (watchdog, heartbeat detection). To further ensure that all Mailhardener services are resilient to instance failures, a 'Chaos Monkey' process may be used to randomly terminate instances in production.
Even with the best business continuity designs, a catastrophic disaster beyond our control may still result in a service outage. In order to minimize the impact of a disaster, a Disaster Recovery plan is in place and periodically practiced.
The Disaster Recovery plan contain, but is not limited to:
Mailhardener services are built upon open standards and, where acceptable, open-source software. The Mailhardener software stack is designed to be cloud-vendor agnostic, this allows Mailhardener to migrate to different hosting environments on short notice.
A copy of the off-site backup encryption key is stored at a (different) off-site location in case of catastrophic loss of the encryption key within the Mailhardener data center. See chapter ‘backups’. This key allows the recovery of the encrypted offsite backup in case of catastrophic loss of the Mailhardener infrastructure (including the original encryption key) at the data center.
Any cryptographic key material should be considered tainted after a catastrophic disaster. All cryptographic key material shall be re-generated upon disaster recovery, no cryptographic material should ever be reused once deployed.
Mailhardener systems are designed in such a way that even in the event of catastrophic failure of the Mailhardener infrastructure the impact on customers domains are minimal.
Mailhardener hosted services (rfc8461 MTA-STS policy hosting, BIMI asset hosting) are designed and configured for optimal caching strategies, allowing maximal resilience while still retaining the ability to instantly change policies or assets. By leveraging the resilience of the internet protocols Mailhardener hosted services will remain effective for an extended period, even in the event of catastrophic failure.
Furthermore, all services are designed in such a way that unavailability of said service shall not impact a customer domain email infrastructure in any way that could lead to undeliverable email.
| Service | Impact of sustained outage |
|---|---|
| rfc8461 MTA-STS policy hosting | Reduced protection against downgrade attacks after caching period expires (2 weeks) |
| BIMI asset hosting | BIMI mark not shown to recipients, unless cached (up to 12 months) |
| Frontend HTTP services | Inability to access Mailhardener website, dashboard and inspection tools |
| rfc7489, rfc8460 reporting endpoints | Delayed delivery of reports, potential loss of reports after 48 hours |
| Mailhardener API | Inability to use Mailhardener dashboard to change policy settings or review reports and domain status |
| rfc7489, rfc8460 report processing | Delayed processing of rfc7489 and/or rfc8460 reports, no data loss |
| Domain inspection process | Delayed warning on detected DNS changes |
Mailhardener employees can access customer data on a need to know basis, principle of least privilege.
The Mailhardener administrative interface is internal tooling designed for Mailhardener employees to perform administrative tasks such as billing or technical support. The Mailhardener administrative interface is browser based and only accessible for Mailhardener employees. All Mailhardener employees are required to use SSO with 2FA to access the Mailhardener administrative interface. The Mailhardener administrative interface features role-based access (IAM) which limits which information can be accessed, and which actions can be performed by the employee. The administrative interface uses the Mailhardener API to access customer data. The browser-based setup ensures a minimal attack surface and allows Mailhardener employees to use computer devices of choice (‘bring your own device’).
Mailhardener IT administrators may access the Mailhardener servers and database for administrative and maintenance purposes. Access and activity is logged for possible future forensics.
Mailhardener employees may access the financial administration to view and create invoices and financial transactions.
Mailhardener internal systems and processes should guarantee that no customer data should ever be permanently stored locally on employee devices, nor should there ever be a need for an employee to do this. This should reduce (or even fully mitigate) impact in case of misplacement, theft or catastrophic failure of said device.
Mailhardener B.V. is registered in the Netherlands. As an EU company Mailhardener B.V. is subject to, adhering to and compliant with European GDPR legislation.
Mailhardener is designed using the following principles:
In case of unauthorized access to Mailhardener data (a data-leak), Mailhardener is obligated to inform the Dutch authority of data protection (Autoriteit Persoonsgegevens) in a timely manner.
Mailhardener employees can access customer data on a need to know basis, principle of least privilege. See chapter ‘employee access’.
For more information on how Mailhardener handles personal data, please refer to the Mailhardener privacy statement: https://www.mailhardener.com/legal/privacy-statement
| Version | Since | Changes |
|---|---|---|
| 1.0 | 20-05-2024 | Initial document release |
| 1.0.1 | 14-06-2024 | Typographical corrections |
| 1.0.2 | 20-08-2024 | Typographical corrections |
| 1.0.3 | 23-08-2024 | Added external links to attestations for partners |
| 1.1.0 | 23-08-2024 | Added chapter 'Vulnerability management' |
| 1.2.0 | 01-12-2024 | Added details on Business Continuity and Service Continuity |