DMARC step by step to p=reject
Move from p=none to quarantine, then reject, when the reports show it is safe: the rules, the “Not mine” button and the alert.
A DMARC policy at p=none only watches. To stop others from sending mail in your name, the policy has to move to p=quarantine (failing mail goes to spam), then p=reject (failing mail is refused). Done too early, a stricter policy also stops your own newsletters or invoices. The DMARC: step by step to p=reject card tells you when each step is safe, from what the reports show.
When the card appears
On the page of a proved domain, from the Solo plan, once DMARC reports are turned on. If the domain has no DMARC record yet, publish one first (the DMARC finding of your report gives one ready to copy): the steps start from monitoring, p=none.
The three stages
| Stage | Policy | What happens to mail that fails DMARC |
|---|---|---|
| Monitoring | p=none |
Delivered as usual; the reports show it. |
| Quarantine | p=quarantine |
Sent to spam. |
| Reject | p=reject |
Refused. |
When the next step is ready
The card says the domain is ready for the next policy when the reports of the large mailbox providers (Google, Microsoft, Yahoo), since the current policy was published, show all of this:
- time: at least 14 days under the current policy, so that every service that sends in your name has had time to show up;
- volume: at least 3 reports and 50 messages;
- success: at least 98% of the messages pass DMARC;
- no failing sender, apart from those you marked as not yours.
Until then, the card lists what holds the step back: the days left, the reports missing, the share of messages that pass, or the senders with failing mail. If no recent report arrived, it says so: check that your record still sends them to us.
A service that sends very little mail may not appear in the reports of the large providers. Check your own list of senders too before moving on.
What to do about each failing sender
Next to each sender with failing mail, the card says who it is and what to do:
- a sending service we know (Google Workspace, Microsoft 365, SendGrid, Mailchimp, Brevo, Amazon SES and about twenty others): its mail was signed or sent in the service’s name, not yours. The card names the service and where, in its settings, to authenticate your domain; it gives you DKIM records to publish;
- your own domain: often mail that was forwarded or went through a mailing list (a few messages are normal), else one of your servers that is missing from SPF and does not sign;
- a bare address: a server that neither signs nor uses a domain. If it is yours (website, application, printer), send through your mail service or add it to SPF;
- a sender we do not know: a service you use, to set up, or someone using your name.
Below the list, the card says about how many of the messages seen would go to spam, or be refused, if the next policy applied today.
Senders that are not yours
A sender you do not recognise is someone using your name, which is exactly what the next step stops. Press Not mine next to it: its failing mail no longer holds the step back. Mine after all puts it back.
Take the step
When the domain is ready, the card shows the record to publish: your current record with the new policy, pct= removed so the policy applies to every message, a weaker subdomain policy (sp=) raised with it, and our report address kept.
- Copy it into your DNS zone, or
- on the Agency plans with a connected DNS provider, apply it in one click. The step is checked again at the moment you apply it, and logged with undo like the other DNS fixes. It is the only way the app ever writes
p=rejectfor you.
The next audit reads the new policy, and the reports follow it from the next day.
The alert
When a domain becomes ready for its next step, an alert goes once to the channels of the Alerts page set to “changes” or “always”. The date also appears in the deadline calendar.
Once at p=reject, the card says so. The reports keep showing who sends in your name.