The enforcement journey: p=none to p=reject

21 June 2026 · 27 min read

Why enforcement is the whole point of DMARC

Publishing a DMARC record with p=none is not "doing DMARC" - it's switching on the lights so you can see who is sending mail as your domain. Nothing gets blocked at p=none. The real value of DMARC only arrives when you move to p=quarantine and then p=reject, because that is the point at which mailbox providers actually start refusing spoofed mail claiming to be from you.

This guide is the rollout playbook: how to go from a fresh p=none record to a confidently enforced p=reject, without breaking a single legitimate email along the way. It assumes you've already delegated your DMARC record to DMARC Engine (or are about to) and covers the whole journey - monitoring, fixing senders, ramping percentages, watching failures, and handling the awkward cases like forwarding and mailing lists.

If you haven't set up DMARC hosting yet, start with your domain in app.dmarcengine.com/domains first, then come back here. For the mechanics of SPF and DKIM alignment specifically, see the companion guides Understanding SPF alignment and DKIM signing and rotation.

Note: This guide assumes you're running DMARC Engine's hosted delegation model - you publish a CNAME once, and we serve and auto-update the underlying record. If you're self-managing your DMARC TXT record instead, the policy-editing steps below still apply conceptually, you'll just edit the raw TXT record yourself each time rather than using the builder at /dmarc.

The three enforcement policies at a glance

DMARC has exactly three policy values, and the whole rollout is about moving through them in order, never skipping ahead.

Two modifiers ride alongside the policy and matter just as much:

• pct - what percentage of failing mail the policy applies to (the rest falls back to p=none behaviour). This is your ramp lever.
• sp - the policy applied to subdomains, which can differ from the main domain's policy.

Warning: Do not jump straight from p=none to p=reject. Even if your monitoring dashboard looks clean, DMARC aggregate (RUA) reports are aggregated once every 24 hours from a subset of receivers and can miss low-volume or infrequent senders (an annual renewals system, a support tool that only emails at month-end, a marketing platform your team just started using). Rushing to reject is the single most common cause of "why did our invoices stop arriving" support tickets.

Prerequisites: get the hosted DMARC record live

Before any monitoring can happen you need a DMARC record resolving for your domain, receiving RUA reports, and visible inside DMARC Engine. If you've already done this, skip to Phase 1.

Step-by-step: add your domain and delegate DMARC

1. Sign in to app.dmarcengine.com and open Domains.
2. Click Add domain and enter your sending domain (e.g. example.com).
3. Open the domain's DMARC builder page. It will show you a per-domain hosting slug and the exact CNAME record to publish.
4. In your DNS provider, create:

   _dmarc.example.com.    CNAME    <slug>._dmarc.dmarcengine.com.
   

1. Save the DNS change and wait for propagation (usually minutes, occasionally up to 24-48 hours depending on your DNS provider's TTL).
2. Back in DMARC Engine, use Lookup to query _dmarc.example.com and confirm the CNAME resolves and the served DMARC record is being returned.
3. Once verified, the builder will show the record is live and serving p=none by default, sending aggregate reports to r-<token>@reports.dmarcengine.com.

Tip: Prefer to self-manage instead of delegating? You can publish the DMARC TXT record directly - for example v=DMARC1; p=none; rua=mailto:r-<token>@reports.dmarcengine.com; fo=1 - using the RUA address shown on your domain's DMARC builder page. You'll lose the auto-managed policy ramping described below and need to hand-edit the TXT record at each stage instead.

With the record live, reports will start arriving within 24-48 hours as receivers batch and send their daily aggregate summaries.

What's actually inside an aggregate (RUA) report

It helps to know what you're looking at before you start reading Analytics and Reports in anger. Every receiver that gets mail claiming to be from your domain and supports DMARC will, roughly once every 24 hours, send an XML aggregate report to the rua= address on your record. DMARC Engine parses these automatically and renders them as the dashboards you actually use, but the underlying data always has the same shape:

A single report typically bundles many rows - one per distinct source IP the receiver saw in that window. This is why "check the domain-wide pass rate" is the wrong first instinct: a 97% domain-wide pass rate can still mean one specific source is failing 100% of the time, just at low volume. Always drill into the per-source breakdown in Analytics rather than trusting the headline number alone.

Tip: Forensic (RUF) reports are a separate, optional mechanism that sends a redacted copy of individual failing messages rather than aggregated statistics. Most receivers don't send them at all, and DMARC Engine doesn't require them for this rollout - the aggregate reports above are sufficient for the whole enforcement journey.

Phase 1: p=none - discovery and monitoring

The entire point of this phase is to build a complete, verified inventory of everything that sends email using your domain - your marketing platform, helpdesk, HR system, invoicing tool, transactional email service, the CEO's phone, all of it - and confirm each one passes SPF or DKIM in alignment with your domain. Nothing is blocked yet, so this is the safe phase to take your time in.

Step-by-step: start monitoring

1. Confirm the record is live per the prerequisites above.
2. Open Analytics and set the date range to "last 7 days" once reports start flowing.
3. Look at the pass/fail breakdown by sending source (usually shown as sending IP or resolved organisation), not just the domain-wide total. A domain-wide 95% pass rate can hide one source failing 100% of the time at low volume.
4. Open Reports and drill into any source showing SPF or DKIM failures. Each row will show whether SPF aligned, whether DKIM aligned, and the raw envelope-from / header-from used.
5. Build a spreadsheet (or use the source list in Analytics) of every distinct sending source you recognise, and flag any you don't recognise for investigation - an unrecognised source failing alignment might just be a legitimate tool you forgot about, or it might be someone spoofing you (check Threats for anything that looks malicious rather than misconfigured).
6. For every legitimate source, work through the alignment fix steps below until it shows a clean pass.

Note: "Pass" in DMARC terms means SPF or DKIM passes and is aligned to your header-from domain - it doesn't require both. A source that has correctly configured DKIM signing will pass DMARC even if its SPF doesn't cover your domain, and vice versa. Aim for both where practical since it gives you redundancy, but one aligned mechanism is enough to satisfy DMARC.

Fixing SPF alignment for each source

Most sending tools (email marketing platforms, CRMs, helpdesks, invoicing systems) need to be added to your SPF record so their sending IPs are authorised.

1. Identify the sending platform's documented SPF include value (e.g. include:sendgrid.net, include:_spf.google.com).
2. Open SPF for the domain.
3. Publish the delegation record if you haven't already:

   example.com.    TXT    "v=spf1 include:<slug>.spf.dmarcengine.com ~all"
   

1. Inside the SPF builder, add the new sender's include (or IP4/IP6 range) to your managed list. DMARC Engine auto-flattens the result so you never hit SPF's hard 10-DNS-lookup limit yourself, no matter how many senders you accumulate.
2. Save, then re-check the source in Analytics after its next send - allow 24-48 hours for the next aggregate report cycle.

Tip: If you'd rather not delegate SPF, you can publish and maintain the flattened list yourself as a plain TXT record, but you are then responsible for tracking the 10-lookup limit manually every time you add a sender - see Fixing SPF too many DNS lookups for how that limit is calculated and why it bites people.

Fixing DKIM alignment for each source

DKIM alignment additionally requires the signing domain (the d= value in the DKIM signature) to match your organisational domain - an unrelated third-party signing domain won't align even if the signature itself is cryptographically valid.

1. In the sending platform's admin panel, generate (or locate) its DKIM selector and public key value for your domain.
2. Open DKIM and add the selector.
3. Publish the CNAME the builder gives you:

   <selector>._domainkey.example.com.    CNAME    <selector>.<slug>._domainkey.dmarcengine.com.
   

1. Confirm with the sending platform that it is configured to sign outbound mail from your domain using that selector (some platforms require you to toggle "custom DKIM" on their side once the DNS record is confirmed).
2. Send a test message through that platform and check Reports or your own inbox headers for dkim=pass with an aligned d= domain.

Warning: A DKIM signature that verifies fine but is signed with d=sendgrid.net (the vendor's domain) instead of d=example.com will not count as DMARC-aligned, even though the signature itself is valid. This is the single most common cause of "SPF and DKIM both show green in my email client but DMARC still fails" confusion - check alignment, not just pass/fail, in the Reports detail view.

The discovery checklist

Work through this before considering moving off p=none:

• [ ] Every internal mail system (Exchange/Google Workspace/etc.) passes and is aligned
• [ ] Every marketing/newsletter platform passes and is aligned
• [ ] Every transactional email service (billing, password resets, notifications) passes and is aligned
• [ ] Every helpdesk/support tool passes and is aligned
• [ ] Any HR, payroll or e-signature platform sending as your domain passes and is aligned
• [ ] At least one full billing cycle (invoicing, monthly reports) has been observed, since these senders are often infrequent
• [ ] Any source in Analytics you don't recognise has been identified and either fixed or confirmed as unauthorised/malicious via Threats
• [ ] No unexplained failing volume has appeared for at least 2 consecutive weeks

Note: Use the free DMARC lookup and header analyser tools to spot-check any individual message's headers manually while you're chasing down a stubborn sender - pasting a raw header block is often faster than waiting for the next aggregate report cycle.

Phase 2: ramping to p=quarantine

Once your discovery checklist is clean, move to p=quarantine - but do it gradually using the pct tag rather than flipping the whole domain over in one step. pct tells receivers what proportion of would-fail mail to actually apply the policy to; the rest is treated as if the policy were none.

The ramp schedule

Tip: Ramping is not a fixed calendar - it's a "wait for evidence" process. If you see zero unexplained failures at pct=25 after a week, it's fine to move to pct=50 early. If anything unexpected shows up, hold the current pct (or drop back a step) until it's resolved.

Step-by-step: set the ramp in the DMARC builder

1. Open DMARC for the domain.
2. Change the policy field from none to quarantine.
3. Set pct to 10.
4. Save. DMARC Engine updates the served record immediately (no DNS change needed on your side since you're delegated via CNAME).
5. Set a calendar reminder for 3-5 days out to review Analytics.
6. Repeat steps 2-5 raising pct at each stage (25, 50, 100), only advancing when the previous step showed no unexplained failures.

If self-managing the raw TXT record instead of delegating, the equivalent record at step 1 looks like:

example.com.    TXT    "v=DMARC1; p=quarantine; pct=10; rua=mailto:r-<token>@reports.dmarcengine.com; fo=1"

Watching for failures during the ramp

1. Open Alerts and confirm you have an alert configured for "new failing source detected" and "failure rate increase" - these will surface problems faster than manually checking Analytics daily.
2. Check Analytics at each ramp step for a spike or a new source appearing in the failure breakdown.
3. Check Threats in parallel - a rise in quarantine hits from sources that are clearly not yours (unfamiliar IP ranges, unrelated countries, no prior sending history) is a good sign, not a bad one: it means quarantine is now catching spoofed mail that p=none was letting through silently.
4. If a legitimate source starts failing partway through the ramp, drop pct back to the last known-good step, fix the source's SPF/DKIM alignment (see Phase 1 steps), confirm clean for a few days, then resume the ramp.

Warning: Don't confuse "failure volume dropped" with "problem fixed" if you also lowered pct at the same time - you may just be sampling fewer of the failures, not actually resolving them. Confirm the underlying source shows a genuine pass before ramping back up.

Phase 3: full quarantine and the final review before reject

By the time you reach p=quarantine; pct=100, every enrolled source should be passing consistently. This phase is a deliberate pause - resist moving to p=reject immediately even if the dashboard looks perfect.

Step-by-step: the pre-reject review

1. Run p=quarantine; pct=100 for a minimum of two to three weeks, spanning at least one full billing/reporting cycle (month-end invoices, weekly newsletters, any quarterly system).
2. Review Analytics weekly during this window, not just once at the end.
3. Ask internal stakeholders (finance, HR, marketing, sales ops) directly: "has anyone reported emails from us landing in spam or bouncing in the last three weeks?" Automated monitoring won't catch every human complaint.
4. Re-check Reports for any forwarding-related failures specifically (see the forwarding section below) - these are the pattern most likely to slip through discovery.
5. Confirm no alerts have fired in Alerts for at least the final 7 days of the window.

Note: This review period is the cheapest insurance you'll ever buy. At p=quarantine, a mistake means someone's email lands in spam and can usually be recovered by the recipient checking their junk folder. At p=reject, a mistake means the message is dropped and never arrives at all - often silently, with no bounce reaching the sender either, if the receiving side chooses not to notify.

Phase 4: moving to p=reject

Once the pre-reject review is clean, ramp reject exactly the same way you ramped quarantine - don't skip straight to pct=100.

Step-by-step: enforce p=reject

1. Open DMARC.
2. Change the policy to reject.
3. Set pct=10 and save.
4. Hold for 3-5 days, watching Analytics and Alerts as before.
5. Raise to pct=25, then pct=50, then pct=100, holding at least a few days to a week at each step, exactly as in the quarantine ramp.
6. At p=reject; pct=100, also review the sp (subdomain policy) setting - if you have subdomains that send mail (e.g. mail.example.com, marketing.example.com), make sure each is either covered by the same enforcement or has its own DMARC record and ramp. An unprotected subdomain is a common gap attackers exploit even after the main domain is locked down - see Protecting subdomains with DMARC for the details.
7. Once stable at p=reject; pct=100, consider tightening adkim/aspf from relaxed (r, the default) to strict (s) alignment only if every sender's signing/envelope domain exactly matches your domain - most organisations stay on relaxed alignment indefinitely and that's fine.

The fully enforced record (served by DMARC Engine, visible via Lookup) will resolve to something equivalent to:

v=DMARC1; p=reject; pct=100; rua=mailto:r-<token>@reports.dmarcengine.com; fo=1

Tip: Keep the rua= reporting address live permanently, even after reaching full reject. Aggregate reports keep flowing and remain your early-warning system for new senders your organisation adds later (a new SaaS tool someone signs up for and starts emailing customers from, for instance).

Handling special cases

Three categories of sending pattern break DMARC in ways that plain SPF/DKIM fixes don't solve, and they deserve separate attention before you enforce.

Mail forwarding

When a recipient forwards your mail (e.g. a personal Gmail account with a corporate address forwarding to it), the forwarding server typically becomes the new sending IP, which breaks SPF (the envelope-from no longer resolves to an authorised sender IP for your domain). DKIM, however, signs the message content and headers, so a correctly configured DKIM signature usually survives forwarding intact and still passes DMARC via DKIM alignment alone.

1. Confirm your outbound mail is DKIM-signed with proper alignment (Phase 1 DKIM steps) - this is your safety net against forwarding breaking SPF.
2. If a specific known forwarding destination keeps failing even DKIM (some forwarders rewrite the body, e.g. adding a footer, which invalidates the signature), there is no DMARC-side fix - this is a limitation of DMARC that ARC (Authenticated Received Chain) exists to address, but ARC adoption is inconsistent across mailbox providers.
3. Don't hold your whole rollout hostage to one edge-case forwarder. Track it, understand the volume, and make an informed call before enforcing.

Mailing lists

Mailing list software (list servers, community platforms) commonly rewrites the subject line, adds a footer, and re-sends using the list's own envelope domain - all of which can break both SPF and DKIM alignment for the original sender.

1. Check whether your mailing list provider offers a "DMARC-friendly" or "from-munging" mode, which replaces the From address with the list's own domain and moves your original sender into Reply-To - this avoids DMARC failure entirely because the mail is no longer claiming to be from your domain.
2. If the list can't do that, and it's a low-stakes list, accept it will fail DMARC and factor its volume into your pct decisions - don't let it block enforcement of everything else.
3. If it's a high-stakes list (e.g. a customer-facing distribution list run from your primary domain), consider moving it to a dedicated subdomain with its own, separate (looser) DMARC policy rather than letting it hold back your primary domain's enforcement.

Third-party senders

Any SaaS product, contractor or partner sending email "from" your domain needs the same SPF/DKIM onboarding as your own internal tools.

1. Treat every newly discovered third-party sender in Analytics as an onboarding task, not a nuisance - someone in your organisation is using it for a reason.
2. Where practical, insist third-party senders send from a clearly identified subdomain (e.g. updates.example.com) rather than your root domain, so a compromised or misconfigured third party can't damage your primary domain's reputation.
3. If a third party refuses or cannot configure custom DKIM, its mail will only pass via SPF - make sure its sending IP ranges are included and kept current in your SPF configuration.

A realistic timeline

Every domain is different, but as a planning baseline:

• Weeks 1-2: Record live, reports flowing, initial source inventory built.
• Weeks 2-6: Fixing SPF/DKIM alignment for each discovered source, including waiting out at least one full monthly billing cycle.
• Weeks 6-8: Quarantine ramp (10/25/50/100%).
• Weeks 8-11: Full quarantine review period.
• Weeks 11-13: Reject ramp (10/25/50/100%).
• Week 13 onward: Full enforcement, ongoing monitoring.

Note: For a small, simple domain with few sending sources, this can compress to 4-6 weeks total. For a large organisation with dozens of departments each running their own SaaS tools, 4-6 months is common and entirely normal. Rushing it does not make you more secure faster - it makes you more likely to break something and have to roll back, which erodes trust in the project internally.

Two example profiles

Small business, one office, one email platform (e.g. Google Workspace only, no third-party marketing tools):
Discovery is nearly trivial - there's usually one source to verify. A realistic path is two weeks at p=none to confirm nothing unexpected shows up, a one-week quarantine ramp, a two-week quarantine hold, and a one-week reject ramp - full enforcement inside roughly 6 weeks.

Mid-size company, multiple departments, marketing platform, helpdesk, invoicing tool, HR/payroll system, several contractors sending on the company's behalf:
Expect discovery alone to take 4-8 weeks, because infrequent senders (annual contract renewals, quarterly board reports, one-off recruiting campaigns) only reveal themselves once they actually fire. Budget 3-4 months end to end, and don't be surprised if a "new" sender turns up in Analytics even after you thought discovery was complete - this is normal, not a failure of the process, and is exactly why Alerts stays on permanently rather than just during rollout.

Change management: who to loop in before you flip the switch

DMARC enforcement is a technical change with organisational consequences - it can silently affect departments who have no idea DNS records exist. Treat it as a small change-management project, not just a DNS edit.

1. Before starting discovery, ask every department head (marketing, finance, HR, sales, IT) what tools send email "as" the company, rather than relying purely on what shows up in reports. This surfaces low-volume senders (an annual conference invite tool, a once-a-year audit platform) faster than waiting for them to appear organically in Analytics.
2. Before ramping to quarantine, notify whoever handles customer support that some previously-delivered mail may start landing in recipients' spam folders during the ramp - this is expected and is the mechanism working, not a bug, but support staff fielding "where's my invoice" tickets need to know why.
3. Before ramping to reject, notify the same stakeholders that failing mail will now be dropped rather than delivered to spam - the stakes of a missed sender go up a level, so it's worth a final "does everyone still recognise every item on this list" check-in.
4. After reaching full enforcement, hand ongoing monitoring duty to whoever owns Alerts day to day (usually IT/security) so a newly adopted SaaS tool doesn't sit failing DMARC indefinitely before anyone notices.

Verify it worked

Once you've reached p=reject; pct=100, confirm the following:

1. Open Lookup, query _dmarc.example.com, and confirm the served record shows p=reject; pct=100.
2. Send a deliberately misaligned test (e.g. via the header-spoofing test in the free DMARC tools) to a mailbox you control at a major provider, and confirm it is rejected or lands in spam with an "authentication failed" annotation rather than your inbox.
3. Check Analytics for the past 7 days and confirm your legitimate sending sources still show a pass rate at or near 100%.
4. Check Reports for any disposition=reject entries and confirm every one traces to a source you don't recognise or have already identified as unauthorised - not a legitimate sender.
5. Check Threats to confirm spoofing attempts against your domain are now showing as rejected rather than delivered.
6. Confirm Alerts is still active and configured - enforcement isn't a "set and forget" state, new senders can appear at any time.

Common problems and fixes

A legitimate sender suddenly starts failing after a quarantine/reject percentage increase.
Drop pct back to the previous step immediately in DMARC, fix the sender's SPF/DKIM alignment using the Phase 1 steps, confirm clean for several days, then resume ramping.

DKIM shows "pass" in the raw report but DMARC still fails overall.
The DKIM signature is valid but not aligned - check the d= domain in the signature against your header-from domain in Reports. A signature signed by a vendor's own domain (e.g. d=vendor.com) will never align to example.com; the vendor needs to sign with your domain via a custom DKIM selector.

SPF fails intermittently for a known sender.
Usually means the sender added new sending IP ranges that haven't been added to your SPF include. Check the sender's published SPF documentation for updates and refresh the include in SPF; DMARC Engine's auto-flattening handles the lookup-count housekeeping for you.

A new, unrecognised source appears in Analytics after enforcement is already at 100%.
Investigate before assuming malice - it's frequently a new tool someone in the business just adopted. If it's confirmed illegitimate, check Threats for pattern details and take no DNS action (reject is already handling it). If it's legitimate, onboard it via Phase 1 SPF/DKIM steps, but note it will fail until fixed - this is fine at pct=100 reject since it's genuinely unauthenticated mail being rejected as intended, you just now need to authenticate it.

Mail to one specific recipient domain keeps failing despite correct SPF/DKIM.
Often forwarding-related (see the forwarding section). Check whether that recipient uses a forwarding service and whether your DKIM signature would survive forwarding (no body rewriting by your own systems, footers added post-signing, etc.).

Reports stopped arriving entirely.
Re-check the CNAME with Lookup - a DNS change elsewhere (migrated registrar, edited zone file) can accidentally remove or break the delegation record. Republish the _dmarc CNAME shown on your domain's DMARC page if it's missing.

Percentage ramp feels too slow / too cautious for a low-risk domain.
For a domain with very few, well-understood senders (e.g. a small business using only Google Workspace), it's reasonable to compress the ramp schedule - but never skip straight from p=none to p=reject; pct=100 in one move regardless of how simple the sending profile looks.

FAQ

How long does the whole journey take?
Anywhere from 4 weeks for a simple domain with one or two sending sources, to several months for a large organisation with many departments and third-party tools. The timeline table above is a reasonable planning baseline; let evidence in Analytics, not a calendar, decide when to move to the next step.

Can I skip p=quarantine and go straight from p=none to p=reject?
Technically yes, but it removes your safety margin. Quarantine sends failing mail to spam, where it's recoverable; reject drops it, often silently. Always ramp through quarantine first.

What does pct actually do - does it randomly sample messages?
pct tells receiving mail servers what proportion of messages that fail DMARC should have the stated policy applied; the remainder is treated as if the policy were none. It applies per-message at the receiver's discretion, not as a guaranteed exact percentage, so treat it as an approximate dial rather than a precise switch.

Do I need p=reject on subdomains too, or just the root domain?
Both matter. A DMARC record's sp tag governs the default policy for subdomains that don't publish their own record. Leaving sp at none while the root domain enforces reject leaves subdomains as an open spoofing target - see Protecting subdomains with DMARC for how to set this up.

Will DMARC enforcement stop all phishing that mentions my brand?
No - it only stops mail that spoofs your exact domain in the header-from address. Lookalike domains (e.g. examp1e.com) are a separate problem; DMARC doesn't cover those. Use Threats to monitor domain-spoofing attempts specifically.

What happens to mail from a source I forgot to onboard once I hit p=reject?
It gets rejected outright by receivers that enforce DMARC (most major mailbox providers do). This is exactly why the discovery phase and the pre-reject review period matter - the cost of a missed sender rises sharply at each stage of enforcement.

Can I lower the policy back to p=none if something goes wrong after reject?
Yes, at any time, via DMARC - DMARC Engine updates the served record instantly since it's a hosted CNAME delegation, no propagation delay to wait out on your own DNS. Use this as a genuine safety valve if you discover a serious unonboarded sender post-enforcement, then fix the sender and resume the ramp.

Do RUA reports keep working the same way after I reach p=reject?
Yes - reporting is independent of enforcement. Keep rua= configured permanently so you retain visibility into new senders and any spoofing attempts, using Analytics and Threats as your ongoing monitoring surface.

I only have one or two sending sources - can I move faster than this guide suggests?
Yes. The ramp schedule and review windows in this guide are conservative defaults for typical multi-sender organisations. A domain with a single, well-understood sending platform can reasonably compress the timeline, provided each pct step still gets checked against Analytics before advancing.

Does moving to p=reject affect my email deliverability or sender reputation positively?
Indirectly, yes. Full DMARC enforcement is one of the signals major mailbox providers use when assessing domain trustworthiness, and it's an increasingly common requirement for bulk senders (Gmail and Yahoo both require DMARC records at minimum for high-volume senders). It won't fix an unrelated reputation problem, but it removes one class of risk - spoofed mail sent from your domain damaging your reputation without your knowledge - that you otherwise have no visibility into at all.

What's the difference between the DMARC policy and the SPF/DKIM records themselves?
SPF and DKIM are the authentication mechanisms - they let a receiver check whether a message really came from an authorised source. DMARC is the policy layer sitting on top: it tells receivers what to do when SPF and DKIM both fail to align, and where to send reporting data about the outcome. You need all three configured; DMARC on its own with no SPF or DKIM has nothing to key its pass/fail decision off and every message will fail.

Should I set adkim=s and aspf=s (strict alignment) as part of this rollout?
Not as a default. Strict alignment requires the signing/envelope domain to match your header-from domain exactly, including subdomain - mail.example.com would not align strictly against a header-from of example.com. Relaxed alignment (the default, and what the hosted record uses) accepts any subdomain match, which is what almost every organisation actually wants. Only tighten to strict once you've confirmed every sender signs with the exact domain and you have a specific reason (typically a compliance requirement) to do so.

A short glossary

• Alignment - whether the domain that passed SPF or DKIM matches the domain shown to the recipient in the header-from address. Passing without alignment does not satisfy DMARC.
• Aggregate report (RUA) - the daily XML summary of authentication results sent to the address in your DMARC record's rua= tag.
• Forensic report (RUF) - an optional, per-message failure report; rarely sent by receivers and not required for this rollout.
• Disposition - the action a receiver actually took on a message (none, quarantine, reject), as recorded in the aggregate report.
• pct - the percentage of failing mail a policy is applied to; the ramp lever used throughout this guide.
• sp - the DMARC policy applied to subdomains that don't publish their own record.
• Envelope-from (Return-Path) - the address SPF actually checks; can differ from the visible From address a recipient sees.
• Header-from - the From address a recipient sees in their mail client; what DKIM and DMARC alignment are checked against.