From p=none to p=reject Without Losing Your Own Mail

The reason people stall at p=none is not laziness. It is that enforcement has a real failure mode — your invoicing platform stops reaching customers, and you find out from a customer — and there is no obvious signal telling you when it is safe to proceed. That signal exists. It is in the reports almost nobody reads.

What p=none is for, and what it is not

p=none is a monitoring mode. It is the correct place to start and a poor place to stay: a domain sitting at p=none for two years has all of the DNS configuration and none of the protection. ShipReady rates a DMARC policy of none as a low-severity finding rather than a high one, because it is a real gap on a domain whose owner has clearly done most of the work — but it is still a gap.

If DMARC, alignment, and why SPF and DKIM are not enough on their own are still fuzzy, read what each record actually proves first. The rest of this article assumes it.

Step 1: make sure reports are actually arriving

You cannot do this without data, and the rua tag is what produces it. A DMARC record with no reporting address is a policy with no feedback loop — ShipReady reports a DMARC record with no reporting address for that reason.

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

Two practical points. If the reporting address is at a different domain from the one being reported on, that domain has to authorise it with a TXT record at yourdomain.com._report._dmarc.theirdomain.com — otherwise receivers simply do not send the reports, and the symptom is silence rather than an error. ShipReady reports unauthorised external reporting when that record is missing.

And the reports are XML, one per receiving provider per day, gzipped. They are readable but tedious at volume; a DMARC report processor is worth it once you are past the first week. There are free tiers that cover a single domain comfortably.

Step 2: read the reports and build the inventory

An aggregate report is a list of source IPs that sent mail claiming to be your domain, with counts and authentication results. What you are building from it is a list of every legitimate sender — and this is where the surprises are. A typical small SaaS turns out to send from more places than anyone remembers:

• The transactional provider — Resend, Postmark, SendGrid. Almost always already correct, because you set it up deliberately.
• The marketing platform. Set up by a different person, in a different month, often with no DKIM.
• The helpdesk. Zendesk, Front, Help Scout — these send as you, and their alignment setup is a separate step from connecting the mailbox.
• Invoicing and billing. Stripe’s invoice emails, an accounting tool, a dunning service.
• The CRM, sending sequences from a sales address.
• Someone’s personal Gmail configured to "send as" a company address. This one almost never aligns.
• Calendar invites, from a mailbox on a different platform to your main one.

For each source, the report tells you what you need: did SPF pass, did DKIM pass, and — the column that matters — was either of them aligned with the From: domain. A source with an aligned pass is safe to enforce against. A source with passes that are not aligned is the one that will break.

Step 3: fix the sources that do not align

Almost every unaligned sender has the same cause and one of two fixes.

SPF passes but is not aligned

Your provider set the envelope sender to its own bounce domain, so SPF passes for bounces.provider.net rather than for you. The fix is a custom Return-Path — most providers call it a custom bounce domain or a custom MAIL FROM — which is usually a CNAME you add at something like bounce.yourdomain.com. Adding the provider to your SPF record does not fix this on its own, because the problem is which domain SPF was evaluated for, not whether it passed.

DKIM is missing or signs with the wrong domain

The provider signs with d=provider.net, or does not sign at all. The fix is to complete the provider’s domain-authentication flow, which publishes a DKIM key on a selector under your domain so signatures carry d=yourdomain.com. This is the more valuable of the two fixes: DKIM alignment survives forwarding, and SPF alignment does not.

If a source cannot be made to align at all — some legacy tools genuinely cannot — you have a decision to make before enforcing: move it to a subdomain with its own weaker policy, replace it, or accept that its mail will be rejected.

Step 4: quarantine

When the reports show every known source aligned for a week or two, move to p=quarantine. Failing mail goes to spam rather than being refused, so a mistake is recoverable — the message exists, someone can find it.

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com"

Sit here for a week or two and keep reading reports. What you are watching for is a source you did not know about appearing after the change — a quarterly invoice run, a monthly newsletter, an annual renewal notice. Anything that does not send weekly will not have appeared in your first fortnight of data, and this is the phase where it surfaces safely.

On pct=

RFC 7489 §6.3 defines a pct tag that applies the policy to only a percentage of failing messages; the remainder are handled as though the policy were one level weaker. Used deliberately as a short ramp — p=quarantine; pct=25 for a few days — it is a reasonable tool.

Used permanently it is a trap, because a record reading p=reject; pct=10 looks like enforcement in every dashboard and rejects nine tenths of nothing. ShipReady reports partial enforcement when pct is below 100, so a ramp you forgot to finish does not quietly become your permanent posture.

Step 5: reject

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s"

Now failing mail is refused during the SMTP conversation. This is the point at which DMARC is actually doing the job you published it for.

The adkim=s and aspf=s tags tighten alignment from relaxed to strict, requiring an exact domain match rather than an organisational one. Add them only if your reports show every source already matching exactly — many providers legitimately sign with a subdomain, and strict alignment will break those. Relaxed alignment with p=reject is a perfectly good end state.

Do not forget subdomains

Without an sp tag, subdomains inherit the apex policy — which is usually what you want, since mail.yourdomain.com and notifications.yourdomain.com are exactly the names an attacker will reach for.

Setting sp=none on a domain with p=reject is a common and self-defeating move: it protects the apex and leaves every subdomain forgeable. ShipReady reports a subdomain policy weaker than the domain policy because the gap is invisible unless you go looking for it. If one subdomain genuinely needs a weaker policy, give that subdomain its own record at _dmarc.sub.yourdomain.com rather than weakening sp for all of them.

A realistic timeline

Faster is possible if you know your sending surface is small. A domain that sends only through one transactional provider, and no marketing or helpdesk mail, can reasonably go from none to reject in a fortnight. A domain that sends nothing at all can publish p=reject today, and should.

How ShipReady checks this

ShipReady resolves _dmarc for the domain you scan and reads the policy rather than just its presence: a policy of `none`, partial enforcement below 100%, no reporting address, a weaker subdomain policy, more than one record, and a record that is missing or does not parse.

What it cannot do is read your aggregate reports — those arrive at your mailbox, not in DNS — so it will tell you that you are at p=none but not whether it is safe to leave. That part is the inventory work above. Scan your domain free to see where the record stands, and the pre-launch DNS checklist covers the rest of what to confirm.