Email spoofing, where attackers forge sender addresses to launch phishing and impersonation scams, is a top threat that targets small and mid-sized businesses (SMBs). These attacks often succeed simply because essential email authentication records are missing or misconfigured.
In this guide, we will help you implement vital email spoofing protection, which includes SPF, DKIM, and DMARC, to secure both your outbound and inbound mail for your Windows-based SMB clients.
Why this matters more than ever in 2026
Google, Yahoo, and Microsoft now actively reject unauthenticated bulk email rather than just flagging it as spam. Domains sending 5,000+ messages a day to Gmail, Yahoo, or Outlook.com addresses must have SPF, DKIM, and a published DMARC record, or mail gets bounced outright.
Even SMBs well under that threshold are affected indirectly. Marketing platforms, CRMs, and helpdesk tools sending on their behalf count toward the sender’s own volume, and a shared reputation on unauthenticated infrastructure gets everyone’s mail throttled. This all means that setting these records up is the baseline for mail actually arriving.
The protocols at a glance
| Protocol | What it does | Where it lives | Required by 2026 bulk-sender rules? |
| SPF | Authorizes sending IPs/servers | DNS TXT record | Yes |
| DKIM | Signs messages cryptographically | DNS TXT/CNAME record | Yes |
| DMARC | Sets enforcement policy + reporting | DNS TXT record | Yes |
| BIMI | Displays verified brand logo | DNS TXT record + VMC | No (optional) |
Deploy scripts and configure endpoints with NinjaOne Endpoint Security for better protection
Methods to protect businesses from email spoofing
SPF, DKIM, and DMARC are the essential trio that authenticate senders and stop domain spoofing. Configuring them correctly prevents attackers from impersonating your business or partners.
📌Use case: Implement these protection tools for your business email to prevent email spoofing, stop phishing, protect your brand, and ensure only legitimate emails reach your inbox.
📌Prerequisites: Before starting, make sure you have:
- Administrative access to your domain’s DNS
- An email service supporting DKIM
- The ability to add/update DNS TXT records
- A basic understanding of DNS records
- Tools like PowerShell, mail testing tools (e.g., MXToolbox), and Command Prompt
We recommend checking ⚠️ Things to look out for before proceeding.
📌 Recommended deployment strategies:
| 💻 Best for Individual Users | 💻💻💻 Best for Enterprises | |
| How to configure the SPF record in DNS | ✓ | ✓ |
| How to enable DKIM signing | ✓ | ✓ |
| How to publish DMARC policy | ✓ | ✓ |
| Use PowerShell for Microsoft 365 DKIM and DMARC management | ✓ | |
| How to do GPO and Registry-based email hardening (Windows clients only) | ✓ |
How to configure the SPF record in DNS
The Sender Policy Framework (SPF) configuration is your first critical step in declaring legitimate email sources and preventing domain spoofing. It publishes a DNS “allowed sender list” for your domain. Receiving servers verify that incoming mail truly originates from your approved servers.
📌 Use case: Set up SPF now if your domain sends any email (via Microsoft 365, an on-prem server, a website, or marketing tools). Every domain needs SPF to establish basic sender legitimacy and improve deliverability.
Step-by-step procedure:
- List your authorized senders. Identify every service that sends emails as @yourdomain.com, such as:
- Your email provider (e.g., Microsoft 365, Google Workspace)
- Your website/server (if it sends notifications)
- Marketing tools (e.g., Mailchimp, Constant Contact)
- CRMs (e.g., Salesforce, Hubspot)
- On-prem mail servers
💡 Tip: Check your vendor documents for their required SPF include: value. For instance, Microsoft 365 uses spf.protection.outlook.com.
- Build your SPF record:
- Create a TXT record using this syntax:
v=spf1 [mechanisms] -all |
- Examples:
- Microsoft 365 only:
v=spf1 include:spf.protection.outlook.com -all - Microsoft 365 + website server (IP 192.0.2.10):
v=spf1 ip4:192.0.2.10 include:spf.protection.outlook.com -all - Microsoft 365 + Salesforce:
v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com -all
- Microsoft 365 only:
- Examples:
Note that spf.protection.outlook.com is a Microsoft-managed DNS domain that publishes the official SPF record for Microsoft 365’s outbound email infrastructure. It contains the authoritative list of mail servers and IP ranges that Microsoft 365 is allowed to use when sending email on behalf of customer domains
⚠️ Warning: Always end the syntax with -all for hard fail enforcement. This actively blocks unauthorized senders.
- Publish the DNS record through these steps:
- Log in to your DNS server (e.g., GoDaddy, Cloudflare).
- Create a new TXT record.
- Set the Host field to @ (or your root domain name).
- Paste your SPF record (from the previous step) into the Value/Content field.
- Save your changes.
- Verify your actions with these steps:
- Open Command Prompt or Windows Terminal (Win + X).
- Run this command:
nslookup -type=txt yourdomain.com |
- Check the output for your SPF record.
- Confirm with MX-Toolbox SPF Checker.
Within 24-48 hours, legitimate mail from your services will pass the SPF checks, and spoofed emails should fail the SPF authentication process. You will see SPF results, showing pass/fail in the email headers.
How to enable DKIM signing
DomainKeys Identified Mail (DKIM) adds a unique digital signature to your outgoing emails. This signature is generated by the sending mail server using a private cryptographic key.
The corresponding public key is published in DNS as a DKIM record. When a receiving server gets the email, it retrieves the public key from DNS and uses it to validate the signature.
📌 Use case: Enable DKIM immediately if you send business email, whether transactional, marketing, or internal. It’s required for DMARC enforcement and prevents attackers from manipulating your messages.
Step-by-step procedure:
1. Generate your DKIM keys. Keep in mind that your email service creates cryptographic keys automatically::
- For cloud services: No action is needed since the keys are generated automatically when you enable DKIM.
- Microsoft 365: Find the key in the Microsoft Defender portal > Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM. (You can also skip the navigation entirely with the direct link: https://security.microsoft.com/authentication?viewid=DKIM.)
- Google Workspace: Find the key in Admin Console > Apps > Gmail > Authenticate Email.
- For self-hosted servers: Use tools like OpenSSL or your mail server’s DKIM wizard.
💡 Tip: Use 2048-bit keys where your provider allows it; 1024-bit is the technical minimum most providers still accept, but 2048-bit is now the recommended standard for stronger resistance to key-cracking.
2. Publish your DNS records:
- Get the DKIM record from your email provider:
- Microsoft 365: CNAME records (see below)
- Google Workspace: TXT record
- Others: TXT or CNAME
- Log in to your DNS provider (e.g., Cloudflare, GoDaddy)
- Add the following records:
- Get the DKIM record from your email provider:
| Service | Record Type | Host/Name | Value/Content |
| Microsoft 365 | CNAME | selector1._domainkey | selector1-[domain]-com._domainkey.[tenant].onmicrosoft.com |
| CNAME | selector2._domainkey | selector2-[domain]-com._domainkey.[tenant].onmicrosoft.com | |
| Google Workspace | TXT | google._domainkey | v=DKIM1; k=rsa; p=[long_public_key] |
⚠️ Important: Replace [domain] with your domain and [tenant] with your Microsoft 365 tenant name.
Note: Microsoft 365 uses two DKIM records so that DKIM keys can be rotated transparently, maintaining uninterrupted email authentication and strengthening overall security
3. Verify the setup through these steps:
- Open Command Prompt or PowerShell in Windows Terminal (Win + X).
- For Command Prompt, run the following prompt:
nslookup -type=txt google._domainkey.yourdomain.com # Google TXT checknslookup -type=cname selector1._domainkey.yourdomain.com # M365 CNAME check |
- For PowerShell, use this script:
Get-DkimSigningConfig -Identity yourdomain.com | Format-List Enabled,Status |
- Look for
Enabled: TrueandStatus: CNAMEValid.
- Look for
- Email Test: Send an email to [email protected] and inspect the reply headers.
After configuration, all outgoing emails should include a DKIM-Signature header within 24 hours. Receivers can validate messages using your DNS public key, and forged or modified emails will fail DKIM checks. DMARC reports should also show dkim=pass for legitimate email.
How to publish DMARC policy
DMARC acts as your domain’s policy enforcer, telling email providers how to handle unverified messages and delivering vital spoofing reports. It’s the final set of armor in email spoofing protection.
📌 Use case: Deploy DMARC after SPF and DKIM are active. This is essential for all domains to block phishing, gain visibility into email traffic, and enforce sender spoof protection.
Step-by-step procedure:
- Confirm SPF and DKIM (see Methods 1 & 2) are active and passing for all email sources. This is an essential prerequisite for DMARC.
- Build your DMARC record: via these steps
- Create a TXT record in your domain’s DNS with this syntax:
v=DMARC1; p=<policy>; rua=mailto:[email protected] |
- Set an explanation:
p=(Policy): This tells receiving servers what to do with unauthenticated mail. Choose one:p=none: Monitor only (start here).p=quarantine: Send failures to spam.p=reject: Block failures outright.
rua=(Reporting): This sends you daily aggregate reports, which are essential for spotting spoofing and fixing legitimate mail flow.
- Optionally, these are useful tags for fine-tuning:
pct=5: Apply your policy to only 5% of failing mail (eases enforcement).sp=quarantine: Set a different policy for your subdomains.adkim=r; aspf=r: Use “relaxed” alignment (common for most setups).
- Set an explanation:
- Publish the DNS record by doing the following:
- Log in to DNS provider (e.g.,Cloudflare, GoDaddy)
- Create TXT record:
- Host: _dmarc
- Value: Your DMARC policy string
- TTL: 3600 (1 hour)
- Verify your changes:
- Open Command Prompt or Windows Terminal (Win + X).
nslookup -type=txt _dmarc.yourdomain.com |
- For an online check, use MXToolbox DMARC Lookup
- Monitor and tighten the policy:
- Analyze reports, which are sent to rua inbox for 2 weeks.
- Consistently update SPF and DKIM for legitimate senders.
- Escalate policy: none > quarantine > reject.
Within 72 hours after configuration, your Daily XML reports should display legitimate and fraudulent senders, SPF and DKIM pass rates, geographic threat hotspots, and which emails were sent to quarantine or rejected.
Use PowerShell for Microsoft 365 DKIM and DMARC management
PowerShell streamlines Microsoft 365 email security management with command-line efficiency. Use it to enforce email spoofing protection faster than GUI tools.
📌 Use case: This is ideal for IT admins managing multiple domains, automating deployments, or troubleshooting SPF/DKIM/DMARC logs. It is also essential for enforcing policies at scale.
Step-by-step procedure:
- Connect to Exchange Online:
- To do so, open PowerShell (Admin) and then run this script:
Connect-ExchangeOnline -UserPrincipalName [email protected] -ShowBanner:$false |
- Enable DKIM signing with these steps:
- Run this script:
Set-DkimSigningConfig -Identity yourdomain.com -Enabled $true |
- Verify with this script:
Get-DkimSigningConfig yourdomain.com | Select Name, Enabled, Status |
💡 Note: Look for Enabled: True and Status: CNAMEValid
- Retrieve SPF/DKIM/DMARC logs by running this script:
Get-MessageTrace -SenderAddress [email protected] -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) |Format-List Received, SenderAddress, RecipientAddress, Subject, *SPF*, *DKIM*, *DMARC* |
- The output should show authentication results for each sent email.
- View Detailed Traces (Microsoft Defender) by running this script.
Get-MessageTraceReport -MessageTraceId <ID_from_previous_command> |Select -ExpandProperty Events |Where { $_.Action -eq "Deliver" } |Format-List Connectors, *Authentication* |
After execution, DKIM signing activates immediately for outbound mail. Logs should reveal SPF and DKIM pass/fail rates, DMARC alignment status, and suspicious senders.
How to do GPO and Registry-based email hardening (Windows clients only)
While SPF/DKIM/DMARC protect servers, hardening Windows email clients adds critical user-layer defenses against spoofing.
📌 Use case: Deploy when employees use Outlook on domain-joined Windows 11 PCs. This is essential for finance/HR teams handling sensitive data.
Step-by-step procedure:
Method A: Registry edit (SinglePC)
- Press Win + R, and then type regedit to open Registry Editor. Ensure you have administrative privileges.
- Go to or paste this in the address bar: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Security
- Create a new DWORD (32-bit) Value:
- Name it as ShowSenderAsFrom
- Set Value data to 1.
- This forces Outlook to display the mailbox address in the From field when emails are sent using Send As or shared mailbox permissions, instead of showing “on behalf of.”
Method B: Group Policy (Domain-wide)
- Open Group Policy Management Editor.
- Go to User Configuration > Administrative Templates > Microsoft Outlook 2016 > Security
- Enable two policies:
- Warn about ambiguous sender addresses
- Always show From address in email headers
- Enforce by running gpupdate /force on client PCs.
After implementation, Microsoft Outlook starts displaying warnings for suspicious sender-reply-to mismatches, full headers are visible without plugins, and IT gains visibility on potential spoofing attempts via Event Viewer logs, as well as an additional signal for catching spoofed internal-looking messages that authentication alone won’t stop (e.g., a compromised partner account with valid SPF/DKIM).
⚠️ Things to look out for
This section highlights potential challenges to keep in mind while following this guide.
| Risks | Potential Consequences | Reversals |
| Hard SPF enforcement (-all) without full sender inventory | Legitimate emails blocked (invoices, client communications), CRM/marketing system failures | Switch to ~all temporarily; add missing services to SPF record. |
| Unrotated DKIM keys | Cryptographic compromise allowing sender impersonation; expired key delivery failures | Generate new keys immediately; update DNS within 4-hour rotation window. |
| Aggressive DMARC policy (p=reject) without monitoring | Critical business emails rejected silently (no bounce notices); supply chain disruptions | Revert to p=none; analyze reports for 2-4 weeks before re-escalating. |
| Editing Windows Registry without backup | Outlook crashes; client workstations are unable to send/receive mail | Restore registry from backup; delete ShowSenderAsFrom DWORD value. |
| Invalid DMARC reporting email (rua) | Zero visibility into spoofing attacks; undetected phishing campaigns | Correct the email address in DNS; verify the inbox exists. |
| DNS changes without verification | Email blackholing for 24-72 hours; domain reputation damage | Revert to previous DNS records; use nslookup/MXToolbox for pre-validation. |
Monitor for suspicious emails without with NinjaOne RMM
See how NinjaOne can improve your endpoint monitoring in a free trial
Tips when setting up email spoofing protection
Follow these practical tips to avoid common pitfalls when deploying email spoofing protection. Optimize your setup for security and deliverability.
Why does SPF fail after 10 DNS lookups?
SPF fails if DNS lookups exceed 10, causing legitimate emails to bounce. Avoid this by flattening includes:; replace nested include: statements with direct ip4:/ip6: lists.
You can also use SPF macros by consolidating the providers (include:%{i}._spf.example.com). You should test this rigorously with this script below:
Resolve-DnsName -Type TXT yourdomain.com | Select-Object Strings # Windows 11 |
Should I start with p=reject or p=none?
Never begin with p=reject. It risks blocking valid emails silently. Instead, deploy p=none for 2–4 weeks to gather reports. Then, fix SPF/DKIM gaps for legitimate senders.
You should also escalate to p=quarantine (spam) > p=reject (block). This is because gradual enforcement prevents business disruption while maximizing sender spoof protection.
How often should I rotate my DKIM keys?
Undocumented key changes break email flow. For bulletproof management, record selectors (e.g., selector1, google) in a password vault, rotate keys every 6 months via your email admin console, and audit quarterly via this command:
Get-DkimSigningConfig | Format-List Domain, SelectorCNAME # Microsoft 365 |
Should I use a hosted DMARC tool instead of managing DNS manually?
If manual DNS/PS management overwhelms you, adopt MSP-friendly platforms, like PowerDMARC, Proofpoint, or Valimail. This can help auto-configure SPF/DKIM/DMARC, parse reports into plain English, and alert on spoofing attacks in real-time. This is ideal for teams that lack dedicated mail admins or 24/7 monitoring.
Quick-Start Guide
The specific steps to detect and fix route flapping would generally involve:
1. Monitoring Tools: Use NinjaOne’s Network Management System (NMS) to monitor SNMP metrics like interface status, routing table changes, and protocol uptime.
2. Alerting: Set up alerts for rapid interface flaps or routing protocol instability.
3. Log Analysis: Examine device logs for patterns indicating route instability.
4. Network Diagnostics: Use tools like traceroute, ping, or vendor-specific diagnostics from the affected devices.
5. Configuration Review: Check for misconfigured routing policies, redundant paths, or unstable peering relationships.
Email spoofing protection: Stop phishing before it starts
Configuring SPF, DKIM, and DMARC your frontline defense against phishing, invoice fraud, and brand impersonation targeting SMBs. By implementing these protocols, you enforce domain trust, block spoofed emails at the server level, and gain critical visibility into attack patterns.
Start with SPF’s -all, layer DKIM’s cryptographic signing, and then let DMARC reports guide policy tightening. Remember thatbone missed spoofed “CEO request” can bankrupt a client.
Related topics

