How to Prevent Email Spoofing

Email spoofing means a message is made to look as if it came from a trusted address even when it did not. If people are receiving strange mail “from” you, your mailbox is not always hacked; attackers can forge the visible sender name or address from outside your account. The durable fix is different for each case: victims should secure the mailbox and report the forged mail, while domain owners should align SPF, DKIM, and DMARC so receiving services can reject messages that only pretend to use the domain.

If you are investigating one suspicious message rather than configuring DNS, start with the Office365alerts Costco/BT email scam guide to separate sender spoofing, abused alert notifications, and brand-lure phishing.

Email Spoofing vs a Hacked Mailbox

Before changing DNS records or resetting every password, separate spoofing from account compromise. The symptoms overlap, but the response is not the same.

• Likely spoofing: you receive bounce messages for mail you never sent, recipients show you spam that is not in your Sent folder, and sign-in history looks normal.
• Possible hacked mailbox: messages appear in Sent, forwarding rules were added, recovery details changed, login alerts show unfamiliar devices, or contacts received messages from a real conversation thread.
• Lookalike-domain spoofing: the message uses a similar domain, such as a changed top-level domain, extra word, or one-letter typo.
• Display-name spoofing: the email address is different, but the sender name looks like a boss, coworker, bank, delivery service, or support team.
• Reply-To trick: the visible From address looks familiar, but replies go to an attacker-controlled address.

If the message asks for a password reset, invoice payment, gift card, remote access, crypto transfer, or document login, treat it as a phishing email even when the sender name looks correct. Spoofing is often the delivery trick; phishing or business email compromise is the damage path.

What To Do If Someone Is Spoofing Your Email Address

If you are a normal Gmail, Outlook, Yahoo, or iCloud user and you do not own the domain, you cannot directly stop every forged message on the internet. Google notes that forged messages can be created outside Gmail, so Gmail cannot stop someone from putting your address in a fake From field before the mail reaches other systems.¹ You can still reduce damage:

1. Check whether your account was actually used. Review Sent, deleted items, login history, forwarding rules, app passwords, connected apps, and recovery settings.
2. Change the password and enable MFA if there is any sign of account access, forwarding, or unknown devices.
3. Warn close contacts with a clean new message. Tell them not to open unexpected attachments or links that claim to come from you.
4. Report the forged message as spam or phishing in the mailbox where it arrived.
5. Scan devices if a click or attachment happened. If you opened a file, enabled macros, installed a browser extension, or signed in on a fake page, use a trusted security scan and then secure the affected account.

For a deeper recovery path, use the Gridinsoft guide on what to do if a scammer has your email address. That page covers mailbox rules, account takeover signs, and what to change first.

How SPF, DKIM, and DMARC Stop Domain Spoofing

SPF, DKIM, and DMARC are DNS-based controls that help receiving mail services decide whether a message really has permission to use your domain. They work best together. Google requires SPF or DKIM for all senders to Gmail and requires SPF, DKIM, and DMARC for senders above 5,000 daily messages to personal Gmail accounts.² Microsoft also emphasizes that DMARC fixes a key weakness of SPF and DKIM by checking alignment with the visible From domain.³

That alignment point is why a page about email spoofing should not stop at SPF. A message can pass SPF for one domain while displaying a different From domain. DMARC is the layer that tells receivers whether the domain shown to the user is actually aligned with the authenticated sender.

Step 1: Inventory Every Real Sender

Before publishing a strict SPF or DMARC policy, list every system that sends mail for your domain:

• Google Workspace, Microsoft 365, or another mailbox host;
• website forms, WordPress notifications, CRM, help desk, billing tools, newsletter platforms, and transactional mail providers;
• cloud servers, monitoring systems, scanners, and legacy apps;
• subdomains used for marketing or automated mail, such as mail.example.com or news.example.com.

This is where many spoofing-prevention projects break: the main mailbox is authenticated, but a forgotten invoice system or website form still sends unauthenticated mail. If you run a public site, the Gridinsoft Email Security Checker can help spot missing SPF, DKIM, and DMARC signals before attackers abuse the gap.

Step 2: Publish a Clean SPF Record

SPF is a TXT record at the sending domain. It lists the mail services allowed to send for that domain. A simple Google Workspace example looks like this:

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

A simple Microsoft 365 example looks like this:

v=spf1 include:spf.protection.outlook.com ~all

Use only one SPF TXT record per domain. If you already have one, merge new senders into the existing record instead of adding a second SPF record. Start with ~all while you are still discovering legitimate senders, then consider -all only when you are confident that every real sender is included and monitored.

Step 3: Turn On DKIM Signing

DKIM adds a cryptographic signature to outgoing messages. In Google Workspace, DKIM is configured in the Admin console under Gmail authentication. In Microsoft 365, DKIM is enabled for the domain in Defender / Email authentication settings and usually requires publishing CNAME records.

Use 2048-bit DKIM keys where supported. Google states that sending to personal Gmail accounts requires a DKIM key of at least 1024 bits and recommends 2048-bit keys when the domain provider supports them.²

After enabling DKIM, send a test message to Gmail or Outlook and inspect the message details. You want to see dkim=pass and the DKIM signing domain aligned with the domain users see in the From address.

Step 4: Roll Out DMARC Without Breaking Good Mail

DMARC is also a TXT record. Start with monitoring, read reports, fix legitimate senders, and then move to enforcement.

v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s

A safe rollout usually looks like this:

1. p=none: collect reports and identify real senders, forwarding problems, and lookalike abuse.
2. p=quarantine: ask receivers to treat failing mail as suspicious once the legitimate sender list is clean.
3. p=reject: ask receivers to reject mail that fails DMARC alignment.

For a domain that sends important account, billing, or business mail, do not jump straight to p=reject without reports. Forwarding, SaaS senders, and older systems can fail alignment until you configure them correctly.

Step 5: Check Gmail and Outlook Results

After DNS changes propagate, send test messages to Gmail and Microsoft 365 mailboxes. Open the original message headers and look for these results:

• spf=pass for the expected sending service;
• dkim=pass with your domain or an approved sending subdomain;
• dmarc=pass with the visible From domain aligned;
• no unexpected forwarding, relay, or third-party sender in the path.

If SPF passes but DMARC fails, the envelope sender domain probably does not align with the visible From domain. If DKIM passes but DMARC fails, the DKIM signing domain may be a vendor domain instead of your domain. Configure custom DKIM or a custom return-path with the provider instead of accepting a generic vendor identity.

Common Mistakes That Keep Spoofing Possible

• Only SPF is configured. SPF alone does not authenticate the visible From address that users trust.
• DMARC stays at p=none forever. Monitoring is a first step, not the final state for a domain that sends sensitive mail.
• Marketing platforms are not aligned. A newsletter may pass authentication for the provider but fail alignment for your brand domain.
• Unused subdomains are ignored. Attackers can abuse weak or unprotected subdomains if the parent domain policy does not cover them properly.
• Display-name spoofing is treated as solved. SPF, DKIM, and DMARC help with domain authentication, but users still need to inspect sender addresses, links, attachments, and unusual requests.

Why This Matters in 2026

Email spoofing is still useful to attackers because it helps them make phishing, invoice fraud, fake support messages, and account-warning emails look familiar. Verizon’s 2026 DBIR threat-landscape summary continues to point to the human element, including social engineering, phishing, and stolen credentials, as frequent breach causes.⁴ That is why the technical records and the user-facing checks belong in the same guide: authentication reduces forged-domain delivery, while user checks reduce damage when a message still reaches the inbox.

If your domain is already protected, keep it that way by reviewing DNS records after every new mail tool, CRM, website migration, or newsletter change. If you are only a recipient, focus on the practical signs: mismatched sender domains, strange Reply-To addresses, urgent payment or login requests, unexpected attachments, and links that do not match the claimed sender.

Organizations using external mail gateways should also review Ghost-Sender Exchange Online spoofing, because SPF, DKIM, and DMARC records alone may not stop direct-to-tenant forged mail.

FAQ

References

1. Google. “Someone is sending emails from a spoofed address.” Gmail Help, accessed June 7, 2026. https://support.google.com/mail/answer/50200
2. Google. “Email sender guidelines.” Google Workspace Admin Help, updated guidance page, accessed June 7, 2026. https://support.google.com/a/answer/81126
3. Microsoft. “Email authentication in Microsoft Defender for Office 365.” Microsoft Learn, accessed June 7, 2026. https://learn.microsoft.com/en-us/defender-office-365/email-authentication-about
4. Verizon. “2026 Data Breach Investigations Report.” Verizon Business, accessed June 7, 2026. https://www.verizon.com/business/resources/reports/dbir/