How to Tell If Someone Is Spoofing Your Domain Right Now

Nothing tells you when somebody starts sending email in your business name. There is no bounce, no alert, and nothing in your sent items. Most people find out when a customer rings about an invoice they never sent, and by then the money has usually gone.

Almost everything you need to check is published in your own DNS, where anyone in the world can read it, including you. What follows takes about ten minutes and needs no access to your mail server for most of it.

First, work out which problem you actually have

Three quite different things get called spoofing, and they need three different responses. Getting this wrong wastes the most useful hours you have, so it is worth thirty seconds before anything else.

The third one is an emergency and the rest of this article is the wrong page for it. If mail is going out of a real account right now, containment comes before hardening, and there is a separate page on what to do in the first hour.

The second one is the most common thing people mean when they say somebody is spoofing them, and it is the one nobody wants to hear the answer to. A look-alike domain belongs to the attacker. You cannot publish a record that governs it, because it is not yours. What you can do is make your own domain unusable for the same trick, which narrows them to the option that is easier for a careful reader to spot.

The first one is what the rest of this is about, and it is the only one you can shut down permanently.

Start with one lookup

Three records decide whether your exact domain can be forged: your DMARC policy, your SPF record and your DKIM signing. Done by hand that is three separate lookups in three different places, which is why most people start and do not finish.

What the DMARC answer means

Read this one first, because DMARC is the record that decides what happens to a forged message. Everything else is input to it.

If there is no DMARC record, your domain has no protection and anyone can send as you. If the policy reads p=none you are in monitoring mode, which asks receivers to report and to take no action, so the forged message still arrives in the inbox. Only p=quarantine, which sends it to junk, or p=reject, which refuses it at the door, actually stop anything.

One more thing to look for while you are there. If the record has no rua address, no reports are being generated for your domain at all. Receivers are told not to bother. A record in that state looks like protection to anyone who glances at it and produces nothing you can act on, which is the worst combination available.

What the SPF answer means

SPF is the list of servers allowed to send for your domain, and three things about it matter.

It has to name every service that legitimately sends on your behalf. That usually means Microsoft 365 plus whatever handles the invoicing, the newsletter and the bookings, and the forgotten one is almost always a system somebody signed up for without telling anybody.

It has to end in -all, a hard fail, which tells receivers to drop anything from a server not on the list. A record ending in ~all is a soft fail, which asks them to deliver it anyway and make a note. Plenty of records sit on the soft version for years because it was the safe choice during setup and nobody went back.

And it has to stay under ten DNS lookups. This is the one that catches people, because the limit counts every include your record walks through, not just the ones you typed. A record can read as two short lines and still need seventeen lookups once the includes behind it are followed. Go over and SPF fails permanently for every message you send, from every server, and nothing in your own systems reports it.

What the DKIM answer means

DKIM is the cryptographic signature on your outgoing mail. In Microsoft 365 you can confirm it in the Defender portal, under Email Authentication Settings, then DKIM.

If it shows as disabled, nothing you send is signed and your mail is leaning entirely on SPF. That matters more than it sounds, because SPF breaks the moment a message is forwarded: the forwarding server is not on your list, so the check fails even though the message is genuinely yours. DKIM survives forwarding, because the signature travels with the message rather than describing the server that delivered it. A domain relying on SPF alone will have DMARC failures it cannot explain, and most of them will be legitimate mail.

Then read the reports

A lookup tells you what your records say. It cannot tell you who has been sending as you, which is the question you wanted answered in the first place.

If your DMARC record carries a reporting address, receivers send back a daily summary in XML of every message that claimed to come from your domain, including the sending address, whether it passed and how many there were. Read those and look for sending sources you do not recognise. One unfamiliar host that appears once is usually a forwarding service or a customer with an unusual mail setup. The same unfamiliar host week after week, sending volume, is the clearest evidence you are going to get.

Give it time before drawing conclusions. The monthly and quarterly senders only appear in reports when they send, so a full picture of who legitimately uses your domain takes weeks rather than days. That waiting period is the reason domains sit at monitoring far longer than they should, and it is also the reason moving to enforcement before it is done tends to break something.

Checking one suspicious message

If somebody has forwarded you a message and you want to know whether it really came from you, the answer is in the headers rather than the body. In Outlook, open the message, then File and Properties, and read the internet headers. In Gmail, use Show original.

Look for the Authentication-Results line. It records what the receiving server concluded, and it will say spf=pass or spf=fail, dkim=pass or dkim=fail, and dmarc=pass or dmarc=fail. A message that failed DMARC and arrived anyway tells you two things at once: somebody forged you, and your policy is not at enforcement. If it says dmarc=pass, the message really did come from a system authorised to send as you, which points at the third row of the table above rather than the first.

What you can actually do about it

You cannot stop anybody from sending a message with your name on it. Nothing in email can do that, and any product claiming otherwise is selling you something it cannot deliver. What you can do is make sure those messages are not delivered, which is what an enforced DMARC policy does and is the whole of the available remedy.

For a look-alike domain the options are worse and slower: a report to the registrar, a report to the hosting provider, and if the name is close enough to a trade mark, a formal complaint. None of it is fast. Warning the customers who are likely targets is usually the thing that actually prevents the loss.

If you find a problem, fix it in this order

The order matters more than any individual step. Enforcing a policy before the authentication underneath it is sound is how a business discovers that its own invoices stopped arriving, usually from an irritated customer rather than from a report.

• •Get SPF naming every legitimate sending source, and under the ten lookup limit
• •Enable and verify DKIM in Microsoft 365, so forwarded mail still authenticates
• •Publish a DMARC record with a reporting address if there is not one
• •Read the aggregate reports until you recognise every sender in them, which takes weeks not days
• •Only then step the policy up, first to quarantine and then to reject
• •Publish a record on every domain you own but never send from, so those cannot be forged either

That last one gets skipped almost every time. A domain you registered defensively and never used is not covered by the records on the domain you do use. Until it has a record of its own saying it sends nothing, it is available to anyone who wants to invoice your customers under a name they recognise.