A one-person accounting practice received an angry call from a client who had paid an invoice to a new bank account. The email asking for the change looked like it came from the accountant's domain. It had not.
Her domain had no DMARC record, and her SPF record was permissive. Anyone could send mail with her address in the From line, and many mail systems would accept it.
She published stricter SPF, set up DKIM through her mail provider, and added a DMARC policy that rejects failures. She also began telling clients that bank details never change by email alone, and that a phone call would always confirm. This is a composite, built from the sort of case a support desk sees every few months, and the order of events below is the usual one.
The phone call
The first sign was not a bounce or a warning. It was a client of eleven years ringing on a Thursday morning, polite at first, then not. He had received an email, apparently from the accountant, saying her practice had changed banks and that the next invoice should go to a new sort code and account number. He had paid it the same afternoon. The money was now with someone else.
The email looked right. The display name was hers, the address was hers, the signature block had been copied from an earlier genuine message, and the tone was her usual brisk friendliness. The only odd thing, in hindsight, was that it came at ten past six in the evening, when she normally stopped work at five.
She did what most people do first: she assumed her mailbox had been broken into. She opened the Sent folder and found nothing. No message to that client, nothing odd on the date. That should have been the clue that the mail never passed through her account at all, but at the time it only made her feel more confused, and rather more frightened.
How a forged From line works
Email was designed in an era when the people on the network knew each other. The address you see in the From line of a message is just a header, typed by whoever composed it. Nothing in the original protocol checks that the sender is entitled to use it. A criminal can put your address there from a laptop in a café, and the receiving server has to decide for itself whether to believe it.
Modern checks exist to help the receiver decide. SPF lets a domain publish a list of servers allowed to send for it. DKIM adds a cryptographic signature that proves a message was sent by something holding the domain's private key and was not altered on the way. DMARC ties them together: it says which of those checks must line up with the visible From domain, and what the receiver should do when they do not. Without DMARC, a failing check is a hint, not an instruction, and most receivers lean towards delivering the message.
What her DNS looked like
Her domain was registered years earlier and the mail was hosted by her web host. The records had been set up once and never looked at again. A quick check from any terminal showed the problem within a minute.
$ dig +short TXT example.com
"v=spf1 +all"
$ dig +short TXT _dmarc.example.com
(nothing returned)
$ dig +short TXT selector1._domainkey.example.com
(nothing returned)The SPF record ended in +all, which says that every server on the internet is authorised to send for the domain. It is the opposite of what the record is for. Someone had probably added it to get a mailing tool working years ago and left it. There was no DMARC record at all, and no DKIM key published, so her own outgoing mail was not signed either.
Put plainly: there was nothing for a receiver to check, and nothing telling it what to do if a check failed. The forger did not need to be clever. He needed a mail server and her address.
Wrong turns
She spent the first day on the wrong problem. She changed her mailbox password, enabled two-factor sign-in on the webmail, and asked her host whether the account had been accessed from abroad. All good hygiene, none of it relevant. The login log showed only her own address and her own phone.
She also reported the payment to her client's bank, which was the right move and the only one with any chance of recovering money. Banks in the UK can sometimes recall a payment quickly if the fraud is reported the same day, and slowly or not at all after that. Some of it was recovered; the details are not the point here.
The useful step came when a friend forwarded her the original message with full headers. Under Authentication-Results the receiving system had written spf=pass, because her own record allowed everything, and dmarc=none, because no policy existed. The message had been marked as passing. The sending server was in a hosting range she had never heard of, and the Return-Path was a throwaway domain.
The fix, in stages
Switching straight to a reject policy is tempting and risky. If any legitimate source of her mail, such as an invoicing tool or a newsletter service, was not covered by SPF and DKIM, it would start bouncing. So she did it in order.
- Replaced the SPF record with one naming only her mail provider, ending in
-all. The SPF builder produced the string. - Turned on DKIM signing in her mail provider's control panel and published the key it generated.
- Published a DMARC record in monitoring mode, with a reporting address, and read the daily reports for two weeks.
- Added her invoicing tool to SPF after the reports showed it sending as her.
- Moved the policy to quarantine, then to reject.
example.com. TXT "v=spf1 include:_spf.mailhost.example -all"
sel1._domainkey TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s"The DMARC builder helps with the syntax, and the DNS cheatsheet covers the record types if TXT records are new to you.
What the new policy does and does not do
With a reject policy in place, a receiving server that honours DMARC will refuse a message claiming to be from her domain unless it passes SPF or DKIM with a matching domain. The big mailbox providers do honour it. Smaller or older systems may not, so it reduces the problem sharply without erasing it.
It does not stop lookalike domains. A forger can register examp1e.com or example-accounts.com, publish perfect records for that, and send from it. Her own domain's DMARC has no say over those. That is why the second half of her fix was not technical.
| Attack | Stopped by DMARC reject? | What helps instead |
|---|---|---|
| Forged From using her exact domain | Yes, at providers that enforce it | SPF, DKIM, DMARC |
| Lookalike domain | No | Phone confirmation, client awareness |
| Stolen mailbox password | No | Two-factor sign-in, login alerts |
| Compromised client mailbox | No | Phone confirmation |
The process change
She wrote a short paragraph and added it to her email signature, her engagement letter and her invoice footer: bank details never change by email alone. Any change request is confirmed by a phone call to a number already on file, not one quoted in the message. She also rang her twenty or so regular clients and told them the story, which she found embarrassing and which most of them found reassuring.
Clients tend to respond well to this. A short, specific rule is easier to follow than general advice to be careful, and it gives them a polite way to say no to a stranger who sounds urgent.
A ten-minute check
Three queries tell you most of what you need. Replace the domain with your own.
dig +short TXT example.com | grep spf
dig +short TXT _dmarc.example.com
dig +short TXT YOURSELECTOR._domainkey.example.comIf the first line ends in +all or ?all, or the second returns nothing, you are where she was. Send a message to a mailbox you control at a large provider, open the full headers, and look for spf=pass, dkim=pass and dmarc=pass. The troubleshooting guide has more on reading headers.
Quick answers
Will a reject policy break my own email?
It can, if something sends as you without being listed in SPF or signing with DKIM. That is what the monitoring stage is for. Read the reports before tightening.
Is SPF alone enough?
No. SPF checks the hidden envelope sender, not the From line people read. DMARC is what connects the check to the visible address.
Does this protect my clients if their own account is hacked?
No. A compromised client mailbox can still receive a forged message that passes. Phone confirmation is the defence there.
Can I get the money back?
Report it to the paying bank the same day, and to Action Fraud. Speed matters more than anything else.
Afterwards
Email records that were set up once and never read are a liability, and a permissive SPF record is worse than none. Publish SPF, DKIM and DMARC, move to enforcement in stages, and pair the technical fix with a rule about bank details that clients can remember. None of it is difficult. It has to be done before the phone call rather than after.