Rolling out DMARC safely: from p=none to p=reject
DMARC protects your domain against forged senders — if you roll it out properly. The risk-free step plan: collect reports, evaluate them, then tighten.
SPF and DKIM check the technical side — but only DMARC ties both to the sender address the recipient actually sees, and defines what should happen to forgeries. Without DMARC, anyone can send an email with your domain as the sender; with p=reject, exactly that is rejected. The road there is harmless if you take it in stages — and risky if you skip them.
Stage 1: Observe with p=none
The first step changes nothing about delivery yet. With p=none you merely tell recipients: check my emails and send me reports about them. That requires a mailbox that receives the reports — ideally a dedicated address:
_dmarc.beispiel.atv=DMARC1; p=none; rua=mailto:dmarc@beispiel.atStage 2: Read reports for two to four weeks
The reports now list every sender of your domain. The decisive question for each source: legitimate or not? Legitimate sources that fail SPF or DKIM (the newsletter service without DKIM, the invoicing software without an SPF include) are repaired BEFORE you move on. Skipping this phase risks rejecting your own mail.
Stage 3: Tighten — quarantine, then reject
Once the reports are clean, p=quarantine follows (forgeries go to the spam folder), and after further quiet weeks p=reject (forgeries are rejected). If you want to be cautious, tighten gradually via pct — say pct=25 for a quarter of the emails — and then increase it.
_dmarc.beispiel.atv=DMARC1; p=reject; rua=mailto:dmarc@beispiel.atWhy not go straight to p=reject?
Because almost every domain has forgotten senders: the booking tool from three years ago, the office scanner, the web-form mailer of your hosting provider. With an immediate reject, their mail vanishes without a word. The staged approach costs a few weeks of patience and spares you lost invoices and quotes.
Frequently asked questions
What does "alignment" mean in DMARC?
DMARC requires that the domain from SPF or DKIM matches the visible sender address. An email can pass SPF (say, via the sending service's domain) and still fail DMARC if that domain is not yours. That is why good sending services sign with YOUR domain (a separate DKIM key per service).
Do I really have to read the XML reports?
During the observation phase, yes — they are the only view of who is sending in your name. By hand it is tedious (XML inside ZIP files); tools turn them into something readable. After moving to reject, an occasional look is enough.
What about subdomains?
By default the main domain's policy also applies to subdomains, as long as they have no _dmarc record of their own. With sp= you can set a separate rule for subdomains — useful, for instance, when a legacy subdomain is not clean yet.