Phishing Defense That Works: SPF, DKIM, DMARC and Real Training

Phishing works because email was never designed to prove who sent a message. Anyone can put your domain in the From field. The three records that fix this, SPF, DKIM and DMARC, have existed for years and most small business domains still have at least one of them wrong or missing.

Records protect your domain from being spoofed. They do not stop a lookalike domain or a compromised partner mailbox. That is where users come in, and user training only works when it is built around reporting, not shame.

SPF: who is allowed to send as your domain

SPF is a DNS TXT record listing the servers permitted to send mail from your domain. Receiving servers check the connecting IP against the list. It is simple, and it breaks in predictable ways: too many include statements exceed the 10 DNS lookup limit, and forgotten third-party senders get rejected.

Start by listing everyone who sends mail as you: Microsoft 365, your CRM, the accounting system, the marketing platform, the copier that scans to email. Each needs to be in the record or relayed through something that is.

• A Microsoft 365 tenant with one marketing tool looks like: v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net -all
• End with -all (hard fail) once you are confident. Use ~all (soft fail) only during rollout.
• Check lookup count with a tool such as MXToolbox or dmarcian's SPF surveyor. Over 10 and the record silently fails.
• Printers and line-of-business apps should relay through Microsoft 365 with a connector or through a dedicated SMTP relay, not straight out with your domain in the From field.

v=spf1 include:spf.protection.outlook.com -all

DKIM: a signature that survives forwarding

SPF checks the connecting server, which breaks when mail is forwarded. DKIM signs the message itself with a private key and publishes the public key in DNS. Forwarded mail still validates. Every sending platform needs its own DKIM setup, and Microsoft 365 requires you to publish two CNAME records and then enable signing.

In Microsoft 365, go to the Defender portal, Email and collaboration, Policies and rules, Threat policies, Email authentication settings, DKIM. Select your domain, copy the two CNAME records into your DNS, wait for propagation, then toggle Sign messages for this domain with DKIM signatures.

1. Publish selector1._domainkey and selector2._domainkey CNAMEs pointing at the values Microsoft shows.
2. Enable signing in the portal, or with PowerShell: New-DkimSigningConfig -DomainName yourdomain.com -Enabled $true
3. Send a test to a Gmail address and check the headers for dkim=pass.
4. Repeat for every third-party platform that sends as your domain. Each has its own selector and its own instructions.
5. Rotate keys yearly. Microsoft does this with Rotate-DkimSigningConfig.

Connect-ExchangeOnline
New-DkimSigningConfig -DomainName yourdomain.com -Enabled $true
Get-DkimSigningConfig -Identity yourdomain.com | Format-List Selector1CNAME, Selector2CNAME

DMARC: tell the world what to do with failures

DMARC ties SPF and DKIM together and tells receiving servers what to do when both fail: do nothing, quarantine, or reject. It also sends you reports showing who is sending mail as your domain, legitimate or not. Without DMARC, SPF and DKIM are advisory.

Roll it out in stages. Start at p=none with reporting on, read the reports for a few weeks, fix every legitimate sender that fails, then move to quarantine and finally reject.

1. Publish _dmarc.yourdomain.com TXT: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
2. Send the aggregate reports to a tool that parses them (dmarcian, Postmark's free DMARC digest, Valimail). Raw XML is unreadable at volume.
3. After two to four weeks with no legitimate failures, move to p=quarantine; pct=25 and step pct up to 100.
4. Move to p=reject. This is the setting that actually stops spoofing.
5. Add sp=reject so subdomains are covered, and consider adding a DMARC record with p=reject on parked domains you own but never send from.

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourdomain.com; fo=1

Training that changes behavior

The records stop people from pretending to be you. They do nothing against mail from a lookalike domain, from a real vendor whose mailbox was compromised, or from a personal Gmail address claiming to be the CEO. That is where users are the control, and most training programs make them worse at it.

Simulated phishing that punishes clickers teaches people to hide mistakes. The behavior you actually want is fast reporting, including reporting after a click. Design around that.

• Deploy the Microsoft Report Message add-in or your security vendor's report button to every Outlook client. One click, no form.
• Reply to every report within the business day, even if it is just 'thanks, that one was safe'. Silence trains people to stop reporting.
• Run simulations, but score the team on report rate, not click rate. Publish the report rate. Never publish who clicked.
• Teach three tells, not thirty: unexpected urgency, a request to change payment details or buy gift cards, and a login page reached from an email link. Everything else is detail.
• Enable Safe Links and Safe Attachments in Defender for Office 365 so the link is rewritten and scanned at click time, not just at delivery.

Frequently asked questions

Takeaway

Publish SPF with a hard fail, sign with DKIM on every platform, walk DMARC up to reject, and then build your training around the report button instead of the click. The records take an afternoon. The culture takes a few months of answering every report with a thank you.