Why do SPF and DKIM fail to stop TOAD phishing?

Why transport authentication cannot detect a deceptive lure

SPF and DKIM answer a narrow question: did this message arrive from an authorised sender path, and was the signed content altered in transit? They do not evaluate whether the body is an invoice scam, callback fraud, or help-desk impersonation. That means a message can be authentic in transport terms and still be malicious in intent.

The practical limitation is that these controls are sender and message controls, not persuasion controls. A phish that uses a real mailbox, a compromised account, or a legitimate outbound platform can satisfy SPF and DKIM while still steering the recipient toward a fraudulent action.

How TOAD phishing bypasses SPF and DKIM by design

TOAD, or telephone-oriented attack delivery, shifts the “social proof” step away from email verification and toward a phone call or voicemail. The email often contains only enough context to trigger a callback, so the deceptive payload lives in the conversation, not in a malformed message header.

Because the attacker is exploiting the recipient’s trust in the apparent business process, not the cryptographic properties of the email itself, SPF and DKIM can be fully valid and still useless as a decision boundary. The attack succeeds when users treat authenticated mail as synonymous with legitimate intent.

• Valid sender authentication does not stop an attacker from using a real vendor, mailbox, or relay.
• DKIM can preserve a fraudulent message exactly as sent.
• The callback number, display name, and spoken script are outside SPF and DKIM’s scope.
• TOAD works best when the email only seeds urgency, authority, or payment anxiety.

What has to sit beside SPF and DKIM to block TOAD

Effective defence requires an intent layer that evaluates the request, not just the envelope. That can include callback verification through known numbers, payment-change callbacks through a separate channel, inline phishing detection, and user workflows that force high-risk requests through a second approval path.

For mail security teams, the key design point is that SPF and DKIM remain necessary hygiene, but they are not a fraud decision engine. The control stack has to detect suspicious business language, mismatched request patterns, and off-channel escalation before the recipient acts on the message.

Risk and Threat Considerations

TOAD phishing is dangerous because it turns a trusted communication channel into a trigger for human-mediated fraud. When defenders over-rely on SPF and DKIM, they create a blind spot where legitimate delivery becomes mistaken for legitimate intent.

Failure mechanism: The attacker uses authenticated email to prompt the victim to call a fraudulent number or continue the conversation through a channel the mail controls do not inspect. The malicious step happens after transport validation, so the email security layer sees a compliant message while the user enters the attack path.

Impact: Organisations can lose money, expose account data, or approve fraudulent changes even when their sender-authentication posture looks strong. The risk is highest where payment operations, help-desk resets, and supplier communications depend on fast human approval.

Practitioner Guidance

What to prioritise: Treat TOAD as a workflow abuse problem, not a mail-authentication problem. Any control that depends on a human making a phone call should assume the number in the message may be hostile unless it is independently verified.

What to verify: Check whether high-risk email requests are forced into a separate verification path, such as known-good callback directories, out-of-band confirmation, or payment-change approvals. If the only validation is “SPF passed” or “DKIM passed,” the workflow is still exposed.

Common mistake: Teams often tune phishing defences around spoofing, then miss attacks that use legitimate infrastructure and social engineering. That gap is especially costly when finance, executive support, or service desk teams can act on an email without a second trust check.

Practitioner takeaway: SPF and DKIM are authentication signals, not intent signals, so TOAD is prevented by constraining the action path, not by trusting the message path.

Related resources from NHI Mgmt Group

• Why do SPF, DKIM, and DMARC not stop this kind of phishing?
• What breaks when phishing investigations stop at SPF, DKIM and DMARC?
• How should security teams detect TOAD phishing when emails pass SPF, DKIM, and DMARC?
• Why do MFA and password resets fail to stop consent phishing?