How to check if someone is spoofing your company email address

Start with free reports from Gmail

Is someone using your company's email address without permission? Reports from Gmail can help you find out. When Gmail receives messages with your company domain in the From address, it can send you a free DMARC aggregate report. You request these reports by adding a reporting address to your DNS settings.

Your company does not need Gmail or Google Workspace. Someone could forge your company address and send a message to an ordinary personal Gmail account. Gmail can observe that message and include it in a report, even though it never passed through your company's mail service.

The reports summarize mail by the company domain after @. They show sending servers, message counts and authentication results, including both legitimate mail and mail that failed authentication. Google's report guide ↗

Outlook.com and Yahoo Mail send reports too

Gmail, Outlook.com, Yahoo Mail and other major mail services provide these reports. Each service summarizes the messages it received with your domain in the From address. Outlook.com FAQ, Q11 ↗ Yahoo Mail guidance ↗

Reports usually cover a day's activity. They do not cover every receiver or message, provide instant alerts, or prove inbox delivery. They still offer useful clues about how your domain is being used outside your company.

Your first reports may reveal unexpected senders

Genharden customers have been surprised to discover mail spoofing their company addresses from servers in Russia, Germany and elsewhere. Their own mail service would not have given them that view.

A country is a clue about the sending server's location, not the attacker's nationality. An overseas server is not, by itself, evidence of spoofing.

Check unfamiliar senders with your teams and compare them with the services your company uses. A legitimate newsletter can fail authentication because of a setup error. A failure alone does not prove spoofing.

Add a reporting address to rua in DNS

Look for the TXT record named _dmarc in your company domain's DNS. Its rua field specifies the email address for aggregate reports. If there is no DMARC record, you can start monitoring with an entry like this.

_dmarc.gaon.example TXT "v=DMARC1; p=none; rua=mailto:dmarc@gaon.example"

gaon.example and dmarc@gaon.example are placeholders. Replace them with your real domain and an address that can receive reports. With Genharden, use the dedicated RUA address the service gives you.

The example's p=none policy requests no quarantine or rejection for DMARC failure. Keep an existing p=quarantine or p=reject policy. Update rua in the existing record instead of adding a duplicate DMARC record.

The DMARC setup guide covers DNS entry and authorization for a reporting address on another domain.

XML reports are hard to read and manage by hand

The reports arrive as XML files. Server IPs, message counts and authentication results sit between tags, as in the excerpt below. These are not individual employees' sending logs, and they contain no subject lines or message bodies.

<row>
  <source_ip>203.0.113.7</source_ip>
  <count>12</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>fail</dkim>
    <spf>fail</spf>
  </policy_evaluated>
</row>

This example records 12 messages from one server that failed authentication. In practice, you need to keep collecting files from Gmail, Outlook.com and Yahoo Mail, then compare results for the same senders. That quickly becomes awkward to do one file at a time. Google's explanation of XML reports ↗

You can receive Yahoo reports without using Yahoo Mail at your company. If a Yahoo user receives mail with your domain in the From address, Yahoo can report what it observed on the receiving side. Yahoo's DMARC reporting FAQ ↗

Monitor in Genharden and work toward reject

Genharden collects RUA reports from receiving services and organizes them into message counts and authentication results by sender. You can review the services your company uses, investigate unfamiliar senders and monitor changes without opening each XML file.

In the example, business email passes authentication. The newsletter is legitimate but needs its setup fixed. Only the 312 failing messages from the sender reviewed and marked as blocked count as spoofed mail. The 12 messages from the undecided sender remain separate.

Genharden guides you through checking legitimate senders' authentication and strengthening your policy toward p=reject. In plain language, p=reject asks receiving services to refuse mail using your domain when it fails DMARC authentication. The receiving service makes the final decision. What a DMARC policy requests ↗

Before enforcing it, check legitimate senders and the effect on forwarded employee mail and mailing lists. It does not stop every display-name or lookalike-domain impersonation, or every message from a compromised account. See the DMARC policy guide for the next steps.

Start monitoring email spoofing with Genharden.