Email security is the set of measures that protect an organization's email from attackers who use email to trick people. There are two main threats: phishing, where a fake email gets the reader to click a link, open a file or type a password, and Business Email Compromise (BEC), where the target is tricked into sending money or changing payment details. No single control stops both, so the defense has to work in layers.

Two threats and the figures behind them

A joint guide from four US agencies, CISA, NSA, FBI and MS-ISAC (October 2023), says attackers use phishing mainly for two goals: stealing login credentials and deploying malware. The FBI describes BEC as a scam aimed at getting funds transferred without authorization.

  • Credential phishing: attackers pose as a manager, colleague or the IT team and get the user to type a username and password into a fake sign-in page. CISA notes the same lures also arrive by SMS and chat apps such as Teams or WhatsApp, not only by email
  • Malware phishing: a link or attachment that makes the device download and run malware, used to get in, steal data or gain more privileges
  • BEC: attackers take over a real mailbox, or pose as someone the target knows, and ask for a payment or a change of bank account. The FBI says the targets are businesses that work with suppliers and regularly make wire transfers

The IC3 (Internet Crime Complaint Center) is the FBI's reporting center for internet crime and collects complaints from victims. Its 2025 annual report lists 24,768 BEC complaints with reported losses of about 3.05 billion US dollars, against 21,442 complaints and about 2.77 billion dollars in 2024. Both the number of complaints and the reported losses rose.

These figures count only the complaints filed with the IC3 and are not statistics for Thailand, but they show the scale of the problem. In the same report, the Phishing/Spoofing category has the most complaints, 191,561, and reported BEC losses are the second highest, after investment fraud. An FBI public service announcement from September 2024 says reported BEC losses worldwide from October 2013 to December 2023 added up to more than 55 billion US dollars.

Five layers of defense

No single layer stops everything. Each layer stops a different part of the problem, and the next layer catches what the one before it missed. The five layers in this article are proving who sent the message, filtering at the entrance, protecting accounts, double-checking before payments, and giving people the knowledge and a way to report.

INFOGRAPHIC
Five layers: what each stops and what gets past
A deceptive email
each layer has its own gap
1 Prove the sender
stops forged real domain, not look-alikes
2 Filter the entrance
catches bad links and files, may miss a plain payment request
3 Protect accounts
blocks takeover with stolen passwords
4 Double-check payments
stops the transfer even if the email looks real
5 People and reporting
catches what tools miss and warns others sooner

Layer 1: prove who sent the message

Every email has a sender domain, the part after the @ sign, such as example.com. Attackers often forge the domain of the organization or of a business partner. Three measures let a receiving system check whether a message that claims a domain really came from a system allowed to send for it: SPF (a list of IP addresses allowed to send for the domain), DKIM (a digital signature attached to the message) and DMARC (a rule that tells the receiver what to do with a message that fails the checks). The setup is covered in the companion article, DMARC, SPF and DKIM: How to Set Them Up Correctly.

  • CISA recommends: enable DMARC checking on inbound mail and set your own domain's DMARC policy to reject (receivers refuse mail that fails the checks), so that spoofed mail claiming your domain is refused at the mail server before it reaches the recipient
  • NIST SP 800-177 Rev. 1 recommends: domains that deploy SPF or DKIM should publish a DMARC record, and receivers should handle mail according to the DMARC policy the sender published
  • Limit: this protects your real domain name, but it does not stop a look-alike domain with a similar spelling, and it does not stop mail sent from a real account that has already been taken over

CISA recommends reject, but RFC 9989 (the new DMARC standard, published in May 2026, replacing RFC 7489) warns that a domain whose staff send ordinary mail and may post to mailing lists (groups where a system forwards each message to every member) should not use reject before studying real results. Start in monitoring mode and tighten step by step, as the companion article explains.

Layer 2: filter and block at the entrance

This layer reduces the dangerous mail that reaches users and limits the damage if someone clicks by mistake. The measures below come from the CISA guide.

  • Denylists: at the email gateway, block known malicious domains, URLs and IP addresses, and risky file extensions such as .scr, .exe, .pif and .cpl, including files whose extension is disguised, such as an .exe file named as a .doc
  • Macros off by default: a macro is a set of commands embedded in an Office file, which malware often uses
  • Protective DNS: a DNS service (the system that turns website names into IP addresses) that stops devices from being sent to malicious sites
  • Limit administrator rights: ordinary users should not have admin rights on Windows and macOS, so malware that does run can do less
  • Monitor internal mail and messages: users can be phished from outside without the security team knowing, so inspect internal mail too and set a baseline (the normal level used for comparison) to spot deviations

NIST SP 800-177 Rev. 1 adds controls for outbound mail. It recommends blocking outbound port 25 except for authorized mail senders (port 25 is the channel mail servers use to pass mail to each other), and not letting systems that are not part of the mail infrastructure send mail themselves, to reduce the risk that an unauthorized machine sends mail in the organization's name. NIST also recommends TLS (encryption of the connection) between mail servers, which prevents eavesdropping in transit but does not help decide whether a message is a trick.

Layer 3: keep accounts from being taken over

An attacker who has an employee's password can send mail from the real account through the organization's real server. Such mail usually passes the SPF, DKIM and DMARC checks and is the most convincing to the recipient. In the IC3's description, BEC works by compromising email accounts or other channels, so accounts must be protected from takeover in the first place.

  • Phishing-resistant MFA: MFA (multi-factor authentication, which needs something besides a password) of the FIDO kind (for example passkeys, credentials bound to the real website) or the PKI kind (using digital certificates) resists phishing. CISA points out that phone-based MFA (SMS or voice) and push MFA without number matching can still be tricked
  • If you still use push, turn on number matching: the user types the number shown on the sign-in screen into the app, which stops accidental approval when requests are sent repeatedly
  • Start with administrator and high-privilege accounts: for example accounts with broad access to customer or financial data
  • Use SSO: SSO (single sign-on, one central login for many systems) reduces the chance that users are tricked into typing passwords in many places, and it leaves a record for later review
  • Alert on unusual sign-ins: review denied or repeated MFA attempts, and lock the account when an attack continues

A comparison of the MFA methods is in Which MFA Is Safer? SMS, Authenticator Apps, Push, and Passkeys.

Layer 4: double-check before money moves

BEC is a threat that tools may miss, because a payment request can come from a real account or imitate one well. So the process must not depend on one person's judgment. The IC3 advises verifying requests to change account information through a secondary channel or with two-factor authentication.

  • Verify through a second channel: a request to change bank details or to send a payment must be confirmed outside the email that carried the request (per the IC3)
  • Call back a number already on file: do not use the number that came with the change request. This is common practice, not stated in the IC3 document
  • Separate the requester from the approver: do not let one person receive the request, edit the details and send the payment. This is also common practice
  • Check the real sender address and the domain in links: the IC3 advises checking the sender's actual email address, especially on mobile devices, and watching for links with slightly misspelled domains
  • Never send passwords or personal data by email: even when the request looks legitimate

Confirming by voice or video call alone is not enough either, because AI-faked voices and faces can be used to push people into sending money. Call back a number recorded earlier and have a second person take part in the check. See Deepfake Social Engineering: How Organizations Respond.

INFOGRAPHIC
A bank-detail change request: common slips and safer habits

Common slips

  • Reply to the email to confirmthe reply reaches the same sender
  • Call the number in that emailan attacker can supply their own number
  • One person handles it allnobody checks the work

Safer habits

  • Confirm via a second channelas the IC3 advises
  • Call back the number on filenot the one that came with the request
  • Split requester and approvera second person always checks

Layer 5: people and reporting

Training helps users notice a suspicious email, avoid interacting with its links or files, and report it at once, even if they have already opened it. CISA says reporting is one of the most efficient methods, because it helps email providers identify new or trending attacks, and it encourages use of the report buttons built into cloud email programs such as Outlook. Training and phishing simulation are covered in Security Awareness and Phishing Simulation That Works.

If you suspect a scam: what to do first

If money is involved, move fastest. The IC3 says time is of the essence once a fraudulent transfer is discovered: contact the bank at once to request a recall of the funds, and file a complaint with the IC3 regardless of the amount lost. If an account or device may be compromised, CISA advises re-provisioning the account (issuing fresh credentials), auditing its access history, and isolating a workstation that ran malware.

INFOGRAPHIC
A suspected payment scam: the first five steps
1
Call the bank
request a recall as soon as you find it
2
Reset the credentials
issue fresh credentials for the account that may be taken
3
Audit its access
review the account’s access history
4
Isolate suspect devices
if a file was opened or program run
5
File a report
the IC3 takes reports of any amount

Common mistakes

  • Believing DMARC alone is enough: DMARC does not stop look-alike domains, and it does not stop mail from a real account that has been taken over
  • Setting DMARC to reject without reading the reports first: genuine mail from a forgotten system may be refused too
  • Using SMS or push MFA without number matching on important accounts: CISA points out that it can still be tricked
  • Confirming a bank-detail change by replying to the same email: the reply goes to the same sender, who may be the attacker
  • Letting one person handle the request, the edit and the payment: nobody checks the work
  • Waiting to be sure before calling the bank: the IC3 says time is of the essence once a fraudulent transfer is discovered
  • Watching only inbound mail from outside: CISA says users can be phished without the security team knowing, so internal mail and messages need watching too

Start today

  • Check the SPF, DKIM and DMARC status of every domain that sends mail: if there is no DMARC yet, start in monitoring mode following DMARC, SPF and DKIM: How to Set Them Up Correctly
  • Turn on phishing-resistant MFA for administrators and executives first: for other accounts that use push, turn on number matching in the meantime
  • Block risky file extensions and turn macros off by default: at the mail gateway and on user devices
  • Write a one-page procedure for confirming bank-detail changes: apply it to everyone, including executives, and state which number to call back
  • Give users a report-phishing button: and decide who receives the reports
  • Record the bank contact for fund recalls in the incident plan: because the call has to be made as fast as possible

To see where your organization's email protection and authentication stand against good practice, try the self-assessment.

Scope and accuracy

The IC3 figures count complaints filed with the center, not statistics for Thailand, and they do not cover every incident. The technical advice comes from the joint CISA guide (published October 2023) and NIST SP 800-177 Rev. 1 (February 2019, which cites RFC 7489, now replaced). The latest DMARC standard is RFC 9989. Items marked as common practice are our own view and do not come from those documents. Check the original documents again before acting, since facts and practice change. The sources were read on 22 October 2026.

References and further reading