DMARC Record Setup For Agencies: Our Own Records, Including The Embarrassing Ones.

Short answer: dmarc record setup is a sequence, not a switch. Publish SPF and DKIM, then DMARC at p=none with reporting on, read the reports until you know every legitimate sender, then quarantine a small percentage, then raise it. Skipping to p=reject destroys legitimate mail. Stopping halfway leaves a record that reads like protection and is not.

Rather than invent an example, I read the records on seven domains POSIMYTH owns.

What a real portfolio looks like mid-rollout

one monitoring, and one enforcing with only DKIM to align against. This is what a genuine rollout looks like partway through.*

Domain	Policy	Enforced on	Reading
protuno.com	p=reject	100%	enforcing
nexterwp.com	p=reject	100%	enforcing, sends no mail
stickyheadereffects.com	p=reject	100%	enforcing, sends no mail
posimyth.com	p=quarantine	pct=5	95% of failing mail unaffected
theplusaddons.com	p=quarantine	pct=5	same
uichemy.com	p=none	n/a	monitoring only
wdesignkit.com	p=quarantine	100%	enforcing with only DKIM, no SPF

Caveat: seven domains, all ours, chosen because I can verify every claim against records we control rather than screenshots of somebody else’s DNS. It is not a claim about typical agency DMARC hygiene. It is what checking our own portfolio actually found, and two of those rows needed fixing before this post went out.

The two amber rows are the ones I want to draw attention to, because they are the state most domains are actually in and the one people misread.

p=quarantine sounds like enforcement. With pct=5, the policy applies to five percent of failing messages. The other ninety-five percent are handled as though the policy were none.

That is a correct, deliberate rollout step. It is also very easy to leave in place for a year and believe the domain is protected. Ours have.

The red row is a genuine misconfiguration: a quarantine policy on a domain with no SPF record, which leaves DKIM as the only thing DMARC can align against. It is on the list.

Reading a DMARC record setup, tag by tag

enforcing blind. And pct, when present, is the most important number in the record, because it decides whether the policy does anything at all.*

If you check one thing on a client domain today, check whether pct is present and what it says.

The rollout, and the mistake at each step

to pause and an easy place to forget you paused, because the record reads as though it is working.*

#	Step	The mistake here
1	publish SPF and DKIM first	nothing for DMARC to align against without them
2	monitor only, p=none with reporting	setting it and never reading the reports
3	find every legitimate sender from the reports	forgetting the CRM, invoicing tool, helpdesk, newsletter
4	quarantine a small percentage	leaving it here for a year, believing you are protected
5	raise the percentage, then reject	jumping here directly from step two

Step three is the one that costs agencies real goodwill when skipped. The senders you forget are never the mail server. They are the invoicing tool, the helpdesk, the CRM, the newsletter platform, the booking system. Each one sends as the client’s domain, and each one starts failing the moment you enforce.

That is why p=none with rua exists. It generates the list for you, from real traffic, over a few weeks. There is no way to produce that list by thinking hard about it.

The DKIM half, briefly

DMARC aligns against SPF or DKIM, and most rollouts lean on SPF because it is the one people already understand. DKIM is worth the extra hour for one reason: it survives forwarding.

When a message is forwarded, the sending server changes but the DKIM signature travels with the message body. SPF breaks in that situation and DKIM does not. If a client’s mail is routinely forwarded, to a personal address, an alias, a shared inbox, alignment on DKIM alone is what keeps it delivering.

Check whether a selector is publishing at all:

dig +short TXT google._domainkey.example.com | head -c 120
dig +short TXT selector1._domainkey.example.com | head -c 120

Selector names vary by provider, which is the genuinely annoying part. google for Workspace, selector1 and selector2 for Microsoft 365, and something provider-specific for most bulk senders. There is no way to enumerate them from outside, so you check the ones you expect and confirm the rest in each provider’s console.

Checking a portfolio

takes seconds.*

Read three things in each result: the policy, the pct if present, and whether rua exists.

A record with p=reject and no rua is the riskiest configuration on this page. It is enforcing, and nobody can see what it is refusing.

What it protects, and what it does not

Worth being precise here, because DMARC gets oversold.

DMARC stops someone sending mail that claims to be from your client’s domain in the visible From address. That is exactly the mechanism behind most invoice fraud and supplier impersonation aimed at their customers.

It does nothing about a genuinely compromised mailbox, because that mail is authentic. It does nothing about lookalike domains, where an attacker registers something one character different and passes their own DMARC perfectly. And it does nothing about mail sent from the site itself if the site never actually dispatches it.

So it is worth doing and it is not a mail security strategy on its own. Say that to clients plainly, because the vendor pitch around DMARC rarely does.

Why this drifts

DMARC does not fail loudly. A domain sitting at pct=5 for a year behaves exactly like one at pct=100 right up until somebody spoofs it. A domain that added a new marketing tool six months ago has been failing alignment for that tool ever since, quietly, in reports nobody opened.

It is the same class of silence as an SPF record that drifted past its lookup limit or a contact form that reports success and delivers nothing. Mail problems almost never announce themselves at the sending end.

Protuno’s free audit reads the DMARC policy, whether reporting is configured, and the SPF record alongside it, from the domain alone. That is how the table above was built. Straight with you as on every post here: Echo, the Marketing agent that would watch these records for drift, is built and named but not live yet.

One note on selling this, because it is genuinely hard to charge for. DMARC produces no visible improvement. Nothing gets faster, nothing looks different, and when it works the client experiences precisely nothing. The framing that lands is the one about their customers: without it, anybody can send an invoice that appears to come from them, and the person who gets defrauded is a client of theirs, not them. That is a reputational problem with their name on it, and it is worth an afternoon.

Run the loop on your client domains this afternoon. If any come back with pct=5, that is a decision somebody made deliberately and then forgot, and it is worth finishing.