How Phishing Bypasses DMARC When Attackers Use Legitimate SMTP Servers

When most teams set DMARC to p=reject, they expect that no attacker can send email that appears to come from their domain. In most cases, they are right. But there is an attack scenario that bypasses DMARC even with strict enforcement: the attacker sends phishing from your own legitimate mail servers.

This is not a DMARC misconfiguration. The email passes SPF, DKIM may align, and the From header is perfectly legitimate. p=reject has no effect because the mail is not spoofed in the way DMARC detects.

Understanding this gap matters if you are responsible for email security. Here is how the attack works and what actually reduces the risk.

What DMARC p=reject Actually Stops

DMARC validates that the domain in the From header aligns with the sending infrastructure. Specifically, it checks whether SPF or DKIM passes for a domain that matches the From address. If neither passes alignment, the email fails DMARC.

p=reject tells receivers to reject emails that fail this check. For most spoofing attacks, this works: the attacker is sending from an unauthorized server or forging the From header without proper DKIM signing.

What p=reject cannot do is distinguish between legitimate authorized senders and unauthorized users of that same authorized infrastructure.

How the Attack Works

The attack depends on a gap between SMTP identity and the From header.

In normal SMTP, the MAIL FROM command specifies the bounce address and is validated by SPF. The From header is what the recipient sees. An attacker can control the MAIL FROM to pass SPF checks while keeping a deceptive From header.

But in this attack, the attacker goes further: they compromise or abuse actual access to the legitimate mail infrastructure. This means:

• The MAIL FROM can be set to a legitimate domain that passes SPF
• The From header shows the target domain, exactly as it would in genuine mail
• If DKIM is signed by the legitimate server using the correct domain, DKIM alignment also passes

The result: a phishing email that passes SPF, may pass DKIM alignment, and therefore passes DMARC. The From header looks identical to genuine mail. The receiver has no signal to block it.

This is distinct from classic spoofing. Classic spoofing fails because the sending server is not authorized. This attack succeeds because the sending server is authorized, even though the person using it is not.

Why p=reject Cannot Stop This

DMARC validates authorization, not legitimacy. It answers the question: is this email from an authorized sender for this domain? It cannot answer: is this email from a legitimate user of this domain?

When an attacker has access to the legitimate MTA, both answers are yes from DMARC's perspective. The server is authorized. The From header is aligned. p=reject has done its job correctly; the gap is in what p=reject is designed to detect.

This is not a DMARC failure. It is a scope limitation. DMARC was designed to stop spoofing from unauthorized infrastructure. It was not designed to be an access control system for legitimate servers.

Real-World Scenarios

This attack is not theoretical. It appears in several real-world patterns:

Compromised internal mailboxes. An attacker gains access to an internal mailbox through credential theft. They use the company's own mail server to send phishing to other employees or external contacts. SPF passes because the mail originates from the corporate IP. DKIM may sign with the corporate domain.

Rogue OAuth apps and MTA relaying. An OAuth application with mail.send permissions, or an improperly secured SMTP relay, can be used to send authenticated mail that passes SPF and DKIM alignment. This is particularly common in organizations with many integrated SaaS tools.

Third-party marketing platforms. A compromised account on a bulk email platform (CRM, marketing automation, transactional email service) can be used to send phishing that appears to come from the organization's domain. The platform's servers are often explicitly authorized in the organization's SPF record.

Insider threats. A disgruntled employee with access to the mail system uses legitimate credentials to send malicious mail. No external attack required. DMARC cannot distinguish this from normal authorized sending.

What Actually Catches These Attacks

Since DMARC cannot stop authorized misuse, other layers are required:

Aggregate report anomalies. DMARCFlow monitors aggregate reports for sudden changes in sending infrastructure. A new sending IP appearing in reports, or a spike in volume from an existing IP, can indicate infrastructure misuse before user complaints arrive.

Domain reputation tracking. If a domain's sending reputation suddenly shifts, it may indicate that legitimate infrastructure is being abused for spam or phishing. DMARCFlow tracks these shifts across major receivers.

SPF flattening and least-privilege sending. Restrict SPF records to only the IPs that genuinely send mail. Avoid overly permissive include statements that give third-party platforms blanket authorization.

Mail flow monitoring. Track unusual patterns: internal-to-external forwarding chains, mass BCCing, or mail sent outside business hours from accounts that normally do not send externally.

User reporting workflows. When users receive suspicious mail from what appears to be an internal address, they report it. These reports are a critical signal that automated systems miss.

Multi-factor authentication on mail accounts. Preventing account compromise is the most direct way to stop attackers from accessing legitimate sending infrastructure in the first place.

How DMARCFlow Helps

DMARCFlow aggregate monitoring catches the infrastructure anomalies that SEG-based filters miss. The key signal is not the email itself but the pattern in DMARC reports: a sending IP you do not recognize appearing in your aggregate reports, or a sudden change in the alignment rate for a domain you monitor.

When legitimate infrastructure is being misused to send phishing, the telltale sign in your DMARC reports is inconsistency. One day your aggregate report shows a known sending IP with normal volume. The next day, a new IP appears, or the same IP is sending to entirely different recipient domains at unusual volume.

This is the layer where automated monitoring earns its value. You are not reading DMARC reports manually. You are looking for the specific anomalies that suggest infrastructure misuse, and those anomalies are what DMARCFlow surfaces.

FAQ

Does p=reject stop all phishing from my domain?
No. p=reject stops emails sent from servers that are not authorized for your domain. If an attacker uses your legitimate, authorized mail servers, p=reject has no effect because the mail passes DMARC validation.

Can SPF pass for an attacker?
Yes, if the attacker sends from an IP address that is included in your SPF record. This is why least-privilege SPF records matter: only include IPs that should actually send mail for your domain.

What if my DKIM is signed automatically by the mail server?
If the attacker has access to your mail server and can control what gets DKIM-signed, they can produce correctly aligned DKIM signatures. This is why DKIM rotation monitoring and access controls on signing keys matter.

How do I detect this type of attack?
Monitor DMARC aggregate reports for new sending infrastructure, unexpected volume changes, and alignment anomalies. DMARCFlow is designed to surface exactly these signals. User reports of suspicious internal mail are also a critical detection layer.

Is DMARC useless if p=reject cannot stop this?
No. DMARC aggregate reports are the detection layer, even when enforcement cannot block the mail. The reports tell you that something unusual is happening with your sending infrastructure. Without DMARC monitoring, you may not know until users report the phishing.