How DMARC Prevents Email Spoofing and Phishing Attacks

Learn how DMARC protects your domain from email spoofing and phishing. Understand the authentication flow, BEC prevention, and why p=reject matters.

Last updated: 2026-01-28

Every day, billions of emails are sent with forged "From" addresses. The sender pretends to be someone else -- your company, your CEO, your bank -- and the recipient has no easy way to tell the difference. This is email spoofing, and it is the engine behind phishing attacks, business email compromise, and brand impersonation.

DMARC is the protocol that stops it. When properly configured, DMARC tells receiving mail servers to block messages that falsely claim to come from your domain. This guide explains how email spoofing works, how DMARC prevents it, and what you need to do to protect your domain.

What Is Email Spoofing?

Email spoofing is the act of sending an email with a forged "From" address. The email protocol (SMTP) was designed in the 1980s without built-in authentication. Anyone can connect to a mail server and claim to be sending from any address. The protocol does not verify the claim.

When you receive an email from ceo@yourcompany.com, all you see is that "From" header. You have no way to know whether the message actually originated from your company's mail server or from an attacker's server halfway around the world. The "From" address is just a text field that the sender fills in.

This is not a theoretical vulnerability. It is exploited constantly. The FBI's Internet Crime Complaint Center reports billions of dollars in losses each year from business email compromise alone, and spoofed emails are the primary attack vector.

Without DMARC, your domain can be spoofed by anyone. You will not receive any notification when it happens, and you have no control over what those spoofed messages say or who they target.

How Attackers Exploit Domains Without DMARC

When a domain has no DMARC record, attackers can impersonate it freely. Here are the most common attack patterns:

Business email compromise (BEC). An attacker sends an email that appears to come from a company executive. The message typically asks an employee to wire money, share sensitive data, or update payment details for a vendor. Because the email looks like it came from the CEO or CFO, the employee complies. BEC attacks cost organizations an average of $125,000 per incident according to FBI data.

Customer phishing. An attacker sends emails to your customers that look like they come from your support or billing team. The message might include a fake invoice, a password reset link, or a request to update payment information. The link leads to a credential-harvesting site. Your customers lose money or data, and your brand takes the reputation hit. Ecommerce businesses are especially vulnerable to this attack vector because customers routinely expect order and payment emails from their domains.

Vendor impersonation. If you work with other businesses, an attacker can spoof your domain to send fake invoices or payment instructions to your partners and clients. The recipient sees your domain in the "From" field and trusts the message.

Internal phishing. Attackers spoof your domain to target your own employees. A message appearing to come from HR or IT asking employees to click a link or provide credentials is highly effective when it comes from a trusted internal domain.

All of these attacks rely on the same technique: forging the "From" header. And all of them are preventable with DMARC.

The DMARC Authentication Flow

Understanding how DMARC stops spoofing requires understanding the authentication flow. Here is what happens when a receiving server gets an email claiming to be from your domain:

1

The receiving server checks for a DMARC record

The server queries DNS for a TXT record at _dmarc.yourdomain.com. If no record exists, there is no DMARC policy to enforce, and the message is processed normally -- spoofed or not.

2

It runs SPF and DKIM checks

The server checks whether the message passes SPF (is the sending server authorized?) and DKIM (is the cryptographic signature valid?). These are independent checks that can pass or fail separately.

3

It checks alignment

This is the critical step. DMARC requires that the domain in the passing SPF or DKIM check matches the domain in the "From" header. A spoofed email might pass SPF for the attacker's own domain, but it will not align with your domain in the "From" header. This is how DMARC catches spoofing that SPF and DKIM alone would miss.

4

It applies your policy

If the message fails both SPF alignment and DKIM alignment, the server applies your DMARC policy: none (deliver normally and send a report), quarantine (send to spam), or reject (block entirely).

The alignment requirement in step three is what makes DMARC effective. An attacker cannot pass alignment because they do not control your domain's DNS. They cannot add their server to your SPF record, and they cannot sign messages with your DKIM private key.

Why p=reject Is the Goal

DMARC offers three policy levels, and only p=reject provides full protection against spoofing.

p=none is monitoring mode. Spoofed messages are still delivered. You get reports showing that spoofing is happening, but recipients are not protected. This is a necessary starting point but not a final destination.

p=quarantine sends failing messages to the spam folder. This helps, but spoofed messages are still reachable. A determined recipient might check their spam folder and fall for the phishing attempt.

p=reject blocks failing messages entirely. They are never delivered to the inbox, spam folder, or anywhere else. The spoofed message simply disappears. This is the only policy that fully prevents spoofing.

Getting to p=reject takes time. You need to start at p=none, confirm all your legitimate email sources pass authentication, and gradually increase enforcement. Our policy levels guide explains the process, and our quarantine vs reject comparison breaks down the practical differences between the two enforcement levels. But p=reject should be your goal for every domain you own.

Protecting Parked and Non-Sending Domains

If you own domains that do not send email -- parked domains, redirects, or domains you have registered but are not using -- they still need DMARC protection. In fact, these are among the easiest targets for attackers because they often have no authentication records at all.

For any domain that should never send email, publish this DMARC record:

v=DMARC1; p=reject; sp=reject;

You can skip the reporting tags since there is no legitimate email to monitor. The p=reject policy tells receiving servers to block any email claiming to come from this domain. The sp=reject applies the same policy to all subdomains.

Also publish an SPF record that authorizes no senders:

v=spf1 -all

This two-record combination makes the domain useless for spoofing. Any email claiming to come from it will be rejected.

Audit all your domains

Make a list of every domain your organization owns, including old domains, redirects, and alternate TLDs. Check each one for DMARC records at dmarcrecordchecker.com. Any domain without a DMARC record is a potential spoofing target.

Real-World Impact

The impact of DMARC on spoofing prevention is well documented. Organizations that move to p=reject see spoofed messages from their domain drop to near zero. The messages do not just get flagged -- they are blocked before reaching recipients.

Consider a common scenario. A small e-commerce company notices that customers are receiving fake shipping notification emails from orders@theirstore.com. The emails contain links to a phishing site that harvests credit card numbers. Before DMARC, there is nothing the company can do to stop these spoofed messages. After publishing a DMARC record at p=reject, receiving servers block the spoofed emails. Customers stop receiving them, and the phishing campaign dies.

This applies equally to businesses of all sizes. A five-person agency is just as capable of publishing a DMARC record as a large enterprise. The protocol is free, the tools are available, and the process is the same.

Getting Protected

Protecting your domain from spoofing follows the same path as any DMARC implementation:

  1. Confirm SPF and DKIM are in place for all your legitimate email sources.
  2. Publish a DMARC record starting at p=none with reporting enabled.
  3. Review your reports to confirm legitimate mail is passing and identify any spoofing.
  4. Move to p=quarantine, then p=reject.
  5. Publish p=reject on all non-sending domains immediately.

The entire process takes weeks, not months. And once you reach p=reject, your domain is protected against the most common email-based attack vector in existence.

Monitor Your DMARC Record

You've created your DMARC record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.

Never miss a DMARC issue

Monitor your SPF, DKIM, DMARC and MX records daily. Get alerts when something breaks.

Start Monitoring