DMARC Implementation Guide: Why Most Companies Fail Before Enforcement

A phishing email lands in your customer’s inbox. It looks perfect – your domain, your branding, your tone, your formatting, your authority, and even the footer matches your company’s latest corporate identity. The sender? It appears to be your official domain. There is no malware signature for your filters to detect and no compromised account to trace. The attack succeeds because your domain is allowed to be used by anyone, not because your systems were technically breached.

Now the only question that matters: Would your systems stop it?

Most organisations can’t answer that without hesitation. And that hesitation is the vulnerability. Data shows that while many domains have started adopting DMARC, only a small fraction enforce it at a level that actually blocks unauthorised email. Research from our partners at Red Sift, involving the analysis of over 73 million domains, found that just 14.9% have implemented even a basic DMARC policy. Only 2.5% enforce the strictest protection level: p=reject. That means roughly 84% of domains have no visible DMARC record at all, leaving them wide open to impersonation.

The industry continues to repeat the same comfortable lie: that simply publishing a DMARC record equals protection. It does not. A policy set to monitoring observes abuse but does nothing to stop it. This creates a dangerous illusion of security where dashboards look active while attackers continue to use the domain freely. These aren’t obscure technical gaps; they’re open doors.

Understanding the Architecture: SPF, DKIM & DMARC

The architecture behind email authentication is straightforward, yet almost nobody “finishes the job.” SPF (Sender Policy Framework) was launched in 2006 and defines which systems are allowed to send email. DKIM (Domain Keys Identified Mail) arrived in the same year and verifies that messages have not been altered in transit. DMARC (Domain-based Message Authentication, Reporting and Conformance) sits above both and enforces alignment between the authenticated sender and the visible domain.

Together, they form a layered defense that tells receiving mail servers how to verify whether an email genuinely came from who it claims to be. On paper, this is a clean system. In practice, it often breaks under the weight of real-world Google Workspace environments. Organisations no longer send email from a single controlled system; they operate across multiple platforms like CRM tools, HR systems, marketing platforms, and billing providers – each with its own configuration.

The technical model is simple; the operational reality is not. Treating this as a basic DNS exercise guarantees failure during enforcement. An email can pass SPF and DKIM checks and still fail DMARC if the domains do not align correctly. This is where sequencing matters: SPF must include all legitimate senders without exceeding technical limits, and DKIM must be configured for each sending service with proper domain alignment.

Catch Up: Our Community Sessions with Billy McDiarmid

If you are struggling with the transition from monitoring to enforcement, you aren’t alone. At Patronum, we are dedicated to bringing the best expertise to our Google Workspace community. We highly recommend catching up on our previous community session featuring Billy McDiarmid from Red Sift.

In that session, Billy broke down the fundamental reasons why email remains the primary vector for cyberattacks and how DMARC acts as the ultimate shield for your brand’s reputation. It is essential viewing for any Google Workspace admin looking to understand the baseline security requirements of 2026.

We are also thrilled to announce that we will be welcoming Billy back for an upcoming community session in June! We are excited to have him return to dive deeper into the evolving world of sender identity. You won’t want to miss this – join our community and stay tuned for registration details to ensure you can join the conversation live.

Why Email Security Matters More Now Than Ever

The pressure is coming from multiple directions at once, and it’s converging fast. Three key
forces are driving this shift:

• Inbox Provider Mandates: Google and Yahoo introduced DMARC requirements for bulk senders in early 2024. Microsoft followed in 2025. If you send more than 5,000 emails a day, DMARC is no longer optional. It directly affects whether emails reach the inbox.
• Regulatory Frameworks: PCI DSS 4.0.1 now requires organisations handling payment data to implement DMARC at enforcement levels (p=quarantine or p=reject). Non-compliance can result in penalties ranging from $5,000 to $100,000 per month.
• AI-Generated Phishing: Advances in AI have dropped the cost of producing phishing emails significantly. What used to take a skilled attacker 16 hours to craft manually can now be generated in 5 minutes. The volume is climbing, and attackers are impersonating your domain to do it.

The Gap Between Management and Security

At Bespin Labs, we work with organisations every day on Google Workspace management through Patronum. We see the operational side: user provisioning, email signatures, access controls, and offboarding workflows.

What we keep seeing is the same gap: organisations invest heavily in managing their infrastructure but overlook the authentication layer. They have detailed policies for when an employee leaves and automated signatures across thousands of users, but their DMARC policy remains an “open door.” This gap often exists because email authentication falls between IT operations, security, and marketing, with no single team owning the DNS records.

This is why we partner with Red Sift. While Patronum ensures your internal Google Workspace is running perfectly, Red Sift OnDMARC provides the specialised automation needed to classify senders and move you safely to p=reject.

Frequently Asked Questions (FAQs)

1. What is DMARC and how does it work in email authentication?

DMARC is a policy layer that tells receiving mail servers how to handle emails that fail authentication checks. It builds on SPF and DKIM by enforcing alignment between the authenticated domain and the visible “From” address. If an email fails these checks, DMARC instructs the receiver to either monitor, quarantine, or reject it based on the policy set.

2. What is the difference between SPF, DKIM, and DMARC?

SPF defines which servers are allowed to send email for a domain. DKIM uses cryptographic signatures to verify message integrity. DMARC sits above both and enforces alignment while specifying what happens when authentication fails. SPF and DKIM validate signals; DMARC turns those signals into action. 

3. What does p=none vs p=quarantine vs p=reject mean in DMARC?

These are DMARC policy levels.

• p=none: Monitors traffic but takes no action.
• p=quarantine: Sends suspicious emails to spam, requiring manual verification.
• p=reject: Blocks unauthorised emails completely. Only quarantine and reject provide actual protection. “None” is purely observational.

4. How do you implement DMARC step by step without breaking email?

Start with a DNS audit of SPF, DKIM, and existing DMARC records. Map all email senders using DMARC reports. Authenticate and align each sender. Deploy DMARC at p=none for monitoring, analyse reports, fix issues, then gradually move to quarantine and finally reject. The sequence matters more than speed.

5. Why does DMARC implementation sometimes break legitimate emails?

Because it exposes misconfigured or unknown senders. If a service sending email on your behalf is not properly authenticated or aligned, DMARC enforcement will block it. The issue is not DMARC itself but incomplete sender mapping and configuration.

6. What is DMARC alignment and why is it important?

Alignment ensures that the domain used in SPF or DKIM matches the visible “From” domain in the email. Even if SPF or DKIM passes, DMARC fails if alignment is missing. Without alignment, DMARC cannot verify that the email truly represents your domain.

7. How long does it take to fully implement DMARC?

For simple environments, implementation can take a few weeks. For organisations with multiple sending services, it can take several months due to sender discovery, authentication fixes, and phased enforcement. The timeline depends on ecosystem complexity, not just technical setup.

8. Do I need DMARC for compliance like PCI DSS?

Yes. PCI DSS 4.0.1 requires organisations handling payment data to implement DMARC at enforcement levels such as quarantine or reject. Monitoring alone does not meet compliance requirements.

9. What tools can help monitor and manage DMARC effectively?

DMARC management tools provide visibility into sending sources, automate report analysis, and guide policy escalation. Without tooling, organisations must manually parse XML reports, which is operationally intensive and often leads to stalled implementations.

10. Can DMARC completely prevent phishing attacks?

No. DMARC prevents attackers from spoofing your domain, which is a major phishing vector. However, it does not stop attacks using lookalike domains or compromised accounts. It reduces risk significantly but does not eliminate phishing entirely.

Start With What You’ve Got

The barrier to protection is not access; it is action. The protocols are free, and tools exist to assess your current state. Use a tool like Red Sift Investigate to run a real-time check on your domain.

For existing Patronum customers, we’re ready to help you transition your security and visibility to maintain full compliance and control. Speak to our team today to see how Red Sift and Patronum are ready to help you.