How to Prevent Email Spoofing: 10 Essential Security Measures for Businesses

The most effective way to prevent email spoofing on a company-owned domain is to configure SPF, DKIM, and DMARC correctly, then monitor authentication results and gradually enforce a policy that rejects unauthorized messages.

VPN

Surfshark

3.5

3.5

This Surfshark review breaks down speed, security features, pricing tiers and real world testing to help you decide if it fits your needs.

• Unlimited devices on one account
• Genuinely fast speeds across servers

• Monthly pricing far pricier than yearly
• Two year plans cannot be renewed

Read review View Plans Affiliate Link

Businesses should also secure their email accounts, implement anti-phishing protections, and establish independent verification procedures for sensitive requests.

These measures make it harder for criminals to impersonate a legitimate sender, although they cannot prevent every phishing attack or stop someone from creating a lookalike domain.

Email spoofing occurs when someone forges email sender information to make a message appear to come from a trusted person, company, or organization.

Attackers use this technique to imitate executives, impersonate suppliers, distribute fraudulent invoices, steal login credentials, and persuade employees or customers to transfer money.

The Federal Trade Commission (FTC) recommends email authentication as a fundamental safeguard for businesses using their own domains.

The three principal technologies are Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC).

Together, they help receiving email systems assess whether a message is authorized to use a domain and determine how to handle authentication failures.

What Is Email Spoofing?

Email spoofing is the manipulation of sender information to make an email appear to originate from a source that the recipient trusts.

For example, an employee might receive a message that appears to come from the company's chief financial officer requesting an urgent payment.

The display name, email address, signature, and language may resemble a legitimate business message, but the actual sender may be a criminal attempting to redirect company funds.

Spoofing can target individuals, businesses, financial institutions, public agencies, and technology providers.

Attackers may use it as part of phishing campaigns or business email compromise (BEC), in which criminals attempt to obtain money, credentials, or sensitive information through fraudulent communications.

The Federal Bureau of Investigation (FBI) explains that spoofing involves disguising an email address, sender name, phone number, or website address to convince a victim that a communication comes from a trusted source.

A spoofed message may encourage the recipient to send money, disclose sensitive information, or download malicious software.

It is important to distinguish email spoofing from a compromised email account.

In a spoofing attack, the criminal may forge the sender information without accessing the legitimate account.

In an account compromise, the attacker gains access to a real account and can send messages through it.

The two threats require overlapping but different defenses.

Email authentication primarily helps protect domains against unauthorized use.

Multi-factor authentication, access controls, and account monitoring help protect legitimate accounts from being taken over.

1. Configure SPF to Identify Authorized Email Senders

Sender Policy Framework, or SPF, is an email authentication standard that allows a domain owner to specify which mail servers are authorized to send messages using that domain.

The domain owner publishes an SPF record in the Domain Name System (DNS).

Receiving mail servers can check that record to determine whether the server sending a message is authorized under the domain's SPF policy.

For example, a business may send email through its primary email provider, a marketing platform, and a customer relationship management system.

Its SPF configuration must account for the services that are legitimately authorized to send email for the relevant domain.

If a legitimate sending service is missing from the configuration, messages from that service may fail SPF checks.

Conversely, an incorrectly maintained record may authorize systems that should no longer send messages.

How to implement SPF correctly

Start by identifying every legitimate service that sends email using your domain.

Include the relevant business email platform, marketing provider, transactional email service, and other authorized systems.

Next, work with your DNS administrator or email provider to publish an SPF record that accurately reflects those senders.

Check for existing SPF records before making changes.

A domain should not have multiple separate SPF records for the same DNS name, because that can cause SPF evaluation errors.

Review the record whenever your organization changes email providers, introduces a new sending platform, or retires an existing service.

Avoid adding broad authorizations simply to make a delivery problem disappear.

An SPF record should reflect the organization's actual sending infrastructure, not grant unnecessary permission to additional servers.

Google recommends that organizations account for their legitimate sending services in SPF and notes that messages from third-party senders missing from the record may be more likely to be marked as spam.

Important limitation: SPF does not independently authenticate every aspect of the visible sender address.

It evaluates whether a sending server is authorized for the relevant envelope-sender domain.

DMARC adds an alignment requirement that connects successful authentication to the domain displayed in the message's From address.

2. Enable DKIM to Authenticate Outgoing Messages

DomainKeys Identified Mail, or DKIM, uses a digital signature to help receiving mail servers verify that a message was signed by a domain associated with the signature and that signed message content has not been altered in ways that invalidate the signature.

The sending system signs outgoing email using a private key.

The corresponding public key is published in DNS, allowing receiving systems to verify the signature.

DKIM provides an important additional layer of authentication because it does not rely solely on the IP address of the sending mail server.

This is particularly useful for businesses that use external email platforms, marketing services, or other providers to deliver messages on their behalf.

How to set up DKIM

First, identify the email services that send messages using your domain.

Use the provider's administrative documentation to generate or obtain the appropriate DKIM configuration.

Depending on the service, this may involve publishing a public key in DNS and enabling message signing in the provider's administration console.

After the DNS configuration is published, enable DKIM signing and send test messages to verify that authentication succeeds.

Check the results in the receiving email system's message headers or authentication reports.

A successful DKIM result indicates that the signature passed verification, but it does not automatically prove that the message is trustworthy in every other respect.

Maintain DKIM configuration when you change email providers, rotate keys, or introduce new sending services.

Google recommends configuring DKIM for domain authentication and advises using a 2,048-bit key when supported by the provider.

Its published requirements specify a minimum 1,024-bit key for sending to personal Gmail accounts.

Important limitation: DKIM authenticates a signing domain and protects the integrity of signed content.

A valid signature alone does not prove that a message is harmless, that its sender is honest, or that the visible From domain is aligned with the signing domain.

3. Deploy DMARC to Control Unauthorized Messages

Domain-based Message Authentication, Reporting, and Conformance, or DMARC, builds on SPF and DKIM to help domain owners control how receiving email systems handle messages that fail authentication and alignment checks.

DMARC also supports reporting, allowing organizations to obtain information about messages that claim to use their domains.

For businesses seeking to prevent unauthorized use of their email domains, DMARC is the policy mechanism that connects authentication results to a requested handling action.

A DMARC policy can use three principal settings:

• None: Requests monitoring without asking receiving systems to quarantine or reject messages solely because they fail DMARC.

• Quarantine: Requests that messages failing DMARC be treated as suspicious, commonly by placing them in a spam or quarantine area.

• Reject: Requests that receiving systems reject messages that fail DMARC.

The actual handling of a message depends on the receiving system's implementation and policy decisions.

Publishing a DMARC record does not guarantee that every receiving provider will apply the requested action identically.

How to deploy DMARC safely

Begin by confirming that SPF and DKIM are configured for all legitimate sending services.

Publish a DMARC record with a monitoring policy, commonly p=none, and configure a reporting destination.

Review the reports to identify legitimate services, authentication failures, and unauthorized sources that appear to be sending messages using your domain.

Correct the problems you identify before increasing enforcement.

Once legitimate mail streams are accounted for and authentication is working consistently, move toward quarantine or rejection according to your organization's risk tolerance and operational readiness.

For a domain that is ready for full enforcement, a reject policy provides the strongest of DMARC's three requested handling actions against messages that fail DMARC.

However, the policy should be introduced carefully to avoid disrupting legitimate email that has been incorrectly configured.

The UK government's guidance on secure email services recommends progressing from monitoring to quarantine or rejection as part of a managed implementation.

Google's guidance also explains how DMARC determines the handling requested for messages that fail authentication.

Do not move directly to strict enforcement without checking legitimate senders. A misconfigured policy can affect invoices, password-reset emails, customer notifications, newsletters, and other important business messages.

4. Understand SPF, DKIM, and DMARC as a Combined Defense

SPF, DKIM, and DMARC perform related but different functions.

They should be implemented as complementary controls rather than treated as interchangeable technologies.

SPF checks whether the sending server is authorized for the relevant envelope-sender domain.

DKIM verifies a domain-associated digital signature and the integrity of signed message content.

DMARC checks whether a message passes SPF or DKIM authentication with the required alignment to the domain in the visible From address.

It also communicates the domain owner's requested handling policy and supports reporting.

Consider a company that sends invoices through an external billing platform.

The platform might be authorized by SPF, sign messages using DKIM, and align one of those authenticated domains with the company's visible From address.

If the platform is configured correctly, the messages can pass DMARC.

If a criminal forges the company's visible From address using an unauthorized sending system, the message may fail DMARC and be subject to the domain's published policy.

The exact result depends on the sender configuration, authentication results, alignment, and receiving mail system.

The combined approach is stronger than relying on a single authentication method.

Both Google and Microsoft describe SPF, DKIM, and DMARC as important components of email authentication and domain protection.

5. Secure Your Email Accounts With Multi-Factor Authentication

Domain authentication does not stop criminals from sending messages through a legitimate account they have compromised.

If an attacker steals an employee's password and successfully accesses the employee's mailbox, the attacker may be able to send messages that appear to come from the real account.

Depending on the sending configuration, those messages may pass SPF, DKIM, and DMARC.

Businesses should therefore protect email accounts with multi-factor authentication (MFA), which requires an additional verification factor beyond a password.

Where available, organizations should prioritize phishing-resistant authentication methods, such as passkeys or hardware security keys, particularly for administrators and employees with access to sensitive financial or business information.

Other important measures include:

• Requiring MFA for email and administrative accounts.

• Removing access for former employees and contractors promptly.

• Reviewing mailbox forwarding rules and suspicious account changes.

• Monitoring unusual sign-ins and unexpected email-sending activity.

• Restricting administrative permissions.

• Applying security updates to email clients and related systems.

• Using strong, unique passwords where passwords remain part of the authentication process.

Organizations should also review OAuth application permissions and connected applications that can access mailboxes.

A compromised third-party application or overly broad permission can create email security risks even when the user's password is not directly stolen.

MFA is not a replacement for SPF, DKIM, or DMARC.

These controls address different attack paths and should be implemented together.

6. Use Email Security Filtering to Detect Suspicious Messages

Email security gateways and filtering services can inspect incoming messages for indicators of phishing, malware, impersonation, suspicious links, and other threats.

Depending on the product and configuration, these tools may evaluate sender authentication, message content, attachments, URLs, sender reputation, and unusual communication patterns.

A business should configure its email security platform to use authentication results and available anti-impersonation controls appropriately.

For example, security rules may flag messages that claim to come from an executive but originate from an unusual external address.

They may also detect suspicious messages that imitate a supplier or use a lookalike domain.

Security teams should review how their platform handles messages that fail DMARC, especially messages that appear to impersonate the organization's own domain.

Filtering is useful, but it is not infallible.

Some malicious messages can pass automated checks, and overly aggressive rules may block legitimate communications.

Organizations should monitor security alerts, review false positives, maintain appropriate policies, and ensure employees have a way to report suspicious messages.

Cisco's anti-spoofing guidance also recommends enabling SPF, DKIM, and DMARC alongside other email security controls rather than relying on a single protective mechanism.

7. Protect Against Lookalike Domains and Display-Name Spoofing

SPF, DKIM, and DMARC primarily help protect domains through authentication.

They do not prevent criminals from registering a different domain that resembles a legitimate business.

For example, an attacker might register a domain with a subtle spelling variation or use a different top-level domain to imitate a supplier.

A message from that domain could pass its own authentication checks while still being deceptive.

Display-name spoofing presents a related problem.

A message can display the name of a company executive even when the underlying email address belongs to someone else.

Organizations should use email security tools that can identify suspicious similarities between external sender domains and trusted internal domains.

Additional safeguards include monitoring for newly registered lookalike domains, reviewing suspicious sender addresses, and establishing procedures for reporting impersonation attempts.

Companies may also register relevant defensive domain variations where appropriate, although domain registration alone cannot eliminate impersonation.

Employees should be trained to examine the actual sender address and verify unusual requests through an independent communication channel.

8. Verify Payment Requests and Sensitive Instructions Independently

Business email compromise can cause serious financial losses when attackers impersonate executives, suppliers, lawyers, or other trusted contacts.

Even when an email appears authentic, organizations should not rely on email alone to authorize high-risk financial transactions or changes to payment instructions.

The FTC recommends internal verification policies, including confirming wire-transfer requests by telephone.

A practical policy should require independent verification for requests such as:

• Changing a supplier's bank account details.

• Making an unusual or urgent wire transfer.

• Purchasing gift cards or transferring funds outside normal procedures.

• Sharing confidential employee or customer information.

• Changing payroll or direct-deposit details.

• Approving an unexpected request for credentials or account access.

Verification should use a trusted telephone number or communication channel already on file, not contact information supplied in the suspicious email.

For larger transactions, organizations can require dual approval or separation of duties, so one person cannot independently initiate and approve a high-risk payment.

These procedures help address the fact that email authentication establishes technical evidence about a domain or message; it does not prove that every instruction in the message is legitimate.

9. Train Employees to Recognize and Report Spoofed Emails

Technology reduces email spoofing risks, but employee awareness remains important because attackers also use compromised accounts, lookalike domains, and carefully targeted phishing messages.

Training should focus on the decisions employees need to make when a message requests money, credentials, sensitive information, or an unusual action.

Employees should learn to recognize warning signs such as unexpected urgency, unfamiliar sender addresses, changes to payment instructions, unusual attachments, and requests to bypass established procedures.

However, training should not suggest that poor grammar or suspicious-looking links are always present.

Sophisticated attacks may use convincing language and resemble normal business communications.

Every organization should establish a simple process for reporting suspicious messages.

Employees should know where to forward them or which security team to contact, and they should not be discouraged from reporting a message simply because they are uncertain.

Organizations can also run authorized phishing-awareness exercises and use the results to improve training.

These exercises should support learning and risk reduction rather than shame employees who make mistakes.

The FTC recommends staff training and clear reporting options as part of a business's protection against impersonation scams.

10. Monitor Authentication Reports and Respond to Spoofing Incidents

Publishing SPF, DKIM, and DMARC records is not the end of email security work.

Organizations should monitor authentication results and investigate unusual activity.

DMARC aggregate reports can help administrators understand which systems are sending messages that claim to use their domains and whether those messages pass authentication and alignment checks.

A report showing an unfamiliar sending source does not automatically prove malicious activity.

It may represent an unrecognized legitimate service, a forwarding system, a misconfiguration, or an impersonation attempt.

Administrators should investigate the source before making changes to the authentication policy.

A useful monitoring process includes:

• Reviewing DMARC reports regularly.

• Maintaining an inventory of authorized sending services.

• Investigating unexpected authentication failures.

• Checking whether legitimate messages are being rejected or quarantined.

• Reviewing changes to SPF and DKIM configuration.

• Monitoring suspicious mailbox activity and forwarding rules.

• Recording incidents and documenting corrective actions.

When a company discovers that criminals are impersonating its domain, it should investigate the source, verify that authentication policies are correctly configured, and assess whether any legitimate account has been compromised.

The organization should also consider notifying affected customers and employees through a trusted channel.

If money has been transferred because of a suspected business email compromise, the company should contact its financial institution immediately and report the incident to the appropriate authorities.

The FBI directs victims of business email compromise to its Internet Crime Complaint Center, known as IC3.

The FTC also provides reporting guidance for businesses dealing with impersonation scams.

How to Prevent Email Spoofing: A Step-by-Step Implementation Plan

Organizations that have not yet established a mature email authentication process should implement the controls in a deliberate order.

Step 1: Inventory your email-sending services. Identify every legitimate system that sends messages using your domain, including business email, marketing, billing, customer support, and transactional services.

Step 2: Configure SPF. Publish a valid SPF record that accurately identifies authorized sending systems.

Check existing DNS configuration before making changes.

Step 3: Enable DKIM. Configure each relevant email provider to sign messages and publish the corresponding public keys in DNS.

Step 4: Deploy DMARC in monitoring mode. Publish a DMARC record with a reporting destination and review authentication results.

Step 5: Resolve legitimate sending failures. Identify unrecognized services, correct configuration problems, and confirm that legitimate messages authenticate and align as expected.

Step 6: Increase DMARC enforcement. Progress to quarantine or reject when the organization is confident that legitimate mail streams are correctly configured.

Monitor delivery and authentication results during the transition.

Step 7: Secure user accounts. Enforce MFA, restrict administrative privileges, monitor unusual sign-ins, and review suspicious forwarding rules.

Step 8: Strengthen business procedures. Require independent verification for payment changes, sensitive information requests, and other high-risk actions.

Step 9: Train staff and monitor incidents. Establish clear reporting procedures and review authentication reports and security alerts regularly.

Step 10: Reassess after changes. Repeat relevant checks when adding email providers, changing domains, migrating platforms, or introducing new sending services.

This process helps reduce unauthorized domain use while limiting disruption to legitimate business email.

Key Facts

• SPF identifies mail servers authorized to send email for a domain.

• DKIM uses digital signatures to authenticate a signing domain and protect signed message content against undetected alteration.

• DMARC checks SPF or DKIM authentication with alignment to the visible From domain and communicates the domain owner's requested handling policy.

• A DMARC reject policy provides the strongest requested handling action against messages that fail DMARC, but it should be deployed only after legitimate sending services have been accounted for.

• Email authentication should be combined with multi-factor authentication, anti-phishing protections, employee training, and independent verification of high-risk financial requests.

Sources

1. Federal Trade Commission (FTC) — Cybersecurity for Small Business Supports recommendations on SPF, DKIM, DMARC, staff training, payment verification, and responding to email impersonation.
2. Google — Email Sender Guidelines Explains SPF, DKIM, DMARC, authentication alignment, sender requirements, and email-delivery considerations.
3. Microsoft Learn — How Email Authentication Works in Microsoft 365 Explains the roles of SPF, DKIM, and DMARC in identifying forged senders.
4. Google Workspace — About Authentication Methods Describes email authentication and Google's recommendations for configuring SPF, DKIM, and DMARC.
5. UK Government — Set Up Government Email Services Securely Provides guidance on implementing SPF, DKIM, DMARC, and related email security standards.
6. Federal Bureau of Investigation (FBI) — Spoofing and Phishing Defines spoofing and phishing and explains their use in fraud and information theft.
7. Federal Bureau of Investigation (FBI) — Business Email Compromise Explains business email compromise and recommends reporting suspected incidents to IC3.
8. Cisco — Detect and Prevent Email Spoofing Supports the use of SPF, DKIM, DMARC, and additional email security controls.

VPN

Surfshark

3.5

3.5

This Surfshark review breaks down speed, security features, pricing tiers and real world testing to help you decide if it fits your needs.

• Unlimited devices on one account
• Genuinely fast speeds across servers

• Monthly pricing far pricier than yearly
• Two year plans cannot be renewed

Read review View Plans Affiliate Link