Email impersonation can affect your customers even without a breach of your systems. In one possible scenario, a customer receives a message that appears to come from your company and acts on a fraudulent request. In another, a real account may have been compromised. Establishing which situation applies is part of the investigation, rather than something to assume from the appearance of the message.
That conversation is difficult in a way the technical problem is not. Your customer does not want an explanation of protocols. They want to know why an email with your name on it was able to reach them, and what you have done about it. Having an accurate answer helps you explain what is known, what remains under investigation, and what steps the customer can take.
Three different things people call spoofing
The term can describe different situations. Separating them helps you choose an appropriate response.
Display-name impersonation uses the familiar name shown beside an address. The sender sets the display name to your company while the actual address is an unrelated free mailbox. It works because many mail clients, particularly on phones, show the friendly name prominently and the address barely at all. You cannot prevent someone typing your name into a field, and this is largely a matter of what recipients notice.
Lookalike domains are the middle ground. Someone registers a domain that reads like yours at a glance — a swapped character, a different ending, an extra word — and configures it properly. Mail from that domain may pass authentication if it is configured to do so. That result says nothing about whether the domain is associated with your company. Authentication records on your own domain do nothing here.
Exact-domain spoofing is the one you can directly affect. Someone sends mail claiming to be from your actual domain. This is what SPF, DKIM and DMARC exist to address, and it is the reason those records deserve your attention.
The check, in about ninety seconds
Our training walkthrough shows a free check you can run yourself, with no account required. You need one thing: your domain name.
What you are looking for is whether your domain publishes an SPF record, whether it publishes a DMARC record, and if so, what policy that DMARC record states. Those three facts tell you roughly where you stand.
Reading the result honestly matters more than running it. Three distinctions are useful when interpreting a check.
SPF authenticates the envelope sender — the address used at the protocol level — not necessarily the From address a recipient reads. An SPF pass on its own does not mean the visible sender is genuine.
DMARC is what ties authentication to the domain your recipient actually sees. It is satisfied by an aligned SPF result or an aligned DKIM signature; it does not require both.
A DMARC policy of p=none is a monitoring posture, not a blocking one. It does not request quarantine or rejection because of DMARC failure. Reports require configured reporting destinations and receiving-system participation. Seeing a DMARC record in a result does not, by itself, mean an enforcement policy is in place. It is a legitimate and sensible first step, but on its own it does not ask anyone to stop a message.
What a good outcome looks like
- SPF published, and accurately listing the services that legitimately send on your behalf.
- DKIM signing enabled at your mail platform and at your significant third-party senders.
- DMARC published, with reporting going somewhere a human or a service actually reviews.
- A deliberate plan to move the policy from monitoring toward enforcement once your legitimate senders are confirmed.
- A record of which systems send mail as your domain, kept current as marketing and finance tools change.
The sender inventory helps you interpret reports and plan changes. Places to check include the mail platform itself, an invoicing system, a marketing tool, a CRM, an appointment reminder service, a form on the website, and older services that may still be active.
Changing a policy before understanding legitimate senders can interrupt wanted messages. Consider a hypothetical company that moves straight to a rejecting policy and discovers a week later that its appointment reminders have been silently discarded, having never appeared in the inventory because a different department bought that tool. Do the inventory first, watch the reports, then tighten.
The parts that are not technical
Authentication addresses only part of the problem. Clear verification procedures give staff and customers an additional way to handle requests that appear unusual.
Tell customers plainly how you will and will not contact them, and put it somewhere permanent on your website. Establish a rule that changes to bank details are always verified by a phone call to a previously known number, in both directions, and tell your customers you expect them to do the same to you. Make it socially acceptable — expected, even — for someone to ring and check. Attacks like these rely on urgency and on people not wanting to seem distrustful.
If an impersonation attempt does reach your customers, tell them quickly and specifically. A factual notice can help recipients recognize the message and find a trusted contact. Avoid asserting a cause before it has been established, and coordinate the response with the people responsible for the incident.
What authentication does not do
Correct records do not guarantee delivery, and they do not make your mail immune to being filtered. They do not prevent lookalike domains. They do not help when a real account of yours has been compromised, because mail from that account may pass authentication. And a failure at the receiving end does not prove malice — forwarding and misconfiguration can affect results.
They help receiving systems evaluate messages that claim to use your exact domain. That is worth doing, and it is not the whole answer.
Your next step
Watch the walkthrough and run the check on your own domain today. Write down what you find, then start the sender inventory — it provides context for the next decisions.
If you would rather have someone work through it with you, ALCO USA Inc does this alongside managed hosting, development and IT support.
Sources and further reading
ALCO training on email spoofing: https://alcohq.com/training/email-spoofing
Video walkthrough: https://youtu.be/ueK8L2fFGv0
Google on preventing spoofing with SPF, DKIM and DMARC: https://support.google.com/mail/answer/81126?hl=en-GB
RFC7208, SPF: https://www.rfc-editor.org/rfc/rfc7208
RFC7489, DMARC: https://www.rfc-editor.org/rfc/rfc7489