How to Verify a Vendor’s Customer Support Email

A customer support message can look perfectly familiar while coming from an unrelated mailbox. Attackers often copy a vendor’s branding, ticket numbers and signature, then use a lookalike domain to request passwords, payment changes or remote access. Checking the sender address carefully is a practical way to reduce phishing and business email compromise risks.

For Australian organisations, the stakes are significant. A message that appears to come from an IT provider in Sydney, a software supplier in Melbourne or a managed service company supporting a regional office may arrive during a busy arvo and seem routine. A few technical checks can show whether it really belongs to the vendor’s domain.

Start With the Complete Sender Address

Do not rely on the display name, logo or profile image. Expand the sender details and inspect the address after the @ symbol. A genuine vendor might use support.vendor.com, while an impostor could register vendor-support.com, vendor.com.au.security-alerts.com or a misspelt version such as vend0r.com.

Read the address from right to left when checking its ownership. In help@tickets.vendor.com, the organisational domain is vendor.com; in help@vendor.com.au.example.net, the real domain is example.net. Be cautious with extra hyphens, unfamiliar country-code combinations and free-mail accounts. A .com.au address can look reassuring in Australia, but the ending alone does not prove that the organisation owns it.

Compare the Reply Path and Links

The visible From address is only one part of an email’s routing information. Review the Reply-To field, especially if the message asks you to respond, provide a verification code or approve an account change. A support email claiming to be from a vendor but directing replies to Gmail, Outlook or a different unrelated domain deserves independent verification.

Hover over links without opening them and compare the destination with the known vendor domain. Shortened URLs, unusual subdomains and spelling changes are warning signs. A legitimate ticket may use a separate support platform, but the vendor should document that arrangement on its official website or in previous correspondence. Never use a phone number supplied only in a suspicious message; find the published number yourself.

Inspect Authentication Results

Email authentication provides useful evidence about whether a message was authorised. SPF checks whether the sending server is permitted to send for the domain. DKIM attaches a cryptographic signature, and DMARC tells receiving systems how to handle messages that fail alignment checks. These controls help detect spoofing, but a pass result does not make every message safe: a criminal can send from a genuine but compromised account or an attacker-controlled domain.

Open the message’s technical details and look for Authentication-Results. Check whether SPF and DKIM show pass, whether the signing domain matches the vendor, and whether DMARC passes with alignment. Header formats vary between Gmail, Microsoft 365 and other services, so a security team may need to interpret results alongside the envelope sender and originating servers. You can run an independent domain reputation and authentication check through Trusted Sender Score when investigating a vendor domain.

Verify the Request Through a Separate Channel

An email asking for a password reset, bank account change, invoice payment or urgent remote session should be treated as a high-risk request. Contact the vendor using a number from its official website, contract or existing support portal. If the vendor operates in Australia, check its registered business details and established contact routes rather than trusting a new number in the email.

For an internal help desk, pause the ticket and ask the vendor to confirm it through the portal or a known account manager. This is especially important when an email references an Australian customer, an NBN-related service, a government contract or a GST invoice. Familiar wording such as “no worries” or “just chasing this up” can be copied easily, so conversational style is not evidence of authenticity.

Build Ongoing Domain Trust Checks

A single inspection may miss a compromised vendor account or a domain whose reputation changes later. Record the vendor’s approved domains, support portals, sending services and escalation contacts. Monitor SPF, DKIM and DMARC changes, newly observed subdomains, certificate details and reputation signals over time. A sudden change in sending infrastructure should be reviewed before staff continue trusting messages.

Security teams handling many suppliers can automate these checks instead of examining every domain manually. The API threat hunting guidance explains how domain trust data can fit into detection workflows, while this trust monitoring checklist supports recurring reviews. Combined with staff awareness and a clear payment-verification process, these controls make suspicious vendor correspondence easier to stop before it reaches a customer, finance team or administrator.