Data Processing Agreement

Version 1.0, effective 28 August 2026

This Data Processing Agreement (the DPA) forms part of the Master Service Agreement (the MSA) between Meridian Interface Ltd, trading as Mailbox Fleet (Company No. 16150489, Park House, Wilmington Street, Leeds, LS7 2BP; ICO registration ZC101614) (Mailbox Fleet, we, us) and the Customer. It sets out the terms required by Article 28 of the UK GDPR for the personal data we process on the Customer's behalf. Capitalised terms not defined here have the meaning given in the MSA.

1. Definitions

1.1 Data Protection Law means the UK GDPR, the Data Protection Act 2018, the Privacy and Electronic Communications Regulations 2003 (PECR) and, where they apply to the Customer's recipients, the EU GDPR and equivalent laws.

1.2 Controller, processor, data subject, personal data, personal data breach, processing and supervisory authority have the meanings given in the UK GDPR.

1.3 Prospect Data means personal data about the Customer's recipients and prospects that passes through the Service: recipient email addresses, names and job titles in message headers, message content the Customer sends, replies received into Mailboxes, and the delivery telemetry generated for each message.

1.4 Customer Personal Data means Prospect Data and any other personal data we process as the Customer's processor under this DPA.

1.5 Sub-processor means a third party we engage to process Customer Personal Data.

1.6 Suppression List has the meaning given in the MSA and section 6 of the Privacy Policy.

2. Roles

2.1 The Customer is the controller of Prospect Data. The Customer decides who to contact, what to send and why. We process Prospect Data only as the Customer's processor, for mail transit through the Mailboxes and Sending IP, storage of Mailbox contents, and the logging and telemetry needed to operate the Service.

2.2 We are an independent controller of the data we decide to collect for our own purposes: account and Verification data (identity, sanctions and Companies House checks), billing data, the platform-wide Suppression List, aggregate deliverability telemetry, and website data. That processing is described in the Privacy Policy and is outside this DPA, except as clause 9.3 provides.

2.3 Where the Customer operates a Fleet for an End Client under clause 8 of the MSA, the Customer warrants that it is authorised by the End Client to give the instructions in this DPA on the End Client's behalf and that the End Client's own arrangements with the Customer permit our processing.

3. Details of the processing

3.1 Subject matter. The transit, storage and logging of business-to-business email sent and received through Mailboxes provisioned for the Customer.

3.2 Duration. The term of the MSA, plus the deletion period in clause 9.

3.3 Nature and purpose. Receiving messages submitted by the Customer's Sending Tool, signing them (DKIM), transmitting them to recipients' mail servers, storing sent and received mail in the Mailbox, recording delivery outcomes, bounces, complaints and opt-outs, enforcing Caps and the Suppression List, and running inbox-placement tests. We do not read message bodies for our own purposes and we do not use Prospect Data to build, enrich or sell any dataset.

3.4 Categories of data subject. Individuals at the businesses the Customer contacts (prospects and their colleagues); the Customer's own staff and contractors who operate the Mailboxes; and anyone who replies to a Mailbox.

3.5 Categories of personal data. Names, work email addresses, job titles and employer; message headers, subject lines and body content written by the Customer or the recipient; delivery metadata (timestamps, IP addresses of receiving servers, bounce and complaint codes); and unsubscribe and complaint events. No special category data is intended to be processed, and the Customer must not send it through the Service.

4. Our obligations as processor

4.1 Instructions. We process Customer Personal Data only on the Customer's documented instructions. The MSA, the Acceptable Use Policy, the Sending Policy and this DPA are the Customer's complete instructions; submitting a message to a Mailbox is an instruction to transmit it. We will tell the Customer if we believe an instruction breaches Data Protection Law, and we may suspend processing under that instruction until it is resolved.

4.2 Legally required processing. If UK or EU law requires us to process Customer Personal Data otherwise than on instruction, we will tell the Customer before doing so unless the law prohibits it.

4.3 Confidentiality. Only personnel who need access to operate the Service have it, and every one of them is bound by a written confidentiality obligation.

4.4 Security. We implement the technical and organisational measures in Annex 1, and any further measures needed to provide a level of security appropriate to the risk under Article 32 of the UK GDPR. We may update Annex 1 provided the overall level of protection does not fall.

4.5 Data subject requests. We notify the Customer without undue delay if a data subject contacts us directly about Prospect Data, and we do not respond except to acknowledge and redirect, unless the Customer instructs us or the law requires it. We provide reasonable assistance, through the Portal where possible, for the Customer to answer access, rectification, erasure, restriction, portability and objection requests.

4.6 Objections to marketing. Opt-outs are different. Because PECR requires a recipient's opt-out to be honoured, and because we enforce opt-outs platform-wide, an unsubscribe, complaint or "stop" reply received through the Service is added to the Suppression List immediately and without the Customer's instruction. Clause 9.3 explains what happens to those entries.

4.7 Assistance. Taking account of the nature of the processing and the information available to us, we assist the Customer in meeting its obligations under Articles 32 to 36 of the UK GDPR (security, breach notification, data protection impact assessments and prior consultation). We may charge reasonable costs for assistance beyond what the Portal provides.

4.8 Records and information. We make available the information reasonably necessary to demonstrate compliance with Article 28, and we maintain the records of processing required of us as processor.

5. Sub-processors

5.1 General authorisation. The Customer authorises us to engage the Sub-processors listed in clause 5.2 and any replacement or additional Sub-processor appointed under clause 5.3.

5.2 Current Sub-processors.

5.3 Changes. We will give the Customer at least 30 days' written notice (by email to the account owner and in the Portal) before adding or replacing a Sub-processor that will process Customer Personal Data. The Customer may object in writing within that period on reasonable data-protection grounds. We will then work with the Customer in good faith to address the objection; if we cannot, the Customer may terminate the affected Fleet under clause 7.2 of the MSA without penalty, and we refund any Fees prepaid for the period after termination.

5.4 Flow-down. Every Sub-processor is bound by a written contract imposing data-protection obligations at least as protective as those in this DPA. We remain fully liable to the Customer for our Sub-processors' performance.

6. International transfers

6.1 Prospect Data in transit and at rest on our mail servers stays in Germany or Finland (Hetzner) and, for the control plane, in the EU (Supabase). The UK Government has found the EEA to provide adequate protection, so these transfers need no further safeguard.

6.2 Where a Sub-processor in clause 5.2 is in the United States, the transfer relies on the UK Extension to the EU-US Data Privacy Framework where the Sub-processor is certified, and otherwise on the ICO's International Data Transfer Agreement (IDTA) or the ICO Addendum to the EU Standard Contractual Clauses, together with a transfer risk assessment. Copies of the relevant safeguard are available on request.

6.3 Messages the Customer sends to recipients outside the UK are transferred by the Customer as controller; delivering a message to the recipient's mail server is inherent in the Customer's instruction and is not a transfer by us.

6.4 We will not transfer Customer Personal Data to any other country without an appropriate safeguard under Chapter V of the UK GDPR.

7. Personal data breach

7.1 We notify the Customer without undue delay and in any event within 48 hours of becoming aware of a personal data breach affecting Customer Personal Data, by email to the account owner.

7.2 The notification includes, so far as known at the time: the nature of the breach, the categories and approximate number of data subjects and records affected, the likely consequences, the measures taken or proposed, and a contact point. We provide further information in phases as it becomes available.

7.3 We cooperate with the Customer's investigation and any notification the Customer makes to the ICO or to data subjects. Notification by us is not an admission of fault.

8. Audit

8.1 We make available on request, no more than once a year unless a breach or a supervisory authority requires otherwise, the information reasonably necessary to demonstrate compliance with this DPA, including summaries of any third-party security assessments we hold and a completed security questionnaire.

8.2 If that information is not sufficient, the Customer (or an independent auditor bound by confidentiality and not a competitor of ours) may audit our processing on at least 30 days' written notice, during business hours, no more than once in any 12 months, without disrupting the Service or exposing other Customers' data. Physical inspection of Sub-processor data centres is limited to the audit rights those Sub-processors offer. The Customer bears its own audit costs and reimburses our reasonable costs where the audit finds no material non-compliance.

9. Return and deletion

9.1 On termination of the MSA, or on the Customer's instruction for a particular Fleet, we delete Customer Personal Data held in the Mailboxes and control plane within 30 days. Before deletion the Customer may export Mailbox contents through standard mail protocols (IMAP) using its Mailbox credentials.

9.2 Backups are deleted on their normal rotation, no later than 90 days after termination, and are not accessed in the meantime except to restore the Service.

9.3 Suppression List exception. Suppression entries created from unsubscribes, complaints and "stop" replies are retained after termination. We hold them as controller, not on the Customer's behalf, because PECR obliges us and the Customer to honour those opt-outs permanently and deleting them would defeat their purpose (Article 6(1)(c) UK GDPR; section 6 of the Privacy Policy). Entries are redacted to a cryptographic hash on a data subject's erasure request so that the block continues to work without the readable address being held.

9.4 We may also retain the minimum Customer Personal Data required by law (for example in billing records) for as long as the law requires, and delivery telemetry in aggregated, non-identifying form.

10. Liability and precedence

10.1 Each party's liability under this DPA is subject to clause 12 of the MSA, save that nothing limits either party's liability to data subjects or supervisory authorities under Data Protection Law.

10.2 If this DPA conflicts with the MSA or any other document, this DPA prevails for personal data.

11. Term and changes

11.1 This DPA applies from the Effective Date and for as long as we process Customer Personal Data, including the deletion period in clause 9.

11.2 We may update this DPA where Data Protection Law, ICO guidance or our Sub-processors change, following the notice process in clause 18.2 of the MSA. Changes to Annex 1 follow clause 4.4 and changes to Sub-processors follow clause 5.3.

Annex 1: Technical and organisational measures

A. Infrastructure and hosting

• Mail servers run on dedicated Hetzner hardware in Germany and Finland; each Customer has its own Sending IP and DKIM keys, so no Customer's reputation or mail flow is shared with another.
• Servers are hardened, patched on a defined schedule, and reachable for administration only over SSH with key authentication from named operator accounts; password login is disabled.
• Firewalls default to deny; only mail, DNS and administrative ports are open.

B. Encryption

• Mail is transmitted with opportunistic TLS (STARTTLS) and delivered with TLS wherever the receiving server supports it; MTA-STS and TLS-RPT are published for Domains.
• Mailbox storage and control-plane databases are encrypted at rest. All Portal and API traffic uses TLS 1.2 or later.
• Credentials and API keys are held in a secrets store, never in source code or application configuration checked into version control.

C. Access control

• Each Customer can read only its own records: the control plane enforces row-level security in the database, so a query from one Customer's session cannot return another Customer's data.
• Least-privilege service credentials; no shared administrative keys in application code; production access limited to named operators with multi-factor authentication.
• Access is reviewed when staff join, change role or leave, and revoked the same day on departure.

D. Sending controls that protect data subjects

• Per-Mailbox daily Caps enforced at the server, with an automated Ramp that cannot be bypassed.
• A working one-click unsubscribe (RFC 8058 List-Unsubscribe headers) is required on every message and enforced at platform level; opt-outs are effective immediately and require no sign-in.
• The Suppression List is append-only and checked on every send.
• SPF, DKIM and DMARC published on every Domain; automatic pausing of Domains that trip spam-trap, complaint or blacklist thresholds.

E. Logging and monitoring

• Delivery attempts, outcomes, complaints and opt-outs are logged with timestamps. Compliance-relevant events (Verification decisions, suppression entries, pauses, credential issuance) are written to append-only audit records.
• Infrastructure and blacklist monitoring runs continuously with alerts to operators.

F. Data minimisation and retention

• We do not read message bodies for our own purposes; telemetry stores headers and outcomes, not content.
• Identity documents and biometric data never enter our systems (held and redacted at Stripe). Retention periods are those in section 9 of the Privacy Policy and clause 9 of this DPA.

G. Resilience and backup

• Encrypted backups of the control plane on a defined schedule, tested restores, and infrastructure defined as code so servers can be rebuilt from a known state.

H. Organisational

• Named person responsible for data protection; staff confidentiality obligations and data-protection training; documented incident-response procedure supporting the 48-hour notification in clause 7; Sub-processors contracted and reviewed under clause 5.

Signature

Meridian Interface Ltd trading as Mailbox Fleet

Signed: ______________________ Name and title: ______________________ Date: [Date]

[Customer legal name] (Company No. [Customer company number])

Signed: ______________________ Name and title: [Signatory name and title] Date: [Date]