DMARC p=reject: how to set up your DMARC policy without losing legitimate email

A DMARC record with p=reject asks receiving mail servers to refuse any message that uses your domain in the From address but fails authentication. For a business that sends invoices, rent reminders or bank details by email, DMARC p=reject is the setting that stops a fraudster from sending messages that display your exact address.

Getting there takes method: publish reject too early and your own invoicing tool or newsletter can start bouncing. This guide shows how to set up DMARC following RFC 9989, the current DMARC standard (it replaced RFC 7489 in May 2026), from observation to rejection without breaking legitimate mail. The examples use the fictional domain dupont-immo.fr.

SPF, DKIM and DMARC: what each one checks

SPF: which servers may send for a domain

SPF (RFC 7208) is a TXT record on the domain that lists the servers allowed to send its mail. The receiver checks it against the envelope sender (the Return-Path address used during the SMTP exchange), not against the From address your recipient sees. Here, spf.example.com stands for your mail provider's SPF domain:

dupont-immo.fr.  TXT  "v=spf1 include:spf.example.com ip4:203.0.113.25 -all"

The final -all fails any server not listed; ~all (softfail) is a weaker signal.

DKIM: a signature tied to a domain

DKIM (RFC 6376) adds a cryptographic signature to each message. The DKIM-Signature header names the signing domain (d=) and a selector (s=); the receiver fetches the public key published under that selector and checks that the signed content was not altered. Your mail provider generates the keys and gives you the record to publish:

selector1._domainkey.dupont-immo.fr.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"

DMARC: the visible From address and a policy

DMARC links these checks to the address people actually see: the domain in the From header. A message passes DMARC when SPF or DKIM passes and the domain it authenticated is aligned with the From domain. The DMARC record then tells receivers what to do with messages that fail (the policy) and where to send reports.

Alignment: relaxed or strict

In relaxed mode, the default, the authenticated domain and the From domain must share the same organizational domain: a DKIM signature from mail.dupont-immo.fr aligns with a From address at dupont-immo.fr. In strict mode they must match exactly. The adkim and aspf tags set the mode for DKIM and SPF. Relaxed suits most small businesses.

The DMARC record and its tags

Your DMARC policy is a TXT record published at _dmarc.dupont-immo.fr. Only one DMARC record may exist at that name: if receivers find two, they do not apply DMARC to your domain at all.

_dmarc.dupont-immo.fr.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@dupont-immo.fr"

• v=DMARC1: the version, required and always first.
• p: the policy for the domain. none (observe only), quarantine (treat as suspicious, typically the spam folder) or reject (refuse the message).
• sp: the policy for subdomains. Without it, subdomains follow p.
• np: the policy for subdomains that do not exist, a favourite of spoofers who invent names under your domain. Without it, sp applies, then p.
• rua: where receivers send aggregate reports, as one or more mailto: addresses.
• ruf: where to send failure reports on individual messages. They can contain parts of the message, which raises privacy questions.
• t: test mode. With t=y, receivers apply one level below the published policy (reject is treated as quarantine, quarantine as none) and keep sending reports.
• adkim and aspf: the alignment mode for DKIM and SPF, r (relaxed, default) or s (strict).

Reports sent to another domain, such as a report-analysis service, require that domain to publish a TXT record accepting reports for yours.

DMARC quarantine vs reject

Both policies act on messages that fail DMARC. With quarantine, the receiver accepts the message but treats it as suspicious, usually by filing it as spam: the forged email still reaches the mailbox, where a hurried reader can act on it. With reject, the receiver should refuse the message during the SMTP exchange, so it never arrives.

Reject is the goal: under it, receivers that enforce DMARC do not deliver forged messages using your exact domain. Each receiver keeps the final say under its local policy, so DMARC is a strong instruction, not an absolute guarantee.

From p=none to DMARC p=reject in five steps

1. Publish p=none with reports

Start in observation mode with the record shown above. p=none changes nothing for delivery, but receivers that support reporting send aggregate reports to the rua address, typically once a day. Each report lists the IP addresses that sent mail with your domain and whether SPF and DKIM passed and aligned. The reports are XML files: a report-analysis tool makes them readable.

Create the mailbox before publishing the record. Spamr's free domain scan also reads your current SPF and DMARC records and suggests the next step (none, quarantine, then reject) with the exact record to publish.

2. List every legitimate sender

Compare the reports with your own list of every service that sends with a From address at your domain:

• your mail provider (your team's everyday mailboxes);
• your CRM or property management software;
• your invoicing or accounting tool;
• your website's contact forms, often sent through the web host;
• your newsletter or marketing platform;
• devices and services that send notifications, such as a booking system.

Cover at least one full monthly cycle, so that tools sending only at month end (rent reminders, invoices) show up.

3. Fix SPF and DKIM for each sender

For each service, enable DKIM signing with your own domain (it provides the records to publish under _domainkey), and add its include to your single SPF record if it sends with your domain as envelope sender. Aligned DKIM is the more reliable route: many services keep their own bounce domain, which passes SPF without aligning with yours. A service that cannot authenticate your domain should send from a dedicated subdomain, or stop using your From address.

4. Move to quarantine

When the reports show only known services, all passing with alignment, switch to quarantine. A mistake at this stage stays recoverable: a legitimate message that fails lands in the spam folder, where it can still be found.

_dmarc.dupont-immo.fr.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@dupont-immo.fr"

Older guides apply the policy to a share of messages with pct=25, then 50, then 100. RFC 9989 removed pct: receivers that follow it ignore the tag. Its t=y test mode does not replace it either, since receivers still following RFC 7489 ignore t and apply the full policy. Give quarantine a full business cycle instead, and read the reports.

5. Move to reject

Once quarantine has run for a full cycle without losing legitimate mail, publish reject. Keep rua: the reports will reveal any new service a colleague adds without telling you.

_dmarc.dupont-immo.fr.  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@dupont-immo.fr"

Protecting subdomains and domains that send no mail

When a receiver finds no DMARC record on a subdomain, it falls back to the record of the organizational domain and applies sp if present. sp=reject therefore covers billing.dupont-immo.fr and any name an attacker invents under your domain. A subdomain that sends through its own service can publish its own _dmarc record.

Domains you own but never use for email (an old brand name, a defensive registration, a redirect) are easy targets because nobody watches them. Declare that they send and receive nothing:

example.com.         MX   0 .
example.com.         TXT  "v=spf1 -all"
_dmarc.example.com.  TXT  "v=DMARC1; p=reject; sp=reject"

The null MX (RFC 7505) declares that the domain accepts no mail, v=spf1 -all authorizes no server, and p=reject asks receivers to refuse anything sent in its name.

Common DMARC policy mistakes

• Two SPF records. A domain may publish only one SPF record. With two, SPF returns a permanent error. Merge them into one.
• Too many DNS lookups in SPF. The include, a, mx, ptr and exists mechanisms and the redirect modifier count toward a limit of 10 DNS lookups set by RFC 7208, nested includes included. Past it, SPF returns a permanent error. Remove services you no longer use.
• Forgetting a sending service. An invoicing tool that sends with your From address but without aligned DKIM or SPF is rejected under p=reject. The reports would have shown it.
• Jumping to reject without reports. Without rua, you learn about a broken sender when a client says an invoice never arrived.

What DMARC p=reject does not do

DMARC protects one thing: the exact domain in the From header. If a fraudster registers a variant of dupont-immo.fr with one letter changed, or the same name under another extension, that is a different domain. Its owner can publish SPF, DKIM and even DMARC p=reject, and the messages pass every check, because they genuinely come from the domain they claim.

DMARC does not check the display name either: a message showing the name “Dupont Immo” and sent from a free webmail address passes authentication for the webmail's domain. These techniques drive payment diversion fraud: a lookalike domain, a convincing message and new bank details.

DMARC and lookalike monitoring therefore work as a pair. Spamr generates several hundred variants of a domain (typos, other extensions, homoglyphs) and checks only public DNS and registration data to find those already registered, without ever visiting them. Our guide to detecting lookalike domains explains which signals matter.

Key takeaways

• SPF and DKIM authenticate a domain; DMARC requires it to align with the visible From address.
• Publish p=none with rua, list every legitimate sender, then fix SPF and DKIM for each one.
• Move to quarantine, then to DMARC p=reject, reading reports at each step.
• Protect subdomains with sp, and unused domains with a null MX, v=spf1 -all and p=reject.
• DMARC cannot stop lookalike domains: monitor them separately.