Security controls, written for the person filling in the questionnaire

What we secure, and what we ask you to verify

Most trust pages are a wall of badges. We'd rather tell you what the controls actually do, where the boundaries sit, and which claims you can check yourself without taking our word for any of it. Email infrastructure is a place where the gap between "we take security seriously" and demonstrable practice tends to be wide, and the buyers who matter to us — banks, fintechs, health systems, public-sector teams — already know that. So this page is written for the person who has to fill in a vendor security questionnaire and would prefer the answers up front.

The short version: data centres in the EU by default, encryption in transit enforced rather than offered, encryption at rest with AES-256, dedicated IPs that aren't shared with strangers, a small named team rather than an anonymous support queue, and a jurisdiction — Sweden — that doesn't require us to choreograph a data-transfer workaround to stay GDPR-clean. The longer version is below, control by control.

Where your data physically lives

Default sending locations are Sweden and Germany. Both are EU member states, both data centres are operated inside the EU, and the company itself is Swedish — Authorize Hosting AB, registered and run from Stockholm. That combination is the part that quietly removes a lot of work from your compliance team. When the operator, the processing, and the data residency are all inside the EU, there is no Chapter V transfer to document, no Standard Contractual Clauses to attach, no post-Schrems II adequacy argument to construct, no Transfer Impact Assessment to keep current. The data doesn't leave the bloc, so the transfer mechanism question never comes up.

US and Asia-Pacific sending regions exist on Custom plans, but they're opt-in and only provisioned when latency or a specific regulatory requirement genuinely calls for them. We don't route EU customer mail through a US region to save a few milliseconds. If your mail needs to stay in the EU, it stays in the EU, and that's the default state — not a premium upgrade you have to ask for.

Encryption in transit: enforced, not optional

This is the control most providers gloss over, because SMTP makes it easy to gloss over. The protocol was designed in an era with no encryption at all. STARTTLS, which added the option to upgrade a connection to TLS, arrived in 1999 — and the word "option" is the problem. Opportunistic TLS can be stripped by an attacker sitting between two mail servers: they intercept the connection, suppress the STARTTLS advertisement, and the message gets delivered in plaintext while both ends believe nothing went wrong. It's a downgrade attack, and it leaves no trace.

The fix is MTA-STS — Mail Transfer Agent Strict Transport Security — which publishes a policy telling sending servers that TLS is mandatory and that delivery should fail rather than fall back to plaintext. We run MTA-STS in enforce mode on our own domains and we configure it for managed customers as part of standard setup, paired with TLS-RPT so that any rejected connection produces a report you can actually read. We use the same TLS report decoder we publish for free to parse those reports. TLS 1.2 is the floor; 1.3 is preferred and negotiated wherever the receiving side supports it. For customers whose receiving partners have DNSSEC in place — common across German and Dutch government and academic networks — we'll add DANE with TLSA records alongside MTA-STS, since the two aren't mutually exclusive and DANE removes the certificate-authority trust assumption entirely.

None of this is exotic. It's a fifteen-minute configuration that a surprising number of large senders still haven't done. The reason it matters for a security page is that "we encrypt email in transit" is technically true for almost everyone and operationally meaningless unless the encryption is enforced. Ours is.

Encryption at rest, and what we keep

Stored data — message metadata, logs, queued mail, account records — is encrypted at rest with AES-256. The more useful security property, though, is how little we retain and for how long. Mail content is held only as long as delivery and the contractually agreed retention window require; we don't keep a permanent archive of customer message bodies as a matter of course, because an archive you don't hold is an archive that can't leak. Logs that are needed for deliverability diagnosis and abuse handling are retained on a defined schedule and then aged out. The retention specifics live in the Data Processing Agreement, which is the document your legal team will actually want, rather than a marketing summary of it.

Authentication is a security control, not just a deliverability one

SPF, DKIM and DMARC get filed under "deliverability" most of the time, and they do affect whether mail reaches the inbox. But their first job is security: they're what stops someone sending mail that claims to be from your domain. DMARC at p=reject is the difference between a phishing campaign that can impersonate your billing address and one that can't. We treat the authentication stack as a security deliverable. Managed customers get SPF kept under the 10-lookup limit, DKIM signing at 2048-bit, DMARC moved deliberately toward enforcement with aggregate reports monitored, and BIMI where a Verified Mark Certificate is in place. The free tools on this site — the DMARC checker, the SPF flattener, the DKIM tester — are the same checks we run internally, published so you can audit any domain, including ours.

Dedicated IPs and tenant isolation

Every entry plan ships with dedicated IPs. This is a deliverability decision and a security one. On shared sending infrastructure, your sending reputation is hostage to whoever else is on the same IP, and a neighbour's compromised account or spam run becomes your blocklisting. Dedicated IPs mean the reputation is yours, the isolation is real, and there's no noisy-neighbour blast radius. For customers on dedicated servers and managed PowerMTA, the isolation extends to the host: bare-metal separation rather than a shared multi-tenant pool.

The regulatory landscape, honestly mapped

We operate inside a web of overlapping EU frameworks, and rather than claim blanket "compliance" with all of them, here's where each one actually touches an email infrastructure operator and what it means for you as a customer.

GDPR is the baseline. We act as a data processor for the customer data you send through us, the DPA defines that relationship, and the EU-only default residency keeps the transfer rules simple. Breach notification obligations run on the 72-hour clock, and our internal incident process is built to that timeline.

NIS2 — the Network and Information Security Directive 2 — is the one that has reshaped the most over the last eighteen months. Member states were required to transpose it by October 2024, and through 2026 the national authorities have been working through entity identification. NIS2 is relevant to us in two directions: as a digital infrastructure operator we sit closer to its scope than a typical SaaS vendor, and many of our customers are themselves in-scope and need their suppliers to demonstrate alignment. The directive's penalties are GDPR-scale — up to €10 million or 2% of global turnover for essential entities, €7 million or 1.4% for important ones — which is why supplier due diligence around it has become real rather than theoretical. The practical overlap is that a mature ISO 27001-style information security management system covers most of what NIS2 asks for; the incident-reporting timelines (a 24-hour early warning under NIS2) are the part that needs specific operational readiness rather than just documentation.

DORA — the Digital Operational Resilience Act — applies vertically to the financial sector and its ICT suppliers. The grace period ended in early 2026, so financial customers now genuinely need their technology suppliers to evidence resilience and third-party risk management. If you're a bank or a fintech sending through us, the relevant DORA touchpoints are our incident handling, our continuity planning, and the contractual provisions in the DPA that let you meet your own third-party oversight obligations. We're not a financial entity ourselves, but we're the kind of ICT third party DORA expects you to assess — and we've structured the paperwork so that assessment is straightforward.

ISO 27001 is the connective tissue. We run our information security management on the ISO 27001:2022 model — risk identification, proportionate controls, documented procedures, continual improvement. We're transparent that operating to the standard and holding a current third-party certificate are two different claims; where a customer's procurement requires the certificate specifically, that's a conversation to have directly rather than a checkbox to assume. The honest framing matters more here than an optimistic one, because a security questionnaire answered optimistically is a liability you inherit later.

How incidents are handled

When something goes wrong — an IP gets listed, a customer account is compromised, a deliverability cliff appears overnight — the value of a small named team is that someone who understands the system picks up. There's no tier-one script, no ticket bouncing between queues, no waiting for an offshore shift handover. The incident process runs to the notification timelines the regulations require (72 hours for a personal-data breach under GDPR, the shorter early-warning windows where NIS2 applies to a customer's own obligations), and the people doing the remediation are the same people who run the infrastructure day to day. For deliverability incidents specifically — the 4am blocklisting on a Saturday — the operator on call has dealt with the same listing on other customer infrastructure recently, which is the difference between a fast recovery and a week of confusion.

What you can verify without asking us

Trust pages improve when the reader can independently check the claims. A few you can verify right now: run our own domain through the DMARC checker and confirm the policy is at enforcement. Check our MTA-STS policy file — it's served over HTTPS at the standard well-known path, and the TLS report decoder will tell you whether transport security is configured. Look up the company: Authorize Hosting AB is a real Swedish registered entity, and the CEO, Mikael Vainiomaa, has run it since 2012 and is findable on LinkedIn. 23 years of continuous operation is itself a security signal: providers that cut corners on infrastructure rarely last that long.

What we don't claim

We don't claim certifications we don't hold. We don't describe ourselves as "the most secure" anything. We don't promise that mail will never be intercepted, only that we've enforced the controls that make interception genuinely hard and reportable when attempted. And we don't pretend the regulatory picture is simpler than it is — NIS2, DORA, GDPR and ISO 27001 overlap in ways that take real work to navigate, and a provider who tells you compliance is automatic is a provider to be wary of. The trustworthy version of a trust page is the one that draws the boundaries clearly. This is ours.