Cleaning up a mail setup that was letting spam in and legitimate mail out badly

The problem

The client is a managing director at a digital agency, and I've handled his server and infrastructure for about eighteen months — provisioning sites, managing DNS, and keeping the whole setup running.

The email work started with a symptom he raised directly: the volume of spam reaching his mailboxes had become a genuine problem, with a recognisable pattern of crypto-related messages arriving persistently.

Looking at the setup, the inbound flood turned out to be the visible half of a broader problem. The domains' email authentication was in poor shape — SPF, DKIM and DMARC all had issues across the mailboxes involved. That combination has consequences in both directions:

Inbound, weak or absent authentication policy means there's little basis on which to reject forged and spoofed mail, so it lands.

Outbound, the same misconfiguration means legitimate business mail can't reliably prove it's legitimate. Nobody notices this until a client says they never received something — which is the expensive kind of discovery, because by then the deal or the invoice has already gone quiet.

There was also a routing requirement the existing configuration didn't handle: mail for the domains needed to be split across delivery destinations rather than all landing in one place.

Why this doesn't get fixed on its own

Email authentication fails quietly. There's no error, no alert, and no dashboard turning red. SPF passes for the wrong reason, DKIM signs with a key that doesn't match what's published, DMARC sits at p=none reporting to nobody — and everything appears to work until it demonstrably doesn't.

It's also easy to fix in a way that looks correct. Adding the records isn't the hard part. Getting them to actually align — so that the domain in the visible From address matches what's authenticated — is where most setups quietly fail, and no validator front page will tell you that in plain terms.

Toggle the records below and watch what a receiver actually decides. The last control is the one that catches people — it's the difference between a contact form that arrives and one that doesn't.

Domain configuration

SPF record publishedDKIM signing enabledDMARC record published

DMARC policyp=nonep=quarantinep=reject

Contact form sends as

your domainvisitor’s

Receiver evaluation

From: naeem@naeemsafdar.net

Return-Path: naeem@naeemsafdar.net

spf=pass(sender authorised)

dkim=pass(signature valid)

spf alignment=pass(matches From domain)

dkim alignment=pass(d= matches From)

dmarc=pass(aligned pass)

Delivered to inbox

DMARC passed: both SPF and DKIM are aligned with the From domain. Only one aligned pass is required.

What I built

Split delivery routing, so mail for the domains reaches the right destination rather than being forced through a single path that didn't suit how the business actually uses it.

SPF, DKIM and DMARC corrected across the affected domains and mailboxes. Not added — corrected, and verified to align, so authenticated mail passes for the right reason and forged mail has a policy to be judged against.

Server hardening. Rather than moving everything to a third-party transactional provider, I tightened security on the existing server, keeping the client's mail on infrastructure he controls.

Ongoing site provisioning and DNS management across the several sites hosted there — A, CNAME, MX and TXT records, and the authentication records above.

The result

• Support contacts along the lines of "I never received your email": reduced to zero
• Legitimate mail now lands in the inbox, correctly signed, with the company's signatures intact
• The crypto spam pattern that prompted the work addressed at the configuration level rather than by filtering symptoms
• Multiple sites provisioned and running on managed infrastructure
• An eighteen-month working relationship rather than a one-off engagement

The measurable outcome is the disappearance of a support category. The business outcome is that mail stopped being something anyone had to think about — which, for infrastructure, is the correct end state.