Back to Learning Center Email Authentication

Does DMARC stop phishing?

By Ian BussieresAugust 11, 20267 min read

Ask AI to explain

In brief

Does DMARC stop phishing? It helps block spoofed email using your exact domain, but it cannot stop lookalikes, compromised accounts, or all phishing.

Yes, DMARC can help stop phishing that spoofs a domain you control, but it does not stop phishing as a whole. DMARC checks whether an email using your visible From domain has an aligned SPF or DKIM pass. When a domain publishes an enforcement policy, receivers can apply that policy to failing impersonation attempts. It cannot control lookalike domains, compromised accounts, or messages sent from domains outside your control.

At a glance

Quick takeaways

DMARC protects against unauthorized use of the exact domain in an email's visible From field.
A DMARC pass requires aligned SPF or DKIM authentication.
p=none requests monitoring and does not request enforcement for DMARC failures.
p=quarantine and p=reject request stronger handling of messages that fail DMARC.
DMARC cannot stop phishing sent from a lookalike domain or a compromised legitimate account.
A passing DMARC result identifies authenticated domain use. It does not establish that a message is safe.

How DMARC limits exact-domain phishing

DMARC is defined in RFC 9989 as a mechanism through which a domain owner publishes a DNS policy for mail that uses its domain in the visible From field. A receiver evaluates the message's SPF and DKIM results, then checks whether at least one passing identifier aligns with that From domain.

That aligned authentication requirement matters in a phishing attempt. An attacker can place billing@yourdomain.com in a message header, but they cannot make the message pass DMARC for yourdomain.com unless they can send through an authorized path with aligned SPF or DKIM.

The DMARC policy applies after DMARC fails:

p=none asks receivers to take no specific enforcement action and can request aggregate reports.
p=quarantine asks receivers to treat failing messages as suspicious.
p=reject asks receivers not to accept failing messages.

The receiver makes the final delivery decision. A published p=reject policy is a strong request, not proof that every mailbox provider will handle every failing message identically.

DMARC therefore helps remove a specific impersonation route: direct spoofing of a domain you own. For broader protocol context, visit the Palisade learning center.

When DMARC does not stop phishing

DMARC does not give a domain owner control over every phishing message that a recipient might receive. The answer changes when the attacker does not need to forge your exact visible From domain.

A lookalike domain, such as yourdomain-support.com, is a separate domain. Your DMARC record does not govern it. The attacker may publish SPF, DKIM, and DMARC records for that separate domain, and those records can authenticate mail for the attacker's domain.

A display-name phishing message can show a familiar name while using an unrelated email address. DMARC evaluates domains and alignment, not whether a display name is misleading.

A compromised account can also send authenticated mail. If an attacker sends through a legitimate account or authorized system, the message may pass authentication because it genuinely came through that domain's approved sending path.

DMARC also does not assess the content, links, attachments, or intent of an email. Those decisions remain with receiving systems and other security controls. For phishing that uses credential capture, phishing-resistant MFA addresses a different part of the risk.

A usable decision rule is:

If the message claims to be from a domain you own and fails aligned SPF and DKIM, DMARC enforcement can help receivers handle that forgery.
If the message uses another domain, a deceptive display name, or a compromised account, your domain's DMARC policy does not control it.

Worked example: what DMARC can evaluate

Consider an attacker who sends a message with From: invoices@yourdomain.com but has no authorized SPF or DKIM identity aligned with yourdomain.com.

Technical exampletext

Visible From domain: yourdomain.com SPF result: fail for an aligned yourdomain.com identity DKIM result: fail for an aligned yourdomain.com identity DMARC result: fail

Published policy example, illustrative only: v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

In this example, the message fails DMARC. A receiver can use the published p=reject request when deciding how to handle it.

Now compare a message sent from yourdomain-support.com. Even if the display name resembles your organization, the visible From domain is not yourdomain.com. Your DMARC policy has no authority over that other domain.

Decision record showing that DMARC can apply to a failed spoof of yourdomain.com but does not govern a separate lookalike domain — Source: Palisade.

Authentication results are normally recorded in the delivered message's Authentication-Results field. RFC 8601 defines that field, including how a receiving system can record authentication methods and results. A public DNS record alone cannot prove what happened to one message, and a delivered-message header alone cannot show every sending source that uses your domain.

What to do next, based on the evidence you have

If you have a domain name and need to know what it currently publishes, use the DMARC checker to inspect the public record and its policy tags. Compare the result with the DNS record your team intended to publish.

If you have a suspicious delivered message, inspect its full headers. Check the visible From domain and the receiver's Authentication-Results field. That evidence can show whether the message passed or failed DMARC for the domain it used.

If you manage the sending domain, validate the result in four layers before treating enforcement as complete:

Check the DMARC TXT record with the authoritative DNS source and a public resolver.
Confirm the sending vendor's current authentication status for the exact production path.
Send a real message through that path and inspect its delivered headers.
Review DMARC aggregate reports after they accumulate to identify sources and alignment failures.

Do not move a production domain to p=reject based only on a DNS lookup. A valid record does not prove that every legitimate sender is aligned.

For a separate social-engineering pattern that targets public replies and support conversations, see what angler phishing is and how to stop it.

Investigate the sending sources behind your DMARC policy

A public lookup can show the DMARC policy currently published for a domain. It cannot identify every production sender that still fails alignment, confirm a receiver's final decision, or monitor later DNS changes.

Palisade is agentic DMARC software that 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 when the evidence supports it, while your team reviews the evidence and applies DNS changes.

Start with Palisade

Palisade does not control lookalike domains, repair every sender automatically, or guarantee that future messages will authenticate or reach an inbox.

For a provider-specific implementation of these authentication checks, see What is quishing (QR code phishing) and how do you stop it?.

Evidence

Sources and further reading

Questions readers ask

Frequently asked questions

Does DMARC stop all phishing emails?

No. DMARC helps stop phishing that forges a domain you own and enforce. It does not stop phishing from lookalike domains, compromised accounts, unrelated domains, or other channels such as SMS and voice.

Does p=none stop domain spoofing?

No. p=none does not request enforcement for DMARC failures. It can support monitoring through aggregate reports, but p=quarantine or p=reject is needed for a domain owner to request stronger handling.

Can phishing emails pass DMARC?

Yes. A phishing message can pass DMARC when it is sent through an authenticated domain controlled by the attacker, or through a compromised legitimate account. DMARC validates domain authentication and alignment, not the honesty of the sender's message.

Does p=reject guarantee that spoofed email is rejected?

No. DMARC lets a domain owner request rejection after a DMARC failure, but receiving systems make their own final handling decisions under their local policies.

Can a DMARC checker prove that phishing is blocked?

No. A public DMARC lookup can show the record currently published in DNS. It cannot prove how a particular mailbox provider handled a message, whether all legitimate sending paths align, or how future mail will be treated.