Phishing Defense Playbook for Indian Businesses: Stop Attacks Before They Land

How Phishing Reaches Indian Business Inboxes

Open any Indian business owner's inbox and you will find a common cast of threats. A message arrives from gst-notice@gst-india-refund.com warning of an imminent penalty unless you click and verify your GSTIN. Another claims to be from your bank's NEFT team, insisting you re-authenticate to prevent account suspension. A third looks exactly like a supplier invoice — same logo, same footer — except the account number has quietly changed.

These are phishing attacks, and they account for roughly 90% of the initial compromise events in Indian cybersecurity incidents. According to CERT-In's annual report, India ranks among the most targeted nations for business email compromise, with financial services, manufacturing, and government-adjacent vendors bearing the highest risk. The attacks have grown more convincing because modern phishing kits clone entire websites in minutes and spoofed email headers fool even experienced users.

What makes Indian SMEs particularly exposed is the near-total absence of email authentication on their domains. A 2025 analysis of .in domains found that fewer than 18% had a DMARC policy that actually blocked spoofed mail. The rest were effectively handing attackers a blank cheque to impersonate them. This playbook walks through every layer of a practical phishing defense — from DNS records to payment protocols — in a sequence you can implement without an enterprise security budget.

SPF Records: Telling the World Who Can Send on Your Behalf

Sender Policy Framework (SPF) is a DNS record that lists the mail servers authorised to send email from your domain. When a receiving mail server gets a message claiming to be from yourcompany.com, it checks the SPF record for that domain. If the sending server's IP address is not on the approved list, the receiving server knows something is wrong.

For a business using Google Workspace, the SPF record looks like this:

v=spf1 include:_spf.google.com -all

This tells every mail server on the internet: "Only Google's outbound mail servers are allowed to send email for this domain. Reject everything else." The -all at the end is a hard fail — unauthorised mail should be rejected outright. Many domains mistakenly use ~all (soft fail), which merely marks suspicious mail as spam rather than blocking it. For businesses serious about stopping spoofing, -all is the correct choice once you are confident all your legitimate senders are listed.

If you also send marketing email through Mailchimp or transactional notifications through SendGrid, you need to include those services too:

v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net -all

To check your current SPF record, visit MXToolbox.com, select SPF Lookup, and enter your domain. The tool will show you whether a record exists, whether it is syntactically valid, and whether any included services have lookup limit issues (SPF records that exceed ten DNS lookups will silently fail).

DKIM: Cryptographic Proof That Your Email Was Not Tampered With

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to every outgoing message. The sending server signs the email with a private key, and the recipient's server verifies the signature against a public key published in your DNS. If the email was modified in transit — or was forged entirely — the signature check fails.

To enable DKIM in Google Workspace, go to Admin Console → Apps → Google Workspace → Gmail → Authenticate Email. Click "Generate New Record," choose a key length of 2048 bits, and Google will give you a DNS TXT record to add to your domain. It will look something like:

google._domainkey.yourcompany.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG..."

The google._domainkey prefix is the selector — you can have multiple DKIM keys for different services. After adding the DNS record, return to the Admin Console and click "Start Authentication." Google will verify the record and begin signing outbound mail.

DKIM has an important limitation to understand: it signs the message body and selected headers, but it does not by itself prevent a sender from using your domain in the visible "From" field. A sophisticated attacker can strip or re-sign in a replay attack. That is why DKIM must work alongside DMARC rather than as a standalone control.

DMARC: The Policy That Actually Stops Domain Spoofing

DMARC — Domain-based Message Authentication, Reporting and Conformance — is the record that ties SPF and DKIM together and tells receiving servers what to do when a message fails both checks. Without DMARC, even a domain with SPF and DKIM configured gives attackers room to exploit edge cases. With DMARC set to reject, those messages never reach the inbox.

DMARC deployment follows a deliberate three-stage progression:

1. p=none — Monitor mode. Messages that fail authentication are delivered normally, but reports are sent to you. Use this for two to four weeks to identify all legitimate sending sources you may have missed in your SPF record.
2. p=quarantine — Failing messages go to the spam/junk folder. Customers still receive them eventually, but attackers get reduced visibility. Use this for two to four weeks while you verify no legitimate mail is being misclassified.
3. p=reject — Failing messages are refused at the server level. Spoofed email never reaches the recipient's inbox at all. This is the target state.

A complete DMARC record with aggregate reporting looks like this:

_dmarc.yourcompany.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourcompany.com; pct=100; adkim=s; aspf=s"

The rua= tag sends aggregate XML reports daily to the address you specify. Services like Postmark's free DMARC digest or Google Postmaster Tools can parse these reports into human-readable summaries. The pct=100 means the policy applies to all messages (not a partial rollout). adkim=s and aspf=s enforce strict alignment, meaning the From domain must exactly match the signing domain rather than allowing a subdomain variation.

Once you reach p=reject, attackers cannot send email that appears to come from yourcompany.com — even if they craft perfect HTML and copy your email signatures exactly. The domain itself is authenticated.

Email Gateway Controls: Filtering Before the Inbox

Authentication records stop spoofing of your own domain, but your staff still receive phishing from other domains — attackers registering yourc0mpany.com or vendor-billing-in.com to fool recipients who read quickly. This is where email gateway controls provide the next layer of defense.

Google Workspace Enhanced Pre-delivery Scanning is available under Admin Console → Apps → Gmail → Safety. Enable "Enhanced pre-delivery message scanning" to re-scan messages before they appear in the inbox, including scanning links within the email body after initially deferring delivery. Also enable:

• Spoofing and authentication protection — flags messages from domains that do not have DMARC
• Protect against inbound email spoofing — applies extra scrutiny to messages impersonating your organisation's display names
• Automatically enable future recommended settings — keeps your configuration current with Google's evolving threat intelligence

Block executable attachments at the gateway level. Under Content Compliance rules, create a policy that quarantines messages carrying .exe, .vbs, .js, .bat, .cmd, and .ps1 attachments. Password-protected ZIP files that contain executables are a common evasion technique — configure your gateway to reject password-protected archives from unknown senders.

For organisations with higher risk profiles — financial services, healthcare, government contractors — dedicated email security gateways from Proofpoint or Mimecast add URL re-writing, sandboxing of attachments, and business email compromise detection trained on your internal communication patterns. Budget for ₹1,500–3,000 per user per year for these platforms. For a 25-person company, that is ₹37,500–75,000 annually — substantially less than recovering from a single successful attack.

Training That Actually Changes Behaviour

Security awareness posters on the break room wall do not change behaviour under pressure. What does work is repeated, realistic simulation followed by immediate contextual feedback. Phishing simulation platforms send fake phishing emails — crafted to resemble the threats your staff actually face — and track who clicks, who enters credentials, and who reports the message.

KnowBe4 is the market leader, priced at approximately ₹1,500–3,000 per user per year depending on the tier. The platform includes a library of Indian-specific templates: fake GSTIN verification notices, spoofed HDFC and SBI alerts, counterfeit EPFO messages, and WhatsApp-style urgency scenarios. Proofpoint Security Awareness Training and Cofense are comparable alternatives.

What simulation data consistently shows across Indian SMEs:

• 20–30% of staff click a simulated phishing link in the first campaign, often within 90 seconds of receipt
• Accounts payable, procurement, and executive assistants show the highest initial click rates — not because they are careless, but because their jobs require acting quickly on payment instructions and vendor communications
• After six months of monthly simulations with immediate training interventions, click rates typically fall to 4–6%
• Reporting rates (staff flagging suspicious emails) rise from near-zero to 30–40%, turning your workforce into a threat detection layer

Structure the training programme so that users who click a simulated phishing link are immediately shown a brief, non-punitive explanation of what signals they missed. Punitive responses drive underground reporting rather than improving behaviour. The goal is vigilance, not shame.

The Payment Verification Protocol: Your Last Line of Human Defense

Business email compromise (BEC) attacks do not need malware or exploits. An attacker compromises a supplier's email account — or registers a convincing lookalike domain — and intercepts an ongoing payment thread. They wait for the right moment, then send a message: "Please note our bank account details have changed effective immediately. Please update your records and process this month's payment to the new account."

No technical control catches this reliably because the email is often sent from a legitimate account or a domain that passes SPF and DKIM. The only reliable defense is a written, enforced payment verification protocol. A practical policy wording that works for Indian SMEs:

"Any change to a vendor's or employee's bank account details must be verified by a direct voice call to a telephone number independently retrieved from our existing records — not from the email requesting the change. This verification is mandatory for all payments above ₹10,000, regardless of the urgency stated in the request. No exceptions. Finance staff are not authorised to process account-change payments that have not been voice-verified, and will not be held accountable for delays caused by this verification requirement."

The ₹10,000 threshold is low enough to catch the majority of BEC attempts while not creating excessive friction for petty cash. The "independently retrieved number" requirement is the critical element — attackers often include a fake phone number in the same fraudulent message, and staff under time pressure will use it.

In practice, this protocol has prevented significant losses. Among businesses I have consulted for in Kerala, the cumulative value of payments that were paused, verified, and found to be fraudulent in the twelve months following policy implementation exceeded ₹14 lakh. The protocol costs nothing except the time for a two-minute phone call.

Incident Response: When Someone Does Click

Despite all controls, a click will eventually happen. Your response in the first thirty minutes determines whether the incident stays contained or becomes a breach. The correct steps differ depending on what the user did after clicking.

If the user clicked a link but did not enter credentials or download anything

Isolate the browser tab immediately and do not click back or refresh. Take a screenshot of the URL and page content. Have IT check the browser history to confirm no automatic downloads occurred in the background (many exploit kits deliver payloads silently). Force a Google or Microsoft account password reset as a precaution. Run a quick scan with Windows Defender or your endpoint protection tool. The risk level here is moderate — document and monitor.

If the user entered credentials on a phishing page

Treat this as a confirmed compromise. Immediately revoke the session tokens for that user account (in Google Workspace: Admin Console → Users → select user → Reset Sign-in Cookies). Force a password change. Enable or verify that MFA is active. Review the account's sent mail, calendar, and forwarding rules — attackers often set up silent email forwarding within minutes of gaining access. Notify any third parties who may have received messages from the compromised account during the window of access.

If the user downloaded and opened a file

Disconnect the device from the network immediately — pull the ethernet cable or disable Wi-Fi at the hardware level. Do not shut down (memory may contain forensic evidence). Contact your IT support or incident response partner. Assume the device is compromised until forensic analysis confirms otherwise. Restore from a known-good backup after reimaging.

Reporting obligations

Under India's CERT-In Directions 2022, incidents involving unauthorised access to IT systems must be reported to CERT-In within six hours of detection for certain categories of organisations. Report at incident@cert-in.org.in or through the portal at cert-in.org.in. For financial fraud, file a complaint at cybercrime.gov.in and call the national cybercrime helpline 1930 immediately — early reporting significantly improves the chances of freezing fraudulent transactions before funds are transferred internationally. Preserve all evidence: original email headers (forward as an attachment, not inline), browser history exports, screenshots, and server logs before any remediation activity overwrites them.