Previous owner still getting email at my newly registered domain.

40 years in this business. Reject at SMTP time is correct. Bouncing creates backscatter. Keeping it creates liability.

The senders are the ones with the problem. Their patient contact database is stale. That is not your fault and not your fix.

Pro tip: check if any of those addresses are getting password reset emails. That is the real danger signal. Medical spam is embarrassing. Account takeover is expensive.

I would not. You are not processing personal data in the GDPR sense. You are an accidental conduit. The authority has actual breaches to deal with.

What I would do: document. Screenshot the headers with timestamps showing the 11 month gap. If anyone ever asks, you have proof the domain was not under your control when that patient relationship existed.

RackNerd though. I would open a ticket asking them to confirm the previous registrant data was purged from their WHOIS history per ICANN rules. Not because they failed, just to have the paper trail.

Actually I agree with maximus63 here. The registrar dont purge nothing because is not their job. The previous owner should change email everywhere. Is like buying used car and previous owner still getting parking tickets. Not fault of the dealer.

But RackNerd should at least inform the buyer if domain was used for email before. This is not standard either but would be nice.

I check my CloudCone domains for previous email history. Nothing like this. Maybe because CloudCone is compute mostly, not domain auction.

If you automate this, make sure your reject message does not include the original address. Standard 550 is fine. Custom text explaining why leaks info to the sender about what you know.

I automate my automations and even I would do this manually for the first week. Pattern match too aggressively and you reject legitimate email to your own addresses.

Also: check if the previous owner had SPF or DKIM set up. Stale DNS records at the old provider might be causing delivery issues you have not seen yet.

This. Had this exact scenario on a domain from a UK registrar. Previous owner used it for everything. Bank statements, utility bills, and yes, password resets.

I set up sieve rules to folder anything matching common patterns, then reviewed weekly for 3 months. Found two financial institutions that did not verify email changes. Contacted them directly, they were grateful. One sent me a bottle of whisky.

After 3 months I burned the rules and let it hard bounce.

This is dangerously wrong. If you operate a mail server you are processing personal data. The definition is broad. Intent is not required.

That said, the GDPR lawful basis would be legitimate interest in operating your server, and the data subject rights are limited by the fact you cannot identify them to respond.

My actual advice stands: minimize processing. Reject at SMTP time. Do not store. The authority will care more about your process than about one week of accidental receipt.

I have been reading this thread with interest. Sofia perspective: Bulgaria has similar issues with old state email systems. The legal exposure question is really about knowledge and intent.

You now know it is medical data. You have stated so publicly in this thread. That removes the "I did not know" defense if you continue to receive and store it.

Act quickly. The 550 reject is the right move. Do it today.

Technically correct. Practically useless. The DPA in Czechia has bigger fish than a guy who configured postfix correctly within 48 hours of discovering the issue.

I have a rack in a real building. I have seen actual breaches. This is not one. This is a configuration problem with a responsible operator.

LichunLars: if you want to be thorough, add a note to your internal documentation with date and action taken. That is your GDPR accountability evidence. Nothing more needed.

I asked about RackNerd cache purge because polskiegsm claimed it should happen. I have transferred dozens of domains through various registrars. None purge historical DNS or MX data because that is not registrar data. It is zone data. The zone was under the previous owner's control, not RackNerd's.

RackNerd runs their own MX for some customers. That is different. But drift-mx-01 in the traceroute looks like their internal naming. If LichunLars is routing through RackNerd MX that is his choice, not residue from previous owner.

Correct. I added that route myself for spam filtering. The 12ms is RackNerd's MX in Amsterdam to my VPS. Previous owner had Google Workspace, not RackNerd. I can see the stale MX records in historical DNS.

550 reject is now active for the three addresses I identified. I will monitor logs for 48 hours then consider broader pattern matching.

Thank you all. The HIPAA panic was unhelpful but the GDPR nuance was useful.