Data in the European Union: what it means and what it does not
The phrase “data in the European Union” hangs today on the website of just about every marketing tool vendor. It looks like the end of the compliance conversation. It is only the beginning of it. The “servers in the EU” sticker speaks about the location of the disk the database sits on. It says nothing about who logs into that disk, from which country, and on what legal basis you send email. A subscriber’s email address is personal data. So are open logs, click history and the IP address recorded when a form is filled in.
We write this as a team that runs its own fleet of sending servers. So we look at it from the infrastructure side: configuration, access, queues and DNS records, not from the side of a sales brochure. In this text we separate two things that marketing materials merge into one. First, what data location actually settles. Second, what it will never settle, even if the data centre stands in the middle of Frankfurt.
What “data in the EU” actually means
Let us start with the specifics. Data location is the physical place where the contact database, the backups and the sending logs sit. Those three sets can live in three different places, and clients usually ask only about the first one. Exactly. A backup in another region is the same set of personal data, only a day older.
The second layer is the country of registration of the processor and the law that processor is subject to. A company based outside the Union can keep the disk in Europe and still answer to the regulator of its own country. The third layer is the data processing agreement. A good DPA names the location explicitly and lists the subprocessors one by one, instead of pointing at “trusted partners”.
The real benefit is procedural. In case of an inspection or a request from a data subject you have one jurisdiction, one language of proceedings and a shorter path to an answer. That is a lot. But it is not compliance in itself.
The checklist I go through with every vendor:
- Where does the contact database physically sit?
- Where do the backups go and how long are they kept?
- Where are the sending logs and tracking data stored?
- Who has administrative access to production?
- From which country does technical support work?
- Who appears on the list of subprocessors?
What “data in the EU” does not mean
A server in Frankfurt does not rule out access from outside the Union. If an administrator or a support consultant logs in from another continent, a data transfer takes place. Remote insight into the database is a transfer just as much as copying it. A question asked rarely, and the answers can be interesting.
Location does not mean GDPR compliance either. It is one element next to the legal basis for processing, the retention period, the handling of data subject rights and the record of processing activities. A disk in Poland will not replace any of them. It is worth setting this against the list of what makes up the GDPR minimum in email marketing, and checking how many points you really have ticked off.
It also does not mean independence from vendors outside the Union. An analytics script on the signup page, a CDN serving images in the newsletter, a form plugin, a ticketing system. Each of them can move data outside the EU without the shop owner being aware of it. It is worth checking which integrations with external tools you connect to your form and your newsletter, because that is usually where the transfer starts. The sending layer can be clean while the leak happens on the landing page.
A separate matter: the country of the server does not improve deliverability. Filters look at sender reputation, message authentication and recipient reactions. IP geolocation is marginal to them.
And the simplest thing at the end. Location does not protect you from your own decisions. A purchased list sent from a server near Warsaw is still a violation, only with a nicer address.
Consent: GDPR is not everything, there is also PKE
This is where most of the mistakes happen. The basis for processing data and the basis for the commercial mailing itself are two different questions, regulated in two different acts. You can have a solid basis for processing and still have no right to send an offer.
The Electronic Communications Law settles that second layer. PKE article 398 requires the recipient’s prior consent to sending marketing information to an email address. Prior, meaning earlier than the message. Not arranged after the fact.
This applies to B2B as well. A sales department usually assumes that a generic address such as contact@ removes the obligation. In practice it saves the situation less often than it seems, especially when the mailbox is handled by a specific person and not by an automation. We take this apart piece by piece in the text on why marketing consent is required in B2B too.
Consent without proof is only a claim. Record the date, the wording of the clause, the IP address and the signup source. Without that full set you will not answer either the regulator or a recipient who files a complaint.
Tip: keep a snapshot of the clause wording as it stood on the day of signup. After every change to the form, older consents stay with the old version and only the archive will prove it.
Consent has a purely technical dimension too. Confirmed signup, that is double opt-in, filters out typos in the domain, spam traps and signups made with someone else’s address. It costs a few subscribers at the entrance. It saves a lot of trouble later.
What decides whether an email arrives
The foundation is authentication on your own domain: SPF, DKIM and DMARC. Large mailbox providers now expect a published DMARC policy from bulk senders. A missing record is not a detail, it is a missing signature under the message.
Then the details you only see in the headers. The Return-Path and the tracking domain should be consistent with the brand. A return address on someone else’s domain weakens the sender identity signal. The PTR and A records of the sending address have to match both ways, and the IP itself has to have a clean history.
A new address needs warm-up. Volume grows gradually, and you direct the first sends to the most active recipients. Filters learn the sender from reactions, so the order matters.
Bounce handling has to work automatically. A hard bounce unsubscribes the contact immediately, a soft one gets a limit of attempts and also ends in an unsubscribe. Complaints and spam trap hits hurt far more than weak opens. List hygiene is simply cheaper than getting out of a block.
A block at a large filter is a procedure, not a button. You cut off the source of the problem, reduce volume, file a report and watch the queues for a few days.
Shared IP versus a dedicated pool: what to choose
A shared pool rests on reputation built by many senders at once. At low and irregular volume that is a sensible choice, because one campaign a month is not enough to build a history of your own. The price for the convenience: the neighbours affect your results.
A dedicated pool gives full control and full responsibility. It requires steady volume, patient warm-up and real attention to list quality. An address with no traffic loses reputation just as effectively as an address with a pile of complaints.
Whatever you choose, separate the streams. Transactional and marketing messages should go from separate subdomains and separate addresses. A problem with a campaign must not hold up order confirmations.
Tip: before you ask for your own IP, check whether you send regularly enough for filters to remember you between campaigns.
There are four decision criteria without the marketing: monthly volume, regularity of sends, the share of transactional traffic, and readiness to clean the database systematically. One of those points limping? A shared pool will work out better.
How we do it at MailCraft and what we do not have yet
We run our own fleet of sending servers instead of reselling someone else’s API. The difference is practical: we make the decisions about configuration, queues and the response to a block ourselves, without waiting on a ticket at an intermediary. When a filter throttles traffic, we see it in the logs. Not in an email from a vendor.
The infrastructure and the data stay in the European Union. On top of that a data processing agreement and an open list of subprocessors that can be read before signing, not after an incident. We describe the technical details on the product page, where you will find a description of how the MailCraft email marketing platform works.
Honestly about the limits: some things are on the roadmap, not in the panel. We do not describe plans as finished features, because the client checks that on day one and then the conversation gets needlessly hard. We keep the full list of available features in one place, so it can be compared with your own requirements before a decision.
There is also something no vendor will honestly promise: a guarantee of landing in the inbox, or a way around the filters. You can only remove the reasons for a block, consistently and one by one. Anyone promising more is selling something they do not control.
Summary: location is the foundation, not the building
Data in the European Union limits legal risk and shortens the path in case of an inspection. It will not replace consent, list hygiene or authentication. It is a foundation on which something still has to be built.
Three questions for a vendor:
- Where do the data and the backups sit?
- Who has access to them and from which country do they log in?
- Who is a subprocessor?
Three things on your side: documented consent with the date and the wording of the clause, correct SPF, DKIM and DMARC on your own domain, and consistent list cleaning. You will not buy any of them together with a subscription.
The order of work matters too. Authentication and consent first, then building volume, content optimisation last. Reversing that order ends with a polished newsletter that lands in spam.
