SY0-701 Question 331
Single answerA company uses a cloud email gateway to filter inbound and outbound mail for the domain example.com. The security team has published an SPF record that authorizes the gateway and a third-party marketing platform to send mail for the domain. DKIM signing is enabled on the gateway, but the marketing platform signs messages with its own domain instead of example.com. The company then publishes a DMARC policy of p=reject for example.com. Soon after, customers report that marketing emails are being rejected, while normal employee email is delivered successfully. Which action is the BEST way to resolve the issue without weakening the company's anti-spoofing controls?
- A
Modify the marketing platform configuration so it uses DKIM signing aligned to example.com, or a properly aligned subdomain, for outbound campaigns
- B
Remove SPF entirely and rely only on DKIM because DMARC does not evaluate SPF when DKIM is present
- C
Change the DMARC policy from p=reject to p=none permanently so third-party mail is accepted
- D
Bypass the email gateway for all marketing messages so recipient servers will trust the vendor's original DKIM signature
Show answer and explanation
Correct answer: A
Explanation
This scenario tests practical understanding of how SPF, DKIM, DMARC, and email gateways interact in real deployments. DMARC builds on SPF and DKIM by requiring that at least one of them both passes authentication and is aligned with the domain in the message's visible From: header. A common failure occurs when a third-party sender is authorized to send mail but uses its own DKIM signing domain or a non-aligned return-path domain, causing DMARC to fail for the organization's domain. Employee mail succeeds here because the gateway signs on behalf of example.com, creating aligned DKIM. The best-practice fix is to configure the third-party service for aligned authentication rather than lowering the DMARC policy. Relevant guidance can be found in RFC 7489 for DMARC, RFC 6376 for DKIM, and RFC 7208 for SPF. Operationally, many vendors support custom DKIM signing for customer domains specifically to satisfy DMARC alignment requirements while still using an external sending platform.
- A. Correct.
Correct. DMARC requires identifier alignment for either SPF or DKIM to pass. Even if the third-party marketing platform is authorized in SPF, DMARC SPF alignment is evaluated against the visible From: domain. If the vendor signs with its own unrelated DKIM domain and its envelope sender/SPF identity is also not aligned with example.com, DMARC will fail and messages can be rejected under p=reject. Configuring the marketing service to sign with DKIM using example.com or an aligned subdomain is the best fix because it preserves the protective value of DMARC while allowing legitimate third-party mail.
- B. Incorrect.
Incorrect. DMARC can pass through either aligned SPF or aligned DKIM; it does not ignore SPF just because DKIM exists. Removing SPF would reduce protection and could break legitimate sending scenarios. This option reflects the misconception that DMARC only cares whether some DKIM signature is present, when in reality alignment with the From: domain is the key requirement.
- C. Incorrect.
Incorrect. Setting DMARC to p=none would stop enforcement and likely allow the marketing mail through, but it would also weaken the organization's anti-spoofing posture by making DMARC monitoring-only. The scenario asks for a solution that does not weaken controls, so permanently reducing enforcement is not the best answer.
- D. Incorrect.
Incorrect. Recipient servers do not inherently trust a vendor's DKIM signature just because a message bypassed the sender's gateway. DMARC still evaluates alignment between the visible From: domain and the SPF/DKIM identities. Bypassing the gateway could also remove security inspection, logging, and policy enforcement. This option confuses transport path with authentication alignment.