Edit:

It seems the issue is that the to: field is signed, but the whole email can be forwarded afterward as though it were being sent from the source server to a person who wasn't actually a recipient.

In this case Google really did send an email to the strange domain, which then forwarded it to the recipient and made it seem as though it was coming from Google's server directly to the recipient.

This works as long as the recipient doesn't realize that they are not in the "to:" field.

▲

mzajc 2 days ago | parent | next [-]

> This means you can just copy a server's signature from a piece of mail it signed onto another piece of mail that it didn't send, and it will still look like it's been signed by the server and coming from that server.

DKIM signs both body and select headers. Unless those match, the signature verification will fail. TFA is about a replay attack.

▲

logicallee 2 days ago | parent [-]

Edit: thanks for the clarification.

	▲	mzajc 2 days ago \| parent [-]
		DKIM doesn't decide which headers are signed, the mail server does (in the h= field). Gmail signs both To and From[0], but these don't control the 'real' recipient - the RCPT TO command in SMTP does. The recipient would presumably show wrong in the mail client, but since mailing lists and aliases are a thing, this is not suspicious by default. [0] h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to;

▲

brongondwana a day ago | parent | prev [-]

Sadly, BCC is still a real thing, so the recipient system can't reliably tell that the recipient wasn't in the "to:" field and drop the message. That's one of the authentication holes that DKIM2 is planning to fix.