Email Spoofing Prevention: The Complete SPF, DKIM, and DMARC Guide

What is email spoofing?

Email spoofing is when an attacker sends an email that appears to come from your domain -- but was not sent by you or your mail servers. The "From" address shows ceo@yourcompany.com, but the email actually originated from the attacker's infrastructure.

This is possible because the original email protocol (SMTP) has no built-in way to verify sender identity. Without authentication records in your DNS, any mail server in the world can claim to send email on behalf of your domain.

Why is spoofing dangerous?

• Phishing attacks against your employees -- "Hi, this is the CEO. Please wire $50,000 to this account."
• Phishing attacks against your customers -- "Your invoice is attached. Please pay immediately."
• Reputation damage -- your domain ends up on blocklists, and legitimate email stops being delivered
• Compliance violations -- regulations like NIS2 and ISO 27001 require email authentication controls
• Supply chain attacks -- attackers impersonate your company to target your partners and vendors

The three layers of email authentication

No single technology stops spoofing on its own. You need all three working together:

SPF (Sender Policy Framework)

SPF specifies which mail servers are allowed to send email for your domain. It is a DNS TXT record that lists authorised IP addresses and hostnames.

When a receiving server gets an email from your domain, it checks whether the sending server's IP is listed in your SPF record. If not, the email fails SPF.

For a complete setup guide, see How to set up SPF records.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to every outgoing email. The sending server signs the email with a private key, and the receiving server verifies the signature using a public key published in your DNS.

This proves that the email was actually sent by your infrastructure and has not been tampered with in transit.

For a complete setup guide, see How to set up DKIM.

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

DMARC ties SPF and DKIM together and tells receiving servers what to do when an email fails both checks. It also provides a reporting mechanism so you can see who is sending email as your domain.

Without DMARC, a receiving server might still deliver spoofed emails even if SPF and DKIM fail -- it is up to the receiver's discretion. DMARC changes this by publishing an explicit policy.

For a full breakdown of DMARC policy levels, see DMARC policy explained.

How the three work together

Here is what happens when someone receives an email claiming to be from you@yourcompany.com:

1. SPF check -- Is the sending server's IP in yourcompany.com's SPF record?
2. DKIM check -- Does the email have a valid DKIM signature from yourcompany.com?
3. DMARC alignment -- Does at least one of the above pass AND align with the "From" domain?
4. DMARC policy -- If alignment fails, what does the DMARC record say to do? (none, quarantine, or reject)

An email is considered authenticated when it passes DMARC alignment -- meaning either SPF or DKIM (or both) passes and the domain in the check matches the "From" domain.

Step-by-step implementation order

Follow this order. Jumping straight to p=reject without preparation will break your legitimate email.

Step 1: Inventory all email senders

Before touching DNS, list every service that sends email as your domain:

• Your primary mail provider (Google Workspace, Microsoft 365, etc.)
• Marketing platforms (Mailchimp, HubSpot, SendGrid, etc.)
• Transactional email services (SES, Postmark, etc.)
• CRM and support tools (Salesforce, Zendesk, Freshdesk, etc.)
• Internal applications that send notifications

Step 2: Set up SPF

Create (or update) your SPF record to include all legitimate senders:

yourcompany.com.  IN  TXT  "v=spf1 include:_spf.google.com include:mail.zendesk.com include:sendgrid.net ~all"

Use ~all (softfail) initially while you are still identifying all senders.

Step 3: Set up DKIM

Enable DKIM signing for every service in your inventory. Each service will give you a CNAME or TXT record to add to your DNS. Verify signatures are working:

# Send a test email, then check the headers for:
# DKIM-Signature: ... d=yourcompany.com ...
# Authentication-Results: ... dkim=pass

Step 4: Deploy DMARC at p=none

Start with monitoring mode to see who is sending as your domain without blocking anything:

yourcompany.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com; ruf=mailto:dmarc-forensics@yourcompany.com"

Step 5: Analyse DMARC reports

DMARC aggregate reports (RUA) are XML files sent daily by receiving servers. Use a tool to parse them:

• DMARC Analyzer
• Postmark DMARC (free)
• MXToolbox DMARC Report Analyzer

Look for:

• Legitimate senders failing SPF or DKIM -- fix these by adding them to SPF or enabling DKIM
• Unknown senders passing SPF -- investigate whether these are services you forgot about
• Spoofing attempts -- emails from IPs you do not recognise, failing both SPF and DKIM

Step 6: Move to p=quarantine

Once your reports show that all legitimate email is passing, tighten the policy:

yourcompany.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourcompany.com"

Emails that fail DMARC will now be sent to spam. Monitor for a few weeks.

Step 7: Move to p=reject

When you are confident that no legitimate email will be blocked:

yourcompany.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourcompany.com"

This tells receiving servers to outright reject any email that fails DMARC. This is the strongest protection.

How to verify your domain is fully protected

Quick check with MXToolbox

Visit MXToolbox SuperTool and run:

• SPF Record Lookup -- verify your SPF record is valid and not exceeding the 10-lookup limit
• DKIM Lookup -- check each selector for valid public keys
• DMARC Lookup -- verify your DMARC record exists and has the policy you expect

Send a test email

Use mail-tester.com to send a test email and get a score. It checks SPF, DKIM, DMARC, and many other deliverability factors.

Check the headers manually

Send an email to a Gmail or Outlook account and inspect the full headers. Look for:

Authentication-Results: mx.google.com;
       dkim=pass header.d=yourcompany.com;
       spf=pass (google.com: domain of you@yourcompany.com designates 203.0.113.1 as permitted sender);
       dmarc=pass (p=REJECT) header.from=yourcompany.com

All three should show pass.

What to do if you are being spoofed right now

If you discover that someone is actively spoofing your domain:

1. Check your current DMARC policy. If you are at p=none, move to p=quarantine immediately -- even if you have not finished your inventory. Quarantine is better than nothing.
2. Verify SPF and DKIM are working for your main email flow. Broken authentication on your legitimate email is worse than no authentication at all.
3. Notify your team. Alert employees to be suspicious of emails from your own domain and report anything unusual.
4. Notify affected parties. If customers or partners received spoofed emails, inform them that the emails were not from you.
5. Monitor DMARC reports closely. Increase your reporting frequency and watch for the spoofing source.
6. Escalate to p=reject as soon as your legitimate email is confirmed working.

How SurfaceScan helps

SurfaceScan checks every domain in your attack surface for SPF, DKIM, and DMARC configuration. It detects missing records, weak DMARC policies (like p=none that has been left in monitoring mode too long), SPF records that exceed the lookup limit, and DKIM selectors that are missing or misconfigured. All findings appear in the Email Security section with specific guidance on what to fix and in what order.