Why Big Companies Skip DMARC and the Risk They Create

You receive an email that appears to come from a well-known retailer. The email lands in your inbox, passes SPF, passes DKIM. Your DMARC record is properly configured, but the message seems wrong - a different request than you'd expect from this sender.

The SPF and DKIM checks passed because the retailer controls their own mail infrastructure. But they have no DMARC record, which means anyone can send email that appears to come from their domain and passes those same checks.

That gap is not hypothetical. It is a real, documented attack surface that exploited sender non-enforcement to bypass authentication filters in thousands of organizations.

Why big companies skip DMARC

There is no single reason. In practice, large organizations end up at p=none for a combination of the same reasons:

Fear of blocking legitimate mail.

No clear ownership.

Third-party senders they can't control.

Legacy systems that can't be changed.

The result is that a company can be completely trustworthy in its own operations - solid SPF, solid DKIM, active security team - and still leave a gap that attackers exploit.

What that gap actually lets attackers do

DMARC has two policies: `p=none` (do nothing on failure) and `p=reject` (block the message on failure). A company at p=none is telling receivers: "don't trust my domain any more than you already do." A company at p=reject is saying: "anything failing authentication is not from us."

When a major retailer is at p=none, an attacker can craft an email that appears to come from that retailer. The email passes SPF because it was sent from infrastructure the attacker controls - but the SPF record for the retailer's domain lists many IP ranges, some of which the attacker can spoof. The email passes DKIM only if the attacker doesn't try to forge the signature. What matters is that the email looks like it comes from a trusted brand, and the brand's authentication posture doesn't protect recipients from that impersonation.

The attacker spoofs the brand's domain in the From: header. They use a real marketing tool to send through infrastructure that doesn't enforce DMARC for the brand's domain. SPF and DKIM checks pass on receipt because the receiving server sees the connection coming from a legitimate ESP's IP range, not from the attacker's infrastructure. The message lands in the inbox because it looks like a brand email and there is nothing in the authentication results to suggest otherwise.

This is not a theoretical attack. It is the working method behind business email compromise campaigns that impersonate major retailers, logistics providers, and financial institutions.

The asymmetry of non-enforcement

When a large organization skips DMARC, the risk they create is not their own. It is borne by:

- Their customers, who receive spoofed emails that appear to come from the retailer

- Their business partners, who cannot distinguish real retail emails from impersonation attempts

- Any organization that relies on the presence of DMARC enforcement as a signal of sender legitimacy

When a large organization skips DMARC enforcement, the risk does not stay with them. It spreads to:

- Their customers, who receive spoofed emails that appear to come from the retailer

- Their business partners, who cannot distinguish real retail emails from impersonation attempts

- Any organization that relies on DMARC enforcement as a signal of sender legitimacy

This is an asymmetric relationship. The retailer faces no direct consequence from non-enforcement until a spoofing incident becomes public or a business customer demands they fix it. The recipients bear the cost of spoofing campaigns that their own DMARC configuration cannot prevent.

That asymmetry explains why market forces alone don't solve the problem. A retailer that skips DMARC faces no direct consequence until a spoofing incident becomes public or a business customer demands they fix it.

Auditing which big senders are missing DMARC

If your organization receives email from major brands and vendors, you should know which of those senders lack DMARC enforcement. That audit is not a one-time exercise - senders change their DMARC posture over time, and a vendor that was at p=reject six months ago may have dropped to p=none after a system migration.

The practical way to run this audit continuously is to use DMARC reports. Your RUA (aggregate) reports show authentication results for every domain that sends you mail. But parsing those reports at scale across many senders is not something you do manually.

DMARCFlow processes your aggregate reports and maintains a current view of every sending domain's DMARC posture. When a major vendor drops to p=none, you get an alert rather than discovering it after a spoofing incident.

This is the part of the problem that most organizations skip. They know their own DMARC configuration. They don't have a systematic way to monitor the DMARC posture of the companies they receive mail from.

What to do when a key vendor refuses to implement DMARC

Not every vendor will cooperate. Some will say it is not their priority. Others will explain that their infrastructure can't support DKIM signing for customer domains.

When a vendor refuses to implement proper email authentication, you have three options:

Use SPF alignment as a fallback.

Monitor for spoofing from that domain.

Report the gap internally.

The common thread across all three options is that you need visibility. You cannot manage a risk you cannot measure.

How DMARCFlow helps

DMARCFlow monitors the DMARC posture of every domain that sends you email - not just your own. It maintains a live inventory of which vendors are at p=none, which have dropped DKIM signing, and which have changed their authentication configuration recently.

When a major sender changes their DMARC policy, DMARCFlow alerts you immediately. That alert is the difference between discovering a spoofing campaign in your inbox and discovering it in your security team's triage queue.

The core capability is straightforward: you cannot protect your organization from vendor non-enforcement if you don't know which vendors are non-enforcing. DMARCFlow gives you that visibility continuously, without requiring manual report parsing or one-time audits that go stale the moment they're completed.

If you're evaluating email security for your organization, the first question to ask about any vendor relationship is not just "do we have DMARC configured?" It's "do the companies we receive mail from also have it configured?" The answer matters as much as your own setup.

FAQ

If a big company's SPF passes, why does it matter if they have no DMARC?

SPF verifies that the sending server is authorized for the domain in the Envelope-From (Return-Path) header. It does not verify that the From: header domain matches. An attacker can send through an authorized ESP (SPF passes) while putting a major retailer's domain in the From: header. DKIM may or may not be relevant depending on whether the ESP signs for the retailer's domain - but if the retailer's DMARC policy is p=none, the receiving server has no instruction to reject the misaligned message. DMARC closes the alignment check that SPF and DKIM alone leave open.

Can I still get phishing from a domain that has perfect SPF/DKIM but no DMARC?

Yes. If a domain has no DMARC record, or is at p=none, an attacker can send email that appears to come from that domain. SPF and DKIM will pass in many cases because the attacker is sending from infrastructure that the domain's records permit. Without DMARC enforcement, there's nothing to stop the message from reaching your inbox.

What do I do if a key vendor refuses to implement DMARC?

Document the gap as a known risk. Set up monitoring to detect when emails claiming to come from that vendor's domain arrive from unauthorized infrastructure. Use SPF alignment as a fallback where possible. If the vendor is critical enough, escalate the security risk through your vendor management process.

Does DMARC protect me from receiving spoofed email from large companies that don't enforce it?

Only from your side. Your DMARC policy protects your domain - it doesn't protect you when a large company's domain is being spoofed. That's why you need visibility into their DMARC posture, not just your own.