Skip to content
MSTMail Security ToolsField guide · Omaha

Directory / Guides

Field note · 2026-10-15 · DME Computer Services

Is my email domain being spoofed? How to tell

Spoofing, on this page, means a message whose From address uses your exact domain and that your mail system did not send. You tell by reading headers or DMARC reports. The DNS record alone is not the sighting.

A customer forwards you a message that looks like it came from your domain. Before you change DNS, get the headers. Without them you are guessing, and the guess is often a lookalike domain or a real message from a mailbox someone else opened.

Two things people call spoofing

The first is your exact domain in the From address, sent by someone who is not your mail server. DMARC is the control for that, once SPF or DKIM is aligned and the policy is no longer p=none. RFC 7489 is the spec.

The second is a different name that looks like yours. Your DMARC record does not apply to a domain you do not own. The headers will show that other name if you read them. Treat it as a lookalike, warn the people who pay invoices, and do not expect p=reject on your domain to stop it.

Get the headers

In Gmail, open the message and use Show original. The menu has moved before. If you cannot find it, search Google's help for that phrase rather than trusting a screenshot from a blog.

In Microsoft 365, the admin docs for message headers are on Microsoft Learn. You can paste a header into the Message Header Analyzer. Ask the person who received the mail to send the headers, not a screenshot of the body.

Read Authentication-Results

That header is defined in RFC 8601. A sender can put a fake copy in the message. Read the one your receiving mail system added. It is usually the latest one, and it names the host that did the check.

Then match what you see:

  • dmarc=pass and the From domain is yours. The receiver accepted it as aligned. If you did not send it, look in Sent. A message your host really sent is a compromised mailbox, not a DMARC failure.
  • dmarc=fail and the From domain is yours. The receiver could tell it was not authenticated as you. If your published policy is p=none, it may still have been delivered. If it is quarantine or reject, a receiver that honors DMARC should have filed or refused it. Not every receiver honors it.
  • No dmarc= result. You may not have a record at _dmarc, or that receiver did not check. You then have no aggregate reports either, so you cannot see the other copies from a report you never asked for.
  • spf=pass with a domain that is not your From domain, or dkim=pass with d= set to a vendor. Those passes belong to someone else. DMARC does not treat them as you.

If you already collect reports

Aggregate reports go to the rua address on your DMARC record. They list source IPs and whether SPF and DKIM aligned. A source you do not recognize, failing both, on more than one day, is the pattern worth chasing. A single fail is often a forward or a list that rewrote the message. Do not rewrite your SPF record from one row.

The XML is unpleasant to read by hand. The DMARC category in the directory is the products that take those reports. Each listing says what that vendor's own page said about price and a free tier, and the date we read it.

What the DNS check can and cannot say

/check reads MX, SPF, DMARC, and five common DKIM selectors at the moment you ask. It stores nothing. A missing DMARC record, an SPF record that ends in +all, or no SPF record at all means receivers are not being given a strict instruction. That is a reason to publish the records. It is not a sighting of a forged message.

A DKIM warning from that check only means those five selector names had no usable key. A custom selector will not show up. The selector in the header is the one that matters.

What to do when the headers say fail

Tell the person who received it not to pay, not to open the attachment, and not to reply. If the message asked for a new bank account, confirm any real change by a phone call to a number you already had, not the number in the mail.

Then fix the publishing gap if there is one. The order is SPF, DKIM, DMARC at p=none with a report address, then quarantine, then reject. That sequence is How to set up DMARC. Moving straight to reject while a real sender still fails will bounce mail you wanted.

If the message is in Sent, stop treating it as a spoof. Block the sign-in, revoke the sessions, and look for a rule that forwards mail out of the company. That is account takeover. DMARC passed because the mail was yours.

Sources

Free check · nothing stored

See the records you have now

The checker reads MX, SPF, DMARC, and five common DKIM selectors once. It does not send a message, it does not read DMARC reports, and it does not keep the domain.

Report readers and DNS checks. InboxGuards is not in this list on purpose: it alerts on account takeover inside Google Workspace or Microsoft 365, which is a different problem from a forged From address.

The other two notes

Questions

Short answers to the questions this note is for. The paragraphs above are the longer version.

Can a DNS lookup prove someone is spoofing me today?
No. DNS shows whether receivers have a policy and a list of your senders. It does not show that a particular message was forged this morning. For that you need the message headers, or DMARC aggregate reports if you asked for them.
Someone used a domain name that looks like ours. Is that DMARC?
Not unless the From address is your actual domain. A cousin name, or a name with a swapped character, is a different registration. Your DMARC record does not apply to it. You can still report it to the registrar and warn the people who pay bills.
The message is in our Sent folder. Is that spoofing?
No. If your mail host sent it, SPF and DKIM will usually pass, and so will DMARC. That is a mailbox someone else can use. DMARC will not flag it, because the mail really came from you. Lock the account, revoke sessions, and look for a forwarding rule.
We have p=none. Can spoofed mail still arrive?
Yes. p=none asks for reports and does not ask receivers to quarantine or reject. The reports are how you see the sources. They are not a block.
One failed row in a DMARC report means an attack?
Not by itself. Forwarders and some mailing lists fail SPF, and sometimes DKIM, on mail you really sent. A source that fails both, that you do not recognize, and that shows up more than once, is the pattern to investigate. One row is a reason to look, not a verdict.