AlignedMail
Harbourway Group Ltd · 17093218
Email authentication, checked and fixed

Your systems send mail in your name. Nothing tells you it arrived.

Your CRM, your booking system, your finance tools and your marketing platform all send on your behalf, using your name. Whether a receiving system accepts that is decided by records on your domain, and almost nobody checks them.

Send me your domain
Free. You get the answer either way, including when it is fine.
321
UK and US domains checked, September 2026
84
carry a fault that stops them proving their mail is genuinely theirs
54
of those 84 have no reporting at all, so they cannot find out
Checked from public DNS on 20 September 2026, and every one of the 84 re-checked against a second resolver on 21 September before being published here. "Fault" means no SPF record, an SPF that fails to evaluate, several SPF records at once, or DKIM signing not enabled. Every one is reproducible with a single lookup.

You already have the symptom

Someone does not reply. A client goes quiet. You log it as a slow month, a busy contact, a market that has gone cold.

Some of that is exactly what it looks like. Some of it is mail that was filed as junk before anyone read it, and a smaller amount never arrived at all. There is no way to tell any of it apart from where you sit. No bounce comes back. Nothing appears in a log. The only record of what happened sits with the receiving system, and unless your domain asks for it to be sent to you, it is discarded.

Your own desk mail keeps working throughout, because it goes out on a different path. That is the part that makes this hard to notice. The stream that fails is the automated one: confirmations, notifications, invoices, everything your systems send with your name on it.

Broken records rarely bounce a message outright. They make a receiving system trust it less, and trusting it less is a decision nobody tells you about. Email authentication is the only part of an IT estate that fails silently. A broken website is obvious in a minute. This can be wrong for years.

What I actually do

  1. Turn the reporting onWithin about 48 hours you see every system sending as you, and how much of it is accepted. Most firms have never seen this and find senders they had forgotten about.
  2. Authorise every legitimate senderOne SPF list inside the ten-lookup limit, and a signing key for each system, so that mail can prove it is really yours.
  3. Raise enforcement in stagesMonitor, then a quarter, then half, then everything. Watched at each step and reversible in minutes. Nothing goes to enforcement until the reports say it is safe.
  4. Keep reading the reportsNew systems get added and suppliers change. The reports are the only place that shows up, and they only help if a person reads them.

What it looks like

Two things from the screen. One is a domain that publishes three lists where the standard allows one. The other is why that fault shows up as candidates who did not turn up, rather than as an email problem.

$ dig +short TXT anagency.co.uk | grep spf1
"v=spf1 a mx include:_spf.{mailing tool} ~all"
"v=spf1 include:_spf.bullhornmail.com ~all"
"v=spf1 include:spf.protection.outlook.com -all"
three records. the standard allows one.

$ dig +short TXT _dmarc.anagency.co.uk
no output. nothing is reporting, so
nobody there can find any of this out.
The shape of it. Six domains in the 321 publish more than one SPF record, and this is what they have in common: three systems added at three different times, each one appending its own record instead of merging. Two commands, thirty seconds, no tool of mine involved. The middle line authorises their CRM to send candidate mail, and because there is more than one record every receiving system discards all of them.
yourfirm.com one domain Recruiters’ mailbox Microsoft 365 or Google You would notice this breaking. Your CRM, sending as you interview confirmations Nobody notices this breaking.
Two paths out of one domain, and both are judged by the same records on it. Only the top one has anybody watching, which is why a fault shows up as candidates who did not turn up rather than as an email problem.

What this does not do

It stops mail being sent from your exact domain. It does nothing about a lookalike domain, a WhatsApp message using a colleague's name, or a fake advert posted somewhere with your branding on it. Every documented case of a UK agency being impersonated that I could find used one of those routes, not the domain. Anyone selling you this as fraud protection is overstating it.

It will not make a weak email get replies. If your mail is arriving and nobody is answering, this is not your problem and I will tell you so.

I cannot tell from outside whether your mail is currently landing in junk. Nobody can. What I can tell you, before you pay anything, is exactly what your domain publishes and whether it works.

Who I am

Byron Coke
Byron Coke
Harbourway Group Ltd

More than 3 decades working as a Unix/Linux and infrastructure engineer, including building the call centre systems that took a UK answering service from nothing to over 5,000 calls a day.

I found this on my own domain first. I switched reporting on, and the first report showed somebody forging it from a host with no reverse DNS that is listed on Spamhaus. Three messages, and the policy at the time told every receiving system to do nothing about it. I do this work for a living and I could not see it until I looked.

£1,900 One domain, up to three sending systems. Six to eight weeks.
£950 for the first three clients, in exchange for a named case study.
Reading the reports afterwards is £295 a month, and optional.
Send me your domain

You get the check whether or not you ever buy anything, and you get it when the answer is that nothing is wrong. That was true of 237 of the 321 I have looked at.