This Data Processing Agreement ("DPA") is part of the Terms of Service between the customer ("Customer") and Mailway Ltd., Budapest, Hungary ("Mailway"). It applies automatically to every customer — no signature required. If your procurement process needs a countersigned copy, request one via the contact form.
1. Roles and scope
For personal data contained in the email Customer relays through the service ("Customer Data"), Customer is the controller (or a processor acting for its own controllers, in which case Mailway acts as sub-processor) and Mailway is the processor under Art. 28 GDPR. Details of the processing are set out in Annex I.
2. Instructions
Mailway processes Customer Data only on Customer's documented instructions. The Terms, this DPA, and the configuration Customer sets in the console (projects, providers, routing rules, retention, suppressions, webhooks) constitute those instructions. Mailway will inform Customer if, in its opinion, an instruction infringes the GDPR.
3. Confidentiality
Persons authorized to process Customer Data are bound by confidentiality obligations. Access to Customer Data is restricted to what operating the service requires and is logged.
4. Security
Mailway implements the technical and organizational measures in Annex II(Art. 32 GDPR) and keeps them current with the state of the art. The live security posture is documented on the Trust page.
5. Sub-processors
Customer grants general authorization for the sub-processors listed at mailway.net/trust. Mailway will announce additions or replacements at least 30 days in advance (via the Trust page and email to team admins). Customer may object on reasonable data-protection grounds; if no resolution is found, Customer may terminate the affected service. Mailway imposes data-protection obligations on each sub-processor equivalent to this DPA and remains liable for their performance.
Note on providers: the email service providers Customer connects under the bring-your-own-keys model (e.g. Amazon SES, SendGrid) are Customer's own processors, engaged directly by Customer — they are not Mailway sub-processors.
6. Assistance
Taking into account the nature of the processing, Mailway assists Customer with data-subject requests (Arts. 15–22) — the console's search, export, and deletion surfaces are the primary mechanism — and with Customer's obligations under Arts. 32–36 (security, breach notification, DPIAs), providing the information reasonably necessary.
7. Personal data breach
Mailway notifies Customer without undue delay after becoming aware of a personal data breach affecting Customer Data, with the information required by Art. 33(3) GDPR as it becomes available, and cooperates on remediation.
8. Deletion and return
Message content is deleted continuously per the plan's retention window. On termination, Customer may export Customer Data during a 30-day wind-down; afterwards Mailway deletes remaining Customer Data within 30 days, unless EU or Hungarian law requires longer storage.
9. Audits
Mailway makes available the information necessary to demonstrate compliance with Art. 28 — the Trust page, this DPA, and on request written answers to reasonable security questionnaires. Customer may audit (itself or via an independent auditor bound to confidentiality) at most once per year, on 30 days' notice, during business hours, without access to other customers' data; Customer bears the cost.
10. International transfers
Customer Data is ingested, routed, and archived within the EU. Where a sub-processor processes limited supporting data outside the EEA, the transfer is protected by an adequacy decision (including the EU–US Data Privacy Framework) or Standard Contractual Clauses, as listed on the Trust page.
11. Liability and precedence
Liability under this DPA is subject to the limitations in the Terms. If this DPA conflicts with the Terms, this DPA prevails for data-protection matters.
Annex I — Details of processing
| Subject matter | Routing, delivery, observability, and archival of Customer's application email. |
| Duration | The term of the agreement, plus the wind-down in §8. |
| Nature and purpose | Receiving messages via SMTP/HTTP, routing them to Customer-connected providers with failover, recording delivery evidence, retention-bound archival, and the console surfaces built on those records. |
| Categories of data | Email content (headers, body, attachments — whatever personal data Customer chooses to send), sender and recipient email addresses, delivery metadata and provider delivery events, suppression entries. |
| Data subjects | Recipients and senders of Customer's email — typically Customer's users, customers, and staff. |
| Special categories | None intended; Customer must not route special-category data without appropriate safeguards on its side. |
Annex II — Technical and organizational measures
- Encryption in transit — TLS on every surface; SMTP authentication is refused before STARTTLS on the submission ports.
- Encryption at rest — provider credentials encrypted at the application layer; archived payloads stored compressed and encrypted.
- Access control — team isolation throughout; four-tier role model with per-project access allowlists; two-factor authentication (TOTP + WebAuthn) with optional team-wide enforcement.
- Auditability — security-relevant actions written to an append-only audit log, visible to team admins in the console.
- Infrastructure — dedicated servers in EU data centers (Germany), private networking between tiers, no shared sending IPs.
- Application security — signed webhooks, hashed share-link tokens with bounded expiry, suppression enforcement at send time, continuous dependency and error monitoring.
- Organizational — access on a need-to-use basis, confidentiality obligations, documented incident response with customer notification (see the Trust page).