Your DMARC record uses p=none, so spoofed mail isn't blocked. Confirm SPF and DKIM are aligned for your senders, then upgrade to p=quarantine or p=reject.
Updated Jul 1, 2026
The short answer
This warning means your domain publishes a DMARC record but its policy is p=none (monitor only) — or no enforcing policy at all — so receivers take no action on mail that fails DMARC, leaving your domain spoofable. Fix it by editing the DMARC TXT record at _dmarc.yourdomain.com to p=quarantine or p=reject, after confirming SPF and DKIM align for your legitimate senders.
This is not an SMTP bounce or a delivery failure — it is a posture/policy warning raised by DMARC checkers, security scanners, and bulk-sender compliance tools. It means your domain has a DMARC record, but the enforcement policy is p=none (monitor only) rather than p=quarantine or p=reject. With p=none, receiving servers report on mail that fails DMARC but take no protective action, so attackers can still spoof your From: domain.
A DMARC record's behavior is set by the p (policy) tag in the TXT record at _dmarc.yourdomain.com. Per RFC 7489 §6.3 there are three values:
p=none — "no specific action"; monitor and collect reports only. This triggers the warning.p=quarantine — receivers treat failing mail as suspicious (typically the spam folder).p=reject — receivers reject failing mail, ideally during the SMTP transaction.The warning fires when the record is p=none, when the p tag is missing, or (less often) when an enforcing root policy is undercut by sp=none for subdomains or pct= set below 100. p=none is a valid starting point — Google and Yahoo's 2024 bulk-sender rules require only p=none as a minimum — but it provides zero anti-spoofing protection, which is why scanners flag it.
Do not jump straight to p=reject. DMARC only passes when at least one mechanism — SPF or DKIM — both authenticates and aligns with the From: domain (RFC 7489 §3.1, §4.2). Enforcing before every legitimate sender aligns will silently quarantine or reject your own mail.
p=none and read your aggregate (RUA) reports. Confirm every legitimate source — your ESP, Courier, CRM, helpdesk, marketing tools — passes SPF or DKIM with alignment._dmarc.yourdomain.com:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.comv=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.comDMARCbis note: In May 2026 the IETF published RFC 9989/9990/9991, obsoleting RFC 7489. They remove the pct= tag entirely (RFC 9989 Appendix A.6) — it is no longer a defined tag, not merely discouraged — so use the staged rollout above instead, and add the np= tag for non-existent-subdomain policy. Existing v=DMARC1 records remain backward compatible, so the fix above is unchanged.
For Courier senders, ensure the From-domain you configure aligns with the DKIM signature your email provider applies before tightening to p=reject.
References
RFC 7489 — DMARC (§3.1 alignment, §4.2 pass, §6.3 tags)
DOCSdmarc.org — IETF Publishes Updated DMARC Specification (RFC 9989/9990/9991, May 2026)
HELPGoogle — Email sender guidelines (bulk sender DMARC requirement)
DOCSdmarcian — Understanding Gmail and Yahoo DMARC Requirements
DOCSCourier — What is DMARC?
FAQ
Yes, as a minimum. Since the February/June 2024 rollout, Gmail and Yahoo require senders of 5,000+ messages/day to publish a DMARC record of at least p=none. But p=none offers no spoofing protection, so both providers recommend advancing to p=quarantine or p=reject.
One API, every provider
Courier connects to your email, SMS, and push providers, handles retries and failover, and surfaces delivery errors in plain language.
Reply-code definitions per RFC 7489 §6.3 (obsoleted by RFC 9989). Last reviewed Jul 1, 2026. Courier is not affiliated with third-party providers; error behavior may vary by implementation.
© 2026 Courier. All rights reserved.