Question and scenario
A company is consolidating several email providers under one sending domain. Explain DMARC alignment and the roles of RFC 9989, 9990, and 9991, then design validation and rollback from p=none to reject.
This fits platform, security, email-infrastructure, and cross-team incident-diagnosis roles. It tests protocol reasoning and rollout control; it does not require claiming that every receiver already implements every new RFC identically.
What the interviewer is testing
- Whether you separate the roles and inputs of SPF, DKIM, and DMARC.
- Whether you know that DMARC needs at least one passing, aligned SPF or DKIM path.
- Whether you can distinguish RFC 9989 core DMARC, RFC 9990 aggregate reports, and RFC 9991 failure reports.
- Whether you can tighten policy from observations instead of switching directly to
p=reject. - Whether you can handle forwarding, third parties, subdomains, report privacy, and rollback.
Clarifying questions before answering
- Is the protected identity one organizational domain or several subdomains, and what are the From, Return-Path, and DKIM d domains for each sender?
- What do SPF, DKIM, and DMARC pass and alignment rates look like by provider and subdomain, and can aggregate reports be received?
- Are marketing, transactional, and employee messages sent from the same domain, or can they be separated?
- Has receiver behavior been verified through tests and provider documentation, or are we only assuming standards support?
30-second answer framework
DMARC checks whether the visible From domain aligns with an authenticated SPF domain or DKIM d domain; at least one path must pass and align. RFC 9989 defines core DMARC, while RFC 9990 and RFC 9991 define aggregate and failure reports. Start with p=none as an observation mode, parse reports, repair provider, subdomain, and message-type alignment, then move gradually to quarantine and reject. Each step needs metrics, representative tests, and a fast rollback. A new RFC number is not evidence that every receiver produces identical reports today.
Step-by-step deep answer
1. Draw the three identity paths
SPF authenticates whether a sending server is authorized, usually using the SMTP envelope MAIL FROM domain. DKIM verifies a signature, with its d domain participating in alignment. DMARC evaluates the From domain visible to the recipient and applies policy based on alignment. These inputs differ, so one Authentication-Results line is not a substitute for checking the actual domains.
2. Judge alignment rather than a bare pass
The key DMARC condition is that SPF or DKIM passes and its authenticated domain aligns with From under the organization’s relaxed or strict mode. A provider can have SPF pass while its envelope-from is misaligned, or DKIM pass with a provider-owned d domain. Both require changing the domain, signature, or sending boundary.
3. Explain the 2026 RFC boundary
RFC 9989 is the core DMARC specification and replaces the historical positioning of RFC 7489. RFC 9990 describes aggregate reports for long-term source distributions, while RFC 9991 describes failure reports. Keep “the specification is published” separate from “every receiver emits the same reports”; verify concrete support with tests and provider documentation.
4. Design a gradual policy change
Publish p=none first with a controlled rua destination and an access-controlled analysis mailbox or pipeline. Aggregate SPF, DKIM, From, subdomain, and failure dimensions by sender, then repair legitimate sources. Use sp for carefully scoped subdomains or separate transactional and marketing subdomains. Move to quarantine only after legitimate traffic is stable and unknown sources are explainable, then consider reject.
5. Put verification and rollback in the change record
Save the DNS records, provider settings, and report baseline before each change. After tightening, watch legitimate delivery, DMARC pass, alignment failures, complaints, and report delay. Test forwarding, mailing lists, and attachments with real inboxes. If legitimate delivery falls, revert the previous policy or narrow the subdomain first, then determine whether propagation, DKIM signing, forwarding rewrites, or missing reports caused it.
High-quality sample answer
I would inventory every sender’s From, MAIL FROM, and DKIM d domain, then calculate pass and alignment by provider and subdomain. DMARC does not require SPF and DKIM to pass together; one passing, aligned path is enough. RFC 9989 owns the core policy, while RFC 9990 and RFC 9991 cover the two report types, whose receiver coverage must be measured rather than assumed. I would start at p=none, collect aggregate reports, fix third-party, forwarding, and subdomain issues, then tighten a scoped segment to quarantine before reject. Each step gets thresholds for legitimate delivery, alignment, and unexplained sources, plus a DNS rollback and subdomain isolation path. That makes the change auditable and limits harm when an assumption is wrong.
Common errors
- Declaring DMARC passed after SPF or DKIM pass without checking From-domain alignment.
- Treating SPF MAIL FROM, DKIM d, and visible From as the same field.
- Calling all three 2026 RFCs “the DMARC core” without separating report responsibilities.
- Switching to
p=rejectwithout a report baseline and blocking legitimate third-party mail. - Assuming forwarding preserves SPF or DKIM without testing lists and forwarding paths.
- Publishing report data without considering address and organization information in those reports.
Follow-up questions and responses
SPF passes but DMARC fails. What do you inspect first?
Compare the SPF authenticated domain with From and confirm relaxed or strict alignment. Then inspect subdomain inheritance, rewrites, and the real message headers; an authorized sending IP alone is not enough.
DKIM passes but fails after forwarding. What next?
Check whether the forwarder rewrites the body or signed headers and whether the d domain and selector still resolve. For uncontrolled forwarding, evaluate stable signing, list handling, and an isolated subdomain instead of hiding unknown sources by weakening policy.
How do you decide to move from quarantine to reject?
Use provider, subdomain, and message-type slices of reports to show sustained alignment, and complete forwarding, marketing, and transactional tests. Set thresholds for legitimate delivery, alignment failures, complaints, and unexplained sources, with a rollback window.
What matters when the report address is in another domain?
Confirm that the receiving domain explicitly authorizes the reporting relationship, and restrict access and retention in the report pipeline. Cross-domain reporting is not automatically a trusted data export.
Sources: RFC 9989, RFC 9990, RFC 9991, Google Gmail “Email sender guidelines,” and Dataford “Explaining Email Authentication Clearly” (full URLs are recorded in meta.json).