How Phishers Bypass SPF and DKIM: Attack Techniques Explained

If you have spent any time configuring email authentication, you probably feel a certain confidence. SPF is set, DKIM is signing, DMARC is enforcing. Your domain is locked down. Nobody can spoof you.

That confidence is misplaced.

Attackers do not need to break SPF or DKIM. They need to work around them. And over the past several years, they have gotten remarkably good at it. The techniques in this article are not theoretical. They are in active use, showing up in phishing campaigns every single day. Understanding them is the first step toward defending against them.

If you are still getting up to speed on the basics, start with our complete guide to SPF, DKIM, and DMARC before diving in here.

1. Cousin Domains: The Art of Looking Close Enough

This is the oldest trick in the phishing playbook, and it still works better than it should. Instead of spoofing your actual domain, an attacker registers a domain that looks nearly identical.

Think paypa1.com instead of paypal.com. Or arnazon.com instead of amazon.com. Or micros0ft.com instead of microsoft.com. The attacker registers the cousin domain legitimately, sets up proper SPF and DKIM records for it, and starts sending. Every authentication check passes because the email genuinely comes from the domain it claims to come from. The deception is in the domain name itself, not the authentication layer.

The sophistication has increased over time. Attackers now register domains like paypal-security-notice.com or microsoft365-admin.com that pass casual inspection. They add SSL certificates, build landing pages that mirror the target brand, and sometimes even set up MX records to receive replies.

The Defense

DMARC cannot help here because the attacker is not spoofing your domain. Defense relies on domain monitoring services that watch for newly registered domains similar to your brand, browser and email client warning systems, user education, and threat intelligence feeds. Organizations with high phishing exposure should actively monitor certificate transparency logs for cousin domain registrations.

2. Subdomain Delegation Attacks

This is more subtle and significantly more dangerous. Many large organizations have SPF records that include third-party services. Over time, some of those services get decommissioned, but the DNS records remain. An attacker who finds a dangling include can exploit it.

Here is how it works. Suppose bigcorp.com has this SPF record:

v=spf1 include:mail.bigcorp.com include:thirdparty.example.com ~all

If thirdparty.example.com no longer exists or its domain expires, an attacker can register it, set up an SPF record that authorizes their own mail servers, and now they can send email that passes SPF for bigcorp.com.

The same principle applies to CNAME records used for DKIM. If a company pointed a DKIM selector at a third-party domain via CNAME and that third party is no longer in use, an attacker who gains control of the target domain now controls the DKIM signing for that selector.

This is not hypothetical. Researchers have found dangling DNS delegations in SPF records of Fortune 500 companies. The attack surface is enormous because most organizations never audit their DNS records after initial setup.

The Defense

Regular DNS audits are essential. Review SPF includes quarterly. Remove any reference to services you no longer use. Keep DKIM selectors tight and rotate them. Tools exist to scan for dangling DNS records, and any serious security team should be running them regularly.

3. Overly Broad SPF Includes

This is less of an attack technique and more of a self-inflicted wound, but attackers exploit it ruthlessly. Consider this SPF record:

v=spf1 include:_spf.google.com ~all

This tells the world that anyone authorized to send mail through Google Workspace infrastructure can send mail as your domain. That sounds reasonable until you realize that millions of organizations use Google Workspace. Any one of them, including any attacker who signs up for a free trial, can now send email that passes SPF for your domain.

The same problem exists with other large providers. Including a shared sending infrastructure in your SPF means every other customer of that infrastructure is implicitly authorized to pass SPF checks for your domain. Attackers know this and specifically target domains with broad includes.

The attack is straightforward. They sign up for the same email service, configure their sending to use that shared infrastructure, and fire away. SPF passes. If the target domain does not enforce strict DMARC, the email lands in the inbox.

The Defense

Use dedicated IP addresses for sending rather than shared pools when possible. If you must use shared infrastructure, ensure DMARC is set to p=reject with proper DKIM alignment, because an attacker can pass SPF through the shared infrastructure but cannot forge your DKIM signature. DKIM alignment becomes your real line of defense in this scenario.

4. DKIM Replay Attacks

This is one of the more elegant attacks in the phishing arsenal, and it is surprisingly underappreciated by defenders.

DKIM signs the body and certain headers of an email. Once signed, that signature remains valid regardless of where the email travels. An attacker exploits this by first receiving a legitimate, DKIM-signed email from the target organization. This could be a marketing email, a password reset, a notification, or anything with a valid DKIM signature.

The attacker then takes that signed email and replays it to new recipients. They modify the envelope (the SMTP-level routing information) but leave the signed headers and body intact. The DKIM signature still verifies because the signed content has not changed. If the receiving server checks DKIM but does not strictly validate the envelope-to-header alignment, the replayed email passes authentication.

In more advanced variants, the attacker triggers a specific email from the target service (like a password reset to an account they control), captures it, then replays it at scale to thousands of recipients. The email is pixel-perfect because it is the actual email from the real service.

The Defense

DMARC with strict alignment helps because the envelope sender must match the header From domain. Including recipient-specific headers in the DKIM signature (like the To: header) also helps, though many DKIM configurations omit these. Some advanced email security systems track DKIM signatures and flag replays by checking whether the same signature is appearing across many different recipients in a short time window. Rate limiting and anomaly detection are your friends here.

5. Display Name Spoofing

Sometimes the simplest attacks are the most effective. Email clients show the display name prominently and often hide the actual email address behind it. An attacker sends from "PayPal Security" <random@attacker.com>. On a mobile device, most users only see "PayPal Security" and never bother to check the actual address.

This bypasses SPF, DKIM, and DMARC entirely because the attacker is not claiming to send from paypal.com at the protocol level. They are sending from their own domain with their own valid authentication. The deception is purely in the display name, which is a free-form text field with zero authentication requirements.

A targeted variant of this is devastating in corporate environments. The attacker sets the display name to match the CEO or CFO name and sends to employees from a random Gmail address. On mobile email clients, employees see their boss's name and react with urgency. This is the foundation of most Business Email Compromise (BEC) attacks, which account for billions of dollars in losses annually.

The Defense

Email clients need to do better at exposing the actual sender address, but you cannot control end-user software. On the organizational side, implement policies that flag external emails with display names matching internal executives. Many secure email gateways and spam filters offer this feature. User training remains critical: teach people to verify the actual email address, especially on mobile devices. For a deeper dive into spotting these fakes, see our guide on how to spot phishing emails in 2026.

6. Unicode and Homoglyph Attacks

Unicode introduced a problem that email security has never fully solved. Many characters from different scripts look identical to Latin characters. The Cyrillic "a" (U+0430) is visually indistinguishable from the Latin "a" (U+0061) in most fonts. The same applies to dozens of other characters across Greek, Cyrillic, Armenian, and other scripts.

An attacker registers a domain using these lookalike characters. To the human eye, the domain appears exactly like the target domain. In the DNS system, it is encoded as Punycode (a string starting with xn-- followed by ASCII-encoded characters), making it a completely separate domain. The attacker sets up full email authentication for this Punycode domain, and every authentication check passes with flying colors.

Modern browsers have largely addressed homoglyph attacks in URLs by displaying the Punycode representation when mixed scripts are detected. Email clients have been significantly slower to adopt similar protections, and many still render unicode domain names in their visual form, making the attack invisible to users.

The Defense

IDN (Internationalized Domain Name) homoglyph detection is available in some email security tools and should be enabled wherever possible. DMARC helps if the target organization has a strict policy, because the attacker is technically using a different domain. But the real defense is security tooling that can flag domains with mixed-script characters or known homoglyph substitution patterns before they reach the user.

7. Null MX and Misconfiguration Exploitation

Some domains are configured with a null MX record (a single MX pointing to ".") to indicate they do not accept or send email. Attackers have found that many mail servers do not properly handle null MX records and may still accept email claiming to come from these domains. If the domain also lacks a DMARC record, which is common for domains not intended for email use, there is no policy to enforce against spoofed messages.

A related technique exploits domains that have an SPF record ending in ?all (neutral) or no SPF record at all. Without SPF and without DMARC, there is nothing to fail. The attacker spoofs these domains freely because the receiving server has no authentication policy to evaluate against.

Attackers maintain curated lists of high-value domains with weak or missing authentication policies. Government agencies, educational institutions, healthcare organizations, and older enterprise domains are frequent targets because their DNS configurations tend to be outdated, incomplete, or managed by teams that do not prioritize email security.

The Defense

If you own a domain, even one not used for email, publish a DMARC record with p=reject, an SPF record with -all, and a null MX. This trio tells the world that no legitimate email should ever come from your domain. On the receiving side, implement DMARC checking and configure your filters to treat the absence of authentication records as a risk signal rather than a neutral condition.

The Bigger Picture

What connects all of these techniques is a fundamental truth about email security: authentication protocols were designed to verify that an email comes from the domain it claims to come from. They were never designed to verify that the sender is who they claim to be. That gap between domain authentication and human identity verification is where every phishing attack lives.

SPF, DKIM, and DMARC are necessary but not sufficient. They raise the bar significantly, and they stop the most basic, automated forms of domain spoofing. But a determined attacker with a five-dollar domain registration and thirty minutes of setup time can bypass all three without breaking a sweat.

Real defense requires layered security: authentication as the foundation, reputation systems and threat intelligence on top, behavioral analysis and content inspection above that, and informed, skeptical users as the final layer. No single technology solves phishing. Anyone who tells you otherwise is either naive or selling something.

The attackers know your defenses inside and out. Make sure you understand their offense just as well.