Your mail server just signed a contract. No human touched a keyboard.

When the server says yes before the lawyer can say no

B Corp’s CFO had just left the office on a Friday evening when the proposal landed. Software licensing terms from A Corp, with a single line buried in the fine print: “A reply confirming receipt of this offer shall constitute unconditional acceptance.” B Corp’s IT team had programmed the mail server to auto-acknowledge every message received after 6 PM. The server replied within seconds. By Monday morning, B Corp had a binding contract it never intended to sign — and no human had touched a keyboard.

That scenario is not hypothetical. It is the logical endpoint of Section 11(c) of the Information Technology Act, 2000, a provision that most corporate legal teams have never stress-tested. The statute attributes any electronic record to the originator if it was sent by an information system “programmed by or on behalf of the originator to operate automatically.” No human intent required. No signature. No second look. The machine’s reply is the company’s reply, and the company cannot later claim the machine acted without authority.

What the IT Act actually says about your server’s legal capacity

Section 10A of the IT Act, 2000, settled the question of electronic contract validity years ago. A contract formed through email, automated responses, or any electronic means is not unenforceable merely because it was formed electronically. The exchange of emails can constitute a valid contract when the essential elements of offer, acceptance, and consideration are present.

But Section 11 goes further. It creates three attribution pathways:

• The record was sent by the originator personally.
• The record was sent by a person authorised to act on the originator’s behalf.
• The record was sent by an information system programmed by or on behalf of the originator to operate automatically.

The third pathway is the trap. Most corporate counsel focus on the first two — who signed, who authorised, who had actual authority. The third pathway removes the human element entirely. If your procurement portal, your CRM, or your email server is programmed to generate replies without human review, those replies are your replies under law.

Three questions that change the cross

If you are advising a corporate client — or if you are the CFO or founder who signs off on IT procurement — here are the three moves that separate a defensible system from a ticking bomb.

1. Audit every auto-reply for contractual language.
The most dangerous auto-reply is the one that says “Thank you for your proposal. We confirm receipt and acceptance of your terms.” Even if your system is programmed to send that only to certain senders, the moment it fires, you have potentially accepted a contract. The fix is simple: every automated response must contain a disclaimer that the message is a system-generated acknowledgment only and does not constitute acceptance of any offer, proposal, or legally binding communication. The disclaimer should be the first sentence, not buried in a footer.

2. Segregate your communication channels by legal risk.
Not every incoming message carries the same weight. A customer support ticket is not a contractual proposal. But a procurement portal that auto-generates a “bid accepted” confirmation is. Corporations should designate specific computer resources for receiving and responding to contractual communications. Those designated systems should require human review before any affirmative reply is generated. General company-wide auto-reply systems should never be the channel through which contractual acceptances flow.

3. Train your IT team on what “programmed to operate automatically” means.
The IT team that configures your mail server or your e-auction platform does not think in terms of Section 11(c). They think in terms of uptime, latency, and user experience. But the legal risk is entirely in their hands. Every time they set a rule that says “if email from domain X, send reply Y,” they are creating a potential contract. Legal counsel should run quarterly training sessions with IT operations — not on the law generally, but on the specific scenarios where an automated reply can bind the company.

The counter-example that proves the rule

Consider what happens when the automated system is not programmed by the originator but by a third-party vendor. The attribution still flows to the originator under Section 11(c) if the system was programmed “on behalf of” the originator. This means that if your SaaS vendor configures an auto-reply feature as part of your subscription, and that feature generates a contractual acceptance, you cannot deflect liability by pointing at the vendor. The vendor acted on your behalf. The record is yours.

This is not a theoretical risk. In the kind of personal guarantee disputes that ended the Vijay Mallya bank cases, the question of who sent what communication — and whether it was automated — became central. Banks that used automated loan sanction systems found themselves arguing that the system’s output was not a “decision” but a “generated document.” Courts consistently rejected that distinction. If the system was programmed to generate the document, the document was attributed to the bank.

THE PLAY: Before your next IT system upgrade, have legal counsel review every rule that generates an outbound reply — and add a contractual disclaimer to every automated response that touches external counterparties.

What changed in 2025

Recent judicial decisions have clarified something that had been ambiguous: the timing of attribution. Courts have held that an electronic record generated by an automated system is attributed to the originator at the moment the system sends it, not at the moment a human reviews it. This closes the argument that “the system sent it but we hadn’t approved it yet.” Under this reading, the sending is the approval, because the system was programmed to send.

This has direct implications for the Friday-night scenario. If B Corp’s auto-reply fires at 8:47 PM on a Friday, the contract is formed at 8:47 PM on a Friday. The CFO cannot undo it on Monday by claiming the system was not authorised to accept contracts. The system was authorised to send replies. The reply was the acceptance. The contract stands.

If you’re in this spot: the three-step emergency protocol

If you discover that your company’s automated system has already generated a reply that could be construed as acceptance, here is the immediate playbook:

Step one: Do not delete or alter the automated reply. Spoliation of electronic evidence creates a separate liability. Preserve the log showing when and how the reply was generated.

Step two: Check whether the incoming proposal contained a clause that required a specific form of acceptance — for example, “acceptance must be signed by an authorised officer.” If it did, the automated reply may not satisfy the form requirement, and you may have an argument that no contract was formed. But do not rely on this. Courts have held that form requirements in proposals can be waived by conduct.

Step three: Immediately disable any automated reply rule that generates affirmative language. Replace it with a rule that sends only a neutral acknowledgment: “Your message has been received. No action is taken by this automated response.” Then have legal counsel review every remaining rule within 48 hours.

The bottom line

If your company operates any information system that generates outbound replies without human review, you have already delegated the power to form contracts to a machine. Section 11(c) of the IT Act, 2000, makes that delegation legally binding. The only question is whether the machine’s reply will ever intersect with a proposal that says “reply equals acceptance.” The fix is not expensive. It is not complicated. It is a disclaimer in every automated response and a rule that no contractual acceptance is ever generated by a system that does not require a human to press send. Do that this week. The Friday-night proposal is already in someone’s inbox.