How to move DMARC from p=none to p=reject

A DMARC record with p=none is where most domains start, and where many of them stay. It is the right first step. It is not protection. This guide takes you from p=none to p=reject in stages, so that forged mail is refused and your own mail keeps arriving.

The examples use example.com. Replace it with your own domain.

What p=none does and does not do

DMARC (RFC 7489) lets a domain owner publish a policy in DNS. It tells receiving mail servers what to do with a message that claims to come from your domain but fails authentication. The record lives at _dmarc.example.com:

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

The p tag has three values:

So p=none does one useful thing: with a rua address, receivers send you aggregate reports about who is sending mail as your domain. That is visibility. It does not stop anyone. A forged invoice from accounts@example.com is delivered exactly as it would be with no DMARC record at all.

Some large mailbox providers now require bulk senders to publish a DMARC record, and p=none meets that requirement (Google's sender guidelines). Meeting a deliverability rule is not the same as preventing spoofing.

How a message passes DMARC

A message passes DMARC when at least one of SPF or DKIM passes and is aligned with the domain in the visible From header.

• SPF (RFC 7208) checks the envelope sender, the address in the MAIL FROM command, also seen as Return-Path. It is aligned when that domain matches the From domain.
• DKIM (RFC 6376) checks a signature. It is aligned when the signing domain, the d= value, matches the From domain.

Alignment is relaxed by default: mail.example.com aligns with example.com because they share an organisational domain. You can make it strict with aspf=s and adkim=s, but relaxed is fine for most organisations.

This is why third-party senders are the usual obstacle. A newsletter platform may pass SPF for its own bounce domain and sign with its own DKIM key. Both checks pass, neither is aligned with example.com, and DMARC fails.

Before you enforce: find every service that sends as your domain

Make a list before you touch the policy. Typical senders:

• your main mailbox provider (Microsoft 365, Google Workspace or your own servers)
• marketing and newsletter platforms
• CRM, support desk and ticketing systems
• invoicing, payroll and HR systems
• website forms, e-commerce and booking systems
• monitoring tools, printers and scanners that send alerts
• agencies or partners sending on your behalf

Ask each owner what the service sends and from which address. Then check the list against the aggregate reports, because the reports will show senders nobody remembered.

For each legitimate sender, aim for DKIM alignment first. DKIM survives forwarding better than SPF does. Most platforms let you publish a DKIM key under your own domain, often as a CNAME to a key they manage:

s1._domainkey.example.com.  3600  IN  CNAME  s1.domainkey.sender.example.

Where the platform supports it, also set a custom bounce (return-path) domain under your domain, so SPF aligns too. Keep one SPF record, and stay within the limit of ten DNS lookups that RFC 7208 sets:

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:spf.sender.example ~all"

Read your aggregate reports

Make sure your record has a rua address, then collect reports for at least a few weeks. Monthly and quarterly senders, such as payroll or annual statements, need a longer window.

If reports go to a mailbox on another domain, that domain must publish a record that accepts them, or receivers will not send them (RFC 7489, section 7.1):

example.com._report._dmarc.reports.example.net.  3600  IN  TXT  "v=DMARC1"

Aggregate reports are XML files, one per receiver per day. A report tool or service that parses them saves a lot of time. For each source IP address, look at:

1. how many messages it sent as your domain
2. whether SPF passed, and whether it was aligned
3. whether DKIM passed, and whether it was aligned
4. the resulting DMARC verdict

Sort what you find into three groups. Your own services that pass: done. Your own services that fail: fix their SPF or DKIM, then wait for clean reports. Sources you do not recognise: that is usually spoofing, which is what enforcement will stop. Investigate before you dismiss any of them.

You are ready for the next step when all your legitimate volume passes with alignment, and what remains failing is either forged or indirect mail you understand (see the breakages below).

Move to p=quarantine, gradually

The pct tag applies the policy to a share of failing mail. RFC 7489 says messages outside that share are treated under the next policy down, so p=quarantine; pct=10 quarantines about one in ten failing messages and treats the rest as p=none.

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.com"

Raise pct in steps, for example 10, 25, 50 and 100, with a week or two of reports between each. Watch for new failing sources and for complaints about missing mail. If something breaks, lower pct or step back to p=none while you fix it. The change takes effect as fast as your DNS TTL allows.

Receivers honour pct with varying precision, and the revision of DMARC being worked on in the IETF (known as DMARCbis) replaces it with a simpler testing flag. Treat pct as a way to limit the blast radius, not an exact dial.

Move to p=reject

Once quarantine at 100% has run cleanly for a few weeks, switch to reject. You can stage this the same way: under p=reject; pct=50, the messages outside the sample are quarantined rather than delivered.

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Keep the rua address. Enforcement is not the end of the work. New services get added, keys get rotated and suppliers change platforms, and the reports are how you notice.

Subdomains: the sp tag

Without an sp tag, subdomains inherit the p policy of the organisational domain. That is usually what you want, because an attacker can spoof billing.example.com just as easily as example.com.

Use sp when subdomains need a different pace. For example, enforce on the main domain while a subdomain used by an older system is still being fixed:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-reports@example.com"

A subdomain can also publish its own record at _dmarc.billing.example.com, which overrides the parent for that name. Once every subdomain is ready, remove sp or set it to reject.

Domains that never send mail should say so. Parked and brand-protection domains are easy to spoof and easy to lock down:

example.org.         3600  IN  TXT  "v=spf1 -all"
_dmarc.example.org.  3600  IN  TXT  "v=DMARC1; p=reject"

Common breakages, and what to do about them

Most problems come from mail that does not travel straight from sender to recipient. RFC 7960 describes them in detail.

• Forwarding. When a mailbox forwards your message, the forwarding server becomes the sender, so SPF fails. An intact DKIM signature still passes and still aligns. This is the main reason to get DKIM aligned for every sender, not only SPF.
• Mailing lists. Lists often add a footer or tag the subject, which breaks the DKIM signature. Many list servers now rewrite the From address to their own domain for this reason. Some receivers use ARC (RFC 8617) to trust the authentication results the list saw, but you cannot rely on it everywhere.
• Third-party senders. A platform that sends with its own bounce domain and its own DKIM key fails DMARC for your domain. Set up DKIM under your domain for it, or move it to a subdomain with its own records.
• Forgotten senders. Devices and old systems that send through an unauthenticated relay show up in reports as failing sources inside your own network. Route them through an authenticated service.
• Too many SPF lookups. Adding includes for every platform can take SPF past ten lookups, and receivers then treat it as an error. Prefer DKIM alignment for smaller senders rather than adding another include.

How TrustSek reports each stage

TrustSek reads the DMARC record you publish in DNS, together with SPF, DKIM keys and the other mail records in the email security module. It does not receive or read your aggregate reports, and a scan is a reading at one point in time.

What a scan shows at each stage:

• No DMARC record. The finding DMARC record missing, in the High severity band.
• p=none. The finding DMARC policy set to none, in the Medium band. It maps to CIS Controls safeguard 9.5 and ISO/IEC 27001:2022 control A.8.9.
• p=quarantine or p=reject. No DMARC policy finding. The scan does not weigh pct, so a quarantine record at pct=10 already clears this finding. Do not treat that as the finish line.

The SPF record is scored on how it ends. A record ending in +all is a High finding, one with no all mechanism at all is Medium, and ~all or -all raise nothing. DKIM keys found by probing common selectors are checked for their size.

This is how the p=none finding appears in a report:

Every finding carries the four fields shown: what was tested, why it matters, the impact and how to fix it. For the scoring model behind the severity bands, see the methodology. Terms such as DMARC, SPF and DKIM are defined in the glossary.

Check your domain's DMARC and the rest of its email security

See the DMARC policy your domain publishes today, alongside SPF, DKIM, MTA-STS and the rest of the outside-in score.

Your domain

Check your domain

Free, no sign-up. Takes about 30 seconds.