Why p=none Is No Longer a Safe Resting Place
For years, many Amazon SES senders published a DMARC record with p=none, told themselves they were "monitoring," and left it there indefinitely. In 2026, that posture carries real risk. Gmail began its bulk sender enforcement in February 2024 with temporary deferrals, then moved to full enforcement in November 2025, at which point non-compliant mail started receiving permanent 550-series rejections rather than spam-folder placement. Microsoft followed from 5 May 2025, requiring SPF, DKIM, and DMARC for domains sending 5,000 or more messages per day to Outlook.com, Hotmail.com, and Live.com addresses. Yahoo has enforced equivalent requirements since February 2024. Unauthenticated bulk mail is no longer routed to spam as a courtesy; it is refused outright at the SMTP level.
Staying at p=none means your domain remains open to exact-domain spoofing. Attackers can send convincing phishing messages that appear to come from your brand, and the DMARC record you published does nothing to stop them. The policy tells receiving servers to report on failures but to take no action. That gap between monitoring and enforcement is precisely where brand abuse thrives. Moving to p=reject is the only policy that closes it, but doing so without proper preparation will break legitimate mail streams. This guide walks through how to make that journey safely, using Amazon SES-specific signals at every step.
What DMARC Policy Levels Actually Do
A DMARC policy instructs receiving mail servers on how to handle messages that fail DMARC authentication. There are three values. p=none takes no action on failing mail; messages pass through to the inbox while aggregate reports are generated for you to read. p=quarantine tells receivers to treat failing messages with suspicion, which in practice usually means routing them to the spam or junk folder. p=reject instructs receivers to refuse the message entirely, typically during the SMTP conversation, so the message never reaches the recipient's mailbox at all.
The pct tag controls what percentage of failing messages the policy applies to. A record reading p=quarantine; pct=10 means the quarantine instruction applies to only ten per cent of messages that fail DMARC. The remaining ninety per cent are treated as if the policy were p=none. This gives you a graduated dial to turn up as you gain confidence. Note that pct applies only to failing messages. Mail that already passes DMARC is unaffected regardless of the pct value.
One important nuance: receivers are asked to apply your policy on a best-effort basis. Per RFC 7489, a receiver may apply local judgement and override the published instruction. In practice, major providers such as Gmail, Yahoo, and Microsoft follow published policies closely, but your DMARC record is a strong signal rather than an absolute rule.
Why SES Senders Face Unique DMARC Complexity
Amazon SES is rarely the only system sending mail as your domain. A typical SES customer has transactional mail flowing through SES configuration sets, marketing campaigns sent via an integrated CRM such as HubSpot or Salesforce, support tickets sent by a platform such as Zendesk, billing notifications from a payment or subscription tool, and possibly a separate SES sending identity used for a staging or sandbox environment. Each of these systems may use different IP addresses, different MAIL FROM headers, and different DKIM signing configurations.
SES-specific complexity compounds the problem further. SES identities are scoped to an AWS region: if you send from both us-east-1 and eu-west-1, each region requires its own verified identity and its own custom MAIL FROM configuration. Dedicated IP pools used for high-volume or reputation-isolated sending appear in aggregate DMARC reports as distinct IP ranges. Shared IPs, used by default if you have not purchased dedicated IPs, appear under Amazon's shared IP space, which can make attribution harder when reading raw reports.
By default, SES uses amazonses.com as the MAIL FROM domain. This means SPF authenticates against amazonses.com rather than your own domain, which breaks SPF alignment. Unless you have configured a custom MAIL FROM subdomain, your messages can only achieve DMARC compliance through DKIM alignment. That arrangement works, but it leaves SPF alignment as an unresolved gap. Marketing platforms, CRM tools, and ticketing systems often fail DMARC entirely if their DKIM signing or SPF includes are not correctly configured for your domain.
Phase 1: Audit with p=none
Publishing your initial DMARC record
Publish a TXT record at _dmarc.yourdomain.com with p=none and an rua tag pointing to a mailbox you control, for example: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com. The rua tag is the address to which receiving mail servers send aggregate XML reports. Major providers typically send these reports once per day. If you send from multiple domains or use multiple From addresses, set up a dedicated inbox or a DMARC report processing service so that reports do not accumulate unread.
Reading aggregate reports
DMARC aggregate reports are XML files delivered as gzip or zip attachments. Each report covers a period, usually one day, and contains rows identifying the sending IP address, the message count, the SPF result, the DKIM result, and the DMARC disposition. The most important things to look for during the p=none phase are: IP addresses you do not recognise, which may indicate spoofing or a forgotten sending service; known IPs where SPF alignment or DKIM alignment is failing, which indicates a misconfiguration you need to fix; and volume patterns that reveal third-party senders you may not have fully inventoried.
Spend at least 30 days at p=none collecting reports before making any judgement about readiness to advance. The fuller picture you build now directly determines how safely you can tighten policy later. Use this phase to produce a complete inventory of every system sending mail using your domain in the From header.
Ensuring SES-Side Alignment Is Solid First
Before tightening policy, confirm that SES itself passes DMARC on both mechanisms. For DKIM alignment, enable Easy DKIM on your verified domain identity in the SES console. SES generates three CNAME records pointing to rotating 2048-bit keys. Only one key is active at any given time, and SES rotates them automatically approximately every 90 days. Publish all three CNAME records in DNS so that rotation happens without interruption. The DKIM signing domain must match your From header domain at the organisational level for relaxed alignment, which is the default.
For SPF alignment, configure a custom MAIL FROM domain within Amazon SES. Without this, SES uses amazonses.com as the Return-Path domain, which breaks SPF alignment because that domain does not match your From header domain. Choose an unused subdomain such as mail.yourdomain.com or bounce.yourdomain.com, set it as the custom MAIL FROM in the SES console under your verified identity, and publish the MX and SPF TXT records that SES provides for that subdomain. Once DNS propagates and SES validates the records, SPF alignment will be correct.
SES identities are region-scoped. If you operate across multiple AWS regions, configure the custom MAIL FROM on each regional identity separately. Overlooking a region leaves a gap that will surface as SPF alignment failures in your aggregate reports.
With both DKIM and SPF alignment confirmed for SES-originated mail, turn your attention to third-party senders. For each platform identified in your aggregate reports, follow that platform's own documentation to either add a DKIM signing domain that matches your From domain, or add the platform's sending IPs to the SPF record on your custom MAIL FROM subdomain. Do not add them to your apex domain's SPF record unless those IPs also send from your apex MAIL FROM, and be mindful of the ten DNS lookup limit that SPF imposes.
Phase 2: Moving to p=quarantine with a Low pct
Once your aggregate reports show that all identified legitimate senders are consistently passing DMARC, you are ready for the first enforcement step. Update your DMARC record to p=quarantine; pct=10. This is a low-risk starting point: only ten per cent of failing messages are quarantined, and the rest are still treated as p=none. Watch your aggregate reports and your SES sending metrics closely over the following one to two weeks.
The key signals to monitor during quarantine rollout are bounce rate changes, complaint rate changes, and any reports from recipients or internal teams that legitimate mail is disappearing. If a sending source was misconfigured and you missed it during the audit phase, the first sign is often a rise in soft or hard bounces from affected recipients, or a report from a colleague that a password-reset email never arrived. SES configuration sets with event publishing to Amazon SNS or Amazon EventBridge make it straightforward to capture delivery events in near real time, giving you the earliest possible warning before any problem scales.
If everything looks stable after one to two weeks at pct=10, step the value up to pct=50, then to pct=100. Each step should be followed by a monitoring period. There is no requirement to rush. Many organisations spend four to eight weeks stepping through quarantine before moving to reject. The goal is confidence, not speed.
Phase 3: Graduating to p=reject
The pre-reject checklist
Before changing your policy to p=reject, confirm every item on this list. All legitimate sending sources have been identified and are consistently passing DMARC alignment, either through DKIM or SPF. Your aggregate reports show no unexplained failures from IPs associated with your own infrastructure. You have run p=quarantine; pct=100 for at least four weeks without observing any unexpected delivery problems. You have reviewed forwarding scenarios, particularly auto-forwards used by staff members, and understand that SPF alignment will break on forwarded mail regardless of your policy. You have set subdomain policy explicitly using the sp= tag if your subdomains send mail independently. You have confirmed that sandbox or staging SES identities are either using a separate subdomain or are fully authenticated.
What rejection looks like in SES
When a receiving mail server enforces your p=reject policy and refuses a message, the refusal generates an SMTP-level bounce. Amazon SES surfaces this as a bounce event in your configuration set event stream, with a bounce type of Permanent and a reason that reflects the remote server's rejection response. This means that if you inadvertently reject legitimate mail, the failure is visible in your SES bounce and complaint data. Tracking these bounce events continuously after the policy change is essential: a sudden increase in permanent bounces from domains such as gmail.com or outlook.com in the first days after moving to p=reject is a strong signal that a legitimate sender is failing authentication.
Keep the ability to roll back quickly. Your DMARC record's TTL should be set low, ideally 300 to 600 seconds, so that a revert from p=reject to p=quarantine propagates within minutes if you discover a problem.
Common Mistakes SES Senders Make
The most common error is moving to p=reject without spending meaningful time at p=none. Spending fewer than 30 days collecting aggregate reports means you almost certainly have not seen every sending source. New sources emerge as marketing teams add tools, developers integrate new services, and vendors update their sending infrastructure.
Forwarding is a structural edge case that never fully resolves. When a recipient auto-forwards your message to another inbox, the SPF check at the forwarding destination sees the forwarder's IP, not yours, so SPF alignment breaks. DKIM alignment usually survives forwarding as long as the message body is not modified in transit. This is one reason DKIM is considered the more reliable DMARC mechanism for SES senders, and why you should confirm DKIM alignment is solid before enforcing any policy.
Subdomain policy gaps catch many organisations off guard. Without an explicit sp= tag in your DMARC record, subdomains inherit your main domain policy. If your main domain policy is p=reject and a subdomain is used by a service that is not DMARC-compliant, mail from that subdomain will be rejected. Audit subdomain senders during the p=none phase and set sp=none or sp=quarantine for subdomains that are not yet ready for enforcement.
Forgetting SES sandbox or staging domains is another common oversight. If a staging environment sends mail from the same domain as production, it will appear in your aggregate reports and may have different authentication configuration. Either align it fully or move staging sends to a separate subdomain with its own explicit DMARC policy.
Finally, letting pct sit at a low value indefinitely provides false comfort. A record at p=quarantine; pct=5 for six months is not a cautious posture; it means ninety-five per cent of failing mail reaches inboxes unchecked. Use pct as a ramp, not a permanent setting.
Ongoing Maintenance
DMARC enforcement is not a one-time configuration. New sending sources appear as your business adds tools. DKIM keys must be monitored: while SES Easy DKIM rotates keys automatically approximately every 90 days and manages the CNAME records for you, if you use BYODKIM with your own keys, rotation is your responsibility and a lapsed key will cause DKIM failures across all SES-sent mail. SPF records drift as vendors change their sending infrastructure and update the IP ranges behind their include mechanisms. An SPF record that was correct six months ago may no longer authorise all the right servers today.
Review your aggregate DMARC reports at least once a month even after reaching p=reject. New IP addresses appearing in reports and failing DMARC warrant investigation: they may indicate a new legitimate sender that needs authentication configuration, or they may indicate active spoofing of your domain, which is exactly what p=reject is designed to stop.
How SES Monitor Closes the Feedback Loop
The challenge with DMARC policy progression is that the feedback loop from raw aggregate XML reports is slow, arriving once a day at best, and requires parsing and interpretation before you can act. During the critical window when you are stepping up pct values or have just switched to p=reject, you need faster signals.
SES Monitor processes your SES configuration set event stream in real time, surfacing bounce and complaint rate changes as they happen rather than hours later. Because a DMARC rejection at p=reject surfaces as a permanent bounce in SES event data, SES Monitor can alert you within minutes of a pattern emerging, rather than after you have reviewed the following morning's aggregate report. This is the difference between catching a misconfigured third-party sender affecting a few hundred recipients and catching it after it has silently failed for an entire sending campaign.
During the p=quarantine ramp, SES Monitor's complaint rate tracking gives you an independent signal. If a legitimate source begins failing DMARC and messages land in spam folders, recipient complaint rates often rise before the sender or domain owner has any other indication. Watching complaint rate trends by configuration set lets you isolate which stream is affected and address the authentication gap before stepping pct higher.
Treating SES bounce and complaint data as part of your DMARC enforcement workflow, rather than as separate concerns, is what transforms policy progression from a risky DNS change into a controlled, observable operational discipline.
Suggested Timeline and Next Steps
For a typical SES sender with a moderate number of third-party integrations, a realistic timeline from first DMARC record to p=reject runs as follows. Spend 30 to 60 days at p=none collecting aggregate reports, building your sender inventory, and fixing alignment for every identified source. Spend two weeks at p=quarantine; pct=10, then another two weeks at pct=50, then advance to pct=100 and hold for four weeks while monitoring bounce and complaint signals closely. If no problems emerge, update to p=reject with a low TTL, monitor intensely for the first 72 hours, and then settle into a monthly review cadence.
The full journey typically takes three to six months for a well-organised SES sender, and longer if the organisation has many third-party integrations to remediate. Rushing it is the only way to make it painful. A phased approach, backed by real-time delivery signals, makes p=reject an unremarkable destination rather than a gamble.