Using Gmail or Outlook? Your company domain can still be spoofed

First, separate the mail app from the mail service

Gaon's employees say they use Gmail. One member of the finance team reads the same company account in the Outlook app. That does not mean the company sends through both Google and Microsoft.

The app provides the screen for reading and composing messages. The service runs the systems that send and receive them. The domain is the part of the address the company owns. Outlook can connect to a Google account, so an app's name is not enough to identify the underlying sending service. Microsoft: accounts you can add to Outlook ↗

Gaon needs to check gaon.example, not gmail.com. Google's own domain being correctly authenticated does not establish that Gaon's custom domain and all of its sending tools are correctly configured.

Start with three facts: which service sends employee mail, where the active DNS records are managed, and which other services send using the company's address. The domain registrar and DNS host may be different companies, so the mail administrator's control panel may not show the whole arrangement.

A spoofing attempt can start outside your mail provider

An employee normally signs in to the company's chosen service. That service checks account permissions and sends the message. Strong passwords, MFA, and unusual-login detection protect this route.

An outside spoofing attempt can follow a different route. The sending server supplies the From field. The internet does not first ask for Gaon's account password before allowing a server to submit a message with that address.

Your provider can restrict unauthorized use of its own systems, but it does not control every other sending server. An external attempt might leave no record in your provider's Sent Items or outbound logs. That is why changing a password and addressing domain spoofing solve different problems.

An empty Sent Items folder does not rule out account compromise. A message may have been deleted or sent through an application or another permission. Preserve and inspect the relevant account, application, and sending logs before drawing a conclusion.

How the receiver checks the claim

SPF compares the connecting IP with a domain's authorized senders. That domain usually comes from MAIL FROM, the transfer address used for delivery failure notices, rather than the visible From address. It is commonly shown in the received message's Return-Path. A pass for an outsider's own domain does not authenticate Gaon. The identity SPF checks ↗

DKIM verifies a digital signature. The signature's d= identifies the signing domain. A valid signature from an unrelated domain does not establish that Gaon authorized the message. The DKIM signing domain ↗

DMARC checks whether a passing SPF or DKIM domain aligns with the visible From domain. At least one method must both pass and align. If neither does, the receiver considers the company's failure policy alongside its own rules. Being able to attempt delivery is therefore quite different from being guaranteed a place in the supplier's inbox. DMARC checks and handling ↗

One passing employee message does not cover every sender

Gaon's administrator sends a test from an employee account. SPF, DKIM, and DMARC all pass. That is good evidence for that route, but the company also sends monthly invoices through a billing service and replies through a customer-support tool.

Those services may use their own servers without passing through Google Workspace. They need their own domain authentication setup, even when customers see the same company domain on every message.

A legitimate invoice can fail the same check as a spoofing attempt

Suppose the billing service still uses its default mailer.example.net domain. Gaon has changed the visible sender address, but has not completed the provider's domain verification process.

From: billing@gaon.example
Return-Path: bounce@mailer.example.net
Authentication-Results: mx.partner.example;
  spf=pass smtp.mailfrom=mailer.example.net;
  dkim=pass header.d=mailer.example.net;
  dmarc=fail header.from=gaon.example

SPF and DKIM correctly authenticate the provider's domain. Neither aligns with gaon.example. The receiving system cannot see Gaon's commercial agreement with that provider; the configuration has to express the relationship.

One solution is to enable DKIM signing with the company domain in the billing service. Publish the records that service issues, activate signing, and send a new test. If the result becomes dkim=pass header.d=gaon.example, DMARC can pass through DKIM while the MAIL FROM remains unchanged. Providers may instead, or also, support a custom MAIL FROM. Check the options that your actual service offers. Microsoft: authentication and outside sending services ↗

Do not label every failure an attack or add every unfamiliar IP to SPF. Establish whether the source belongs to an approved business service. For a legitimate source, follow that provider's supported authentication process.

Check provider defaults against a received message

For Google Workspace, confirm both public-key publication and signing activation in the Admin console. Some environments may already have a working setup; inspect it before generating replacements. When choosing an RSA key, Google recommends 2,048 bits where supported. Google: DKIM setup and verification ↗

For Microsoft 365, inspect DKIM for the custom company domain and copy the CNAME targets shown for that domain in the admin interface or PowerShell. Another company's example values are not interchangeable. In either service, the final check is an externally received message with a valid signature from the intended company domain. Microsoft: DKIM for custom domains ↗

Compare the original suspicious message with a known-good one

Ask the supplier for the original message or full headers, alongside any useful screenshot. Headers contain sender identities, transfer information, and authentication results. Copying the body or forwarding the message normally may omit the evidence you need. A downloaded original or attached message preserves more of it.

In Gmail on the web, open the message, use the More menu beside Reply, and choose Show original. In new Outlook, look under the message's additional actions for View → View message details. In classic Outlook for Windows, open the message in its own window and use File → Properties → Internet headers. Labels vary by version. Gmail: viewing message headers ↗ Outlook: viewing message headers ↗

The two examples below keep only the relevant fields. Assume mx.partner.example is the supplier's trusted receiving system. Read them in order: From, the SPF and DKIM domains, then DMARC.

From: "Gaon Trading Finance" <finance@gaon.example>
Return-Path: finance@gaon.example
Authentication-Results: mx.partner.example;
  spf=pass smtp.mailfrom=gaon.example;
  dkim=pass header.d=gaon.example;
  dmarc=pass header.from=gaon.example

From: "Gaon Trading Finance" <finance@gaon.example>
Return-Path: bounce@outside.example.net
Authentication-Results: mx.partner.example;
  spf=pass smtp.mailfrom=outside.example.net;
  dkim=pass header.d=outside.example.net;
  dmarc=fail header.from=gaon.example

First, inspect the full From address. It is finance@gaon.example in both examples. Expanding the sender name is useful, but even the exact address cannot distinguish these two messages.

Next, read the domain beside each pass. In A, smtp.mailfrom and header.d name Gaon's domain. In B, both name outside.example.net. Those results authenticate the outside domain, not the company shown to the reader.

Then check DMARC. These examples assume a valid policy is published, so A passes and B fails. Without an applicable policy, a receiver may report dmarc=none. That header result is different from DNS policy p=none, which asks for no quarantine or rejection because of a failure.

Finally, compare sending records. Match the time, recipient, source IP, and provider logs. A legitimate but unconfigured billing tool can resemble B. Ask other departments about infrequently used services before deciding that an unknown source is unauthorized.

Also review the company's DMARC policy and aggregate reports. If it is monitoring with p=none, resolve legitimate failures before moving toward quarantine or rejection. RUA reports summarize observed sources and results; they are not message originals or employee login records and cannot establish the full incident path on their own. DMARC aggregate reporting ↗

Choose the next action from the evidence

“It looked like it came from your company” can describe several different situations. Classify what the original message actually shows before deciding which controls to change.

For the exact company domain, verify the sending route

If neither the employee nor an approved service sent the message, investigate unauthorized use of the domain. Correct authentication gaps and prepare an appropriate enforcement policy. Include low-volume and month-end mail in the legitimate-sender checks. Give the supplier a verified business contact and explain which message remains unconfirmed.

For a similar domain or copied name, inspect the identity itself

gaon.example and ga0n.example are different domains. Someone controlling the second can authenticate it correctly. Publishing p=reject on the first cannot prevent every message from the second. Address checking, receiver-side impersonation detection, and reporting remain necessary. What DMARC does not cover ↗

For aligned mail the supposed sender denies, investigate access

An attacker with a legitimate account or sending permission can use authorized servers and signatures. Authentication may work exactly as designed even though the payment request is fraudulent.

Preserve relevant login and sending records. Inspect unfamiliar sessions, application access, forwarding rules, and deletion rules. Where compromise is suspected, follow the provider's incident procedure to block access, revoke sessions, and reset credentials. A password reset alone can leave other permissions or rules in place. Microsoft: responding to a compromised account ↗

For a bank-account change, verify the request through a previously known phone number or contact, regardless of the authentication result. A new number supplied in the questionable message may lead back to the attacker. If a payment has already been sent, contact the financial institution promptly and preserve the message and transaction records. FBI: business email compromise ↗

Collect one original message from employee mail and one from each outside sending service. Compare their authenticated domains with their From addresses, then compare the suspicious original. That gives you a practical basis for deciding whether to repair domain authentication, investigate a misleading identity, or examine account access.