DMARC Stuck at p=none? How to Reach Reject Without Breaking Email

Someone at your company got an invoice “from the CEO” that the CEO never sent. Or your own quotes started landing in customers’ junk folders. You asked your IT provider about DMARC, and they said it was set up. You check, and the record says p=none. It has said that for two years, and nobody reads the reports.

That situation is extremely common. A DMARC record at p=none only asks receiving mail servers to report on your mail. It does not stop anyone spoofing your domain. Protection starts when the policy reaches quarantine or reject, and getting there safely depends on finding every service that sends email as you. The tool you use to read the reports matters much less than whether someone actually does that work.

What SPF, DKIM and DMARC each do

• SPF lists the servers allowed to send mail for your domain.
• DKIM adds a cryptographic signature proving a message was authorised by a domain and not altered.
• DMARC ties them to the address people actually see in the From line. A message passes DMARC when SPF or DKIM passes and the domain that passed aligns with the From domain. DMARC also tells receivers what to do with failures and where to send reports.

Alignment is the part most setups miss. Your CRM can send mail that passes SPF for the CRM’s own domain and still fail DMARC for yours.

Why this is no longer optional for many senders

Mailbox providers have turned authentication into a delivery requirement. Google requires senders of more than 5,000 messages a day to personal Gmail accounts to use SPF and DKIM, publish a DMARC record (a policy of none is the minimum), and align the From domain with SPF or DKIM. Google also sets a user-reported spam rate threshold, advising senders to stay below 0.1% and never reach 0.3%. Microsoft introduced similar requirements for senders of more than 5,000 messages a day to Outlook.com, Hotmail and Live addresses, with non-compliant mail filtered and then rejected.

Notice what those rules demand: a DMARC record, not enforcement. They improve deliverability. They do not stop impersonation. Stopping impersonation is your job.

The standard itself changed in 2026

In May 2026 the IETF published RFC 9989, the updated DMARC specification, with companion documents for aggregate reporting (RFC 9990) and failure reporting (RFC 9991). It replaces RFC 7489. For most small and mid-sized organisations, three changes matter:

• The pct tag, often used to apply a policy to a percentage of mail during rollout, has been removed from the standard.
• A new t tag signals test mode, which is the new way to ask receivers to apply a softer treatment while you validate.
• A new np tag sets a policy for subdomains that do not exist, which closes a gap attackers used for spoofing made-up subdomains.

Receivers will take time to adopt the new behaviour, so check with your DMARC reporting provider how they are handling the transition before you rely on either tag. If a vendor’s documentation still only mentions RFC 7489, ask them about it.

Getting from p=none to reject without breaking email

Here is a practical sequence for a typical 50-person company. The timings are illustrative, not rules.

1. Publish p=none with a reporting address and send aggregate reports to a service that turns the XML into something readable. Raw reports are not realistic to read by hand.
2. Inventory every sender for two to four weeks. Expect more than you think: Microsoft 365 or Google Workspace, the CRM, marketing email, the helpdesk, invoicing, the website contact form, HR and payroll notifications, the scanner in the office, a sales tool someone signed up for last year.
3. Fix each legitimate sender. Where possible, set up DKIM signing with your own domain in each platform. Add SPF includes only where needed; SPF allows a maximum of ten DNS lookups, and a record crammed with includes will quietly break.
4. Move non-marketing services to subdomains where it helps, so a noisy bulk sender cannot damage the reputation of the domain your staff use.
5. Move to quarantine, watch reports and helpdesk tickets for a few weeks, and fix anything that surfaces.
6. Move to reject. Keep monitoring. New tools get added, and one new unconfigured platform can start failing overnight.
7. Protect domains you do not send from. Parked and unused domains should publish p=reject and an SPF record that allows nothing.

The failure to avoid is jumping to reject on day one. The first sign of trouble is usually a customer saying they never received the invoice.

What MSPs and IT buyers should look for in a DMARC tool

MSPs managing many client domains ask which platform to standardise on. Buyers should ask their provider the same question. The market has plenty of capable options; judge them on these points rather than on dashboards:

• Multi-tenant management with per-client views and permissions, if you are an MSP.
• Sender identification that names the source of mail (for example, “your CRM” rather than an IP address).
• Alerts when a new sender appears or pass rates drop, not just monthly summaries.
• Guidance for enforcement, showing what will fail if you move to quarantine or reject today.
• SPF management that warns about the ten-lookup limit.
• RFC 9989 support and a clear position on pct, t and np.
• Data handling: where report data is stored and for how long, particularly if client data residency matters.
• Pricing that fits your domain and volume profile. Per-domain and per-volume pricing behave very differently across a large client base.

If you are a business buying email security from a provider, one question cuts through: “Which of our domains are at reject today, and when will the rest be?” A vague answer tells you the work has not been done.

What DMARC will not solve

DMARC protects your exact domain. It does not stop lookalike domains such as a swapped letter or a different extension, compromised mailboxes sending real authenticated mail, or impersonation using a free webmail address with your CEO’s name in the display field. Those need monitoring for lookalike registrations, strong account security, and staff who verify payment changes by phone. Payment fraud controls matter as much as DNS records.

Getting your domains to enforcement

Moving a domain to reject is less about buying software than about the patient work of tracking down every sender and fixing it. AB7 Solutions’ cybersecurity team can take that on: auditing SPF, DKIM and DMARC across your domains, identifying and configuring each legitimate sending service, managing the staged move to enforcement, and setting up ongoing monitoring as part of wider email security and managed security services. If your domains are already at reject and correctly configured, we will confirm it and leave it there.

Send us the domains you want checked, and we will tell you where each one stands and what it would take to protect it.

Email: ab@ab7solutions.com | director@ab7solutions.com
Phone: +91 9878067778 | +1 321 341 7733
Website: www.ab7solutions.com

Sources: IETF, RFC 9989 (DMARC); IETF, RFC 7208 (SPF); Google, email sender guidelines; Microsoft, Outlook requirements for high-volume senders.