# Email address spoofing prevention > Email address spoofing prevention uses aligned SPF or DKIM and a DMARC policy to limit exact-domain spoofing. Learn its limits and checks today. Email address spoofing prevention means making it harder for someone to send mail that uses your domain in the visible `From:` field without authorization. Publish and operate DMARC with aligned SPF or DKIM, then use DMARC reports to find legitimate sources before requesting stronger handling for failures. This controls exact-domain spoofing only. It does not stop lookalike domains, deceptive display names, or mail sent from a genuinely compromised account. ## Quick takeaways - The visible `From:` address is the identity DMARC evaluates. - SPF or DKIM must pass with a domain aligned to the visible `From:` domain for DMARC to pass. - DMARC lets a domain owner request handling for messages that fail that validation. - A receiving mailbox provider makes the final handling decision. - DMARC aggregate reports can reveal sources using a domain, but report delivery is not guaranteed. - A DMARC pass does not prove that a message is safe or that the sender's mailbox was not compromised. ## How email address spoofing prevention works Email address spoofing usually concerns unauthorized use of a domain in the visible `From:` field. [RFC 9989 defines DMARC](https://datatracker.ietf.org/doc/html/rfc9989) around that author domain because SPF and DKIM alone can authenticate domains that are not directly associated with the visible `From:` domain. DMARC connects those systems through identifier alignment. A message passes DMARC when SPF or DKIM passes and the authenticated SPF or DKIM domain aligns with the author domain. With relaxed alignment, related subdomains can align through their shared organizational domain. With strict alignment, the domains must be identical. The domain owner publishes a DMARC DNS TXT record that states a requested handling policy for failures and may request aggregate reports. A receiver can use that policy when deciding how to handle incoming mail, but [the DMARC specification leaves the final decision with the receiving organization](https://datatracker.ietf.org/doc/html/rfc9989#section-1). DMARC is designed to reduce successful exact-domain spoofing. It does not directly address a lookalike domain such as `yourd0main.com`, or a message that uses a trusted display name with a different address. Those are related threats, but they are not the same control problem. See [spoofing versus phishing](/learning/phishing-vs-spoofing-whats-the-difference) for the distinction between impersonating an identity and using that impersonation to obtain information or action. ![Decision flow showing when an email using yourdomain.com in the visible From field can pass DMARC through aligned SPF or DKIM, and when a DMARC policy can request handling for failure](/images/editorial/email-address-spoofing-prevention/email-address-spoofing-prevention-decision-flow.webp "1200x829") *Source: Palisade.* ## When the answer changes The right response depends on what is being impersonated and what evidence you have. If the message uses your exact domain in the visible `From:` field, DMARC is the domain-level control that applies. Start by inventorying real sending systems and confirm that each important mail path has an aligned SPF or DKIM pass. Then use DMARC reports to identify mail sources that still fail and remediate them before moving to a stronger policy. If the message uses a similar domain or only copies a person's display name, DMARC for your domain cannot directly prevent it. [RFC 9989 explicitly limits DMARC's direct protection to specific forms of exact-domain spoofing](https://datatracker.ietf.org/doc/html/rfc9989#section-2.2). If a message came from a legitimate but compromised mailbox, it may authenticate successfully. A DMARC pass validates authorized use of the author domain for that message. It does not make a claim about the message's safety, content, or the account holder's intent. Investigate suspected account compromise through the affected mail system and identity provider. For a recipient, treat an unexpected request for money, credentials, or sensitive information as suspicious even when the sender name looks familiar. [Google's phishing guidance](https://support.google.com/mail/answer/8253?hl=en) advises people to avoid interacting with suspicious requests and verify through an established, independent contact method. ## Worked example: what DMARC can establish This illustrative example shows a message claiming to be from `yourdomain.com`. Do not copy these values into a production configuration. Your sending service generates the real authentication details. ```text From: Billing Authentication-Results: receiver.example; spf=fail smtp.mailfrom=mailer.example; dkim=pass header.d=yourdomain.com; dmarc=pass header.from=yourdomain.com ``` The message can pass DMARC because DKIM passes with `header.d=yourdomain.com`, which aligns with the visible `From:` domain. The failed SPF result does not by itself make DMARC fail when aligned DKIM passes. `Authentication-Results` is a receiver-added field that records authentication assessments. [RFC 8601 defines its syntax and trust model](https://datatracker.ietf.org/doc/html/rfc8601): use the result added by the receiving system you trust, not a similarly named header injected earlier in transit. Use this decision rule: - An exact visible `From:` domain plus an aligned SPF or DKIM pass means DMARC can pass. - An exact visible `From:` domain with no aligned SPF or DKIM pass means DMARC fails when the receiver evaluates DMARC. - A DMARC failure can trigger the domain owner's published request, but it does not prove every receiver rejected the message. - A passing result does not rule out a compromised authorized sender. For the broader protocol controls, read [email security](/learning/email-security). Email-address spoofing is distinct from IP spoofing, which concerns network source addresses rather than the visible identity in an email message. ## What to check next Start with the evidence you actually possess. If you are a domain owner, inspect the public DMARC record for the exact domain used in the visible `From:` field. Then verify each production sending path in four layers: - DNS: query the authoritative DNS service and a public resolver for the intended SPF, DKIM, and DMARC records. - Vendor: confirm that each sending service shows its domain authentication as complete. - Message: send a real message through each production path and inspect the trusted receiver's `Authentication-Results`. - DMARC: review aggregate reports after they accumulate to find sources and alignment failures. Do not move directly to a rejecting policy because a DNS record looks correct. A public lookup cannot prove that an application signs mail, uses the intended return path, or continues to do so after a later configuration change. If you received a suspicious message, preserve it for your security team or report it through your mail provider. Do not reply, open attachments, or use the message's contact details to verify it. If the message appears to come from a known contact, use an existing phone number, chat channel, or address book entry instead. A public [email security score check](/tools/email-security-score) can help you inspect exposed domain controls. It cannot establish the production sending path, a receiver's private filtering decision, or whether a particular message was spoofed. ## Review the broader email security controls Email address spoofing prevention requires more than a published record. Use the [email security guide](/learning/email-security) to place DMARC, SPF, DKIM, user reporting, and account security in the same operating plan. [Review email security controls](/learning/email-security) A guide or public score cannot prove that every sender is aligned, repair a compromised mailbox, or guarantee inbox placement. ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://datatracker.ietf.org/doc/html/rfc8601) - [RFC 5322: Internet Message Format](https://datatracker.ietf.org/doc/html/rfc5322) - [Google: Avoid and report phishing emails](https://support.google.com/mail/answer/8253?hl=en) ## Frequently asked questions ### How can I stop my email address from being spoofed? You cannot prevent every deceptive email that names your organization, but you can limit exact-domain spoofing by deploying DMARC with aligned SPF or DKIM. Inventory legitimate senders first, validate their real mail, review DMARC reports, and then consider a stronger DMARC policy. ### Should I be worried if my email is spoofed? Take it seriously when the message asks for credentials, money, an attachment, or any unusual action, because that is where the harm happens. Do not use the message itself to verify the request. If you own the domain, check whether it used your exact domain, a lookalike domain, or an authorized account that may be compromised. ### How do spoof emails get my address? An attacker only needs to know your address, not to have access to your mailbox. [RFC 5322 defines the `From:` field as part of the message format](https://datatracker.ietf.org/doc/html/rfc5322), so a sender can put any text there. Addresses are usually picked up where they are already visible, such as a website or staff directory, a mailing list, an earlier email thread, or a leaked dataset. A spoofed message does not record where its sender found the address, so you cannot tell from the message alone. ### How do I check if my email is spoofed? Check the visible `From:` domain, then inspect trusted `Authentication-Results` from the receiving system for SPF, DKIM, and DMARC results. For a domain-wide view, review DMARC aggregate reports. Neither a single header nor a public DNS check proves all mail using the domain is legitimate. ### Can SPF alone stop email address spoofing? No, SPF alone cannot stop it, because SPF authenticates the SMTP envelope sender domain, which can differ from the visible `From:` domain a recipient reads. DMARC is the piece that requires an aligned SPF or DKIM pass, which ties the authentication result to the address people actually see.