How to move DMARC from p=none to p=reject without losing real email

The three records, in one paragraph each

SPF lists the servers allowed to send email for your domain. It is checked against the envelope sender, the hidden return address, not the From line people see.

DKIM adds a cryptographic signature to each message. The receiving server checks it against a public key in your DNS. If the message was changed in transit, or not signed with your key, the check fails.

DMARC ties the two to the visible From domain. A message passes DMARC when SPF or DKIM passes and the domain that passed matches the From domain. This is called alignment. DMARC also tells receivers what to do with failures and where to send reports.

Step 1: Publish DMARC in monitoring mode

Start with a policy that changes nothing about delivery but turns on reporting:

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1"

• p=none asks receivers to deliver as normal.
• rua is where receivers send daily aggregate reports. Use a mailbox or a DMARC reporting service, because the reports are XML files that are hard to read by hand.
• fo=1 asks for failure details when either SPF or DKIM fails. Few receivers send these, but it costs nothing.

If the report address is on a different domain from the one being protected, that domain must publish a record authorising it to receive the reports.

Step 2: Inventory every sender

Give the reports one to two weeks, then list every source sending as your domain. Typical findings in a small business:

• Microsoft 365 or Google Workspace
• A CRM or marketing platform
• Invoicing, accounting or payroll software
• A helpdesk or ticketing system
• Website contact forms and the web server itself
• Scanners, printers or line-of-business apps relaying through your mail server
• Sources you do not recognise. Some are forwarding, and some are spoofing.

For each legitimate source, decide whether it should keep sending as your main domain or move to a subdomain such as mail.example.com or billing.example.com. Subdomains keep bulk and transactional mail from affecting the reputation of your staff mailboxes.

Step 3: Fix SPF without breaking the lookup limit

You can only have one SPF record per domain, and it can trigger at most 10 DNS lookups during evaluation. Every include:, a, mx and redirect counts, including the ones nested inside the includes. Exceed it and SPF returns a permanent error, which DMARC treats as a fail.

example.com  TXT  "v=spf1 include:spf.protection.outlook.com include:_spf.crm-provider.example -all"

• Remove includes for services you no longer use.
• Move high-volume senders to their own subdomain with their own SPF record.
• Avoid ptr and +all.
• Once DKIM covers every sender, the choice between ~all and -all matters less, because DMARC makes the decision.

Step 4: Turn on DKIM for each service

DKIM survives forwarding better than SPF, so it should carry DMARC for every service that supports it. In Microsoft 365, enable DKIM signing for the domain in the Defender portal after publishing the two CNAME records it gives you. In Google Workspace, generate the key in the Admin console and publish the TXT record. Most CRM and marketing tools have a domain authentication page that gives you the records.

• Use 2048-bit keys where the service allows it.
• Check in the headers of a test message that the signing domain, d=, is your domain and not the provider's.
• Rotate keys when staff with DNS access leave or a provider changes.

Step 5: Read the reports until real mail passes

You are ready to enforce when, over at least two weeks, every legitimate source shows DMARC passing through aligned DKIM, aligned SPF or both. What is left failing should be:

• Spoofing from servers that have nothing to do with you, which is what enforcement will block
• Forwarded mail and mailing lists, which often break SPF and sometimes DKIM. Major receivers use ARC to accept forwarded mail that passed authentication originally.

Step 6: Raise the policy in stages

The pct tag applies the policy to a share of failing messages. It is widely supported under the current standard, but a coming revision of DMARC replaces it, so treat it as a short-term ramp rather than a setting to keep.

At each stage, check the reports and ask staff whether any expected email has gone missing. Do not move on while a legitimate source is still failing.

Step 7: Cover subdomains and parked domains

By default, subdomains inherit the policy of the main domain. Use sp= if you need a different policy for them during the rollout. Domains you own but do not send email from should be locked down completely:

parked-example.com         TXT  "v=spf1 -all"
_dmarc.parked-example.com  TXT  "v=DMARC1; p=reject"

Why this is no longer optional

Google and Yahoo have required SPF, DKIM and DMARC from senders of more than 5,000 messages a day since February 2024. Microsoft applied similar requirements to high-volume senders to Outlook.com consumer addresses from May 2025, and rejects non-compliant mail. Even below those volumes, authenticated mail is treated better by spam filters, and an enforced policy is the only DNS setting that stops criminals sending invoices in your name.

A realistic timeline

For a business with Microsoft 365 and two or three other services: one to two weeks of monitoring, one to two weeks of fixes, then four weeks of staged enforcement. Six to eight weeks in total, with no lost email if the steps are followed in order.