Custom return path: the envelope address that makes SPF count toward DMARC

When one mail server hands a message to another, it starts with an envelope: a MAIL FROM command naming where failure notices should go, then RCPT TO for each recipient, and only then the message itself. That MAIL FROM address is the return path. RFC 5321 calls it the reverse-path; people also say envelope sender, bounce address, or mail from domain for the part after the @.

S: 220 mx.example.com ESMTP
C: EHLO out.mail.example.net
S: 250 mx.example.com
C: MAIL FROM:<bounce+7f3a9c@rasket.acme.example>
S: 250 2.1.0 OK
C: RCPT TO:<ronald.williams@example.com>
S: 250 2.1.5 OK
C: DATA
S: 354 Go ahead
C: From: Acme <orders@acme.example>
C: To: ronald.williams@example.com
C: Subject: Your order 1042
C: Date: Sat, 17 Oct 2026 09:14:02 +0000
C: Message-ID: <7f3a9c@acme.example>
C:
C: Thanks for your order.
C: .
S: 250 2.0.0 Accepted
C: QUIT
S: 221 Bye

The envelope and the message disagree on purpose. The envelope address is unique per message, a variant of VERP (variable envelope return path, which classically encodes the recipient), so a bounce that comes back to it can be matched to the send that caused it without parsing any text. The From address is for the reader. When the receiving server delivers the message, it writes the envelope address into a Return-Path header (RFC 5321 §4.4), which is how you can see it later:

Return-Path: <bounce+7f3a9c@rasket.acme.example>
Authentication-Results: mx.example.com;
        spf=pass smtp.mailfrom=rasket.acme.example;
        dkim=pass header.d=acme.example header.s=rasket;
        dmarc=pass header.from=acme.example
From: Acme <orders@acme.example>
To: ronald.williams@example.com
Subject: Your order 1042

Because the receiver writes that header, a sender cannot set it: the API refuses a Return-Path header in a send request.

The row that matters is “Checked by”: SPF checks the envelope, and DMARC then requires the domain that passed to belong to the From domain’s organisation, which RFC 9989 (the DMARC standard that replaced RFC 7489 in May 2026) calls identifier alignment (more on alignment).

The return path needs records that make its domain receive bounces and pass SPF. We set the form when you add the domain, and the domain page shows which one, with the exact names and values (full record set).

• One CNAME. The label points at a host under rasket.net, a domain we keep only for mail infrastructure, named for your domain’s region, such as us1.rasket.net. That host publishes exactly two records: the MX that receives your bounces and one SPF TXT for the shared servers we send through. Its include costs one DNS lookup, counted against this label’s own limit of ten, not your root record’s, because the record it includes lists addresses only. Receivers follow the alias and read both. We change them only when the servers behind them change, and the change reaches your label without a DNS edit, which is what the alias is for.
• An MX and an SPF TXT. The same two records, published in your zone. The TXT has the shape v=spf1 include:… ~all, with the include naming our sending servers; the domain page shows the exact value. Here you own the records, and a change on our side shows up as a record that no longer verifies. Either form verifies for either domain, so you can switch by publishing the other one.

Receivers check that a return-path domain can receive mail before they trust it: a MAIL FROM domain with no MX and no address record is commonly refused, because a bounce sent there could never arrive (RFC 5321 §5.1 falls back to the address record when there is no MX). Both forms give the label an MX.

Your SPF record at acme.example is not touched. SPF is evaluated only at the return-path domain, so the root record keeps serving your office mail, spends none of its 10-lookup budget on us, and a mistake in one cannot break the other.

A new domain gets its return path at rasket, the first free label of rasket, rasketmail, rk, rasket1, rasket2. A label is free when nothing is published there, or only our own records. So acme.example gets rasket.acme.example, and news.acme.example gets rasket.news.acme.example. A zone with a wildcard record answers for every name, so no label can be checked; the domain then gets rasket, and you should look at what that name returns before publishing. Domains added before this default keep the label they were given.

To choose a label yourself, pass custom_return_path when you add the domain. It is a label, not a hostname: bounce makes the return path bounce.acme.example. If the domain you add is itself a subdomain, such as send.acme.example, the label goes under it: bounce.send.acme.example. A label where another service already publishes records is refused with 422 invalid_parameter and details.reason return_path_in_use.

# A request with no User-Agent is refused (403); curl sends its own, so name your integration.
curl -X POST https://api.rasket.com/domains \
  -H "Authorization: Bearer $RASKET_API_KEY" \
  -H "User-Agent: acme-billing/1.0" \
  -H "Content-Type: application/json" \
  -d '{ "name": "acme.example", "custom_return_path": "bounce" }'

HTTP/1.1 201 Created

{
  "object": "domain",
  "id": "d9b2f1c4-…",
  "name": "acme.example",
  "status": "not_started",
  "custom_return_path": "bounce",
  "records": [
    { "record": "SPF", "name": "bounce", "type": "CNAME",
      "status": "not_started", "value": "us1.rasket.net" }
  ]
}

Until that row first verifies, mail goes out with our mail servers’ own return path, so SPF passes unaligned and DKIM carries DMARC. Once it has verified, we stop falling back: if the label’s records later disappear, sending from the domain fails instead of quietly losing aligned SPF. Another Rasket customer cannot use your return path, because a domain one team has verified is refused to every other team, and moving it needs a fresh DNS proof.

PATCH /domains/{id} with { "custom_return_path": "mail" } changes it later; the records move to the new label and are checked there. Leave the old records in place for a week. RFC 5321 §4.5.4.1 recommends that a server keep retrying a delivery for at least 4–5 days before it gives up (Postfix’s default is five), and the bounce it then sends goes to the old label; a week covers that plus the old records’ TTL.

When you stop using Rasket altogether, delete the domain and then its records, as the verification walkthrough lists. A leftover CNAME to a service you have left is how subdomain takeovers start. Ours points at a name in a zone we own, which nobody else can claim while we keep it registered, but a record for a service you have left still authorises mail you no longer send, so delete it. Once both legs pass, the next step is a stricter DMARC policy: moving DMARC from none to reject.

Send yourself a message and open its raw headers; the DMARC article shows where. In Authentication-Results, smtp.mailfrom should name your return-path subdomain and header.d your own domain, with dmarc=pass. If smtp.mailfrom shows your sending service’s domain, SPF is passing without aligning, and the return path is the fix.

Mail your staff send from their own mailboxes does not need this: their provider already uses your domain as the envelope sender. The split happens when an application sends through a service.