Stop Email Spoofing: Lock Down Your Domain

Summary: You cannot stop every idiot on the internet from trying to impersonate your company, but you can make direct domain spoofing dramatically harder. Proper SPF, DKIM, and DMARC enforcement, combined with sender audits, monitoring, account security, and protection against lookalike domains, can make most basic spoofing attempts fail before they reach the inbox.

First, understand what email spoofing actually is

Email is surprisingly trusting by design.

An attacker can create a message that claims to come from finance@yourcompany.com, your CEO, your support team, or another address on your domain even though they never logged into your email system.

That does not necessarily mean your mailbox was hacked.

It can simply mean someone forged the visible From address.

This distinction matters because the solution to a compromised mailbox is different from the solution to domain spoofing.

Attack	What happened	Main defence
Domain spoofing	Attacker forged your domain in the From address	SPF, DKIM, DMARC
Display-name spoofing	Attacker used your employee’s name from another address	Impersonation filtering and user awareness
Lookalike domain	Attacker registered a domain similar to yours	Domain monitoring and anti-phishing controls
Mailbox compromise	Attacker gained access to a real account	MFA, account security, session controls

SPF, DKIM, and DMARC are extremely important, but they primarily solve the first problem. They do not magically solve every form of impersonation.

1. SPF tells the world who is allowed to send for your domain

SPF, or Sender Policy Framework, is a DNS record that lists the systems authorised to send email on behalf of a domain.

If your business sends through Google Workspace, Microsoft 365, a CRM, an email marketing platform, your website, a ticketing system, or another application, those sending systems need to be accounted for correctly.

A typical SPF policy eventually ends with a hard fail:

v=spf1 include:your-authorised-sender.example -all

The important part is -all. It says that sources not covered by the policy are not authorised to send for that domain.

But SPF alone does not solve spoofing.

SPF checks the technical envelope sender used during email delivery. The address the recipient sees in the From field can still be different. That is one of the reasons DMARC exists.

Do not blindly keep adding services to SPF

Every third-party tool that asks you to add another SPF include should be reviewed.

Old CRMs, abandoned newsletter platforms, retired servers, and forgotten SaaS tools can remain authorised long after the company stops using them.

Your SPF record should reflect your current email infrastructure, not the history of every tool your business has ever tested.

2. DKIM proves that authorised infrastructure signed the message

DKIM, or DomainKeys Identified Mail, adds a cryptographic signature to outgoing messages.

The sending system signs the message using a private key. Your DNS publishes the corresponding public key. The receiving email server can then verify that the signature is valid.

This gives the recipient another way to determine whether a message claiming a relationship with your domain actually passed through infrastructure authorised to sign for it.

Use strong DKIM keys, keep selectors documented, remove abandoned selectors, and rotate keys when appropriate.

More importantly, make sure every important sender is actually signing with your domain rather than relying entirely on the vendor’s domain.

3. DMARC is where spoofing protection becomes serious

DMARC connects the visible From address with SPF and DKIM.

For DMARC to pass, at least one authentication method must pass and align appropriately with the domain visible to the recipient.

Then DMARC tells receiving mail systems what you want them to do when authentication fails.

p=none: monitor failures but request no enforcement.
p=quarantine: ask receivers to treat failing mail suspiciously.
p=reject: ask receivers to reject failing messages.

If your domain is permanently sitting at p=none, you have monitoring, not strong enforcement.

The destination for a mature deployment is usually enforcement once every legitimate sender has been identified and configured correctly.

4. A strict DMARC policy is powerful, but only if alignment works

Publishing p=reject is not enough if legitimate services are configured badly.

Imagine your CRM sends an email with:

From: sales@yourcompany.com

but neither its SPF identity nor its DKIM signature aligns properly with your domain.

Your own DMARC policy could correctly identify that message as unauthenticated and cause it to be rejected.

That is why moving from monitoring to enforcement should happen after a sender audit.

Map every system that sends email using your domain:

Employee mailboxes.
CRM systems.
Email marketing platforms.
Help desks.
Accounting and invoicing systems.
Website contact forms.
E-commerce notifications.
Appointment platforms.
Cloud applications.
Internal software.

Every one of them needs an authentication strategy.

5. Your website and applications are part of your email perimeter

Companies often secure employee email properly while forgetting about applications that send automated messages.

A website might send password resets. A CRM sends proposals. An e-commerce platform sends order confirmations. A custom system sends alerts. A support platform sends tickets.

If those systems use your domain, they are part of your email infrastructure.

This is particularly important when businesses invest in custom software development. Email authentication should be treated as an infrastructure requirement during implementation, not something somebody remembers after messages start landing in spam.

The same applies to website development. Contact forms and transactional notifications should send through properly authenticated infrastructure instead of whatever basic mail function happens to be available on the server.

6. Use DMARC reports instead of guessing

One of the most useful parts of DMARC is reporting.

Aggregate reports can show which servers are sending messages that claim to represent your domain and whether those messages are passing SPF, DKIM, and DMARC.

This lets you identify two very different things:

Legitimate services you forgot to authenticate.
Infrastructure attempting to impersonate your domain.

The raw reports are not especially pleasant to read, so many organisations use a DMARC reporting platform to turn them into dashboards and alerts.

The important part is not which reporting tool you choose. It is that somebody actually reviews the information.

7. Protect your subdomains too

Locking down yourcompany.com while ignoring its subdomains can leave unnecessary room for abuse.

If attackers can impersonate something like billing.yourcompany.com or support.yourcompany.com, many recipients will still see the trusted brand name and assume the message is legitimate.

Your DMARC policy can include a subdomain policy using sp=.

If your subdomains are not supposed to send mail, they should not be left unnecessarily permissive.

For businesses with more complicated infrastructure, specific sending subdomains can also be deliberately separated. Marketing mail might use one subdomain, transactional mail another, and corporate employee mail the primary domain.

This can make authentication, reputation, troubleshooting, and vendor management easier to control.

8. Lock down domains that should never send email

Companies often own defensive domains, old domains, campaign domains, product domains, or domains purchased simply to protect the brand.

If a domain should never send email, say so explicitly.

An SPF record such as:

v=spf1 -all

tells receivers that no server is authorised to send email for that domain.

A DMARC reject policy can add another layer of protection for messages using that domain visibly.

Do not leave unused domains sitting around with no mail policy simply because nobody inside the company sends from them.

9. Google Workspace or Microsoft 365 will not fix everything automatically

Moving your company email to a major provider is generally useful for security and administration, but changing providers does not automatically stop somebody from typing your domain into a forged From field.

You still need the DNS authentication layer.

Google Workspace, Microsoft 365, and other professional mail systems can handle DKIM signing and provide additional anti-phishing controls, but your SPF, DKIM, and DMARC configuration still needs to represent how your company sends mail.

If your DNS policy is weak, simply paying for a better mailbox does not magically publish a strong DMARC policy for you.

10. DMARC does not stop lookalike domains

This is where many companies get confused.

Suppose your real domain is:

yourcompany.com

An attacker registers:

yourcornpany.com

where the letters have been changed slightly.

Your DMARC record has no authority over the attacker’s domain.

The attacker owns it. They can even configure SPF, DKIM, and DMARC perfectly for their fake domain.

This is called a lookalike or cousin-domain attack.

Defences can include monitoring registrations similar to your brand, registering particularly important variants yourself, using inbound impersonation detection, monitoring certificate activity, and teaching employees to inspect the actual sender domain instead of relying on the display name.

11. DMARC also cannot stop display-name spoofing

An attacker does not always need your domain.

They can send from:

randomaccount@gmail.com

while setting the display name to:

Ahmed Hassan, CEO

On a mobile email interface, the display name can be much more visually prominent than the actual address.

Your DMARC record cannot prevent someone from using a person’s name.

This needs inbound anti-impersonation controls, employee awareness, clear financial approval procedures, and mailbox security policies.

12. Protect the real accounts too

Spoofing is annoying. A compromised real mailbox is worse.

If an attacker gains access to an actual executive or finance account, the email can legitimately pass SPF, DKIM, and DMARC because it really came through your authorised infrastructure.

That is why email authentication needs to sit beside strong identity security.

Require multi-factor authentication.
Prefer phishing-resistant authentication where practical.
Review suspicious sign-ins.
Remove old accounts quickly.
Control administrator privileges.
Review forwarding rules and mailbox delegates.
Protect password-reset processes.
Train finance and management teams against payment-change fraud.

SPF, DKIM, and DMARC protect the domain identity. Account security protects the actual people using it.

13. Do not let third-party vendors become your weak point

Every SaaS platform allowed to send as your company expands the email supply chain.

Before allowing a vendor to use your primary domain, check whether it supports aligned DKIM, how return-path domains are handled, how authentication is documented, and what happens if you stop using the service.

Where sensible, isolate external senders onto dedicated subdomains instead of giving every system the same identity used by executives and employees.

This becomes especially important as companies connect marketing platforms, CRMs, support systems, custom applications, and automation. A connected digital ecosystem needs governance around who is allowed to send email just as much as it needs APIs and integrations.

14. Know what p=reject actually means

This point is worth making clearly.

DMARC p=reject does not prevent a scammer from pressing Send.

It publishes an instruction telling receiving mail systems that messages failing DMARC should be rejected.

Major receiving systems use email authentication heavily, but the receiving server ultimately controls what happens to a message.

So even a correctly configured domain cannot promise that a forged email will never exist anywhere on the internet.

What you can do is make unauthenticated use of your exact domain much harder to deliver successfully.

15. Do not confuse extra email security standards with anti-spoofing

You may also come across technologies such as ARC, MTA-STS, TLS reporting, and BIMI.

They can be useful, but they solve different problems.

ARC helps preserve authentication information when legitimate intermediaries modify or forward messages.
MTA-STS helps enforce encrypted SMTP transport between supporting mail systems.
TLS reporting helps identify delivery encryption problems.
BIMI can support verified brand presentation with participating mailbox providers.

None of them replaces SPF, DKIM, and DMARC as the core anti-spoofing foundation.

Email spoofing lockdown checklist

Publish one valid SPF policy containing only authorised senders.
Move toward SPF hard fail once the sender inventory is correct.
Enable DKIM signing for every important sending platform.
Use your own domain for aligned DKIM where possible.
Publish DMARC and collect aggregate reports.
Do not leave DMARC at p=none forever.
Move to enforcement after legitimate senders are validated.
Protect unused and non-sending subdomains.
Review old SaaS services that still have sending authority.
Monitor lookalike domains separately.
Enable inbound impersonation protection for employees.
Use strong MFA on real mailboxes.
Secure website, CRM, support, and transactional email senders.
Review DMARC reports continuously instead of treating setup as a one-time project.

If SPF, DKIM, and DMARC already pass and your policy is set to reject, you have done the most important work for protecting the exact domain. The next layer is visibility, third-party sender governance, subdomain protection, lookalike-domain defence, inbound impersonation controls, and securing the real accounts attackers would prefer to compromise.

FAQ: How to stop email spoofing

Can email spoofing be stopped completely?

You can make direct spoofing of your exact domain much harder to deliver by using SPF, DKIM, and DMARC with enforcement. You cannot prevent every display-name attack, lookalike domain, poorly configured receiving server, or attempt to send a forged message.

Is DMARC p=reject enough to stop spoofing?

It is one of the strongest controls for direct domain spoofing, but it only works properly when legitimate senders authenticate and align correctly. It also does not protect against similar domains or compromised real mailboxes.

Why can attackers still spoof my company after I set up SPF?

SPF alone validates the technical sending source and does not fully protect the visible From identity. DKIM and DMARC are needed to create stronger domain authentication and alignment.

Will Google Workspace stop people spoofing my domain?

Google Workspace can provide secure mail infrastructure, DKIM signing, and anti-phishing controls, but you still need to configure your DNS authentication correctly. Moving providers alone does not stop someone from attempting to forge your domain.

How do I protect against fake domains that look like mine?

DMARC cannot control domains owned by someone else. Monitor lookalike registrations, consider registering critical variants, use inbound impersonation detection, and train employees and customers to verify the actual sender domain.

If your company has multiple websites, CRMs, email platforms, support systems, or custom applications sending mail and you are not completely sure which systems are authorised to use your domain, book a free consultation with Mighty Leap. We can map the digital infrastructure, identify authentication gaps, and help turn a messy collection of senders into a controlled system.

Ramy Moussa

Author & Moderator

Building unforgettable brands through web development, SEO, paid ads and CRM.