Your DMARC Record Is at p=none. That's Not a Security Control.

You have an SPF record. Your DKIM keys are configured. Your vendor told you to set up a DMARC record and you did. The DMARC record says p=none.

p=none means: please observe, collect data, and take no action when messages fail authentication checks. It is a monitoring policy, not an enforcement policy. Email that fails your DMARC check is still delivered. An attacker sending spoofed email from your domain lands in the recipient's inbox just like your legitimate mail.

Having a DMARC record at p=none is not meaningfully different from having no DMARC record at all, from the perspective of someone who wants to impersonate your organization.

A significant portion of organizations with DMARC records are running p=none. They have the record. They are not protected. This is the gap that gets exploited.

Why p=none Exists

p=none is not a mistake. It is a starting point. The intended lifecycle of a DMARC deployment goes from p=none to p=quarantine to p=reject. You start permissive because you cannot reject mail until you are confident you have authorized everything legitimate. p=none lets you observe what is actually sending email on behalf of your domain before you start blocking.

The problem is that organizations park at p=none and treat that as the destination. The monitoring phase extends for months, then years, then indefinitely. The DMARC aggregate reports arrive. Nobody reads them systematically. A new email-sending system gets added without updating SPF or signing with DKIM. The monitoring data accumulates. Nothing moves to enforcement.

The reason is usually a mix of fear and complexity. Moving to enforcement will break something. You just don't know what. And finding out by blocking legitimate email is not a risk most people want to accept on a Tuesday afternoon. So p=none stays.

The SPF Record Problem

SPF authorizes the IP addresses permitted to send mail on behalf of your domain. The record is a DNS TXT entry listing those sources.

There are two common ways SPF records fail in practice.

First, too many includes. SPF has a 10 DNS lookup limit. Every include directive counts toward that limit. Marketing uses Salesforce. Finance uses a payroll platform that sends email. Customer success uses a support ticketing system. Engineering sends notification emails from a SaaS monitoring tool. Each of these is an include. Large organizations routinely exceed the 10-lookup limit, which causes SPF to return permerror on every check. The domain technically has an SPF record. It is not functioning.

Second, the record is wrong. A platform was decommissioned two years ago and nobody removed its IP range from SPF. A new platform was added last quarter by someone who didn't know the domain had a record to update. The SPF record and the actual sending infrastructure have drifted apart. Authenticated mail that shouldn't be authorized passes. Legitimate mail from unknown sources fails.

Either condition means your SPF check isn't working the way you think it is.

DKIM Is Mostly Invisible Until It Breaks

DKIM signs outgoing messages with a private key that recipients verify against a public key published in your DNS. When it works, it is silent. When it breaks, delivery problems are sometimes the first sign.

The failure modes worth knowing: key rotation that doesn't happen (DKIM keys should be rotated periodically and many organizations set them up once and forget them), third-party senders that don't support DKIM signing for custom domains at all, and selectors that get orphaned when a sending service is replaced without cleaning up the old DNS records.

DKIM also does nothing on its own against spoofing the From address. DKIM validates the signing domain, which may be a different domain than what the recipient sees. DMARC is what connects the two: it checks that the domain in the From header aligns with either the SPF-passing domain or the DKIM signing domain. Without DMARC enforcement, DKIM is useful for deliverability but not for spoofing protection.

Getting to Enforcement

Getting to p=reject requires knowing every legitimate source of email from your domain. This is harder than it sounds.

Start by enabling DMARC aggregate reporting and routing those reports somewhere they will actually be reviewed. There are free and paid tools that parse aggregate XML reports into something readable. Run in p=none for 30 to 60 days while you inventory legitimate senders.

Build the inventory. Every marketing platform, CRM, HR system, notification tool, and third-party service that sends email as or from your domain goes on the list. For each one, confirm it is either correctly included in SPF or signing with DKIM aligned to your domain. Anything that fails one or both needs to be fixed before you enforce.

Then move to p=quarantine. Quarantine routes failing messages to spam rather than blocking them outright. This catches problems that aggregate reports missed without the cost of blocking legitimate mail. Keep it there for two to four weeks while watching for reports of missing email.

If quarantine produces no complaints, move to p=reject.

The full process takes two to three months for most organizations with reasonable mail flows. The ones who take years are the ones who never actually work the aggregate data, or who keep discovering new third-party senders because they don't have a process for tracking what sends email on their behalf.

Why This Matters

Business email compromise is one of the most consistently profitable fraud categories in the threat landscape. A meaningful portion of it works by spoofing executive email addresses. The attacker sends a message that appears to come from the CEO's address asking someone to authorize a wire transfer. The address looks correct. It came from an external server, failed DMARC, and was delivered anyway because DMARC was at p=none.

A correctly enforced DMARC policy at p=reject stops this specific attack vector. Not all BEC, because attackers also use look-alike domains and compromised accounts. But spoofing your exact domain at p=reject requires the attacker to use a different approach, which is a better position to be in.

The record is the easy part. Most organizations did that part. The work is the inventory, the report analysis, and the operational commitment to actually move through the enforcement stages. That is the part most organizations have not done.