DMARC From Zero to Reject: A Step-by-Step Rollout

DMARC is not a sender authentication mechanism. It is a policy layer on top of SPF and DKIM that tells receivers what to do when those underlying mechanisms fail to align with the From: header. If you publish DMARC without first having clean SPF and DKIM, the only thing that happens is your legitimate mail starts getting flagged the moment you move past p=none.

SPF must be published at the apex of every domain that appears in the envelope From. The record must list every IP or include: that legitimately sends for the domain, must stay under 10 DNS lookups per RFC 7208, and must end with ~all during rollout (you can move to -all after DMARC reaches reject). Run dig +short TXT example.com and confirm exactly one record begins with v=spf1. Two SPF records is a permerror and silently breaks everything.

DKIM must be published as a CNAME or TXT under the selector your ESP gives you (s1._domainkey, google._domainkey, etc.). Each ESP has its own selector — you can have many DKIM signatures on a single message. The selector is rotated by responsible ESPs every 6-12 months; if your selector is more than two years old, your ESP almost certainly has a new one waiting. Verify each selector signs successfully using a tool that decodes DKIM-Signature headers from a real test send.

Run a Mail-Tester test from each major sending source — Google Workspace, your transactional ESP, your marketing ESP, your billing platform. The Mail-Tester report breaks down SPF, DKIM, and DMARC alignment per source. Anything that fails alignment must be fixed before you raise the DMARC policy.

The first DMARC record you publish should be p=none with a rua= reporting address. This tells receivers "do not change your delivery decision based on DMARC, but please send me daily aggregate reports about what you saw". You will live in this state for at least two weeks while you discover every legitimate sending source you forgot about.

The record goes at _dmarc.example.com as a TXT record. The minimum useful version is v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-failures@example.com; pct=100; adkim=r; aspf=r;. Do not skip the rua= field — without it, the policy is invisible to you and there is no way to know what is happening.

The reporting mailbox should be a dedicated address, not a person's inbox. Aggregate reports arrive as compressed XML files daily from every major receiver — Gmail, Microsoft, Yahoo, Fastmail, and many smaller providers. A typical mid-sized domain receives 10-50 aggregate reports per day. Manually parsing them is impossible; route the mailbox to a DMARC analytics service. Free tiers exist at dmarcian, EasyDMARC, and Postmark; enterprise options at Valimail, Red Sift, and Agari.

The ruf= failure reports are different — they are per-message forensic dumps with full headers and a partial body, sent by a small number of receivers (mostly Yahoo and a few hosting providers). They are useful for debugging specific incidents but not for ongoing monitoring. Some teams skip ruf= entirely to avoid PII concerns.

Aggregate reports are XML documents that summarize how a single receiver evaluated DMARC for messages from your domain over a 24-hour period. Each report contains one or more elements, each describing the source IP, the message count, and the disposition (none/quarantine/reject) the receiver applied — plus the SPF and DKIM evaluation per record.

The first thing to look for is unauthorized sending from IPs you do not recognize. Marketing teams onboard new tools without telling DNS owners; old contractor accounts keep sending months after offboarding; abandoned subdomains spin up phishing relays. Every IP in your aggregate reports that is not on your authorized sender list is either a forgotten legitimate source or an unauthorized one. Both need attention.

The second thing to look for is misalignment on legitimate sources. A common pattern: HubSpot sends transactional mail through their shared infrastructure, the SPF check passes (HubSpot's IPs are in your SPF), but DKIM fails because the d= domain in the signature is hubspot-mail.com instead of your domain. That is alignment failure — DMARC requires either SPF or DKIM to align with the From: header domain. The fix is enabling "branded sending" in HubSpot and publishing the CNAMEs they give you.

Most DMARC analytics services chart this as "compliant" vs "non-compliant" mail by source. Aim for >99% compliance from your top 10 sources before moving to quarantine. The long tail of one-off mailers (a Calendly notification, a Stripe receipt) is rarely worth chasing if it represents <0.1% of total volume — those will be caught by individual receivers' spam heuristics regardless.

After two weeks of clean reports from your major sources, you can begin enforcement. The trick is to not enforce on 100% of mail at once — use the pct= tag to gradually increase the percentage of failing mail that gets the new disposition. Start with p=quarantine; pct=10;, which tells receivers to apply quarantine to a randomly-selected 10% of failing mail.

Wait one week. Watch your aggregate reports for any spike in unexpected quarantines from legitimate sources. If you see one — and you usually will, because there is always a forgotten ESP — go back to p=none, fix the alignment issue, and try again. This is the entire point of pct: it limits the blast radius of mistakes.

If everything is clean, raise to pct=25. Wait one week. Then pct=50. Then pct=100. The whole quarantine ramp takes about a month for a domain with consistent sending patterns. Domains with end-of-month batch sends (invoicing, monthly newsletters) should hold each pct level long enough to cover one full send cycle, since alignment problems often only manifest on those high-volume days.

Quarantine means "deliver to spam folder" at most receivers, though some deliver to inbox with a warning banner. Either way, it is not silent failure — your users will see the impact of any mistake quickly. Set up a dedicated mailbox monitoring address so you can see what your customers see.

After a clean week at p=quarantine; pct=100;, you are ready to move to reject. The transition is p=reject; pct=100;. There is no benefit to ramping reject with pct because most receivers treat any reject percentage as a strong signal — staying at pct=50 reject just confuses receivers and produces inconsistent results.

At reject, failing mail is rejected at the SMTP transaction with a 550 response. The sender bounces immediately. There is no spam folder to fish messages out of. This is what you want for production-grade enforcement, but it means you have zero margin for error — any new sending source you forget about will silently bounce until someone notices and complains.

We recommend leaving the DMARC analytics monitoring in place permanently. New sending sources get added all the time (a new tool, a new vendor integration), and the aggregate reports remain the canonical signal that something has gone wrong with alignment. Set up alerts in your DMARC analytics tool so unexpected reject volume surfaces in your team chat within 24 hours.

Once at reject, you can also tighten SPF from ~all (softfail) to -all (hardfail). The combination of DMARC reject and SPF hardfail is the strongest deliverability posture you can achieve and is required for some compliance frameworks (HIPAA, PCI-DSS guidance for financial services, FedRAMP for federal contractors).

In February 2024, Gmail and Yahoo jointly announced new requirements for bulk senders — anyone sending more than 5,000 messages per day to either provider. The requirements: SPF and DKIM must both be set up; DMARC must be published (any policy, even p=none); the From: header must align with either SPF or DKIM; one-click unsubscribe (RFC 8058 List-Unsubscribe-Post) must be implemented; and spam complaint rates must stay below 0.3%.

Microsoft 365 announced similar requirements in mid-2024 for high-volume senders to Outlook.com and Hotmail addresses, and Apple iCloud has tightened their enforcement as well. The functional reality in 2026: any domain sending more than a few thousand marketing emails a day must have a published DMARC record or expect rate-limiting and bulk-spam folder placement at the major providers.

The Gmail enforcement is also stricter than just "DMARC published". Gmail wants alignment, which means the d= in your DKIM signature or the envelope from in your SPF check must match the visible From: domain. Sending from marketing.example.com while your DMARC is on example.com works only if the DMARC record uses sp= for the subdomain policy and the alignment mode tags (adkim, aspf are set appropriately.

Practically, this means most teams need to publish a DMARC record at every subdomain that sends mail, or use the sp= tag to set a subdomain policy. We recommend explicit per-subdomain DMARC records for each — it is more verbose but easier to debug.

Aggregate reports are XML, and the schema (defined in RFC 7489 §7.2) is dense. The minimum understanding you need: the block tells you what disposition the receiver applied; the block tells you the underlying SPF and DKIM results; and the element tells you which IP sent the mail.

Read enough of these and patterns emerge. SPF passing but DKIM failing usually means a forwarder rewrote the envelope (mailing lists,.forward files); SPF failing but DKIM passing usually means a third-party sender that signs with their own d= but does not have your domain in their SPF; both failing usually means actual spoofing or a new sending source that needs onboarding.

DMARC analytics services map this to a UI. dmarcian's free tier is the easiest entry point and handles up to 1k report records per month free; EasyDMARC offers more detailed source matching and integrates with Postmark and Mailgun directly; Valimail and Red Sift are enterprise tools with automated remediation suggestions and pre-built integrations with major ESPs. Pick one early — manual XML parsing scales for about three days before becoming the bottleneck.

Forensic reports (ruf= are different. Each one is a copy of a single failing message, with subject and partial body, sent by a small subset of receivers. They are useful when investigating a specific phishing campaign but most teams turn them off after initial rollout because of the operational cost and the privacy implications of receiving snippets of customer mail.

Mailing lists break alignment. Internal mailing lists (Google Groups, Mailman) often rewrite the envelope-from. SPF then evaluates against the list's domain, not yours, and DKIM may or may not survive depending on whether the list adds an Author-Domain Signing Practice (ADSP) wrapper. The fix is configuring the list to use the From: rewriting feature (most modern list software supports it) or accepting that mailing-list traffic will fail DMARC and configuring your reporting accordingly.

Forwarders break SPF. Users who set up .forward files at universities or older ISPs will have their forwarded mail SPF-fail because the forwarding server is the new envelope-from sender. DKIM almost always survives (signatures persist across forwarding) so the DMARC pass/fail comes down to DKIM alignment. Make sure DKIM is rock solid before moving to enforcement.

Salesforce and HubSpot need branded sending. Both default to using their own domain in DKIM. Both offer "branded" or "custom domain" features that publish CNAMEs back to your DNS so DKIM signs as your domain. Without this, every Salesforce-sent email will fail DMARC alignment regardless of policy.

Default Microsoft 365 DKIM is short. Out of the box, Microsoft 365 publishes 1024-bit DKIM keys, which Gmail flags as "weak" since 2023. Rotate to 2048-bit via the Microsoft 365 admin center (Mail flow → DKIM → Rotate DKIM keys). The transition is non-disruptive but takes ~24 hours.

Free email forwarding services often strip DKIM. ImprovMX, Cloudflare Email Routing, and similar services rewrite headers in ways that can break DKIM signatures. Verify with a test send whether DKIM survives forwarding before relying on it for production.