SendSecure — A Dated Record of Who You Sent Your Music To, and When It Was Opened

SendSecure records who you sent a music file to, when it was delivered, and when their copy was opened.

What you get is a record: a named recipient, the file and version they received, and dated events for delivery and opening.

It exists for one job — documenting access. Access is one of the things a US copyright infringement claim has to establish, and it is a recurring reason claims fail. The Ninth Circuit states the test this way:

"To prove access, a plaintiff must show a reasonable possibility, not merely a bare possibility, that an alleged infringer had the chance to view the protected work."

Art Attacks Ink, LLC v. MGA Entertainment Inc., 581 F.3d 1138, 1143 (9th Cir. 2009), quoted in Loomis v. Cornish, 836 F.3d 991, 995 (9th Cir. 2016)

A delivery record is one piece of evidence a court may weigh toward that finding. It is not the finding. The rest of this page is about where exactly that line sits — the part nobody else in this category writes down, and the reason the claim above is worth anything.

Included in a SongSecure subscription: $9.95 a month, or $97 a year.

Which record do you actually need?

Two products, two questions. They get conflated constantly, including by search engines.

You need to show… Use What it records
You had the song first SongSecure registration A SHA-256 hash of your file anchored to a public blockchain — a dated record that this exact file existed by this date
You sent it to a particular person SendSecure Who it went to, when it was delivered, when their copy was opened, and which version

Registration answers when. SendSecure answers who. Most people who need one eventually need both. If you are choosing, register first: a delivery record of a file you cannot date is half a record.

What the record contains

One record per recipient. Send to five people and you have five records, each with its own events.

  • Recipient — by name and email address, as you entered them
  • File and version — so a later send of a revised mix is a separate record rather than an overwrite
  • Delivered — the date and time the file was made available to that recipient
  • Opened — the date and time it was first opened, and each subsequent open
  • Sender and record date — you, and the moment the record itself was written

That is the list. Nothing in it describes what the recipient thought, whether they played the audio to the end, or who they spoke to afterwards. A record claiming those things would be a record of something no software can observe.

What a record looks like

Of the competitor and adjacent-product pages we examined on 13 August 2026, every one describes its record and none shows one. Here is ours — the names are invented, the fields are the fields.

SendSecure delivery record
────────────────────────────────────────────────────────
Record ID        SS-2026-04817
File             Bright_Room_master_v3.wav
Version          v3
Sent by          jordan@example.com
Recipient        A. Whitfield — a.whitfield@examplerecords.com
Delivered        14 March 2026, 09:41 UTC
First opened     14 March 2026, 16:07 UTC
Later opens      17 March 2026, 11:22 UTC
                 02 April 2026, 08:55 UTC
Record written   14 March 2026, 09:41 UTC
────────────────────────────────────────────────────────

Read literally, that says a great deal: a named person was sent a specific version of a specific file on a specific day, and something at their end fetched it seven hours later and twice more over three weeks. Read just as literally, it says nothing about whether A. Whitfield liked the song, played it, or mentioned it to a songwriter. Both readings are correct, and the second is why the first is credible.

What this proves, and what it does not

The record establishes The record does not establish
That a named recipient was sent a specific file, on a specific date That they listened to it, or heard any part of it
That their copy was opened, and when That the named recipient was the person who opened it
Which version they received That they understood it, remembered it, or were influenced by it
That the record was written on the day of the send, not reconstructed afterwards That they, or anyone else, later copied it
That anyone else at their organisation ever saw it
That a court has found access, or will
That the record is admissible — that is a ruling, made case by case

An open event is a file being fetched. It is not a person hearing a song. We say opened, and never heard, listened or read, because those are different things and only one of them is in the log.

The same care applies to the word who. The record shows that the copy sent to a named recipient was fetched. It cannot show who was at the keyboard when it happened — no delivery product can, and any that says otherwise is describing something software does not observe.

Loomis v. Cornish: the case where delivery was not in dispute, and the claim failed anyway

Will Loomis wrote "Bright Red Chords." In May 2010 an Artists and Repertoire representative at UMG Recordings, Sunny Elle Lee, asked the band for a copy, and, as the Ninth Circuit recorded it, "The band furnished Lee a copy of the song." Loomis later sued over Jessie J's "Domino." Delivery to a major-label A&R representative was accepted as fact. He still lost:

"On the record before us, there is no evidence of a nexus between Lee and the Domino songwriters that would be sufficient to raise a triable issue of access."

Loomis v. Cornish, 836 F.3d 991, 996 (9th Cir. 2016)

Lee, the court noted, "was not part of the work unit that created Domino." Quoting Jorgensen v. Epic/Sony Records, the same opinion states the rule: "Bare corporate receipt …, without any allegation of a nexus between the recipients and the alleged infringers, is insufficient to raise a triable issue of access."

A delivery record proves delivery to the person you sent it to. It proves nothing about anyone else. That is not an argument against keeping one — it is an instruction about how: send to a named person, and write down who they are, what they do, and who they work with. A record naming an individual and their role is worth more than a record naming a company inbox, and this is the case that shows why.

Why the date is the whole point

Bowen v. Paisley, M.D. Tennessee, 25 August 2016. Amy Elizabeth Connor Bowen — who wrote in Nashville as Lizza Connor — had as her best access evidence a real email containing an actual recording of her song: admissible, uncontested, and attached to the work itself. The court:

"…she fails to acknowledge that this communication took place in October 2011, well after both the creation and public release of the Paisley Work. The email exchange therefore could not establish access for purposes of copyright infringement."

Her evidence failed on its date and nothing else. A record made at the moment of sending is the one thing that cannot be assembled after a dispute starts, and sequencing is the single thing a delivery log genuinely settles.

Bowen lost the case anyway, on substantial similarity — the only thing the two songs shared was the phrase "remind me." Her documentation answered when and who, and those were not the questions she lost on.

What we found in 197 court decisions

We read every US music copyright decision we could find from 2015 to 2026 — 197 decisions, 108 of them merits rulings across 82 disputes, screened independently by two coders (κ = 0.8297, n = 203, 95% CI 0.7502–0.9010).

Access is a recurring reason these claims fail. In the decisions we read, the failure was more often about the connection between the recipient and the writers than about whether a file changed hands — that is our reading of the decisions, hand-counted by one reader, and not part of the coded screen, which records inclusion only. Loomis is the case we quote because it puts the point most plainly.

Not one of those 197 decisions discussed a blockchain record, a cryptographic timestamp, or a trusted timestamping service. No court in that set was asked. Nor are we aware of a reported US music copyright decision assessing a delivery record produced by a service of this kind. That is not evidence a court would accept it, and not evidence a court would reject it — the question is open, for us and for everyone else in this category. Read the full analysis.

How to use it

  1. Register the file first. Hash it before it leaves your machine. A delivery record is stronger attached to a dated file than floating alone.
  2. Send to a person, not a role. demos@ inboxes give you a record of delivery to a company, and Loomis is what that is worth. More on the practicalities: how to share a demo with a label, producer or collaborator.
  3. Write down who they are — name, job, label or studio, and how you got the introduction. The record captures the send; you capture the context.
  4. Keep what comes back. A reply, a rejection, silence: all three are useful, and the rejection is often the most useful, because it is the recipient confirming receipt in their own words.
  5. Send each revision as a new send. "Which version did they have" is a real question in a real dispute. If it ever becomes one, hand your lawyer the record together with the original file, not instead of it.

What it costs

$9.95 a month, or $97 a year, with SendSecure included — no separate charge, no per-file fee, no limit on how many files you send or register.

U.S. Copyright Office registration is a separate and unavoidable expense: $45 for a single work, $65 standard, $85 for a group of up to 10 unpublished works, $65 for an album of up to 20. You should be paying that too. It buys things a subscription cannot.

How it compares

SendSecure Email read receipt File-sharing view counts USCO registration
Names the recipient Yes Yes Often aggregate only n/a
Records an open, with a time Yes Only if the recipient allows it Usually a count, not a person n/a
Records which version was sent Yes Only if you kept the attachment Per file n/a
Lets you file a US infringement suit No No No Yes, and only this does
Better than us at Free, and carries the recipient's own words Built into tools recipients already use Everything a court requires before you sue

A kept email is already a delivery record. What this adds is the open event, per recipient, in a form you can still produce years later without doing archaeology in a mailbox.

Questions

Does SendSecure prove someone listened to my song?
No. It records delivery to a named recipient and the times the file was opened. An open event is a file being fetched by a browser or a client — not evidence that a person listened, understood, remembered, or copied anything.

Does a SendSecure record prove access in a copyright case?
No. Access is a finding a court makes on the whole record, and a delivery record is one piece of evidence a court may weigh toward it. In Loomis v. Cornish, 836 F.3d 991 (9th Cir. 2016), the Ninth Circuit accepted that the band had furnished the song to a UMG A&R representative, and the claim still failed: "there is no evidence of a nexus between Lee and the Domino songwriters that would be sufficient to raise a triable issue of access."

Is a SendSecure record legally admissible?
Admissibility is a ruling a judge makes about a specific exhibit in a specific case, after both sides have argued about it. No product is admissible in advance, and we do not describe SendSecure as one. What we can tell you is what the record contains, and when each event was written.

Does this replace registering my song with the U.S. Copyright Office?
No. Circular 1: "Before an infringement suit may be filed in court, registration (or refusal) is necessary for U.S. works." And: "When registration is made prior to infringement or within three months after publication of a work, a copyright owner is eligible for statutory damages, attorneys' fees, and costs." SendSecure does not register anything.

What if they never open it?
The record shows a delivery with no open event, and that is what it says. It is still a dated record that you sent the song, written on a date you did not pick after the fact.

Does it matter who I send it to?
More than anything else about the record. Quoting Jorgensen v. Epic/Sony Records, the Ninth Circuit in Loomis wrote: "Bare corporate receipt …, without any allegation of a nexus between the recipients and the alleged infringers, is insufficient to raise a triable issue of access." Send to a named individual, and note their role and who they work with.

Is a SendSecure record better than just emailing the file?
An email you still have is already a delivery record, and a good one. What SendSecure adds is a per-recipient open event and a record you do not have to reconstruct from a sent folder years later. If you only ever do one of the two, keep the email.

What does it cost?
$9.95 a month or $97 a year, SendSecure included, no per-file charge.


Last updated: 13 August 2026.

Legal note

This page is informational and is not legal advice. It quotes court decisions and official guidance; it does not tell you how any of them apply to your situation. SongSecure is not a law firm. No record, from SongSecure or anyone else, guarantees any legal outcome.

Sources

Loomis v. Cornish, 836 F.3d 991 (9th Cir. 2016) · Art Attacks Ink, LLC v. MGA Entertainment Inc., 581 F.3d 1138 (9th Cir. 2009) · Jorgensen v. Epic/Sony Records, 351 F.3d 46 (2d Cir. 2003) · Bowen v. Paisley, M.D. Tenn., 25 August 2016 · 17 U.S.C. §§ 411(a), 412 · U.S. Copyright Office, Copyright Basics (Circular 1) and current fee schedule · SongSecure frozen decision universe, 2015–2026: 203 records covering 197 distinct decisions, 108 in-scope merits decisions across 82 disputes, two independent coders, κ = 0.8297 (95% CI 0.7502–0.9010), measuring the inclusion screen and not any outcome variable.


JSON-LD

One block, one @graph, four nodes. No aggregateRating — see the note below. The limitations are written into the node descriptions and the FAQ answers, so an engine that lifts our markup lifts the qualification with it.

Schema choices, and why.

  • No aggregateRating and no review. This forfeits SoftwareApplication rich-result eligibility, which requires one of them. Deliberate: our only ratings are self-hosted, and marking them up reinforces the trust weakness engines already flag against us. Revisit only if a genuine third-party rating source appears.
  • SoftwareApplication and Service, two nodes, distinct @ids. The first is what Google documents and validates; the second is the more accurate description of what SendSecure is. Do not let this page inherit the site-wide defect of emitting two duplicate Article nodes — there is no Article node here and there should not be one.
  • FAQPage is kept for machine-readability only. Google dropped FAQ rich results on 7 May 2026 and removed Search Console API support in August 2026. The markup is still valid schema.org, still ingested by Bing and the RAG crawlers, and costs nothing. Expect no SERP appearance from it.
  • No priceValidUntil. A stale price is worse than no price, and nobody will maintain the field. The prices themselves appear as visible text on the page, as Google requires.
  • No offers.url on any of the four Offer nodes. They previously pointed at https://songsecure.com/pricing, which returns HTTP 404 on both the bare and trailing-slash forms (measured 13 August 2026, following redirects). offers.url is optional; a 404 in structured data is not. Restore it only when a pricing URL returns 200.
  • No isPartOf on SoftwareApplication. It pointed at https://songsecure.com/#organization; isPartOf expects a CreativeWork, and publisher already carries that relationship. Removed rather than retyped.
  • mainEntityOfPage and publisher/provider still reference #webpage and #organization, which are not nodes in this block. They resolve on merge only if the site's own output emits them on this URL. That must be checked against the rendered page, not assumed — see the pre-flight list.
  • No Product, no HowTo, no standalone Offer node. SendSecure is not a purchasable SKU with an availability state and a returns policy, and the page is not a procedure.
  • The limits live inside the markup. SoftwareApplication.description, Service.description and four of the eight FAQ answers each carry the boundary. Every one of those statements also appears in the visible copy.