Why does DMARC seem to allow bypasses when SPF uses all:~all or all=*?

You configure SPF with all:~all, expecting it to block unauthorized senders. Yet spoofed emails still arrive in inboxes. Why does DMARC not stop them?

The short answer: DMARC doesn’t block messages on its own. It acts only when SPF or DKIM pass. If SPF misconfigures to allow subdomains or any IP, DMARC respects that result—even if alignment fails. A misaligned pass from SPF, or a permissive all=* record, lets attackers bypass filters that should catch them.

Key takeaways

  • DMARC’s enforcement only applies if SPF or DKIM passes validation—never overrides a passing result.
  • SPF’s all:~all allows subdomain senders to pass even without domain alignment, weakening sender validation.
  • An SPF record with all=* effectively disables SPF filtering, enabling widespread spoofing if DMARC alignment is not enforced.

What does SPF all:~all actually do in a DMARC context?

SPF all:~all tells the receiving server to treat a passing SPF check as a soft fail—meaning the message is allowed to deliver, even if the sending IP isn’t fully authorized. When combined with DMARC, this setting relaxes alignment enforcement, allowing emails from a valid SPF domain to pass DMARC even if the From domain doesn’t match. This weakens email authentication and makes spoofing easier.

How it weakens authentication in practice

Let’s say your company uses spf=include:_spf.google.com but sends from a third-party service like Mailchimp. If you set all:~all in SPF and don’t enforce strict alignment, the email can pass SPF even if Mailchimp’s domain doesn’t match your brand’s From address. DMARC doesn’t block it, because alignment is relaxed. That’s a gap spammers can exploit.

This behavior is a holdover from early SPF implementations, where strict alignment wasn’t widely supported. Today, it’s a known flaw. According to RFC 7208, DMARC alignment is required to ensure sender authenticity. Using all:~all undermines that.

Why DMARC policy=none makes it worse

If you’re running DMARC with policy=none, you’re only monitoring. With all:~all in SPF, you’re effectively allowing any sender that passes SPF—even if misaligned—to bypass authentication checks. This is how attackers can send messages pretending to be your brand, but the DMARC report won’t catch them as malicious.

Even if your DMARC policy eventually moves to quarantine or reject, a all:~all SPF result can still cause a DMARC pass if alignment is weak. That’s because DMARC evaluates alignment *after* SPF, and ~all lets the SPF side pass with a soft fail. If your policy allows soft failures to still pass, you’re not stopping spoofing.

If you’re unsure if your SPF record is using all:~all, validate it with tools like MxToolbox. Or, check real-time sender reputation and alignment integrity using MailTester’s inbox placement test—it shows how your emails appear in real inboxes, including alignment and reputation signals.

How does all=* in SPF enable bypasses under DMARC?

When SPF includes all:*=, it explicitly allows any IP address to send email on behalf of the domain, effectively disabling all IP-based sender validation. Since DMARC checks SPF alignment and sees a "pass" from this overly permissive policy, it treats the message as compliant—even if it comes from a compromised server or malicious source. This creates a critical gap attackers exploit.

Why all=* undermines SPF's core function

SPF exists to verify that a sending IP is authorized to send from a domain. By setting all:*=, you’re saying: “Any IP can claim this domain.” That’s the opposite of authorization—it’s a complete open door.

Once you do this, SPF no longer validates identity. Any attacker who gains access to a mail server, even one outside your infrastructure, can send messages that appear legitimate. DMARC, relying on SPF checks, sees no failure and doesn’t block the message.

How attackers exploit this weakness

Attackers often target domains with lax SPF policies—especially those missing a record or using all:*=. These are easy to spoof because the SPF check passes by design.

Even if the domain doesn’t send from those IPs, DMARC has no way to detect the breach. The message appears to meet all technical requirements. It passes both SPF and DMARC alignment checks, so spam filters don’t flag it. The result? High deliverability for malicious messages.

This is not theoretical. The widespread abuse of lax SPF records has been documented in several industry reports, including findings from the Anti-Phishing Working Group (APWG) and insights from the IETF’s RFC 7208, which outlines DMARC’s intent and limitations. RFC 7208 specifies that DMARC compliance depends on proper SPF alignment—but not on the soundness of the SPF policy itself.

Even worse, some organizations use all:*= unintentionally due to configuration errors or missteps during migration. It’s easy to add this line to bypass temporary delivery issues, but it removes all sender validation permanently.

Let’s be clear: all:*= doesn’t just weaken email security—it eliminates it. You can’t trust deliverability or inbox placement when your SPF policy allows anyone to send on your domain’s behalf.

To prevent bypasses and reduce spoofing risk, use strict SPF policies with whitelisted IPs only. And check your domain’s full email sending setup with a comprehensive verification tool.

Verify individual addresses before sending to catch invalid or risky patterns early. For larger lists, run bulk verification to clean your database and remove domains with suspicious SPF configurations.

What happens when DMARC policy=none and SPF uses all:~all or all=*?

DMARC policy=none means no enforcement — even if SPF passes with all:~all or all=*, messages from any IP can still reach inboxes. This configuration only logs delivery attempts, not blocks. It’s often used for monitoring, but it leaves the domain open to spoofing, as attackers can send emails from any server and exploit the lack of enforcement.

Why SPF alignment doesn’t matter when DMARC is set to none

If your DMARC policy is set to none, the domain’s reputation and sender legitimacy aren’t enforced by receiving servers. Even if SPF evaluates as "neutral" with all:~all or "permits" with all=*, the DMARC check passes — but that pass doesn’t mean anything is blocked.

That’s a key distinction. A "pass" in DMARC logs doesn’t mean the message is safe — it just means the policy didn’t block it. You’re collecting data, not stopping abuse. SPF validation alone doesn’t secure your brand.

Attackers exploit this gap — and you’re vulnerable

When DMARC policy=none, the entire email delivery process becomes a testing ground for bad actors. An attacker can send emails from any IP address, even if it's not in your approved list. If the IP passes SPF (via all:* or all:~all), the message may appear to come from your domain, and most recipients will never know it’s fake.

This creates a major risk for brand impersonation. If your domain has email validation disabled at the policy level, phishing campaigns can use your name, logo, and branding under the illusion of legitimacy. This is especially dangerous if your brand is well-known or your customer base relies on email communication.

Even if SPF is set to all:~all (which is meant to indicate "soft fail" for non-aligned senders), a DMARC policy of none removes all consequences. The receiving server sees a pass, delivers the message, and the reputation of your domain erodes — even if you're doing everything "right" on the technical side.

For context: RFC 7483 [defines DMARC policy=none](https://www.rfc-editor.org/rfc/rfc7483) as a monitoring-only mode. But using it without a clear path to enforcement means you're essentially handing attackers a free pass.

It’s not about how well SPF is configured. It’s about what happens after the check. If your domain doesn’t enforce policy, spoofed messages can still land in inboxes — and that’s where trust breaks down.

Use DMARC with policy=quarantine or policy=reject to ensure alignment. Check your domain posture regularly with tools like [MxToolbox](https://mxtoolbox.com/) or [Spamhaus](https://www.spamhaus.org/). For deeper validation of your sending setup, test actual inbox delivery using inbox placement tests before launching campaigns.

How does alignment affect DMARC evaluation when SPF is lenient?

DMARC evaluates whether the domain in the email’s From header aligns with the domain that passed SPF authentication. Even if SPF uses a permissive policy like all:~all or all=*, alignment can still fail if the authorized sending domain is a subdomain of the From domain—unless relaxed alignment is in use. Relaxed alignment, the default, allows subdomain matches, meaning SPF’s leniency doesn’t necessarily undermine DMARC’s anti-spoofing effectiveness. But strict alignment, which requires an exact domain match, is less forgiving—though rarely used in practice.

Why relaxed alignment matters in real-world SPF configurations

Most organizations set SPF policies to all:~all to allow flexibility in email sources, especially when using third-party services. But this can trigger alignment issues if the sending IP is authorized under a subdomain like mail.example.com instead of example.com. In such cases, without relaxed alignment, DMARC fails even if SPF passes—leading to unnecessary rejections. Fortunately, relaxed alignment, which is the default in DMARC policies, accepts subdomains as valid. This means an email from [email protected] can pass DMARC if SPF auths via mail.mycompany.com, even with a lenient SPF policy.

This alignment behavior is defined in RFC 7073, which clarifies that “relaxed” alignment applies to subdomain relationships and is designed to balance strictness with operational feasibility. It’s why most DMARC reports still show high pass rates despite flexible SPF configurations.

When lenient SPF and relaxed alignment reduce spoofing risk

Let’s be clear: a lenient SPF policy like all:~all isn’t inherently insecure if alignment is enforced correctly. The real security comes from DMARC’s alignment check, not SPF alone. When relaxed alignment is used—standard across 90% of deployed DMARC policies—the system still blocks spoofed emails from domains that don’t align, even when SPF is permissive. That means you can allow a broad range of sending IPs while maintaining anti-spoofing coverage through domain alignment.

However, misconfigurations still happen. If your From domain is example.com but your SPF authorizes mail.sender.example.com, alignment passes—unless strict alignment is enforced. But strict alignment is impractical: it breaks legitimate email flows, especially when using tools like SendGrid or Mailchimp. That’s why relaxed alignment is default—and why SPF alone, no matter how lenient, doesn’t weaken DMARC if alignment is properly evaluated.

To catch these issues early, test your domain’s email authentication setup with an inbox placement tester. Verify your email delivery performance across major providers before sending to real users, especially when using shared or third-party senders.

Why is using all:~all or all=* in SPF dangerous for deliverability and security?

Using all:~all or all=* in your SPF record effectively disables SPF’s ability to block unauthorized senders. This allows any IP address to pass SPF checks, meaning spoofed emails — including phishing attempts and spam — can bypass initial authentication, even if they’re not from your domain. The result? A broken security layer that harms sender reputation and increases inbox placement risk.

SPF loses its gatekeeping function

SPF was designed to specify which IP addresses are allowed to send on your behalf. When you use all:~all, you’re saying “any IP not explicitly listed is a soft fail.” The recipient server treats that as “accept, but mark it as suspicious.” But many servers don’t act on soft fails — they just let the email through. It’s like having a bouncer who says “maybe” to every visitor. The system is no longer protecting you.

Using all=* is even worse. It tells every server: “All IPs are allowed.” This is functionally equivalent to having no SPF record at all. Malicious actors can send from any server, and you won’t know unless someone flags it. According to RFC 7208, SPF is meant to be restrictive, not permissive — and this undermines its core purpose.

DMARC doesn't catch the weakness

DMARC reports can look clean even when SPF is set to ~all or *. That’s because DMARC only applies when SPF or DKIM fails. If SPF is set to ~all, it passes as a soft fail, and DMARC won’t block the message. So even though DMARC reports show “pass,” your domain is still vulnerable to impersonation.

Attackers exploit this gap. They send spam or phishing emails from unauthorized IPs, and since SPF soft-fails, the email gets delivered. That raises your spam score over time — even if you’re not sending it. Reputable providers like Google and Microsoft track sender behavior across IPs, not just your own. If your domain appears in messages from untrusted sources, your reputation takes a hit. Cloudflare notes that weak SPF policies significantly reduce the effectiveness of DMARC enforcement.

Let’s be clear: even if you set DMARC to reject, it won’t stop spoofing when SPF is relaxed. You need strong, precise SPF records to make DMARC work. Otherwise, it’s a paper shield.

If you're unsure whether your records are secure, test your setup with inbox placement testing or verify your sender infrastructure through bulk list verification. A single misconfigured SPF policy can open your entire domain to abuse — and your reputation pays the price.

How to verify if your SPF record configuration enables bypasses

You can verify if your SPF record allows bypasses by testing your sending domains in real time using an email-verification API that checks SPF, DKIM, and DMARC alignment. Look for all:~all or all=* in your SPF records—both signals allow unauthorized senders to pass SPF checks. Use tools like MxToolbox or MailTester’s API to compare domain alignment with actual sender IPs and monitor DMARC reports for unexpected passes from untrusted IP ranges.

Check for weak SPF configurations

  • Review your SPF record for all:~all or all=*—these allow any IP to pass SPF, creating a bypass risk even if DKIM or DMARC are enabled.
  • Run your domain through a tool like MxToolbox’s SPF checker to validate syntax and alignment against known standards.
  • Confirm that only approved IPs, domains, and services (like SendGrid, Mailchimp, or your mail server) are listed in your SPF record.

Validate alignment and monitor reports

  • Use a real-time verification API like MailTester’s Email Verification API to test if your sending domains pass SPF/DKIM/DMARC checks across real mail providers.
  • Compare the IP address used to send mail with the ones listed in your SPF record. A mismatch indicates potential spoofing or misconfiguration.
  • Enable DMARC reporting and review reports from providers like Google or Microsoft to identify unexpected passes from unfamiliar IP ranges.
  • Watch for reports with policy=none or spf=pass when no legitimate sender should be able to send from that IP—these indicate misaligned or weak authentication.

Weak SPF configurations are a common vector for spoofing. Even if DKIM signs messages, a poorly configured SPF can still allow unauthorized senders to bypass authentication. According to RFC 7208, using all:~all should only be done with strict monitoring, and all=* is not recommended at all—it’s essentially a no-op for sender validation.

How MailTester helps detect and prevent deliverability risks from lax SPF configurations

You can prevent deliverability issues caused by weak SPF policies—like all:~all or all=*—by using MailTester to scan your list at scale. It identifies addresses tied to domains with permissive SPF configurations that increase the risk of spoofing, rejection, or spam filtering. Real-time feedback and AI-guided fixes help you harden your sending posture before you send.

How MailTester uncovers risky SPF configurations

  • Use MailTester’s bulk verification to scan tens of thousands of email addresses and flag those associated with domains that allow relaxed SPF policies like all:~all or all=*. These settings are often misused and increase exposure to spoofing.
  • With the real-time API, each address returns a detailed verdict—valid, invalid, catch-all, or risky—highlighting domains whose policies may allow unauthorized senders.
  • Domains using all:~all (soft fail) or all=* (unknown/ambiguous) are flagged as high risk because they don’t enforce sender authenticity, making them more likely to be blocked by receivers that follow strict DMARC policies.
  • MailTester’s AI assistant analyzes SPF, DKIM, and DMARC alignment and interprets configurations that deviate from best practices, such as missing or overly permissive records, and suggests tightening them.
  • Testing inbox placement with MailTester’s inbox tester shows how likely messages will land in the inbox versus spam, revealing whether lax SPF or DMARC setups are dragging down deliverability.

Why lax SPF settings hurt deliverability

SPF, as defined in RFC 7208, governs which servers can send on behalf of a domain. When SPF is set to all:~all or all=*, it allows any server to send, which breaks sender authentication and contradicts DMARC policy enforcement.

DMARC relies on SPF and DKIM alignment. If SPF fails to properly restrict sending sources, DMARC can still pass only if the domain’s policy is set to none—but even then, receivers often mark such messages as suspicious.

MailTester doesn’t assume you know every RFC detail. It surfaces the risks in plain language, so you can act before you send to risky domains. Even if your list has high validity, sending to domains with weak SPF undermines sender reputation and inbox placement.

Even a single weak SPF record can expose your domain to abuse and trigger blocking by receivers that enforce DMARC enforcement.

SPF, DKIM, and DMARC: Their real roles in email security and deliverability

You can’t trust email deliverability or sender reputation without understanding how SPF, DKIM, and DMARC work together. SPF checks if the sending IP is authorized to send on behalf of the domain. DKIM verifies that the message hasn’t been altered and comes from a legitimate sender. DMARC combines both results, using domain alignment to decide whether to pass, quarantine, or reject messages. When alignment fails — for example, if the SPF domain doesn’t match the From domain — DMARC fails, and the email might be blocked regardless of SPF or DKIM passing.

How SPF Works: Authorizing Sending IPs

SPF is a DNS record that lists the IP addresses allowed to send mail for a domain. You add it to your DNS zone, and mail servers check it at send time. If the sending server’s IP isn’t on the list, SPF fails. It’s not about the content — it’s about the server’s authorization. However, SPF alone doesn’t prove message authenticity. It only says, "This IP is allowed to send from this domain." For more complete protection, you need DKIM and DMARC.

DKIM and Message Integrity: Signing the Message

DKIM uses a cryptographic signature attached to each email. The sending server signs the message with a private key, and the receiving server uses a public key (published in DNS) to verify it. This confirms the message wasn’t altered in transit and was truly sent by the domain owner. Unlike SPF, DKIM works across forwarded messages and third-party senders, making it more resilient. But DKIM doesn’t check who sent the email — just that the message is valid.

DMARC is where SPF and DKIM meet. It’s a policy framework that tells receivers what to do when SPF or DKIM fail. You publish a DMARC record in DNS that includes your policy (none, quarantine, or reject), reporting preferences, and, most importantly, alignment requirements. Alignment means the domain in the From header matches either the SPF domain or the DKIM domain. If not, DMARC fails, even if SPF and DKIM pass.

A common misconfiguration is setting SPF with all:~all (soft fail) or all=* (a wildcard that bypasses SPF checks). These don’t bypass DMARC — they weaken it. A ~all soft fail means the sender isn’t officially authorized, but the email might still be accepted. If DMARC policy is set to reject, and alignment fails, the email is blocked. This is why alignment must be enforced.

For detailed validation, especially when setting up or auditing your DMARC policy, test individual addresses with a tool like our email checker to verify SPF and DKIM alignment, or use our inbox placement tester to see how your messages are handled in real inboxes. The IETF RFC 7483 defines DMARC’s role in email authentication. You can also explore how to integrate DMARC monitoring with your existing senders via our integrations.

Best practices to prevent spoofing and enforce deliverability

You reduce spoofing risk and improve inbox placement by avoiding lax SPF policies like all:~all or all=*, using strict DMARC alignment with p=reject, and monitoring reports for unauthorized senders. Regularly validate your SPF and DKIM setup to catch misconfigurations early. Let’s break down the actions that actually work.

Stop over-permissive SPF rules

  • Avoid all:~all in your SPF record. It allows any IP to send on your behalf with a soft fail, meaning spammers can still succeed. Use all:~all only as a fallback after all valid IPs are included.
  • Never use all=* — that’s an open door. It means anyone can send email pretending to be you, even if they don’t have your permission.
  • Specify only trusted IPs or services. If you use SendGrid, Mailchimp, or AWS SES, include their exact IP ranges or use their published SPF mechanisms instead of blanket allow lists.
  • Use tools like MxToolbox or MailTester’s email checker to validate your SPF syntax and detect unintended relaxations.

Enforce DMARC rigorously

  • Set your DMARC policy to p=reject when you have full confidence in your SPF and DKIM. This blocks all forged mail from unauthorized sources.
  • Use align=strict for both SPF and DKIM. This ensures that only emails with exact alignment between the "From" domain and the authenticated domains pass. RFC 7483 defines how strict alignment improves trust.
  • Enable DMARC reporting and analyze reports monthly. Look for spikes in activity from suspicious IPs or unexpected domains. High-volume reports from unknown sources are red flags.
  • Set up monitoring with tools like MailTester’s inbox placement tester to simulate how your emails land across inboxes — this helps detect alignment issues before they affect deliverability.
DMARC with p=reject and align=strict is an industry-standard defense. Without it, you're not just insecure — you're enabling spoofing at scale.
  • Run monthly audits of your SPF, DKIM, and DMARC configurations. Misconfigured records are common and often go unnoticed for months.
  • Use MailTester’s API to automatically verify sender domains in bulk during onboarding or after list cleansing.
  • Stay updated: third-party providers change IPs or remove SPF support. Regular review prevents sudden spikes in bounces or spam complaints.

Final takeaway: DMARC doesn’t protect you if SPF is broken

DMARC is only as strong as the SPF and DKIM records it relies on. If SPF is misconfigured to allow unauthorized senders—via all:~all or all=*—DMARC will still permit those messages, even under a reject policy.

Messages from unauthorized IPs will pass DMARC checks if SPF is permissive. This means your domain can still be used for spoofing, regardless of DMARC’s enforcement level.

Secure email delivery requires three layers:

  • Strict SPF with no overly permissive mechanisms like all:~all or all=*
  • Properly configured DKIM signing on every legitimate sending source
  • Enforceable DMARC policies set to reject or quarantine

Sources

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Can DMARC block spoofed emails if SPF allows all:~all?

No. If SPF passes due to all:~all, DMARC may still allow the message through, especially under relaxed alignment. DMARC only works when SPF and DKIM are properly configured.

What does all=* in SPF mean?

It grants authorization to any IP address to send emails on behalf of the domain, effectively disabling SPF’s filtering function.

Is all:~all a security risk?

Yes. It allows subdomain-based sending to pass SPF checks even if the domain doesn't match, reducing protection against spoofing.

Can a domain have DMARC but still be compromised?

Yes. If SPF is misconfigured with all:~all or all=*, DMARC may not prevent spoofed messages from reaching inboxes.

How do I test if my SPF record is too permissive?

Use a real-time email verification API to test the domain’s policy. Look for any SPF records containing all:~all or all=*.

Does MailTester detect weak SPF configurations?

Yes. MailTester’s API and bulk verification identify email addresses tied to domains with lax SPF policies like all:~all or all=*.

What happens if DMARC policy is set to reject but SPF passes via all=*?

DMARC may still pass if alignment is relaxed, allowing the message through — even if the policy is reject.

Why does my DMARC report show high pass rates from unknown IPs?

This often indicates a weak SPF record with all:~all or all=*, allowing unauthorized senders to pass validation.

How can I fix SPF to prevent bypasses?

Replace all:~all or all=* with specific IP ranges or include only trusted third-party services. Avoid overly permissive records.

Is it safe to use SPF with all:~all during migration?

It may be used temporarily for compliance during migration, but should be replaced with specific IPs or include statements as soon as possible.