Email spoofing is the forging of an email’s sender information so that a message appears to come from a trusted person or organization when it does not. This is possible because the original email protocol, SMTP, was designed without sender verification. Any server can claim to send mail on behalf of any domain unless that domain uses SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting, and Conformance) to help receiving servers identify unauthorized messages.
Email domain spoofing continues to be one of the most common techniques that cybercriminals use to impersonate legitimate companies and organizations. By making a message appear to come from a trusted institution, cybercriminals significantly increase the chances that it will be opened, read, and considered legitimate by the recipient.
These attacks are often used in phishing campaigns, financial fraud, credential theft, and malware distribution. Messages may contain links to fake websites, malicious attachments, or deceptive requests designed to trick users into sharing sensitive information or taking actions that compromise their own security or their organization’s security.
Advances in artificial intelligence have made it easier for cybercriminals to create more sophisticated phishing messages. They can use AI to produce highly personalized messages that mimic the communication style, visual identity, and even writing style of legitimate companies, making fraudulent messages increasingly difficult to identify.
The impact of spoofing goes beyond direct victims. Organizations whose domains are misused may suffer reputational damage, loss of trust by customers and partners, and increased operational risks. In some cases, the lack of appropriate protective measures may even raise concerns related to compliance and information security governance.
How email spoofing works
Every email carries two separate sender addresses, and this separation is what spoofing exploits.
- The envelope sender (also called MAIL FROM and reflected in the Return-Path header) is used by mail servers to route the message and to handle bounces. Recipients normally never see it.
- The header “From” is the sender address displayed in the recipient’s inbox. It is simply a line of text inside the message, and the sending server is not required to prove that it is entitled to use it.
An attacker can therefore set the header “From” to billing@yourcompany.com while sending from an entirely unrelated server. Nothing needs to be hacked: No mailbox is compromised and no password is stolen. The message is simply constructed with false sender information and handed to a mail server that accepts it.
This is why organizations often discover that their domain is being spoofed indirectly: through bounce messages for mail that they never sent, customer complaints about fraudulent invoices, or a sudden drop in email deliverability caused by damage to their domain’s sending reputation.
How to tell if an email has been spoofed
A spoofed message can look legitimate in the inbox, so whether it has been authenticated requires looking at the message headers. In Gmail, open the message, click the three-dot overflow menu near the top-right corner of the email and select “Show original”; in Outlook, use File › Properties › Internet headers. Look for the Authentication-Results line:
- SPF, DKIM, or DMARC showing fail indicates the sending server was not authorized by the domain in the “From address”.
- A Return-Path that does not match the visible “From address” is a common indicator, although legitimate mailing services also produce this mismatch.
- Received headers that trace back to infrastructure unrelated to the claimed sender are a strong signal.
If your own domain is being spoofed, DMARC aggregate reports are the fastest way to confirm it and to identify which servers are sending email using your domain. Configuring DMARC in monitoring mode, described below, is the practical first step.
How to protect your email domain against spoofing: SPF, DKIM, DMARC and BIMI
Although spoofing is possible due to limitations in the original email protocols, there are widely adopted mechanisms that help authenticate messages and significantly reduce the possibility of forgery. These include SPF, DKIM, DMARC, and BIMI (Brand Indicators for Message Identification). The three core mechanisms work together: SPF and DKIM each provide a signal, and DMARC tells receiving servers what to do when those signals fail. BIMI lets companies’ logo appear alongside their email once the email is verified via SPF, DKIM, and DMARC.
SPF records
SPF (Sender Policy Framework) is one of the fundamental mechanisms for protecting email domains. It is a record published in DNS that specifies which servers are authorized to send messages on behalf of a specific domain.
When an email is received, the recipient server checks the SPF record associated with the sending domain to verify whether the server that sent the message is authorized. If the validation is successful, the message may proceed to additional analysis. Otherwise, it may be rejected, quarantined, or marked as suspicious, depending on the receiving server’s configured policy.
Despite its importance, SPF alone is not sufficient to prevent all forms of spoofing. Therefore, it should be used together with other authentication technologies.
SPF also has a specific blind spot: It validates the envelope sender, not the header of the “From address” the recipient actually sees. A message can pass SPF and still display a forged “From address.” Closing that gap is the job of DMARC alignment.
The main mechanisms used in an SPF record are:
- ip4: Authorizes servers through IPv4 addresses.
- ip6: Authorizes servers through IPv6 addresses.
- a: Authorizes IP addresses associated with the domain’s A record.
- mx: Authorizes servers defined in the domain’s MX records.
- include: Allows authorization of external email sending services.
- all: Defines the policy applied to unauthorized servers.
Examples:
Authorizes two sending servers.
Authorizes Microsoft 365 (Outlook) sending servers and the server whose IP address is associated with the A record of mail.example.com.
Authorizes servers defined in the domain’s MX records. Messages sent by other servers receive a soft failure indication (~all), allowing the recipient server to decide how to handle them.
It is important to consider that a misconfigured SPF record can cause legitimate emails to fail delivery. Before publishing or modifying an SPF record, organizations should validate the configuration and test its impact on email delivery workflows.
Two failure modes account for most SPF problems in practice. First, an SPF record may trigger a maximum of 10 DNS lookups; every include: for a third-party sending service consumes at least one, and organizations using several marketing, ticketing and CRM platforms routinely exceed the limit, which invalidates the entire record. Second, SPF breaks when mail is forwarded, because the forwarding server is not listed as authorized. Both are reasons to treat SPF as one signal among several rather than as standalone protection.
DKIM (DomainKeys Identified Mail)
DKIM (DomainKeys Identified Mail) is another email authentication mechanism that uses asymmetric cryptography to verify the authenticity and integrity of sent messages. It provides an additional layer of email authentication, complementing SPF and strengthening protection against spoofing and other attacks related to identity forgery.
DKIM works in two main stages. First, the outgoing email is signed: When a message is sent from a domain with DKIM configured, the server adds a digital signature to the email headers, generated using the private key associated with the domain. Next, the receiving server retrieves the public key published in the sender domain’s DNS and verifies the signature, validating the authenticity of the message and confirming that the signed content has not been modified during transmission.
This mechanism not only helps prevent unauthorized use of the sending domain but also strengthens sender trust among receiving servers. Emails from domains with properly configured DKIM have a higher likelihood of passing authentication checks and can contribute to improving domain reputation with email providers.
DKIM configuration is not complex, but it involves several technical steps. Organizations should follow the guidelines provided by their email service providers, such as Google Workspace or Microsoft 365, which include key generation, DNS record publication, and activation of message signing.
The public key is published at a selector-specific subdomain, so a domain can run several keys in parallel—[BP1.1]one per sending platform:
selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."
Use a key length of at least 2048 bits, and rotate keys periodically. Unlike SPF, DKIM survives forwarding, because the signature travels with the message.
DMARC (Domain-based Message Authentication, Reporting and Conformance)
DMARC (Domain-based Message Authentication, Reporting, and Conformance) was developed to complement these two technologies. This protocol uses SPF and DKIM validation results, allowing domain owners to define policies for handling emails that do not meet authentication requirements.
According to the DMARC policy published by the domain owner, the receiving server can accept (take no action), reject, or quarantine (send to spam) an email that does not comply with the established requirements. In addition, the protocol enables periodic reports to be sent to the domain administrator, providing visibility into authentication failures and possible spoofing attempts. This information helps organizations monitor domain usage and adjust security policies as needed.
DMARC adds the element that SPF and DKIM lack on their own: alignment. It requires the domain validated by SPF or DKIM to match the domain in the visible “From address,” which is what actually prevents an attacker from displaying your brand in the recipient’s inbox.
A DMARC record is published as a TXT record at _dmarc.example.com:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100; adkim=s; aspf=s
The key tags:
- p=: The policy applied to failing messages: none, quarantine, or reject.
- rua=: The address that receives aggregate reports.
- pct=: The percentage of failing messages the policy is applied to, used to ramp up gradually.
- sp=: The policy for subdomains, which attackers frequently target when the parent domain is protected.
- adkim=/aspf=: Alignment strictness, relaxed (r) by default or strict (s).
Rolling out DMARC in one step is the most common cause of self-inflicted mail loss. The standard sequence is as follows:
- Publish p=none with a reporting address, and change nothing else. Mail delivery is unaffected.
- Read aggregate reports for four to eight weeks to build a complete inventory of every service sending on your behalf—marketing platforms, invoicing systems, HR tools, and help desks are routinely missed.
- Authenticate every legitimate sender with SPF and DKIM, and correct alignment failures.
- Move to p=quarantine, starting at a low pct= value and increasing it while monitoring reports.
- Move to p=reject—the only policy that actually stops spoofed mail from reaching recipients. A domain sitting permanently at p=none is monitored, not protected.
Email authentication is now a deliverability requirement, not only a security measure
Since 2024, major mailbox providers have made authentication a condition of delivery rather than a recommendation. Google and Yahoo introduced requirements for bulk senders—broadly, those sending in the region of 5,000 messages a day to their users—covering SPF and DKIM authentication, a published DMARC policy, one-click unsubscribe for marketing mail, and spam complaint rates kept below a defined threshold. Microsoft subsequently announced comparable requirements for high-volume senders to outlook.com domains.
The practical consequence is that organizations without these protections now face two costs rather than one: Their domain is available to impersonators, and their legitimate campaign, invoicing, and notification email is increasingly likely to be filtered or rejected. Confirm the current thresholds with each provider’s own documentation before planning a rollout, as they continue to be tightened.
BIMI
So far, all the mechanisms discussed in this article operate primarily behind the scenes, without direct interaction with the end user receiving the email. Although these technologies are essential for validating message authenticity, it is also important to provide recipients with a visual way to recognize that communication genuinely belongs to the stated organization.
This is where BIMI (Brand Indicators for Message Identification) comes in. BIMI is an authentication and visual identification standard that allows organizations to display their logos alongside emails sent from their domains. The logo may appear directly in the recipient’s inbox (for example, next to the sender’s name), providing immediate visual brand recognition and reinforcing trust in email communication.
Implementing BIMI requires several steps that are common across most email providers. First, organizations must prepare a compatible logo, generally in SVG format with specific security and standardization requirements, ensuring that the image is correctly associated with the sending domain. In addition, DMARC must be configured with an enforcement policy (p=quarantine or p=reject), requiring SPF and DKIM mechanisms to be properly implemented and aligned. Depending on the email provider and the required level of validation, a VMC (Verified Mark Certificate) or another certificate accepted by the BIMI ecosystem may also be required. This certificate must be issued by a recognized certification authority, such as DigiCert, to prove ownership and authenticity of the logo being used.
BIMI is the last step, not the first. Because it depends on DMARC enforcement already being in place, it is worth pursuing only once the SPF, DKIM, and DMARC chain is complete and stable.
Protecting your organization from spoofed email arriving in inboxes
SPF, DKIM, DMARC, and BIMI protect your domain from being used against others. They do nothing about the spoofed messages arriving in your employees’ inboxes from domains you do not control—including partner and supplier domains with weak or absent authentication, and lookalike domains registered specifically to evade it.
Inbound protection is a separate layer, and it needs to cover:
- Server-side or cloud-based mail filtering that validates SPF, DKIM, and DMARC results on arrival and quarantines messages that fail, including those from domains whose own policy is only set to monitoring.
- Detection of lookalike and display-name impersonation, where the sending domain is authenticated correctly but was registered to resemble a trusted one.
- Attachment and URL analysis, since spoofed sender information is usually the delivery mechanism for a malicious link or document rather than the attack itself.
ESET Mail Security and ESET Cloud Office Security apply these checks to mail arriving at on-premise servers and at Microsoft 365 and Google Workspace tenants, combining authentication validation with anti-phishing, anti-spam, and attachment scanning.
Technology and education: A necessary pairing
These technologies, although complementary, play a fundamental role in building a safer and more trustworthy email communication environment. By enabling sender domain validation, message integrity verification, and enforcement of policies against spoofing attempts, they reduce opportunities for cybercriminals to misuse legitimate domains and conduct fraudulent campaigns.
In practice, the sequence matters more than the individual records: Publish SPF, sign with DKIM, deploy DMARC in monitoring mode, work through the reports until every legitimate sender is authenticated, and then move the policy to enforcement. The protection provided by these mechanisms extends beyond the organization itself, as it helps users and customers develop greater confidence in received messages.
However, technology alone is not enough. Cybersecurity education remains an essential component for strengthening the protection of companies, employees, and customers. As identity spoofing and social engineering threats continue to evolve, everyone must be prepared to identify signs of fraudulent emails, understand the risks associated with electronic communications, and adopt secure behaviors in the digital environment.
Frequently asked questions (FAQs)
Can I stop my email from being spoofed?
You cannot stop an attacker from writing your address into a message, but you can make receiving servers reject the result. Publishing SPF and DKIM records and enforcing a DMARC policy of p=reject means mail claiming to come from your domain but failing authentication is refused before it reaches the recipient.
How can I tell if someone is spoofing my email?
The clearest evidence is DMARC aggregate reports, which list every server sending mail that claims your domain. Bounce messages for mail you never sent and customer reports of unexpected invoices or password resets are the usual early warning signs.
What happens when an email is spoofed?
The recipient sees a message that appears to come from a trusted sender. Nothing on your side is compromised—no account is accessed and no data is taken from your systems—but the recipient may act on a fraudulent request, and repeated abuse damages your domain’s sending reputation and deliverability.
Is email spoofing illegal?
Forging sender information to commit fraud, steal credentials or distribute malware is a criminal offense in most jurisdictions, and impersonating a company’s domain may also constitute trademark infringement. Sender forgery on its own, such as in authorized security testing, is not inherently unlawful.
