Nine Proofs That I'm Not a Spammer

On Saturday night, a few minutes past eleven, I got an email from my internet provider. It informed me that spam was originating from my connection, and that ports 25 and 465 had therefore been blocked — which is to say, precisely the two ports email travels through.

I hadn't sent any spam. For the previous thirty minutes I'd been testing whether the mail server I'd just finished building was sending mail correctly. I opened maybe fifty connections to mail ports to verify that encryption worked, the certificate matched, signatures validated, and messages landed in the inbox rather than the spam folder.

The heuristic on the router couldn't see content. It saw frequency. And fifty connections to port 25 in half an hour looks like an infected machine, regardless of what's actually happening.

This is a story about everything that has to be right before someone will accept your email — and why that still might not be enough.

Why bother

If you want to send email today, you do it through Google, Microsoft, or a national provider. It's free or nearly free, it works, and you configure nothing.

The price isn't paid in money. It's paid by having your correspondence sit on someone else's disk, pass through someone else's classifiers, and fall under rules nobody negotiated. When the provider decides something looks wrong, the account disappears and the appeal goes through a form no human answers.

For most people that's an acceptable trade. Not for me — I run several projects on their own domains, and I'd rather their communication didn't depend on a decision I can't influence or contest.

So: my own server. One virtual machine, some software, a domain. In 2026 this should be an afternoon's work.

It wasn't.

Time that isn't yours

The first problem showed up before I installed anything mail-related at all.

The server I'd provisioned isn't a full virtual machine but a container. It shares the operating system kernel with its host, which makes it faster and cheaper. That has one consequence: it can't set its own clock.

I tried to start the time synchronization service and got a terse refusal. Operation not permitted.

This looks like a triviality. It isn't.

Modern authentication rests on time. Tokens carry timestamps for when they were issued and when they expire. One-time codes from your phone are computed from the current time in thirty-second windows. Signed messages carry a stamp. When your server's clock drifts two minutes, things break that appear to have nothing to do with time — and the error messages tell you nothing useful.

It worked out. The host keeps time to within a quarter of a millisecond, so I left the service running in a mode where it only measures the offset and never touches the clock. But it's the first of several things on that server I don't control and have to trust someone else is doing correctly.

An address nobody trusts

Before installing the mail server, I had to settle three things that can't be rushed and each take days.

An open port. Ports are numbered entrances through which traffic reaches a computer. Number 25 is reserved for server-to-server mail, and the overwhelming majority of providers keep it closed. The reason is simple: most of the world's spam leaves from infected home computers, so it's easier to close that port for everyone and open it on request for those who genuinely need it.

So the first task in building a mail server isn't installing a mail server. It's writing a request.

A reverse record. Every address on the internet has a number. When your server delivers mail somewhere, the recipient asks: this number, who owns it? That question is called a reverse lookup, and the answer must match the name your server introduced itself with. If you say you're mail.example.com but the number points at vps-4471.hosting.provider, you look suspicious. Not because you're lying — spam simply arrives from such addresses more often.

You set it in your provider's control panel, and it takes hours to propagate across the internet.

A clean history. This is the treacherous part. Addresses get recycled. If someone who ran a spam operation sat on your address before you, you inherit their reputation. And reputation doesn't get erased on the internet — there are lists of problematic addresses that clear slowly, and sometimes not at all.

Before installing anything, I checked my address against four such lists. It was clean. If it hadn't been, the only sensible move would have been to request a different one and start over.

Nine mechanisms and one domain

Then came the part I'm writing this for.

For a major provider to accept your email today and not drop it into spam, a series of independent mechanisms has to agree. They emerged gradually over the past twenty years, each patching a different hole, and none of them suffices on its own.

Who may send for your domain. In your domain settings you declare which servers are authorized to send mail in your name. The recipient checks this, and when a message arrives from elsewhere, rejects it. This addresses sender forgery — without it, anyone could send you mail that appears to come from your bank.

A digital signature. The server signs every outgoing message with a cryptographic key. The public half of that key is published in your domain settings, so the recipient can verify the message wasn't altered in transit and genuinely came from you.

Here I hit something that felt like a preview of everything else.

There are two algorithms you can sign with. The older one is built on large numbers; signatures are long and computation slower. The newer one uses elliptic curves, is faster, and produces shorter signatures. I enabled both, since it costs nothing.

When I sent myself a test message to Gmail and opened the details, I saw this:

dkim=neutral (no key)  ... modern algorithm
dkim=pass              ... older algorithm

Google can't verify the newer one. It marks it as "no key" and moves on. Had I deployed only the modern algorithm — the correct one, the faster one, the recommended one — Gmail would not have verified my signature at all, and my mail would behave as though it were unsigned.

This entire article is really about that. You follow best practice and the system doesn't recognize it.

What to do when something fails. The third mechanism is an instruction to recipients: when a message from my domain fails the signature or authorization check, discard it. It also specifies where to send daily reports on what happened.

I chose the strictest setting. That means any error in my configuration won't show up as mail in a spam folder, but as mail that went nowhere and nobody mentioned it. I'll find out from the report. The next day.

Enforced encryption. When two mail servers hand a message over, they negotiate encryption. The problem is that the negotiation can be stripped by an attacker in the middle — they remove the encryption offer, and both servers conclude the other side doesn't support it. Two mechanisms prevent this, each differently.

The first publishes a document on the web saying "my servers support encryption, don't believe anyone claiming otherwise." The second stores a fingerprint of the certificate in your domain settings, so the recipient can tell whether it's talking to the right server.

I deployed both. And with the second one, I watched it fail in the wild.

When an anti-spam mechanism stops an anti-spam report

My server automatically sends daily reports about what mail it received and how the signature checks went. It's a courtesy — the other side learns that someone is impersonating them.

I was sending one such report to a Slovak company that had repeatedly sent me spam. It didn't get delivered.

DANE authentication failed
Message rescheduled for delivery

That second mechanism — the certificate fingerprint — is broken on their end. They have a fingerprint published in their domain settings that doesn't match the certificate they actually present. My server checked, found the mismatch, and refused to deliver.

It behaved correctly. Exactly as designed.

The result is that I can't deliver a report about spam to a company that sends spam. Because they have a broken security mechanism whose purpose is to reduce spam.

Nobody will tell them, because nobody else can deliver either. And they don't know, because nothing reaches them.

A server that locks itself out

Mail servers defend against brute force. When several failed logins arrive from one address in quick succession, that address gets blocked. It's standard and it works.

After one restart, my desktop mail client tried to connect with an outdated password. It tried, failed, and tried again. And again. Clients do this automatically, without asking.

The server blocked my home address. Completely — not just mail, but also the web interface through which that block gets lifted.

So I couldn't log into my server's administration to unblock my address, because my address was blocked.

I solved it over mobile data. But the logic is the same as everywhere else: the mechanism works exactly as designed, and the outcome is absurd.

Reputation you can't buy

With everything configured, I ran a message through a tool that scores the likelihood of landing in spam. I got 6.3 out of 10.

The breakdown looked like this:

+ signature valid
+ signature from your domain
+ sending authorization verified
- suspicious domain suffix         -0.5
- suspicious domain suffix         -2.0
- untrustworthy domain suffix      -1.0

Three and a half points because my domain ends in .xyz.

That suffix is cheap, so it gets used by people who need many domains briefly. Meaning, mostly, spammers. Filters learned this and penalize it across the board, regardless of what sits behind it.

There's nothing to be done. No process exists for getting out of it. Either you buy a different domain or you live with it.

The general implication is more interesting. A domain costing eight dollars a year gives you a worse starting position than one costing twenty. Not on technical merit, but on statistics about who buys cheap domains. It's a regressive tax built into the infrastructure.

I translated this for myself as: if you're sending invoices, don't use .xyz.

Warming up

Then came something rarely discussed. A new address has no history, and providers don't trust anyone they know nothing about.

The recommended procedure is called warm-up. The first week you send dozens of messages a day. Then you gradually increase. It takes weeks.

When a new address starts producing hundreds of messages overnight, it behaves like a spammer. It doesn't matter that your messages are legitimate — the pattern is identical.

It's a reasonable measure and it makes sense. It also means that between "I have a server" and "I can use it for anything that matters" lies a month of patience.

Someone is watching

Ten minutes after I opened the last port, this appeared in the logs:

Invalid EHLO command ... remoteIp = 121.228.43.8 ... domain = "User"
Authentication not allowed ... remoteIp = 121.228.43.8

A scan from China. The server introduced itself with an invalid name and attempted to authenticate on a port where authentication isn't offered. My server refused.

More arrived during the day. A research project that indexes the entire internet. A company that analyses mail server security — that one connected fifty times in twenty seconds.

None of it was hostile and none of it succeeded. But it's worth knowing: the moment you expose something on the internet, it's in databases nobody asked for within minutes.

And then that email from the provider

Back to the beginning.

With everything finished, I wanted to confirm it worked. I sent test messages to Gmail, to a national provider, to one corporate address. I verified encryption on four ports. I checked the certificate fingerprint. I had two independent tools scan the configuration.

About fifty connections over half an hour. From a home connection.

The provider's router saw unusual traffic intensity on the ports mail travels through and did exactly what it's supposed to. It blocked them for twenty-four hours and sent me a notice politely suggesting I check my computer for malicious code.

The email is well written, incidentally. It explains what happened, offers contact details, lifts the block automatically. I have nothing to hold against them.

But it contains everything else in miniature.

I spent several days configuring nine mechanisms whose sole purpose is to prove I'm not a spammer. I sign messages with two keys. I publish a policy instructing recipients to discard anything that fails verification. I publish a certificate fingerprint so nobody can eavesdrop.

And when I went to verify the whole thing worked, the system flagged me as a spammer.

Not for what I was sending. For how often.

What to take from this

Running your own mail server is more technically accessible today than ever. The software is good, certificates are free, documentation exists. The part that used to be hard is now an afternoon.

What's hard is something else. It's nine independent mechanisms that must agree simultaneously. It's a reputation you don't have and must earn. It's infrastructure that assumes a mail server is run by either a large company or a spammer, and accounts for nothing in between.

It doesn't fail by accident. It works precisely as designed. Each mechanism arose in response to genuine abuse, and each makes sense in isolation. But their sum is a barrier only someone with time and patience gets past.

Which is, incidentally, exactly what centralization looks like. Not a prohibition, but a cost. Nobody forbids you from running your own mail. It's merely demanding enough that almost nobody does.

I'm carrying on. The server runs, mail flows, Gmail and the national provider both deliver it to the main inbox. Certificates renew themselves, signing keys rotate automatically every three months.

But I understand why almost nobody does this. And I understand it better than I did a week ago.