What is email spoofing and how can you prevent it?

When email spoofing prevention changes

The right response depends on the evidence you have and whose domain is involved.

For a message you received, inspect the actual sender address and the delivered message's authentication results. A sender can use a legitimate third-party service, and a public DNS record cannot explain what happened to one delivered message. If the message requests money, credentials, a changed payment destination, or an unexpected attachment, verify the request through a known separate contact method before taking action.

For the header-by-header walkthrough and the visible signals that give a forgery away first, see how to spot an email sender spoof.

For a domain you operate, publish and maintain authentication records, then validate real traffic. DMARC protection is incomplete if a legitimate sending service lacks an aligned SPF or DKIM pass. A p=reject policy is also not a universal instruction that every receiver must apply identically. RFC 9989 allows receivers to apply local policy when handling DMARC results.

Use this decision rule:

• If you have a suspicious delivered email, preserve it and inspect its full headers or message source. Check the displayed address, reply address, and authentication results before replying, opening an attachment, or following a link.
• If you have a domain name and need to inspect its published authentication posture, look up the public DMARC record.
• If you administer the domain, validate four layers before treating spoofing controls as working: authoritative and public DNS, the sending vendor's status, a real delivered message from the production path, and DMARC aggregate reports once they accumulate.
• If the sender uses a different but confusingly similar domain, DMARC for your domain cannot authenticate that lookalike domain. Report and block the specific message through your mail provider's process, then investigate the impersonating domain separately.

Do not move a domain to p=quarantine or p=reject until important production senders have been identified and tested. A policy change can affect legitimate mail that still fails DMARC alignment.

A worked authentication result

A delivered message can contain an Authentication-Results header that records a receiver's authentication evaluation. RFC 8601 defines the Authentication-Results header field. The following is illustrative only, not evidence from a real message:

Authentication-Results: receiver.example;
  spf=pass smtp.mailfrom=mailer.yourdomain.com;
  dkim=pass header.d=yourdomain.com;
  dmarc=pass header.from=yourdomain.com

This example indicates that SPF passed for mailer.yourdomain.com, DKIM passed for a signature using yourdomain.com, and DMARC passed for the visible From domain yourdomain.com.

A result such as dmarc=pass is useful evidence for that message at that receiver. It does not prove every future message will pass, that every sender using the domain is authorized, or that the message belongs in the inbox. Inspect the whole message context, including the recipient's known relationship with the sender and the request being made.

What to do next

If you received a suspicious message, use the email client's reporting controls and contact the apparent sender through a known phone number, internal directory, or previously verified address. Do not use reply details supplied by the suspicious message to perform that verification. For context on impersonation that does not always involve a forged domain, read what email impersonation is and how to prevent it.

If you manage the visible From domain, inventory each service that sends mail for it. For each service, verify the vendor's current authentication status, send a test message through the exact production path, and inspect its delivered headers. Then use DMARC aggregate reports to identify sources and authentication or alignment failures over time. Email filtering can add another layer for inbound mail, but it does not replace domain authentication. See how email filtering prevents spam.

Use a public record check when your question is, "What DMARC policy does this domain publish right now?" It is not the right tool for proving the origin of an individual suspicious message.

Common issues when stopping email spoofing

Why is my own legitimate mail failing DMARC?

Almost always an alignment or missing-source problem. A stream can pass SPF or DKIM but use a different domain in the check than the one in the From address, so it fails alignment. Or a sender you forgot, such as a CRM or a payroll tool, was never added to SPF or given a DKIM key. Read the domain's aggregate reports, identify the source, and either authenticate it or route it through an authorized path before moving to p=reject.

Why does SPF keep returning a permerror?

The record exceeds the 10-DNS-lookup limit, or more than one SPF record exists on the domain. Each include, a, and mx mechanism costs a lookup. Consolidate providers, remove unused include entries, or use SPF flattening, and make sure exactly one v=spf1 record exists. The full fix is in How do I fix SPF permerror: too many DNS lookups.

Attackers are spoofing a lookalike domain, not mine. Does DMARC help?

DMARC only protects the exact domain it is published on. A cousin domain like yourdomaìn.com or yourdomain-support.com is a different domain and needs its own defenses: register obvious variants, monitor for new registrations, and pair enforcement with user training. DMARC stops exact-domain spoofing. It cannot police names you do not own. For the full picture, see how lookalike domains bypass DMARC.

I set p=reject and forwarded mail is bouncing. What happened?

Forwarding breaks SPF because the forwarder becomes the sender, and it can break DKIM if the forwarder rewrites the message. If DKIM survives forwarding intact, DMARC still passes through it, which is why DKIM matters so much. Check the headers of a bounced message to see which check failed, and confirm the forwarding path signs or re-signs correctly.

Check the DMARC record behind a spoofing concern

Run the domain that appears in the visible From address through Palisade's checker to inspect its currently published DMARC record and policy tags. Compare the result with the delivered message's authentication results before deciding whether the message is an unauthorized spoof or a separate impersonation attempt.

Check the DMARC record

A public DNS check cannot prove who sent one message, repair an unauthenticated sender, show a receiver's private filtering decision, or monitor later changes to a domain's sending sources.

When an IT team or MSP needs to work through reports across domains, Palisade is AI-first, agent-first DMARC software. It analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step from the evidence, while a human reviews the evidence and applies any change.

Start with Palisade

Palisade does not autonomously change your DMARC policy, prove every future message will authenticate, or control a receiver's final mailbox decision.

For how spoofing extends beyond email (IP and caller-ID variants included) see What is Spoofing? Spoofing Attacks Explained.