An organization wants receiving mail servers on the internet to reject messages that claim to come from its exact domain but were neither sent through its authorized servers nor signed with its keys. Which control should it publish?
Select an answer to reveal the explanation.
Short Explanation
SPF lists who's allowed to send for you, DKIM signs the mail, and DMARC tells the world what to do when a message fails both. Set it to reject and spoofed mail bounces at the receiver. The trap is the TLS-flavored records; they protect transport, not who's sending.
Full Explanation
DMARC is a DNS-published policy that tells receivers how to handle mail whose visible From domain fails authentication. A message passes DMARC when either SPF or DKIM passes and that result aligns with the From domain: SPF checks the sending IP against the domain's authorized senders, and DKIM verifies a signature made with the domain's private key. With p=reject, receivers that honor DMARC refuse messages that fail, which directly stops exact-domain spoofing; aggregate reports let the owner find legitimate senders before enforcing. MTA-STS tells other servers to require TLS with a valid certificate when delivering mail to the domain, protecting inbound transport from downgrade and interception, not stopping forged senders. DNSSEC signs DNS records so resolvers can detect tampered answers; a signed MX record protects mail routing to the domain but says nothing about mail claiming to come from it. TLS-RPT requests reports on TLS delivery failures and is a monitoring aid for MTA-STS. Exam caveat: DMARC protects only the exact domain, so look-alike domains need separate monitoring. Operational check: start at p=none, review aggregate reports until all legitimate sources pass aligned SPF or DKIM, then move through quarantine to reject.