How to Prevent Email Spoofing on Your Domain

Someone is sending emails that look like they come from your domain. Your clients receive invoices from billing@yourdomain.com that you never sent. Your employees get internal memos from ceo@yourdomain.com written by an attacker. Your domain ends up on spam blacklists because of emails you had nothing to do with.

This is email spoofing — and it is shockingly easy to do. The email protocol (SMTP) was designed in the 1980s without built-in sender verification. Anyone can claim to send from any address. The three authentication standards that fix this — SPF, DKIM, and DMARC — exist precisely because the protocol itself does not verify senders.

This guide explains how spoofing works, what damage it causes, and exactly how to set up SPF, DKIM, and DMARC to prevent it. If you already know why spoofing is bad and just want the fix, skip to the setup section.

How email spoofing works

When you send an email, your email client tells the mail server two things: the envelope sender (the “from” address at the protocol level) and the header from (the “From:” field the recipient sees). Neither of these is verified by default. An attacker can set both to any address they want.

This is not a bug — it is how email was designed. Early internet users trusted each other implicitly. The protocol never imagined a world where billions of strangers would use it. The authentication standards that came later (SPF in 2006, DKIM in 2007, DMARC in 2012) are essentially patches bolted onto a 40-year-old system.

For a deeper look at how attackers exploit this, including real-world examples, see our email spoofing explainer.

The damage spoofing causes

• Phishing attacks using your brand. Attackers send convincing phishing emails that appear to come from your domain. Your customers or employees trust them because the sender address looks legitimate.
• Invoice fraud. Spoofed emails with modified payment details are one of the most costly forms of business email compromise. The invoice looks real because it comes from a real-looking address.
• Domain reputation damage. If spammers use your domain to send bulk email, your domain reputation suffers. Legitimate emails from your actual mail server start landing in spam folders.
• Blacklisting. Severe spoofing abuse can get your domain listed on DNS-based blacklists (Spamhaus, Barracuda, SpamCop), which blocks your legitimate email globally.

Setting up email authentication: SPF, DKIM, and DMARC

These three DNS records work together to prevent spoofing. Each solves a different part of the problem.

Step 1: SPF (Sender Policy Framework)

SPF tells receiving mail servers which IP addresses are allowed to send email on behalf of your domain. When a server receives an email claiming to be from yourdomain.com, it checks the SPF record to see if the sending server’s IP is authorized. If not, the email fails SPF.

How to set it up:

1. Identify every service that sends email from your domain (your mail server, marketing tools, CRM, helpdesk, etc.)
2. Create a TXT record on your domain with the SPF policy
3. A typical SPF record looks like: v=spf1 include:_spf.google.com include:sendgrid.net -all
4. The -all at the end means “reject everything not explicitly authorized” — this is the strict setting you want

Common mistake: Using ~all (soft fail) instead of -all (hard fail). Soft fail tells receivers “this probably should not pass, but do what you want.” Most spam filters treat soft fail as suspicious but not definitive. Use -all for real protection.

Step 2: DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to every email your server sends. The receiving server checks this signature against a public key published in your DNS. If the signature is valid, the email was genuinely sent by an authorized server and was not modified in transit.

How to set it up:

1. Your email provider or mail server generates a DKIM key pair (private key for signing, public key for DNS)
2. Publish the public key as a TXT record on your domain (usually at selector._domainkey.yourdomain.com)
3. Your mail server signs every outgoing email with the private key
4. Receiving servers verify the signature against the public key in DNS

Most email providers (Google Workspace, Microsoft 365, etc.) handle DKIM key generation and signing automatically. You just need to publish the DNS record they provide.

Step 3: DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication fails. Without DMARC, a failed SPF or DKIM check is informational — the receiving server decides what to do. With DMARC, you explicitly instruct receivers to reject or quarantine unauthenticated emails.

How to set it up:

1. Start with a monitoring-only policy: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
2. Wait 2–4 weeks and analyze the reports. Look for legitimate services that fail authentication (you may need to add them to your SPF record or configure DKIM)
3. Move to quarantine: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com
4. Once you are confident all legitimate email passes, move to reject: v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

The p=reject policy is your goal. It tells receiving servers to flat-out reject any email that fails both SPF and DKIM alignment. This is the only DMARC policy that actually prevents spoofing. p=none just monitors. p=quarantine sends failed emails to spam folders. p=reject blocks them entirely.

For a detailed explanation of how SPF, DKIM, and DMARC interact, including alignment rules, see our guide to how authentication failures happen.

Common mistakes that weaken your protection

Mistake	Why it is a problem	Fix
SPF with ~all instead of -all	Soft fail gives receivers discretion to accept anyway	Change to -all once you have verified all senders
DMARC stuck on p=none	Monitoring only, does not block spoofed emails	Progress to p=quarantine then p=reject
Forgetting third-party senders in SPF	Your CRM, marketing tool, or helpdesk fails SPF and gets rejected	Audit all services that send as your domain
Too many SPF lookups	SPF allows a maximum of 10 DNS lookups. Exceeding this causes SPF to fail entirely	Consolidate includes, use IP addresses where possible
No DKIM on third-party senders	Even with SPF, messages forwarded by recipients will fail SPF. DKIM survives forwarding	Configure DKIM signing on every service that sends as your domain
Not reading DMARC reports	You do not know if legitimate email is being blocked	Use a DMARC report analyzer (free tools available) or check reports weekly

Testing your setup

After configuring SPF, DKIM, and DMARC, verify everything works:

1. Send a test email to a Gmail account. Open the email, click the three-dot menu, and select “Show original.” Look for SPF: PASS, DKIM: PASS, and DMARC: PASS.
2. Check your DNS records using online tools like MXToolbox or dmarcian’s domain checker. These tools validate your SPF syntax, DKIM key, and DMARC record.
3. Monitor DMARC reports for at least 2 weeks before moving to p=reject. Reports show every email sent from your domain (or claiming to be), whether it passed or failed, and from which IP addresses.

What authentication cannot prevent

SPF, DKIM, and DMARC prevent direct spoofing of your domain. They cannot prevent:

• Look-alike domains. An attacker registers yourdoma1n.com (with a number 1 instead of the letter i) and sends from that. Authentication passes because they control the look-alike domain. This requires brand monitoring, not DNS records.
• Display name spoofing. An attacker sends from attacker@evil.com but sets the display name to “CEO John Smith.” Many email clients show only the display name, not the actual address. User awareness is the defense here.
• Compromised accounts. If an attacker gains access to a legitimate email account on your domain, they are sending from an authorized server. Authentication passes. Two-factor authentication and strong password policies prevent this.

Monitoring your domain after setup

Authentication is not set-and-forget. You need ongoing monitoring:

• Review DMARC reports regularly. New services added to your stack (a new CRM, a new support tool) may start sending as your domain without proper authentication.
• Watch for blacklist inclusion. Even with authentication, past spoofing damage may have put your domain on blacklists. Check periodically.
• Audit your SPF record when adding services. Every new “include:” counts toward the 10-lookup limit. Plan ahead.

For businesses that want automated monitoring, Cleanbox Relay acts as an inbound MX gateway that checks every incoming email against SPF, DKIM, DMARC, and DNSBL blacklists. Per-address spam thresholds and authentication-based filter rules let you enforce strict policies without managing it manually.