http://en.wikipedia.org/wiki/DKIM
As far as I understand it, you can't fake being an SMTP server sending mail from such a domain because their emails get signed with a private key whose matching public key is published by DNS.
• If you can break DNS, you can get an NXDOMAIN reply, making recipients think there aren't any domainkeys
• If the domainkey private key is small, you can factor it. There's an article on HN's frontpage right now about this.
• If the server uses domainkeys, but it doesn't specifically verify the From: header, an attacker can still forge a message if they share a popular mail provider with their target. I don't know if this is still practical.
• Stupidity. DKIM is difficult to test, and as a security measure it would need to be tested.
An autoreponse confirmation would be immune to all of these attacks and would be trivial to implement correctly.
To clarify this a little, in case anyone isn't familiar, to send an email message programmatically, you basically just send a string with some headers and body content to the email server. Here are what the headers look like:
To change the sender, all you'd need to do is change the from line. For example: A default sendmail implementation will deliver that message all day. Email headers should never be used for authentication.