At ten to three yesterday afternoon an email arrived from nutshell.documents@insure-systems.co.uk, addressed to me by name, quoting my car insurance policy number in bold at the top. It apologised for failing to send me my Insurance Product Information Documents when I bought the policy, and invited me to collect them from My Account.

Every instinct I have says that email is a phish.

The sender domain is not the brand's domain. The brand is nutshell, the site is nutshell-insure.co.uk, and the mail comes from insure-systems.co.uk, a name that sounds like something a fraudster registered on a Tuesday. The visible link text reads www.nutshell-insure.co.uk/MyAccount. The actual destination, hiding underneath it, is:

http://links.budgetinsurance.mkt6122.com/els/v2/[...]

Different brand. Different company name. Plain HTTP, no TLS. Opaque base64 blob. Anchor text that lies about where it goes. If you have ever sat through a corporate phishing awareness module, you were taught to treat that exact combination as the tell. It is lesson one, and this email fails it four times over.

So I opened nutshell's live chat and asked them to confirm it was theirs.

Authenticated, not trustworthy

Then I did what I should have done first, which is read the headers rather than the email.

Authentication-Results: mx.google.com;
   dkim=pass header.i=@insure-systems.co.uk header.s=spop1024;
   spf=pass (domain of v-...@bounce.budgetinsurance.mkt6122.com
        designates 74.121.49.229 as permitted sender);
   dmarc=pass (p=REJECT sp=REJECT) header.from=insure-systems.co.uk

That is not a phish. That is about as verified as consumer email gets.

Taken one at a time: SPF passing means the machine that sent it was on the list of machines allowed to send for that envelope domain. On its own that proves very little, because anyone can publish an SPF record for a domain they just bought. DKIM passing means the message carries a cryptographic signature made with a private key belonging to insure-systems.co.uk, and the signature covers the From header, the Subject, and the body. That is harder to fake, but a signature from an unrelated domain is still worthless.

DMARC is the one that matters, because it ties the other two back to the name a human actually sees. dmarc=pass here means the DKIM signature is aligned with the From address, and p=REJECT means the owner of insure-systems.co.uk has published a policy instructing every receiving mail server in the world to bin anything claiming to be from them that does not authenticate. A forger cannot get around that. They would need the private key.

The rest of the headers tell the same story. It was relayed by mail5524.junctioninsurance.mkt6122.com. Junction is another BGL brand, sibling to Budget and to nutshell. The DKIM selector spop1024 is the fingerprint of Silverpop, now Acoustic, a perfectly ordinary enterprise email platform. The logo is pulled from contentz.mkt6122.com, that platform's content CDN. There is an X-CSA-Complaints: csa-complaints@eco.de header, which means the sender is signed up to the Certified Senders Alliance, a German accreditation scheme that fraudsters are not famously queuing to join.

The footer is true, too. nutshell insurance services is a trading name of BISL Limited, company number 3231094, FCA authorised, registered at Fusion House in Peterborough. The policy number is right because it is their policy number, out of their own database.

The email is real. I was wrong.

Four attempts to reach a human

Worth recording what happened when I asked, because the asking is the part most people will actually do, and it went badly before it went fine.

The chat window opens with a banner in capitals: PLEASE DO NOT ENTER PAYMENT DETAILS INTO THIS CHAT. That is the only security control on the page. Hold that thought.

I opened with "verify email authenticity". The virtual assistant told me its opening hours.

I tried again, in a full sentence this time: "I got an email purporting to be from yourselves and I neeed to check if it is spam or not." It replied that my documents should be available to view within My Account, by selecting the Documents option from the top of my screen, or Docs if I was on a mobile.

Read that one twice. I have asked an insurance company's support channel whether an email directing me to My Account is a phish, and the support channel has answered by directing me to My Account. The suspected fraud and the official assistant gave me the same instruction, in the same words, ninety seconds apart. Had the email been a fake, the bot would have been helping it along.

Somewhere in the middle it decided I might be ringing about a crash, and offered me the claims line.

"i need to chat with a poerson" got back "I'm here to help 24/7!" It took a fourth go, "I bneed a human", before it asked whether I was the policyholder and put me in a queue. Fifty-four seconds later a human joined, which is genuinely quick. He gave his name; I will call him A., because none of what follows is his fault and he does not need it attached to him. Reaching the queue took longer than the queue did.

At no point in that sequence did the assistant recognise "is this email really from you" as a thing a customer might ask. It is not a rare question. It is the question every fraud awareness campaign in the country is actively training people to ask, and the front door of the brand has no answer for it.

Then the human part. I pasted the whole email, listed the domains, pointed out that the sender was not nutshell and that no link in the message resolved to a nutshell address, and said that if it was genuine they really ought to use their own domain, and that if it was not, I would be very interested to understand how somebody had my correct policy number.

The reply, in full:

The email is from nutshell.

Which is correct. It is also, as an answer to that question, worth nothing. It contains no evidence, invites no verification, and is precisely what a fraudster running a fake support channel would also say. A. is not the problem here. Nobody handed him a page he could point at, and I would guess nobody has ever given him the words "it passes DMARC" or anywhere to send a customer who wants proof.

The honest version of that answer takes two sentences. Yes, we send from insure-systems.co.uk and our links go through mkt6122.com. Here is the page on our site that lists every domain we send from, so you can check any future email yourself. That page does not exist.

The easy half and the hard half

Here is what bothers me, and it is not that I lost ten minutes.

BISL did the hard part properly. Publishing DMARC at p=REJECT across a group of brands is genuinely difficult. It means finding every system in the business that sends mail, getting each one signing correctly, and holding your nerve while you move the policy from monitor to quarantine to reject knowing that a mistake silently deletes customer correspondence. Plenty of UK financial services firms still have not managed it. Credit where it is due.

And then they skipped the easy part, which is looking trustworthy to a person.

Every item on the following list is an afternoon's work, and most of it is a support ticket with the ESP:

Send from the brand. Acoustic, like every platform in this market, supports customer sending domains. documents@mail.nutshell-insure.co.uk authenticates exactly as well as insure-systems.co.uk and does not make the recipient's stomach drop.

Brand the click tracking. A CNAME from links.nutshell-insure.co.uk to the tracking host, and the URL in the status bar matches the company that claims to have sent it. This is a DNS record. It is the single highest-value change on this list.

Serve the links over HTTPS. It is 2026. A plain http:// link in a regulated firm's customer mail is an embarrassment, and it means every hop between the customer and the redirect is visible and modifiable.

Never let anchor text be a URL that is not the destination. Link the words "My Account". If the visible text is a web address, it must be the address you go to. There is no legitimate reason to break this and it is the defining characteristic of a phishing link.

Publish a sender page. One static page listing every domain and every link domain the brand uses, linked from the footer of every email. Support can point at it, customers can check against it, and the cost is one HTML file.

Teach the robot one more intent. "Is this email really from you" needs to be a recognised question with a scripted answer, pointing at the sender page above. Anything else, including the current behaviour of sending the customer to My Account, is worse than saying nothing.

There is a seventh item, which is that somebody should look at the message before it goes out, because the <title> of this one is *|MC:SUBJECT|* and there is an unrendered *|MC_PREVIEW_TEXT|* merge tag sitting in the body. A Mailchimp template, pasted into a Silverpop campaign, with the tags left in. It does not affect the security posture. It does tell you how much attention the thing received.

Whose problem this is

The reflex is to call this a security issue, and it is not, quite. Security did its job. The SPF, DKIM and DMARC records are correct, the platform is reputable, the accreditation is real.

This is a marketing problem with a security blast radius. The decisions that made this email look fraudulent were all made for marketing reasons: use the group's shared ESP tenancy rather than standing up a branded one, accept the platform's default tracking domain rather than filing a DNS request, keep the anchor text looking like a URL because it reads as more official. Each one is small, defensible, and invisible to the person making it.

The cost lands somewhere else entirely. Every insurer, bank and utility in this country runs customer education telling people to hover over links, check the sender, and be suspicious when the domain does not match the brand. Then they send mail that fails all three tests, and the customers who learned the lesson get punished for it. The ones who learn the real lesson, which is that the warnings are noise and everything is fine, are the ones who will click the next thing.

You cannot run a fraud awareness campaign and an email programme that contradicts it. Pick one.

In fairness to nutshell

None of this is a reason to avoid them, and I want to be clear about that, because it would be easy to read the preceding two thousand words as a warning and it is not one.

Look at what the email actually says. nutshell found a fault in their own compliance paperwork, decided it mattered, and wrote to every affected customer unprompted. Nobody caught them. Nobody complained. The Insurance Product Information Document is the plain-English summary of what a policy covers and what it does not, they realised they had not sent it, and they put their hand up. That is a firm with a working second line of defence, and it is a good deal rarer in this industry than it ought to be.

The price was competitive, the policy wording is legible, and once I found the words the robot was waiting for, a real person appeared in fifty-four seconds, which is more than I can say for most of my utilities. A. answered the question he had been given the tools to answer. I would recommend them.

Which is exactly why the presentation is worth fixing. A company doing the right thing should not have to send the notice in an envelope that looks forged.

I have redacted my policy number and the tracking URL above. If you want to check your own mail: in Gmail, open the message, click the three dots and choose "Show original". Look for the Authentication-Results line. You want dmarc=pass, and you want the header.from on that line to be a domain the sender would plausibly own. spf=pass on its own means almost nothing; a lot of phishing passes SPF. If DMARC passes and the From domain still looks wrong, you are probably looking at what I was looking at: a real company with a sloppy mail programme.

I gave nutshell the short version of this list in the same chat, a few minutes after A. confirmed the email was theirs. If any of it changes, I will note the date here.

One last thing, and I will keep it short because nobody likes a pitch at the end of a rant. Support triage is something I build for a living, and the failure at the top of this piece is the ordinary kind: not a model problem, an intent problem. Nobody sat down and wrote out the questions customers actually ask, so the assistant confidently answers a different one. If you would like yours to have rather more of the I and rather less of the A, that is a conversation worth having. Intelligent automation, or the form at the bottom of any page here.