Email spoofing is when someone sends a message that appears to come from your business domain without being authorized. It can be used for fake invoices, credential theft, or customer scams. The core defense is to make legitimate mail easy for receiving systems to authenticate and to tell those systems what to do with impersonated mail.
Start with the sending inventory
List every service that sends mail using your domain: employee mailboxes, contact forms, CRM tools, newsletter systems, support desks, payment platforms, and agencies. For each, identify an owner and confirm how it authenticates. This inventory is essential because a policy that blocks an unknown sender is good; a policy that blocks an overlooked business sender is costly.
Set up the three controls together
SPF lists authorized sending systems, DKIM cryptographically signs mail, and DMARC evaluates whether those results align with the visible From address. Use the SPF checker guide, DKIM guide, and DMARC guide to validate what is public. DKIM should be enabled in each provider that supports it, not merely in your primary mailbox platform.
Adopt DMARC gradually
Begin with reporting, study legitimate sources, then move to quarantine and reject only when alignment is reliable. The policy sequence is explained in DMARC none, quarantine, and reject. A gradual rollout gives you evidence and time to correct exceptions while steadily reducing an attacker’s ability to impersonate you.
Protect the people around the domain
Use MFA, minimize administrator access, train staff to verify payment-change requests independently, and register obvious lookalike domains if they pose a realistic brand risk. Authentication is a powerful technical boundary; verification procedures protect against the messages that still arrive from compromised third parties or convincing lookalikes.
Run Beacon’s free domain check to review the public authentication signals for your business domain.
Common spoofing gaps
A missing DMARC record, a permissive monitoring-only policy left indefinitely, or an unauthenticated vendor can leave a domain easier to impersonate. Multiple SPF records and an SPF record that exceeds the DNS lookup limit can also make valid mail fail. Review the complete setup whenever you add a sending service rather than treating DNS as a one-time project.
Validate with real messages
Send a fresh test from each important provider to a mailbox where you can view headers. Confirm SPF and DKIM results, then confirm DMARC passes with alignment. A DNS lookup is valuable, but receiver-side results prove whether the message carries the expected identity.
Keep a domain-change record
Document who owns DNS, the purpose of each sending provider, and the date of each change. This reduces accidental removals and makes incident response dramatically faster.
Verify the public controls after changes
After you add a sender or change DNS, wait for the record to publish and test a fresh message from every important platform. Inspect SPF, DKIM, and DMARC results in the receiving mailbox. If results fail, correct the specific source rather than weakening your overall policy. This approach protects genuine mail while steadily reducing an attacker’s ability to impersonate the domain.
Give customers a trusted reporting route
Publish a clear support address or help page for suspicious messages. A customer who can easily verify an invoice or request is less likely to pay a fraudulent one. Preserve reports so you can improve authentication and communication patterns over time.
Keep responsibility clear
Assign an owner for DNS, mail-platform changes, and customer reports. Clear ownership means a potential spoofing issue gets a prompt, evidence-based response rather than an uncertain handoff between teams.