Moving DMARC from p=none to p=reject: a staged rollout for small businesses

Does your DMARC policy protect your inbox or your domain?

DMARC confuses people because it works in two directions at once (our guide to what DMARC is covers the basics):

• Your policy (_dmarc.yourdomain) tells other people's mail servers what to do with mail that claims to be from you but fails. Moving to p=reject protects your customers and suppliers from fakes of your domain.
• Your inbound checks decide what happens to mail you receive that fails the sender's DMARC policy. That's done by whatever sits on your MX: Microsoft 365, Google Workspace, or a filtering gateway.

A filtering gateway changes the second job. It doesn't change the first. But it adds two things to get right before you tighten your policy, covered below.

What does it mean to pass DMARC?

Under RFC 9989, a message passes DMARC when SPF or DKIM passes for a domain that aligns with the From address. Relaxed alignment (the default) accepts any domain under the same organizational domain, so mail.example.com aligns with example.com.

Every service that sends mail with your domain in From must achieve this. That includes your mailboxes, but also invoicing tools, website forms, CRMs, newsletters, scanners, and anything that "sends as" you.

How long should each DMARC stage take?

The free DMARC Record Generator builds the record for each stage, with the policy and reporting address you choose.

Stage 2 is optional. Because older receivers ignore t, treat it as real enforcement for some of your recipients.

Step by step

1. Publish monitoring. Add the stage 1 record. Use a mailbox you'll actually read, or a DMARC reporting service. If the rua address is on another domain, that domain must authorize it with a example.com._report._dmarc record. On Microsoft 365, also cover your onmicrosoft.com domain, as described in setting up DMARC in Microsoft 365.

2. Fix your outbound path first. If you send through an outbound relay or smart host (for example, behind a gateway), make sure it DKIM-signs with your domain, and that your SPF lists it if it uses your domain as the envelope sender. Test with a message to a Gmail address and read the headers in our Email Header Analyzer.

3. Read the aggregate reports. Reports arrive daily, usually as zipped XML (RFC 9990). For each sending source, note whether SPF and DKIM passed and aligned.

4. Fix each legitimate failure. Typical fixes:

   • Enable custom DKIM in the sending tool so it signs as d=yourdomain.
   • Add the tool's include to SPF, watching the 10-lookup limit.
   • Move bulk tools to a subdomain with their own SPF and DKIM.
   • Retire tools nobody owns.

5. Recognize forwarding noise. Mail forwarded by mailing lists or personal forwarding rules often fails SPF and sometimes DKIM. Small volumes from unexpected servers that originally came from you are usually this, not an attack.

6. Move to quarantine. Change p=none to p=quarantine. Keep rua. Tell staff to report anything sent that "didn't arrive".

7. Watch for at least a month. New failures usually mean a tool someone forgot. Fix it, don't roll back, unless business mail is badly affected.

8. Move to reject. Change to p=reject. Consider sp=reject for subdomains (it inherits p if you leave it out) and np=reject for subdomains that don't exist.

9. Keep reading reports. New tools get adopted. Each one needs aligned DKIM before it goes live.

How do you read a DMARC aggregate report?

Each report covers a period, usually a day, from one receiver. Inside, each record describes a group of messages from one source IP. A trimmed example:

<record>
  <row>
    <source_ip>203.0.113.40</source_ip>
    <count>212</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers><header_from>example.com</header_from></identifiers>
  <auth_results>
    <dkim><domain>example.com</domain><result>pass</result></dkim>
    <spf><domain>bounce.mailer.example</domain><result>pass</result></spf>
  </auth_results>
</record>

Read it like this:

• 212 messages came from 203.0.113.40 with From example.com.
• DKIM passed for example.com, which aligns, so DMARC passed.
• SPF passed, but for bounce.mailer.example, which doesn't align. That's why policy_evaluated shows spf as fail.
• disposition shows what the receiver did: none, quarantine or reject.

Look up who owns each source IP. Group them by service. Anything you recognize that fails both aligned checks needs fixing before you move on. Anything you don't recognize that fails is probably someone spoofing you, and that's exactly what enforcement will stop.

Raw XML gets tedious quickly. A DMARC reporting service, or a simple script that summarizes reports by source, saves time.

How do you roll back if legitimate mail fails?

Before each step, note the exact record you're replacing and lower its TTL, for example to 300 seconds, a day ahead. If a business-critical sender starts failing after you tighten the policy, you can put the previous record back within minutes. Fix the sender, then try again. Rolling back is a normal part of a staged rollout, not a failure.

What changes behind a filtering gateway?

Inbound: make sure your mailbox platform sees the real sender

When your MX points to a filtering gateway, Microsoft 365 or Google Workspace receives mail from the gateway, not from the original sender. Without extra configuration, they may evaluate SPF against the gateway's IP and get misleading results.

• Microsoft 365: configure an inbound Partner connector for the gateway and enable Enhanced Filtering for Connectors. Microsoft says this preserves the original source IP and lets it use explicit SPF, DKIM and DMARC.
• Google Workspace: add the gateway's addresses as an inbound gateway so Gmail looks past them.

This matters for inbound DMARC checks, not for your own policy. But it's the most common reason people think "DMARC is broken" after adding a gateway.

Outbound: one more sender to align

If your outgoing mail also goes through the gateway's relay, that relay becomes a sender in your DMARC reports. It must sign with your domain's DKIM key. Add it before stage 3.

Gateway-generated mail

Notification mail, such as quarantine digests, may come from the filtering service's domain or from yours. Check a sample's headers. If it uses your domain in From, it must pass DMARC like any other sender.

What about subdomains and parked domains?

Your policy covers subdomains too, unless they publish their own record. Before moving to reject, check subdomains that send mail, such as news.example.com or support.example.com, appear in your reports and pass. If you own extra domains that never send email, such as old brand names or typo-protection domains, publish v=spf1 -all, a Null MX record (MX 0 .) and p=reject on each one straight away. They need no staged rollout because no legitimate mail should ever come from them.

What do Gmail, Yahoo and Microsoft require?

Google (close to 5,000 messages a day) and Yahoo (bulk senders, no published threshold) require bulk senders to publish DMARC, at least p=none, with aligned SPF or DKIM. Microsoft announced similar requirements for high-volume senders to Outlook.com consumer addresses from May 2025. Most small businesses are below these thresholds, but p=none is the floor, not the goal.

How iBlockSpam helps

iBlockSpam filters inbound mail at the MX, with phishing and spoofing protection. Our guided setup covers the Microsoft 365 Partner connector with Enhanced Filtering for Connectors, and the Google Workspace inbound gateway. Our outbound relay DKIM-signs your mail (500 messages per month included). The DMARC Checker validates your record at each stage, and domain monitoring alerts you if your DMARC record changes. Our DMARC monitoring, included with every plan, collects your aggregate reports and tells you when it's safe to tighten your policy.

Next steps

1. Check your current record with the free DMARC Checker.
2. If you don't have one yet, build a p=none record with reporting using the DMARC Record Generator.
3. Load your first aggregate reports into the DMARC Report Analyzer and start your sender list.

Related: DMARC quarantine vs reject explains the last step in detail, and DMARC policy not enabled covers the warning many domains see first.

Browse our other SPF, DKIM and DMARC guides.