Check what is actually impersonating the business
A message can show the company's name while using an unrelated address. It can use a similar-looking domain that the business does not own, forge an address at the genuine domain or come through a legitimate account or connected sender. A screenshot of the visible sender alone cannot distinguish all of these possibilities.
Ask the recipient to preserve the original message through an approved process. Do not click its links or forward it widely with private information intact. Record when it arrived, the apparent sender and the action requested. If the message asks for a bank-account change or urgent payment, verify through an independently known contact before acting.
| What appears in the message | What to investigate | Why DMARC alone is not the whole answer |
|---|---|---|
| Company name, unrelated address | Display-name impersonation | The protected business domain may not be used |
| Similar domain spelling | A separately registered lookalike | Your policy does not control another owner's domain |
| Genuine domain, untrusted sending route | Authentication and alignment evidence | A visible From address can be forged |
| Legitimate authenticated account | Account, application and sending activity | Authentication does not prove the account is uncompromised |
Use message headers from a trusted receiving path
Headers can show how the message travelled and what the receiving system evaluated. SPF, DKIM and DMARC results refer to particular identities and conditions. The administrator needs to understand the trusted receiving boundary; an arbitrary Authentication-Results line inside a message is not automatically trustworthy.
Keep conclusions specific. A DNS record currently visible to a public checker does not prove how a previous message was evaluated. A failed result can also affect a legitimate but misconfigured sender. Gather the original example, relevant times and the receiving provider's evidence, and redact unnecessary content before sharing the case.
Check legitimate accounts and sending applications separately
If there are unfamiliar sign-ins, rules, application grants or messages actually sent from the account, involve the authorized administrator in an account-compromise response. Changing only DNS records does not revoke every active session or connected application. The response should also address recovery controls and the trusted device used to administer the account.
Conversely, an apparently forged message does not prove that an employee mailbox was accessed. Avoid resetting every account or deleting business senders without evidence. The useful decision is which observation supports which next check, with the uncertainty recorded rather than filled by the first plausible explanation.
What authentication can improve
SPF describes permitted sending sources for the relevant envelope identity. DKIM validates a signature associated with a signing domain. DMARC evaluates the visible From domain's alignment with a passing SPF or DKIM route and communicates domain policy. Configure these around the business's actual senders, including websites and external tools.
A move toward enforcement should follow inventory, message checks, report review and a plan for exceptions. The current DMARC standard is RFC 9989 from May 2026. Do not rely on a copied legacy configuration or imply that publication of reject stops every kind of impersonation. Recipient handling and legitimate account activity remain separate issues.
Avoid making legitimate business mail the collateral damage
Map employee mail, CRM, billing, support and website notifications before changing authentication. A source not recognized in a report needs investigation, not automatic authorization or removal. Check the appropriate provider configuration and a representative message for each important route, including functions that run only periodically.
Record what changed and how to reverse it if the agreed checks fail. A successful employee message does not cover an invoicing integration. Likewise, a valid authentication result does not guarantee inbox placement; receiver rules, reputation and message characteristics can affect delivery. Google and Microsoft guidance is specific to their services and applicable sending patterns.
If a payment or data disclosure may already have happened
Stop further action and contact the appropriate financial, account or information owner through a known route. Keep timestamps, transaction references and the original communication for the authorized responders. Do not rely on contact details supplied in the suspicious exchange, and do not resend a payment or expose more information as a test.
Reporting, notification and recovery options depend on the jurisdiction, provider and facts. This guide does not set a global legal deadline or promise that funds can be recovered. Technical authentication work can support prevention, but it does not replace an urgent financial response or qualified legal advice where needed.
What to include when requesting technical help
Provide the genuine domain, mail platform if known, type of symptom and whether a trusted administrator has found unusual account activity. Describe the requested action without sending passwords, verification codes or a complete customer email thread in the enquiry form. An original message can be shared later through an appropriate agreed route.
CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide, with a focus on websites, mail and digital-infrastructure dependencies. We can clarify a scoped authentication or access task within the services described on this site. Authentication work, account investigation and urgent financial action have different owners and should be coordinated according to the facts.
