Notes from the DMARCify team

A DKIM CNAME is a controlled delegation, not a harmless DNS shortcut. Inventory every selector, name an owner, monitor the target, and remove it when the vendor relationship ends.

Use DMARC reports to investigate authentication. Use sending logs and recipient-side evidence to investigate delivery. A passing result alone cannot tell you where a message landed.

Relaxed alignment is the DMARC default for good reason: it lets legitimate subdomain-based mail streams pass while still tying authorization to the same organizational domain. Strict alignment is useful only after reports prove every legitimate sender can match the exact From domain.

Use p for the domain itself, sp for existing subdomains that do not publish their own DMARC record, and np for non-existent subdomains. If you omit sp or np, receivers fall back to p where applicable.

External DMARC reporting is a two-domain contract. The policy domain asks for reports with rua, and the destination domain must publish the DNS proof that it is willing to receive them.

Treat RUF failure reports as a short-lived diagnostic instrument, not the normal DMARC dashboard. Aggregate reports give the operating view without exposing message-level content and identifiers.

A non-sending domain should not be quiet in DNS. Publish SPF -all, DMARC p=reject, no DKIM keys, and a null MX record so receivers have clear evidence that mail using the domain is unauthorized.

For bulk senders, DMARC alignment is no longer aspirational. SPF, DKIM, an aligned From domain, one-click unsubscribe, and complaint monitoring belong in the release checklist for every high-volume mail stream.

The DMARC aggregate report is, accidentally, the best SaaS inventory tool you have. Every authorized sender shows up by IP and ASN, and the unfamiliar ASN is the conversation you did not know you needed.

MTA-STS forces senders to use TLS when delivering mail to you. TLS-RPT tells you when they tried and failed. Together they close a gap DMARC does not address.

Alumni fundraising spoofs target donors with personalized wire-transfer requests from trusted university identities. The fix is enforced DMARC across every university subdomain that has ever sent mail.

The risk after an acquisition is not the well-known primary domain. It is the side domains, marketing campaign domains, and defensive registrations. The 30-day playbook: inventory everything, set unused domains to hard reject plus null SPF, and monitor what remains.

Each include, a, mx, ptr, exists, and redirect counts toward the 10-lookup ceiling, and includes count transitively. Once you exceed it, legitimate senders can fail SPF, but DKIM-aligned mail survives.

Rotate DKIM keys on a fixed cadence, use a new selector each time, keep the old selector briefly for queued mail, then remove it. Rotation is not complete until the old selector is gone.

ARC is not something most senders deploy themselves. It is a chain-of-custody signature the forwarder applies so downstream receivers can use original authentication results.

DORA and NIS2 are outcome-based, but the email evidence is concrete: inventory domains, authenticate senders, collect reports, and prove that spoofing risk is being reduced.

If you process card data, PCI 5.4.1 expects anti-phishing controls that actually enforce or quarantine. Monitor-only DMARC is visibility, not protection.

The record still says DMARC1, but the standard around it is cleaner: no pct rollout tag, DNS Tree Walk replaces PSL discovery, PSD support is explicit, and reports carry more policy context.

Forwarding usually breaks SPF but preserves DKIM; spoofing fails alignment. That one distinction removes most false alarm.

BIMI is mostly proof of control: enforced DMARC first, then a compliant SVG, certificate, and DNS record.

Treat p=reject as a rollout, not a switch: observe, fix alignment, quarantine, then enforce.