Sending Domain: Definition, How It Is Measured, and Where It Breaks

Sending Domain: Definition, How It Is Measured, and Where It Breaks

A sending domain is the domain that identifies the sender of a message, carries the DNS records that authenticate it, and accumulates the reputation the receiving side judges when it decides where that message lands. It is the name after the @ in the address the recipient sees, and it is the unit mailbox providers keep a file on.

Everything a receiving server can verify about you before it reads a word of your copy is published on that domain, in public DNS, by whoever controls it.

What the domain publishes

Three record types do the authentication work, and each answers a different question.

SPF is a TXT record published at the domain itself, listing the servers permitted to send mail on that domain's behalf. A receiver takes the domain in the envelope sender, looks up its SPF record, and asks whether the machine currently connected to it appears on that list.

DKIM is a public key published at a subdomain of the form selector._domainkey.yourdomain.com. The sending server holds the matching private key and signs each outgoing message, writing a DKIM-Signature header that names the domain it signed as (d=) and the selector to look the key up under (s=). The receiver fetches the key, recomputes the signature, and learns two things: whether the signed parts of the message were altered in transit, and which domain vouched for it. Selectors matter more than most setup notes suggest, because one domain can carry several at once. That is how a domain sends through more than one platform without either platform's key breaking the other's.

What DKIM covers is worth being precise about, because it explains a failure people misread as a DNS problem. The signature commits to a hash of the body and to a named list of headers, typically the ones that carry identity and threading. Anything outside that list can change in transit without breaking the signature. Anything inside it cannot. A mailing list that appends a footer, or an appliance that rewrites a subject line to prepend a warning, invalidates a signature that was perfectly valid when the message left, and the receiver at the far end sees a DKIM failure on a domain that did nothing wrong.

DMARC is a TXT record at _dmarc.yourdomain.com. It publishes a policy telling receivers what to do with mail that claims to come from the domain and fails to authenticate in the domain's own name, plus an address where reports about those attempts are sent.

On the domain, in public DNS

• ✓Yes: SPF: a TXT record at the domain root, naming the servers allowed to send for it
• ✓Yes: DKIM: a public key at selector._domainkey.yourdomain.com, one per selector in use
• ✓Yes: DMARC: a TXT record at _dmarc.yourdomain.com, carrying the policy and the report address
• ✓Yes: MX: where mail addressed to the domain is delivered, a separate decision from where it sends
• ~Depends: Reputation: held privately by each receiving provider, published nowhere, readable only by inference

The record layout is the easy half. The setup itself, including syntax and the order to roll the records out in, is covered in SPF, DKIM and DMARC for cold email, and the reason SPF is usually the first thing to break at any scale is the ten-lookup ceiling explained in SPF records for cold email. Neither is restated here.

The last item on that list has no record and no API. Reputation is a judgment each receiving provider holds privately about the domain's history: how much mail it sends, how steadily, how often recipients report it, how many of the addresses it writes to do not exist. A domain registered last week has no such history at all, which is a different state from a bad one and is handled differently by receivers. Getting from nothing to something is the entire job of warming a domain before you send.

Why a cold programme sends from a domain the business does not run on

Reputation attaches to the domain. So does damage. If the domain carrying your outbound picks up spam complaints, lands on a blocklist, or trips a provider's threshold, the mail that suffers is every message sent from that domain, including invoices, password resets, support replies and the conversation your account manager is halfway through.

That is why a cold programme almost always runs on domains bought and warmed for the purpose, separate from the domain the company operates on. The separation is a containment boundary. The primary domain keeps its history and its inbox placement no matter what happens on the outbound side, and a problem on an outbound domain can be answered by retiring that domain rather than by negotiating with a provider about the one the business depends on. Recovery on a blocklisted domain is possible, and the delisting process is well documented, but it is slow, and nobody wants to run it against the domain that carries their payroll notifications.

RevenueFlow runs client campaigns from generic pre-warmed sending domains rather than client-branded lookalike domains, with the client identity carried in the sender name and the signature. The reasoning is history. A lookalike domain registered for a campaign starts at zero with every receiving provider, so it buys nothing that an already-warmed generic domain does not have, and it costs weeks of warming before it can carry volume. The recipient sees a person's name and a signature either way.

Three domains, one message

Here is where the tidy definition stops being accurate. "The sending domain" is spoken about as one object. A single message can carry three domains, and they are allowed to differ from each other.

The From domain is the one in the visible From header, defined by RFC 5322. It is the only one the recipient sees without opening raw headers.

The envelope sender domain is the one in the address given in the SMTP MAIL FROM command, defined by RFC 5321. Delivery failures are returned to it, which is why the same thing is also called the return path or the bounce address. It travels in the delivery conversation rather than in the message, and it is what SPF is checked against.

The DKIM signing domain is whatever appears in the d= tag of the signature. It is the domain whose key was used, which is not necessarily the domain in the From header.

From domainRFC 5322 header

• The only one the recipient sees
• Not checked by SPF at all
• DMARC treats it as the identity being claimed
• Wrong assumption: that authenticating anything authenticates this

Envelope sender domainSMTP MAIL FROM, the return path

• Where delivery failures are returned
• This is the domain SPF is evaluated against
• Often set to a platform-owned bounce domain
• Can pass SPF perfectly while belonging to somebody else

DKIM signing domainthe d= tag in the signature

• Names the domain whose key signed the message
• Can be a platform's own signing domain
• A valid signature proves integrity, not identity
• Passing DKIM says nothing about the From header on its own

Platforms set these to different values as a matter of course: a shared bounce-handling domain in the return path, a platform-owned signing domain, and your domain in the From header. In that arrangement SPF can pass and DKIM can pass while the identity the recipient actually reads is vouched for by nobody.

Closing that gap is exactly what DMARC does, and it is the part that catches experienced senders out. DMARC's test is alignment. It asks whether the domain that passed SPF, or the domain that signed with DKIM, matches the domain in the From header. A passing SPF result on a return path owned by your platform does not satisfy it. A valid DKIM signature made by that platform's own domain does not satisfy it either. At least one of the two has to pass in the name of the From domain for DMARC to pass.

1. Step 1Read the From domain

   The identity being claimed. Everything after this is measured against it.

2. Step 2Evaluate SPF against the envelope sender

   A pass here belongs to the return-path domain, which may not be yours.

3. Step 3Verify the DKIM signature and note the d= domain

   A pass here belongs to whichever domain's key signed, which may be the platform's.

4. Step 4Apply the alignment test

   Does either passing result carry the From domain? If neither does, DMARC fails however green the individual checks looked.

5. Step 5Apply the published policy

   The DMARC record on the From domain decides what happens to a failing message.

Alignment itself has two settings, and the default is the forgiving one. Under relaxed alignment the two domains only have to share an organizational domain, so a From address at yourdomain.com aligns with a signature from mail.yourdomain.com. Under strict alignment they have to match exactly, and that same pair fails. A DMARC record that says nothing about alignment is relaxed, which is why a setup can pass for months and then fail the moment somebody publishes aspf=s or adkim=s while tightening the policy. Knowing which mode you are in tells you whether a subdomain is a solution or a new problem.

Subdomains are worth naming for the same reason. A subdomain can publish its own SPF, its own DKIM keys and its own DMARC policy, and receiving providers can build a reputation on it that is at least partly its own. That makes a subdomain a real containment boundary for transactional mail sitting under a corporate parent. It makes it a much weaker one for cold outbound, because the organizational domain is still visibly yours and a provider that decides it dislikes what the subdomain is doing has an obvious next question.

So a sender who has "set up their sending domain" and still fails DMARC has almost always set up one of the three and assumed it covered the others. The usual shape is a correct SPF record on the domain, a platform handling the return path, and no DKIM key published for the domain at all, which leaves nothing capable of aligning. The diagnostic order for that state is laid out in why your DMARC is failing.

The other thing this explains is why DNS-checking tools disagree with reality. A checker that resolves your records and reports three green lights has verified that the records exist and parse. It has not seen a message, so it cannot see which domain your platform put in MAIL FROM, or which key it signed with. Alignment is a property of the message, not of the DNS, and the only way to read it is from a message that was actually sent: raw headers on a test send, or the aggregate reports the DMARC record asks for.

What this means in a live programme

The practical unit of a cold programme is the domain, not the mailbox. Mailboxes on the same domain share its reputation completely, so a provider forming a view of one is forming a view of all of them, and adding mailboxes to a domain that is already struggling adds volume to the thing being judged rather than spreading load.

Volume is the other half. The amount of mail a domain sends into a given provider is what sets that provider's tolerance for it, which is a mechanical argument for reaching a person once. One message per campaign, sent once, on one premise, puts a fraction of the load on a receiver's patience compared with a programme that keeps returning to the same inbox, and a later approach to the same person is a separate campaign with its own premise and its own list. The domain's reputation is downstream of that decision more than it is downstream of any record you publish.

Two terms sit next to this one and get folded into it wrongly. The envelope sender and the return path name the same thing, the address that receives delivery failures, and neither is the address the recipient replies to. A reply goes to the From header, or to Reply-To if one is set. Keeping those apart in your head is most of what it takes to read a set of raw headers correctly.

Alignment, warming and domain hygiene are standing work rather than a setup task. Our pay-per-qualified-meeting outbound is the version where we hold them.