GAO: Email Delivery Receipt Didn’t Confirm Proposal Submission

You might think that if you send an email with the delivery receipt option and the delivery receipt comes back, the email was delivered. But when an offeror submits a proposal by email, does a delivery receipt mean that the agency necessarily received the proposal in its inbox?

At least under the facts of one recent GAO bid protest, the answer was “no.” In that case, the GAO held that an email delivery receipt wasn’t sufficient to demonstrate that the agency received the electronic proposal.

In ManTech Advanced Systems International, Inc., B-414985, (Oct. 20, 2017), the GAO examined a proposal submitted by ManTech to provide cyber security services to the Air Force. ManTech submitted its proposal under a task order solicitation issued under the Air Force’s Cyber Security and Information Systems Technical Tasks IDIQ.

The task order proposals were to be submitted electronically via e-mail to the contract specialist, at the specialist’s email address, no later than 1:00 p.m. Central Daylight Time on July 17, 2017. The solicitation provided that receipt of proposals would be acknowledged by return e-mail.

ManTech sent its email with the proposal to the designated email address on July 17, 2017, at 1:25 p.m. Eastern Daylight Time (EDT) “and received confirmation of completed delivery through its Microsoft Outlook delivery receipt feature.”

Between 1:30 and 2 p.m. EDT, ManTech attempted to confirm receipt. First, it contacted the Air Force and learned the proposal had not been received, so ManTech resent the proposal to the designated inbox, the agency employee it had spoken to, and the contract specialist. Then it sent the email without the cover letter.

Finally, the agency told ManTech to stop trying because it was past the deadline. The agency later informed ManTech that, because the proposal hadn’t been received on time, the agency hadn’t considered ManTech for award.

ManTech filed a GAO bid protest challenging the agency’s decision. ManTech argued that the Air Force should have considered the proposal because the proposal was timely sent to the correct email address, and ManTech received confirmation that it had been received.

ManTech relied heavily on email tracking records from its Microsoft Outlook delivery system. ManTech submitted a declaration from its Director of Network Services to argue that “since it did not receive a bounce back indicating that the e-mail containing the proposal had been rejected, it must have been accepted by the agency’s e-mail exchange server.”

The Air Force responded by tracing the path of an email to its email system:

when an e-mail is sent to any recipient that is at an organization that is part of the Department of Defense, it is first scanned by the enterprise e-mail security gateway (EEMSG) for malicious content.  EEMSG delivers the e-mail to the recipient’s e-mail exchange server if no malicious content is found. The recipient’s e-mail exchange server then performs additional scans based on the specific policies of the recipient organization. The recipient’s server can block, quarantine, drop, or deliver the e-mail to the recipient’s e-mail box.  The Air Force reports that the e-mails sent by ManTech were received by the EEMSG system, which scanned them and attempted to deliver them to the specified Air Force e-mail address. However, based on the content, they were rejected by the Air Force server.  ManTech did not receive a bounce back because the EEMSG inbound system cannot initiate a connection to the internet.

GAO wrote that “[i]t is an offeror’s responsibility to deliver its proposal to the proper place at the proper time.” Moreover, the offeror “has the burden of showing that it timely delivered its proposal to the agency at the specified address.”

Here, “ManTech has demonstrated that it timely sent its proposal to the agency, and that it reached the EEMSG server.” However, “ManTech has failed to establish that its proposal was actually delivered to the agency’s designated e-mail prior to the time set for the receipt of proposals, and thus, has failed to meet its burden of showing the proposal was timely delivered to the agency.”

We have covered electronic timeliness issues on SmallGovCon before, as GAO seems to issue an opinion on the topic every six months. Most of these cases haven’t gone well for the protester. For example, GAO has denied a protest when an initial government server receives a proposal on time, but the proposal doesn’t make it to the final destination until after the deadline. The same result held even when the protester asserted the late email was the result of faulty government servers. And along the same lines (and pretty close to the result here), the GAO denied a protest where the offeror’s proposal was rejected by the agency’s spam filter.

To be clear, my colleagues and I here at SmallGovCon aren’t big fans of these decisions (or the decision in ManTech). Why should a contractor be punished if a government server malfunctions, or a government spam filter rejects a proposal, or (as here) the government server simply “rejects” the proposal after a scan? It seems to us that if the proposal is under government control at the time specified in the solicitation, that should be enough, in most cases, to require the government to evaluate it.

Encouragingly, the Court of Federal Claims may agree. As we discussed in the latter half of this post, the Court has issued several decisions that seem to be at odds with the GAO’s strict view. For companies like ManTech, the Court–not the GAO–is probably the better forum for a protest of this nature.

That said, offerors submitting proposals electronically should be aware of the tough rules that often apply.  As ManTech Advanced Systems International demonstrates, even an email delivery receipt may not be enough to prove that an electronically-submitted proposal actually arrived at the correct place.