Residents receive forged messages that appear to come from [email protected] asking for gift-card payments. Which email-security controls best help receiving systems detect and reject that domain spoofing?

SPF, DKIM, and DMARC form the standard email-authentication triad for the city.gov mail domain. SPF publishes which hosts and services may send mail for the domain, DKIM attaches a cryptographic signature tied to DNS, and DMARC tells receiving systems how to handle authentication failures—monitor, quarantine, or reject—while returning aggregate and forensic reports. Publishing and enforcing that set helps receivers detect and reject forged [email protected] gift-card lures that merely spoof the visible From header without authorized infrastructure or valid signatures.

Removing all MX records breaks legitimate delivery and validation rather than solving organizational-domain spoofing at receivers. Disabling TLS on SMTP weakens confidentiality in transit and does nothing to implement domain authentication; it can even make message tampering easier. Forwarding every inbound message to a shared unmonitored mailbox ignores spoof detection and creates negligent handling of resident communications.

Exam caveat: roll DMARC from p=none to quarantine and then reject only after every municipal sender—including cloud ticketing, newsletters, and help-desk platforms—passes SPF or DKIM alignment. Lookalike domains (c1ty.gov style) need separate brand and DNS monitoring beyond DMARC on the real city.gov zone.

Operational check: inventory all senders into SPF, enable DKIM on the official MTA and SaaS mailers, publish DMARC with rua reporting, remediate alignment failures, advance policy to reject, and review reports weekly for remaining spoof attempts against city.gov.