Checking the Sender Domain of an Unexpected Calendar Invitation
If you need to verify the sender domain of a calendar invitation you did not expect to receive, treat it as unverified until the organiser's address and delivery path make sense. A convincing company logo, a familiar meeting title and a plausible date do not establish who sent the request.
In Australia, shared Outlook and Google calendars are common, and staff in Sydney, Melbourne or Brisbane often see an invitation on a phone before it syncs to a laptop. WhatsApp messages may also carry hurried requests to accept or join, making the organiser's visible name less reliable than usual.
Pause before accepting the invitation
Do not accept, reschedule or open a linked attachment while the sender is still uncertain. Accepting can disclose your attendance, add an unwanted event to your calendar or trigger a follow-up scam aimed at people who interacted with the first message.
A free sender reputation check can reveal whether the domain is newly registered, poorly established or associated with abuse. It is one source of evidence, not proof of legitimacy, because a fraudulent campaign can borrow a domain that has a clean history.
Australian businesses frequently use .com.au or .au addresses, so begin with the exact domain rather than the brand name. A sender such as finance@company-au.com deserves more scrutiny than finance@company.com.au, especially when the invitation came through an unrelated channel.
Read the sender and authentication signals
Open the original message rather than relying only on the pop-up preview. Compare the organiser address, From address, Reply-To value and any sending-service domain; calendar systems often display one person while a notification system handles delivery. The guide on assessing an unknown sender provides a practical way to weigh these differences.
SPF, DKIM and DMARC then help assess the technical route. SPF lists servers permitted to send mail, DKIM signs content, and DMARC checks that the visible domain aligns with an authenticated domain. A pass is reassuring when the sending service and domain are expected, but it does not make a request trustworthy.
The Australian Signals Directorate publishes email-security guidance for government and business defenders, and agencies commonly use .gov.au addresses. Treat an unexpected .gov.au sender as unverified too, especially if the displayed domain has extra characters, an unfamiliar subdomain or a recent registration date.
Compare trusted and suspicious invitation patterns
Use several signals together rather than treating a familiar logo or authentication result as a shortcut.
| Signal | Reassuring pattern | Warning pattern | Sensible response |
|---|---|---|---|
| Visible organiser | Exact address known from an established contact record | Lookalike spelling or unrelated free-mail domain | Verify through a known channel |
| Domain history | Established domain with consistent reputation | Recently registered or repeatedly flagged domain | Check reputation and registration details |
| Authentication | SPF and DKIM pass, with DMARC alignment for the visible domain | SPF, DKIM and DMARC are absent, unexplained or fail | Inspect the original headers and sender pattern |
| Links and files | HTTPS link from a recognised scheduling service | Shortened URL, raw IP address or unexpected attachment | Avoid opening it until verified |
A calendar invitation may legitimately come from a delegated scheduler, so a secondary sending domain is not automatically fraudulent. Look for an aligned DKIM signature, a coherent Return-Path and a sender-service pairing that matches what the organiser normally uses.
If the invitation exposes names, work addresses, an agenda or dietary requirements, an organisation may be handling personal information. Under the Australian Privacy Act 1988 and the OAIC Notifiable Data Breaches scheme, a serious incident meeting the legal thresholds can require assessment and notification; an odd invitation is not itself proof of a reportable breach.
Confirm through a separate channel
Contact the purported organiser using a number or address already held in your directory, not the Reply-To field, invitation link or attached contact card. A short call can establish whether they sent the event, what platform they use and whether a delegate created it.
If you cannot reach the person, ask a colleague or manager to verify through an established chat thread. For a supplier, customer or recruiter, use the contact details on the organisation's known website or contract, then ask them to confirm the exact domain and event time.
When the request involves payment details, access credentials or a video link, keep the calendar event separate from those actions until verification is complete. A genuine organiser should have no reason to object to confirmation through a previously used channel.
Respond safely and strengthen team habits
Leave an unverified invitation unaccepted, report it through your email provider or security team, and warn colleagues without forwarding the live link. ACCC Scamwatch can receive scam reports, while Australian organisations can use ReportCyber for cyber incidents and preserve details that may help an investigation.
For domains your organisation owns, writing actionable DMARC reports helps security teams turn authentication failures into useful triage rather than a stream of alerts they cannot act on. Review reports by source, destination and impact, then correct legitimate senders or reject unauthorised activity.
Bulk domain checks, developer tools and an API can help teams screen recurring contacts or embed trust verification in support and security workflows. Combined with a simple rule that unexpected invitations require out-of-band confirmation, these controls make spoofing harder to exploit.
Until confirmation comes from a trusted channel, the invitation should remain unaccepted and the sending domain untrusted.