Publish SPF, DKIM, and DMARC

Scenario

Ticket SEC-2318: finish Northwind Traders' email authentication after Monday's spoofing incident. You are Riley Chen, Northwind's IT administrator. On October 26, customers received invoices from billing@northwind-traders.example that Northwind never sent, asking them to pay into a new bank account. Northwind moved its mail to MailRoute on October 20. A colleague started the DNS changes for the move before going on leave and never finished them, and Northwind's DMARC policy still asks receivers to take no action on mail that fails. Sign in: open Microsoft Edge, go to dash.zoneharbor.example (ZoneHarbor, Northwind's DNS host), and sign in as riley.chen@northwind-traders.example with the password Harbor#Mail-26. The zone is northwind-traders.example. Requirements: • Enforcement. Leadership wants receiving servers told to reject mail that fails DMARC: not quarantine it, and not only report it. The security team has read a month of DMARC reports, and MailRoute is Northwind's only legitimate sender. Keep the reports going to dmarc@northwind-traders.example. • Signing. MailRoute already signs every outgoing message with DKIM, but receivers can't verify a signature until its public key is published. MailRoute's setup file, mail-dns-records.txt in your Desktop folder, lists the DNS values MailRoute needs, the DKIM selector and key among them. Publish the key exactly as MailRoute gives it. • Authorized senders. The old provider, oldmail.example, was shut off on October 20 and no longer sends mail for Northwind. SPF must authorize MailRoute's servers, and mail from any other server must fail SPF outright, not soft-fail. • The website and inbound mail keep working: the A record, the www alias and the MX record stay as they are. You can check what is published from this PC: nslookup in a Command Prompt queries the zone. Grading is on the zone's final records.

These instructions stay visible beside the lab while you work.You can reread these instructions in the lab at any time.