Your Domain, Their Scam: Cleaning Up After a Joe-Job

It usually starts with a bounce you didn’t send. A message bounces into your postmaster inbox, then another, then a trickle of replies from strangers asking why your company is sending them invoices, password resets or parcel notices. Your domain is in the return address. Your brand is in the complaint. And none of it came from your mail server. Welcome to the joe-job: the email equivalent of someone using your address as the return label on a box of trouble.

The setup: what a joe-job actually is

A joe-job is what happens when a spammer or scammer forges your domain in the envelope sender, the From header, or both. The messages go out to a rented list, a scraped set of addresses, or a targeted group of UK recipients. A chunk of them fail. Those failures generate bounces, challenges, out-of-office replies and complaints. Because the return path points at you, the fallout lands on your doorstep.

The name has been around since the 1990s, when a Joe Doll was reportedly targeted after complaining about spam. The mechanics have not changed much. The scale has. In 2026, a criminal can rent a bulletproof host, buy a list of .co.uk addresses and start borrowing someone else’s domain before lunch. The goal is not always to impersonate you. Sometimes your domain is just convenient cover.

Backscatter: the junk that comes back

Backscatter is the mail you receive because someone else sent a message with your address in the return path. It includes non-delivery reports, vacation autoresponders, spam-filter rejections and the occasional furious human reply. Most of it is not addressed to a real person at your company. It arrives at catch-all addresses, postmaster aliases or old role accounts that someone forgot to close.

The uncomfortable part is that backscatter can look like a delivery problem on your side. Your monitoring might show a spike in bounces. Your helpdesk might get a complaint from a recipient who never opted in. Your sending domain might show up in a blocklist nomination. None of that proves you sent anything. It proves someone used your name.

Real bounce or forged envelope? Reading the clues

Start with the headers. A genuine bounce from your own mail system will usually come from a host you recognise, carry a message ID you can trace, and reference a recipient or campaign that exists in your logs. A forged bounce often has a return path that is not yours, a Received chain that does not touch your infrastructure, and a body that references a message you have never seen.

Check the envelope sender versus the From header. If the From domain is yours but the return path is a random host, that is a spoof of your visible identity. If the return path is yours but the From domain belongs to someone else, that is a forged envelope. Both are bad, but they need different fixes. Also look at the sending IP. If it is not in your SPF record and not one of your ESPs, you can stop blaming your own postfix logs.

What DMARC alignment fixes — and what it doesn’t

DMARC is the grown-up answer to domain spoofing, but it is not a magic spell. It tells receiving servers what to do when a message claims to be from your domain but fails SPF or DKIM alignment. Publish a policy at p=quarantine or p=reject and you make it much harder for someone to send mail with your domain in the From header. That protects your brand and reduces the chance that a scam lands in a UK inbox looking like it came from you.

What DMARC does not do is stop every joe-job. It covers the From header, not the envelope sender. A spammer can still put your domain in the return path while using a different From domain. Your DMARC policy will not save you from the bounces that result. It also will not fix your reputation overnight, and it will not force every receiver on the planet to enforce your policy. Plenty of UK mail servers still accept first and ask questions later.

Bounce-handling policies that stop you becoming the problem

The best defence is to be a boringly well-behaved sender. Reject unknown recipients at SMTP time instead of accepting the message and bouncing it later. Accept-then-bounce is how legitimate mail servers accidentally create backscatter. Use a null return path for automated notifications that should never receive replies. Use VERP or a dedicated bounce domain for bulk mail so you can track failures without exposing your primary domain. Keep postmaster and abuse mailboxes monitored, but do not let them become a dumping ground for forged bounces.

If you run a catch-all, audit it. Catch-alls are lovely for missed enquiries and terrible for backscatter. If you no longer need one, turn it off. If you do need one, filter it hard and route it away from real people.

When blocklists and recipients start blaming you

This is the bit that stings. A joe-job can get your domain or IP nominated for a blocklist, and the listing may be based on complaints about mail you never sent. Do not panic-delete evidence. Save the headers, the timestamps and the DMARC reports. Check whether the listing is for a domain, an IP or a shared hosting range. If it is an IP you do not control, say so politely and provide proof.

Contact the blocklist operator with a short, factual note. Explain that the messages were forged, point to your SPF, DKIM and DMARC records, and include a sample header showing the sending infrastructure is not yours. Some operators will delist quickly. Others will want to see that you have a policy in place. Either way, keep a record. If a recipient complains, reply from a monitored address with the same evidence. Do not argue. Just show the headers.

A calm incident checklist

• Preserve samples of the forged mail and the bounces.
• Check your DMARC aggregate reports for the spoofed domain and the sending IPs.
• Confirm your SPF, DKIM and DMARC records are correct and aligned.
• Review postmaster and abuse inboxes for patterns.
• Reject unknown recipients at SMTP time where possible.
• Contact blocklists only after you have evidence, and keep the thread.
• Tell your UK customers what happened if the scam used your brand. A short, plain-English note beats silence.

The long game: reputation, reporting and receipts

A joe-job is annoying, but it is rarely the end of your deliverability. The senders who suffer most are the ones who ignore the bounces, let catch-alls collect junk, and have no DMARC policy to point to when someone asks. The ones who recover fastest have records, logs and a calm reply ready.

So the next time a bounce lands in your inbox and you know you did not send it, do not just delete it. Read the headers. Check the return path. Take a screenshot. Then fix the bits you can control. Your domain may have been borrowed, but your reputation is still yours to defend.