DMARC: p=none, quarantine or reject – when to tighten

DMARC does not protect your mail on its own. It is an instruction for the receiving server: what to do with a message that claimed your domain but could not prove it. The three levels of that instruction are p=none, quarantine and reject. They differ only in how ruthless the receiver is supposed to be towards a forgery. The record lives in DNS under the name _dmarc.yourdomain.com, and the p tag sets the policy for the main domain.

What a DMARC policy actually does

The whole mechanism rests on two pillars you have to have in place first: SPF and DKIM. DMARC checks nothing by itself. It takes the results of those two verifications and adds one condition: alignment. The domain in the From header has to match the domain in the Return-Path (for SPF) or the domain in the DKIM signature. A passing SPF on its own means nothing if the envelope goes out from the provider’s domain while your domain sits in the header. If you are starting from zero, work through the step by step SPF, DKIM and DMARC setup first.

And this is where most rollouts fall apart. A company sees a green SPF result in a diagnostic tool, switches the policy to reject, and a week later it turns out that invoices from the accounting system are not arriving. SPF passed. On the provider’s domain.

Remember the order. Without working authentication, tightening the policy improves nothing in deliverability. What it does cut off is your own mail – the mail you send legitimately, from tools you forgot about. And the impersonator will survive it, because they will simply switch domains. You are the one left with undelivered transactional notifications.

Three policies and their real effects

The differences come down to the fate of a message without alignment.

• p=none – observation mode. Mail travels its normal path, filters work as usual, nothing changes. The only effect is reports arriving at the address you point to. A data gathering stage, not protection.
• p=quarantine – a message without alignment lands in spam or in quarantine on the receiver’s side. The sender gets no signal at all. The recipient can find it if they go looking.
• p=reject – the receiving server rejects the message during the SMTP session. The sender gets a bounce with a specific reason. On the receiver’s side the message simply does not exist.

On top of that, two tags that save rollouts. pct lets you cover only part of the traffic with the policy, so you tighten gradually instead of in one jump. sp sets a separate policy for subdomains. The second one gets forgotten constantly, and a subdomain without a rule of its own inherits the main domain policy only as long as you do not point somewhere else – in practice the gap left behind can be a way in for impersonating invoices.yourdomain.com.

In the reports all three policies look similar: you see the IP address, the results and the declared disposition. The difference sits in the recipient’s mailbox, not in the XML.

Before you tighten: take stock of your senders

Every domain sends from more places than anyone in the company remembers. The transactional system, the CRM, the invoicing module, the contact form on the website, sales mailboxes, the bulk sending tool, monitoring, HR. Each of those sources is a separate case to check.

Two things get confused here most often. Return-Path decides SPF, so the envelope address and the From address are two different things – they can point at different domains and usually do. DKIM in turn signs the body and selected headers, which means processing along the way can invalidate the signature: an appended banner, a changed subject, a repackaged message. Forwarding and mailing lists break SPF practically every time, because the envelope sender changes. Only a correct DKIM saves them then.

1. Collect a list of every system sending from your domain. Ask the departments, not just IT.
2. For each one, check the Return-Path and the DKIM signing domain for alignment with From.
3. Set up DKIM everywhere the provider allows it, with your own domain in the selector.
4. Only once that list is closed, touch the p tag.

Tip: start with the sales department mailboxes and the external tools. That is where the signature is missing most often, because the integration was done in a hurry and nobody went back to DNS. While you are at it, write down which integrations with external systems your domain’s mail goes out through.

DMARC reports: how to read them without guessing

The address in the rua tag collects aggregate reports, ruf collects reports with message samples. Do not count on ruf – a fair share of operators do not send them, mainly because of personal data in the content. All the work happens on the aggregate reports.

A single report shows the sender IP address, the number of messages, the SPF result, the DKIM result and whether either of them was aligned. Raw XML is fit for parsing, not for reading. You need an aggregator or your own parser dumping the data into a table.

You are looking for three things. First: your own sending infrastructure without a signature – an application server, a network printer, an old cron script. Second: providers nobody remembered, recognisable by their IP ranges. Third: foreign traffic, meaning actual impersonation of your domain.

From our side it looks like this: with our own fleet of sending servers we check Return-Path consistency, PTR records and the DKIM signature before a client’s first campaign goes out. Routine before the start, not a reaction to a problem. To be honest about a limitation: a built in DMARC report panel is on our roadmap, and for analysis we use an external aggregator today.

When to move to quarantine

There is one entry condition. Across a full sending cycle, no legitimate sender appears in the reports without alignment. A full cycle means: including the monthly and quarterly processes. Not two weeks of observation.

Switch over through pct. Start with part of the traffic, wait, raise it. If something breaks, it breaks on a fraction of the sends, and you have time to react before the wave of tickets.

Watch two sources of signal while you do it, not one. Bounces and statistics are one thing, but the more serious cases come from customer service: “the client did not get the confirmation”, “the reminder never arrived”. An aggregate report shows you the problem with a delay, a person reports it the same day.

Rare sends produce the most surprises. Payment reminders, annual notifications, correspondence from HR systems, yearly surveys. Those processes can speak up once every few months from a server that is on no list at all.

Tip: do not tighten the policy in the week of a big campaign or before a long weekend. There has to be someone around to roll the DNS change back.

When reject makes sense and when it is premature

Reject holds up where the cost of a fake message is higher than the cost of a lost one. Transactional domains, banks, shops, brands exposed to phishing impersonation. If somebody is sending payment demands in your name, quarantine is not enough.

Splitting the traffic simplifies the whole operation. A company domain with controlled sending can go to reject quickly. A domain handling scattered traffic from a dozen or so integrations needs more time. Separate sending domains for marketing and for transactional systems solve that conflict at the source.

Treat parked domains and domains not used for sending differently: reject straight away, plus an empty SPF record. Nothing goes out from there, so there is nothing to break.

Let it go if you do not control DNS, if a key provider does not offer DKIM on your domain, or if your mail goes through discussion lists that do not support ARC. That is not a failure, that is the order of work.

One caveat. Reject does not bypass antispam filters and does not improve sender reputation. It reduces impersonation of your domain, and that is all. You get out of blocks at the big filters with stable infrastructure, sensible warmup of new IP addresses and cleaning dead addresses off the list. The policy tag has nothing to do with it.

DMARC, consent and the law

Authentication and the legal basis for sending are two separate matters, confused surprisingly often. DMARC answers the question “does this message really come from you”. It does not answer the question “are you allowed to send it”.

On the legal side, GDPR and the Electronic Communications Law (PKE) apply. Article 398 PKE requires the recipient’s consent also when the address belongs to a company. The B2B versus B2C distinction does not remove the obligation – what counts is whether the address is assigned to a specific person.

A perfectly configured DMARC does not make sending to a purchased list legal. It will improve your authentication results, not your position in front of the supervisory authority. So when you pick a platform, look at the consent register: whether the system records the moment, the source and the wording of the consent, and whether you can produce it a year later. That is a real feature, not a line in a price list. Check whether the sending platform features cover documenting consent, not just the sending itself.

We build it as one thing: authentication on the infrastructure side and consent records on the application side. If you are looking for a single place for both, see the email marketing platform with its own fleet of sending servers.

Summary: the order that works

The order is simple and there are no shortcuts in it. SPF and DKIM for every sender. Then p=none and a few weeks of reports. Then quarantine with a rising pct. Reject at the end.

Skipping a stage always costs the same thing: transactional mail. Order confirmations, password resets, invoices. The things whose absence the customer notices before your monitoring does.

Set sp together with p so subdomains are not left as an open door. And treat DMARC as a process, not a one off DNS record – a new tool in the company means a new sender to check.

A checklist for the coming week:

1. Check whether _dmarc.yourdomain.com exists at all and what policy it has.
2. Add an address in the rua tag if there is none. Without reports you are working on instinct.
3. Write down every system sending from your domain, department by department.
4. For each one, verify DKIM with your own domain in the selector.
5. Set sp to the same level as p.
6. Schedule a report review at a fixed time, for example once a month.