DMARC p=none Is Not Protection: Your Domain Is Still Spoofable

One of your suppliers gets an email from your accounts team. Your domain, your signature block, your usual tone, and a polite note that the banking details have changed. They pay the invoice. The money is gone within the hour.

Nothing was hacked. Nobody clicked anything. No password was stolen. The attacker simply wrote your domain in the From field, and your own DNS quietly told the receiving mail server to deliver it anyway.

That instruction has a name: p=none. It is the monitoring setting in a DMARC record, and it is where the large majority of business domains have been parked since Google and Yahoo forced the issue in early 2024. Publishing it feels like progress. It gets you past the bulk sender checks. It also blocks exactly zero forged messages.

This post covers what p=none actually does, what it costs you to stay there, why the usual objection (that enforcement will break your email) is mostly avoidable, and the phased path to a policy that genuinely stops impersonation.

What p=none actually tells the world

Three DNS records work together to prove an email really came from you. They are worth understanding in plain language, because the difference between them is where most of the confusion lives.

• SPF (Sender Policy Framework): the guest list. It names the mail servers allowed to send on your behalf. Anything sending from an address that is not on the list fails.
• DKIM (DomainKeys Identified Mail): the tamper-proof seal. Your mail server signs each message with a private key, and the receiver checks the signature against a public key in your DNS. If the message was altered in transit, the seal breaks.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): the standing instruction to the receiving mailroom. It says what to do with a message that fails those checks, and asks for a daily report of everything sent using your name.

That instruction is the p= value, and it has three settings. With p=quarantine, failing mail goes to junk. With p=reject, failing mail is refused at the door and never reaches the recipient. With p=none, the receiving server takes no action at all. It delivers the forgery to the inbox and sends you a report about it afterwards.

💡  A DMARC record is public. It lives at _dmarc.yourdomain.com and anyone in the world can read it in about two seconds, including someone deciding which Calgary business is easiest to impersonate this week.

How 'we have DMARC' became a false sense of security

In February 2024, Google and Yahoo began requiring a DMARC record from high-volume senders. Microsoft followed on 5 May 2025, applying the same bar to anyone sending 5,000 or more messages a day to Outlook.com, Hotmail and Live addresses, with a hard 550 5.7.515 rejection for mail that does not comply.

Here is the detail that created the problem. All three providers set the minimum at p=none. A monitoring-only record satisfies the requirement. So a very large number of domains got a DMARC record published in a hurry by whoever was closest to the DNS panel, the deliverability warnings stopped, and the project was marked complete.

The record was published to protect email delivery, not to protect the domain. Those are two different tests, and passing the first one tells you nothing about the second.

⚠️  If your DMARC record was created in 2024 to fix a Gmail or Outlook delivery problem, there is a good chance it is still sitting at p=none today and nobody has read a single report since.

What staying at p=none actually costs you

Your domain becomes free infrastructure for fraud

Business email compromise is the most expensive single incident type a Canadian small business is likely to face, and a spoofable domain makes it easy. The Canadian Anti-Fraud Centre recorded $704 million in reported fraud losses across Canada in 2025, the highest annual figure on record, with spear phishing and business email compromise approaching $68 million of that total. The CAFC estimates only 5 to 10 percent of fraud is ever reported, so the real number is several times higher.

The pattern is consistent: a message that appears to come from a supplier, an executive or a payroll contact, asking to update EFT details before the next run. When the From address is genuinely your domain rather than a lookalike, the request clears every mental check the recipient has.

You wear the damage even when you did nothing wrong

A client who is defrauded by an email carrying your domain does not distinguish between your systems being breached and your domain being borrowed. The invoice looked like yours. The follow-up conversation is the same either way, and so is the effect on the relationship.

Delivery quietly erodes

Mailbox providers score sender behaviour continuously. A domain that has sat on monitoring mode for two years while spoofed mail flows through it is a weaker signal than one at enforcement. That shows up as legitimate mail landing in junk, and it usually shows up first on the messages you care most about: quotes, invoices and onboarding emails.

Insurers, auditors and procurement teams have started asking

Cyber insurance renewal questionnaires now ask about email authentication alongside multi-factor authentication and backups. Vendor security reviews and SOC 2 evidence requests are heading the same direction. Answering 'we have a DMARC record' when the policy is p=none is an answer that will not age well, and an inaccurate attestation on a renewal form is its own problem.

🚨  An attacker can query your DMARC policy in seconds, without touching your network. A domain sitting at p=none is a published signal that impersonation will work. Attackers check, and they pick accordingly.

The real objection: will enforcement break our email?

This is the right thing to worry about, and it is the honest reason most domains never move. Skipping straight to p=reject on a Friday afternoon is how an organization discovers that its invoicing platform has been sending as the company domain, unsigned, for six years.

The risk is almost never your Microsoft 365 or Google Workspace mailboxes. Those authenticate correctly out of the box. The risk is the collection of systems nobody thinks of as email systems, quietly sending as you:

• Marketing and CRM platforms such as HubSpot or Mailchimp
• Accounting and invoicing tools that email statements to customers
• Payroll platforms sending deposit notices to staff
• Booking, scheduling and appointment reminder tools
• E-signature and proposal software
• Applicant tracking systems and HR portals
• The website contact form, and any transactional mail from your site
• The multifunction printer in the corner that emails scans to staff
• An external bookkeeper or agency sending on your behalf

⚠️  SPF allows a maximum of 10 DNS lookups. Every new platform that asks you to 'just add one more include' pushes you toward that ceiling, and once you cross it SPF fails silently for every message you send. This is the single most common cause of a broken enforcement rollout.

The fix is sequencing, not courage. You find every legitimate sender first, get each one signing correctly with your domain, and only then tighten the policy. Done in that order, enforcement is uneventful.

The path from p=none to p=reject

📋  The sequence below typically runs six to ten weeks for a small business with a normal set of tools, and longer for organizations with many marketing platforms or business units.

1. Turn on reporting. Add an rua address to the DMARC record so aggregate reports start arriving, and point them somewhere that parses the XML into something readable. Without this data, every later decision is guesswork.
2. Build the sender inventory. Spend four weeks reading reports and list every system sending as your domain. Expect two or three surprises. There are almost always more senders than anyone remembers.
3. Fix alignment for each legitimate sender. Enable custom domain authentication in every third-party platform so their messages are DKIM-signed with your domain, and rebuild SPF to stay under the lookup limit.
4. Move to quarantine, gradually. Set p=quarantine with a percentage rollout: 25 percent, then 50, then 100, watching reports at each step. Nothing is lost at this stage, only diverted to junk where it can be recovered.
5. Move to reject. Once quarantine has run clean at 100 percent, switch to p=reject and add sp=reject so subdomains inherit the policy rather than becoming the soft target.
6. Lock down the domains you never send from. Parked domains, old business names and defensive registrations should each carry a reject policy and a null SPF record. Unused domains are the ones attackers reach for first.
7. Keep watching. Reports still matter after enforcement. A new marketing platform added next quarter will fail authentication on day one, and you want to know before the campaign goes out.

✅  A percentage rollout on quarantine is the safety net that makes this a non-event. It lets you test enforcement on a slice of your mail volume while the rest is delivered normally.

Why enforcement should be table stakes for any managed IT provider

An IT provider that manages your Microsoft 365 tenant has secured the mailbox: multi-factor authentication, conditional access, phishing filtering, alerting. All of that protects mail coming in and accounts being taken over. None of it protects your name in someone else's inbox. That job belongs to DNS, and it is the one piece routinely left at the default.

The gap is not technical difficulty. It is ownership. DMARC lives in DNS, DNS often sits with a web developer or a domain registrar login from 2014, and the reports arrive as XML that nobody has a tool to read. So it stays where it is. Meanwhile the federal government requires at least a quarantine policy on its own domains, and the Canadian Centre for Cyber Security's implementation guidance (ITSP.40.065) is explicit that only a reject policy delivers complete protection.

At Always Beyond, DMARC enforcement is part of the standard security baseline rather than a separate project. We take ownership of the DNS records, run the sender discovery, fix alignment across every platform in your stack, walk the policy up to reject, and review the reports at your regular technology review. It is deployed as a fleet-wide standard, which means it gets measured and it does not quietly drift back to a default.

💡  The Canadian federal government mandates SPF, DKIM and DMARC on its own email services. Only 9.2 percent of Canadian domains overall have reached full reject enforcement, which is a large gap between what the public sector considers baseline and what most private businesses have in place.

What finished looks like

If you want to check where your organization stands, this is the standard we hold client domains to:

Frequently asked questions

Isn't p=none good enough for Google, Yahoo and Microsoft?

Yes, and that is the trap. All three accept a monitoring policy as the minimum for their bulk sender rules, so p=none keeps your mail flowing. It does not stop a single forged message. Meeting a deliverability requirement and being protected against impersonation are separate goals, and only one of them is covered.

How long does it take to reach p=reject?

For a business with a straightforward stack, six to ten weeks is typical, and most of that is the four-week reporting window needed to find every legitimate sender. Organizations with several marketing platforms, multiple brands or acquired domains take longer, mainly because the sender inventory is larger.

Will enforcement stop someone registering a lookalike domain?

No, and it is important to be clear about that. DMARC protects domains you own. A message from a-lwaysbeyond.com is a different domain and passes its own checks. That threat is handled separately, through domain monitoring, defensive registrations, external sender warnings in Microsoft 365, and staff training. Enforcement removes the easier attack so that the harder one is all that is left.

We're a small team. Are we really a target?

Domain spoofing is not targeted in the way people picture it. Attackers scan for domains with weak or absent policies and work from the list. A 12-person firm with an unprotected domain and a supplier relationship worth six figures is a better prospect than a large enterprise at full enforcement.

Does DMARC protect us from phishing coming in?

Only indirectly. DMARC governs mail sent using your domain, which does stop the internal impersonation trick where a staff member appears to email a colleague. Inbound protection is a different layer: filtering, external sender labelling, multi-factor authentication and payment verification procedures. Both layers are needed.

Who should own this, us or our IT provider?

Your IT provider, with your sign-off on the sender inventory. The work sits in DNS and across every platform that sends mail on your behalf, and it needs someone reading the reports monthly afterwards. If your provider has never raised DMARC with you, that is a fair question to ask at your next review.

‍

Not sure what your domain is currently telling the world? Always Beyond checks your DMARC, SPF and DKIM posture, finds every system sending as you, and takes the policy to full enforcement without interrupting the mail you depend on. It is part of the security baseline we deploy and monitor across every client domain. Reach out to start the conversation.