sendmsg() the POSIX socket call

What sendmsg() actually does

The C signature is:

ssize_t sendmsg(int sockfd, const struct msghdr *msg, int flags);

You hand it a socket descriptor, a pointer to a struct msghdr, and some flags. The struct is what makes sendmsg() more capable than its siblings send() and sendto():

struct msghdr {
    void         *msg_name;       // destination address (datagrams)
    socklen_t     msg_namelen;
    struct iovec *msg_iov;        // scatter-gather buffers
    size_t        msg_iovlen;
    void         *msg_control;    // ancillary / control data
    size_t        msg_controllen;
    int           msg_flags;
};

Three capabilities this gives you that the simpler calls cannot:

1. Scatter-gather I/O

You can send the contents of multiple non-contiguous buffers in a single syscall. Saves you a memcpy when your header lives in one place and the payload sits somewhere else. High-throughput packet engines lean on this for hot paths where every avoided copy matters.

2. Ancillary (control) data

This is where the syscall gets interesting. You can pass things alongside the message that the wire never sees. Most famously, file descriptors. Sending an open file descriptor from one process to another over a Unix domain socket is done via sendmsg() with an SCM_RIGHTS control message. There is no other portable way to do this. It is how privilege separation, fd-passing supervision trees, and process-handoff designs work on Linux and BSD.

3. One call covers both connected and connectionless sockets

send() requires a connected socket. sendto() requires you to pass a destination on every call for datagram sockets. sendmsg() handles both through the same struct, which is one reason kernel-internal code and high-level libraries tend to standardise on it.

sendmsg() vs send() vs sendto()

The simplest mental model:

• send(fd, buf, len, flags) — single buffer, connected socket only.
• sendto(fd, buf, len, flags, addr, addrlen) — single buffer, lets you specify a destination per call (UDP, etc.).
• sendmsg(fd, msg, flags) — everything sendto() does, plus scatter-gather, plus ancillary data.

In practice nobody reaches for sendmsg() until they need one of those capabilities. If you are writing a regular TCP client, send() or write() is fine. If you are writing an SCM_RIGHTS-based privilege separator, a vectored I/O fast path, or a userspace packet engine, this is the syscall you reach for.

A common mistake

The return value is the number of bytes successfully queued for transmission by the kernel — not the number of bytes the receiver actually got. For datagram sockets you typically see the full message length or -1. For stream sockets you can get a short write, and your application has to loop on the remainder. Assuming a single sendmsg() call delivered everything because it did not return -1 is the most common bug in code that uses it.

Why our email platform is called sendmsg.io

Two reasons, in this order:

1. The literal meaning. sendmsg() sends a message. We send messages. Email, SMS, WhatsApp — at the lowest layer they all reduce to a sendmsg() or send() call against an open socket somewhere in the stack. The name is a nod to that base case.
2. The verb is in the brand. Mailchimp is a noun. Postmark is a noun. Send message is what the customer actually wants to do, so we put the action front and centre.

We are not affiliated with the Linux kernel, the IEEE POSIX working group, or any of the man-page maintainers cited above. If you came here looking for the syscall reference, the Linux man page for sendmsg(2) is the canonical source. If you came here for the email infrastructure platform, the homepage and the transactional email API are the right starting points.