How to prevent email spoofing from your domain?

You prevent email spoofing from your domain by publishing three DNS records that let receiving mail servers verify your messages: SPF (which servers may send for you), DKIM (a cryptographic signature on each message), and DMARC (a policy that tells receivers what to do when a message fails those checks). Once DMARC is set to quarantine or reject, most major mailbox providers will stop delivering forged emails that claim to come from your domain.

Email was designed decades ago without any built-in way to prove who sent a message, which is why anyone can type your address into the "From" field of a script and hit send. This article explains how spoofing works, walks you through setting up SPF, DKIM, and DMARC step by step, shows you how to move to full enforcement without breaking legitimate mail, and covers a few extra protections worth adding once the basics are in place.

What Is Email Spoofing?

Email spoofing is the act of sending a message with a forged sender address so that it appears to come from someone else. If your business uses example.com, a spoofer can send an invoice, a password reset notice, or a "change of bank details" request that looks like it came from accounts@example.com, even though they never touched your mail server.

Spoofing is the delivery mechanism behind a lot of phishing and business email compromise. The attacker isn't breaking into your inbox; they're borrowing your reputation. Your customers, suppliers, and staff trust your domain name, and that trust is exactly what the forger is exploiting.

Why Spoofing Hurts Your Domain

Even if you never see the forged emails yourself, they can cause real damage:

• Customer fraud: People who trust your brand may pay fake invoices or hand over login details.
• Deliverability problems: When spam is sent in your name, mailbox providers may start treating your legitimate mail with suspicion.
• Reputation damage: Recipients don't know the email was forged. They just remember that "your company" sent them a scam.
• Compliance issues: Many large providers now require authenticated mail from bulk senders, and some industries expect DMARC as a baseline control.

How Receiving Servers Decide Whether to Trust a Message

Every email actually has two sender identities. The envelope sender (also called the Return-Path or MAIL FROM) is used by servers during delivery and for bounces. The header From is the address you see in your mail client. Spoofers usually forge the header From, because that's what people read.

SPF checks the envelope sender, DKIM checks a signature tied to a domain in the message, and DMARC ties both back to the header From that humans actually see. That "alignment" step is what makes DMARC so effective against spoofing.

Step 1: Inventory Everything That Sends Email for Your Domain

Before you publish any records, make a list of every service that sends email using your domain. This is the step people skip, and it's the reason DMARC rollouts break things.

Typical senders include:

• Your mailbox provider (Google Workspace, Microsoft 365, Zoho Mail, Fastmail, and so on).
• Your website, such as WordPress sending contact form notifications, order emails, or password resets.
• Transactional email services like SendGrid, Mailgun, Postmark, Amazon SES, or Brevo.
• Marketing platforms such as Mailchimp, Klaviyo, or HubSpot.
• Help desk and CRM tools like Zendesk, Freshdesk, or Salesforce.
• Invoicing or accounting software that emails customers on your behalf.

Write down each service and look up its documentation for SPF and DKIM setup. Nearly every reputable provider publishes exact DNS values for you to copy.

Step 2: Publish an SPF Record

SPF (Sender Policy Framework) is a TXT record on your domain that lists which servers are allowed to send mail using your domain as the envelope sender.

A typical SPF record for a business using Google Workspace and a transactional email service looks like this:

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

For Microsoft 365, the include is different:

example.com.  IN  TXT  "v=spf1 include:spf.protection.outlook.com ~all"

Here's what the parts mean:

1. v=spf1: Identifies the record as SPF. It must come first.
2. include:: Pulls in the list of authorised servers published by a provider.
3. ip4: or ip6:: Authorises a specific IP address or range, useful if your own server sends mail.
4. ~all or -all: The final mechanism. ~all (softfail) marks unlisted senders as suspicious, while -all (fail) says they're not allowed at all.

SPF Rules That Trip People Up

Only one SPF record per domain: If you publish two TXT records that start with v=spf1, SPF fails for every message. Merge them into a single record instead.

The 10-lookup limit: Each include, a, mx, exists, and redirect triggers a DNS lookup, and SPF allows a maximum of 10. Stacking many providers can exceed this and cause a permerror. Remove services you no longer use, and avoid a and mx mechanisms if you don't need them.

Protect domains that never send email: Parked or unused domains are popular spoofing targets. Give them a record that says "nobody sends mail for me":

parked-example.com.  IN  TXT  "v=spf1 -all"

When DMARC is in place, ~all is generally fine for your main domain, because DMARC makes the final decision. Many administrators still move to -all once they're confident the list is complete.

Step 3: Set Up DKIM Signing

DKIM (DomainKeys Identified Mail) adds a digital signature to the headers of each outgoing message. The sending service signs with a private key, and you publish the matching public key in DNS so receivers can verify that the message wasn't altered and really was authorised by your domain.

DKIM keys live under a selector, which is just a label that lets you have multiple keys at once. A published DKIM record looks something like this:

google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Many providers ask you to create a CNAME instead, so they can rotate keys for you:

s1._domainkey.example.com.  IN  CNAME  s1.domainkey.u1234567.wl.sendgrid.net.

To enable DKIM for common platforms:

1. Google Workspace: Go to Admin console > Apps > Google Workspace > Gmail > Authenticate email, generate a 2048-bit key, publish the TXT record, then click Start authentication.
2. Microsoft 365: In the Microsoft Defender portal, open Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM, select your domain, publish the two CNAME records it shows, and enable signing.
3. Transactional and marketing services: Look for a "domain authentication" or "sender authentication" section in the dashboard. It will give you the CNAME or TXT records to add.

Use 2048-bit keys where your DNS host supports them. Some DNS panels require long TXT values to be split into multiple quoted strings, which is normal and still valid.

Step 4: Publish a DMARC Record in Monitoring Mode

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the piece that actually stops spoofing. It tells receivers: "A message claiming to be from my domain must pass SPF or DKIM, and the passing domain must align with the From address. If it doesn't, here's what to do."

DMARC lives in a TXT record at _dmarc.yourdomain. Start in monitoring mode:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1"

The main tags are:

• p=: The policy. none means monitor only, quarantine means send failures to spam, and reject means block them outright.
• rua=: Where receivers should send daily aggregate reports.
• sp=: An optional separate policy for subdomains.
• pct=: The percentage of failing mail the policy applies to, useful for gradual rollouts.
• adkim= and aspf=: Alignment mode, either r (relaxed, the default) or s (strict).
• fo=1: Requests failure details when any check fails, if the receiver supports it.

Understanding Alignment

A message passes DMARC if at least one of these is true:

• SPF passes and the envelope sender domain matches the header From domain.
• DKIM passes and the d= domain in the DKIM signature matches the header From domain.

With relaxed alignment, subdomains count as a match, so mail.example.com aligns with example.com. This is why DKIM matters so much: many third-party services use their own envelope sender domain, so SPF won't align, but a DKIM signature using your domain will.

Step 5: Read Your DMARC Reports

Aggregate reports arrive as zipped XML files, which are unpleasant to read by hand. Most people send them to a DMARC reporting service that turns them into readable dashboards. Well-known options include Postmark's free DMARC monitoring, dmarcian, Valimail, EasyDMARC, and Cloudflare's DMARC Management if your DNS is on Cloudflare.

Spend at least two to four weeks watching the reports. You're looking for:

1. Legitimate sources that fail: A forgotten newsletter tool or a CRM sending unauthenticated mail. Fix these by adding SPF includes and enabling DKIM.
2. Forwarding noise: Forwarded mail often breaks SPF but keeps DKIM intact. This is expected, and another reason DKIM is important.
3. Unknown sources: IP addresses you don't recognise sending mail as your domain. These are often spoofers, and they're exactly what enforcement will block.

If you'd rather receive reports at a different domain (for example, a reporting service's address), that service will usually tell you about any extra DNS authorisation record it needs.

Step 6: Move to Quarantine, Then Reject

Once your legitimate senders consistently pass, tighten the policy in stages. A careful path looks like this:

# Stage 1: quarantine a portion of failing mail
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com"

# Stage 2: quarantine everything
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

# Stage 3: full enforcement
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.com"

Give each stage a week or two while you keep an eye on reports and on any complaints about missing mail. At p=reject, receivers that honour DMARC will refuse forged messages before they reach anyone's inbox, which is the goal.

For parked domains that never send mail, you can skip straight to enforcement, alongside the v=spf1 -all record from earlier:

_dmarc.parked-example.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.com"

Making Sure Your Website's Email Passes

Websites are one of the most common sources of failing mail. By default, WordPress uses PHP's mail() function through your host's server, which usually isn't covered by your SPF record and isn't DKIM-signed with your domain.

The fix is to send website mail through an authenticated service over SMTP or an API. Popular plugins for this include WP Mail SMTP, FluentSMTP, and Post SMTP. You connect the plugin to your mailbox provider or transactional service, and that service handles SPF and DKIM for you.

If you'd rather not store SMTP credentials in the database, many of these plugins let you define them as constants in wp-config.php, above the "That's all, stop editing!" line. For example, WP Mail SMTP supports constants like these:

define( 'WPMS_ON', true );
define( 'WPMS_MAILER', 'smtp' );
define( 'WPMS_SMTP_HOST', 'smtp.example-provider.com' );
define( 'WPMS_SMTP_PORT', 587 );
define( 'WPMS_SSL', 'tls' );
define( 'WPMS_SMTP_AUTH', true );
define( 'WPMS_SMTP_USER', 'website@example.com' );
define( 'WPMS_SMTP_PASS', 'use-an-app-specific-password-here' );
define( 'WPMS_MAIL_FROM', 'website@example.com' );
define( 'WPMS_MAIL_FROM_FORCE', true );

Check your plugin's documentation for its exact constant names, and use an app password or API key rather than your main account password. After setting it up, send a test email to a Gmail address, open it, choose Show original, and confirm that SPF, DKIM, and DMARC all say PASS.

Extra Protections Worth Adding

Once DMARC is enforced, a few additional standards can strengthen your email security further.

MTA-STS and TLS Reporting

MTA-STS tells other mail servers that they must use encrypted TLS connections when delivering mail to your domain, which protects inbound mail against downgrade attacks. It requires a small policy file served over HTTPS at https://mta-sts.example.com/.well-known/mta-sts.txt plus a DNS record:

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20260922"
_smtp._tls.example.com. IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

The policy file itself is plain text:

version: STSv1
mode: testing
mx: aspmx.l.google.com
mx: *.aspmx.l.google.com
max_age: 86400

Replace the mx lines with your real MX hosts, start in testing mode, and switch to enforce once reports look clean. Change the id value in DNS whenever you update the policy.

BIMI

BIMI (Brand Indicators for Message Identification) lets supporting mail clients display your logo next to authenticated messages. It requires DMARC at quarantine or reject, a logo in a specific SVG format, and for some providers a paid certificate. It doesn't stop spoofing on its own, but it rewards you for having done the work.

Staff Awareness

No DNS record stops an attacker from registering a lookalike domain such as examp1e.com. Teach staff and customers to check sender addresses, be suspicious of urgent payment changes, and verify requests through a second channel. Some businesses also register common misspellings of their domain defensively.

How to Check Your Setup

You can verify your records from the command line with dig:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT google._domainkey.example.com

On Windows, nslookup -type=TXT _dmarc.example.com does the same job. Free online checkers from MXToolbox, dmarcian, and Google's Admin Toolbox can also validate syntax and flag common mistakes like duplicate SPF records or too many DNS lookups.

---

FAQ: Preventing Email Spoofing

---

Conclusion

Email spoofing works because email, by default, trusts whatever the sender claims. SPF, DKIM, and DMARC change that by giving receiving servers a reliable way to check whether a message genuinely came from you, and a clear instruction to reject it when it didn't. The setup takes some care, mostly in finding every service that sends on your behalf, but the records themselves are short and the payoff is significant.

Start with an inventory, publish SPF and DKIM for each sender, add DMARC in monitoring mode, and let the reports guide you toward full enforcement. Once you reach p=reject, criminals lose the ability to borrow your domain's name, your legitimate mail becomes more deliverable, and your customers get one less convincing scam in their inbox.