I sent a test message from the company address twenty minutes ago. It has not arrived.
It has not bounced, either. That is the worse half. There is no error to read, no rejection notice, nothing to search for.
The message left, and then it simply stopped existing.
And it stopped existing because of a rule this company published itself.
Sitting in both domains is a standing instruction to the rest of the internet, a policy record called DMARC. If a message claims to come from us and does not carry our signature, do not deliver it. Quarantine it. Every one, no sampling.
That rule is working perfectly. It is just being applied to us.
Because the mailboxes and the sending are two separate services. Staff log into one. Outbound messages get handed to the other, and that second one does the signing.
And the signing service had only ever been introduced to a machine-generated address. The long automatic one nobody would print on a business card.
The real company names, the ones sitting in the from field, were never registered with it at all.
So it signs as the name it knows. Which is not the name on the envelope. And our own rule does the rest.
So today, both real domains get registered as senders, in their own names.
resource "aws_ses_domain_identity" "limitless_workmail_domain" {
domain = "limitlessinteractive.com"
}
resource "aws_ses_domain_identity" "glass_workmail_domain" {
domain = "madeof.glass"
}
Then the part that takes longer than it looks. Permission.
Each name gets a policy saying who is allowed to send under it. Not the account. Not anyone who happens to work here.
It names one caller, the mailbox service, in one region. Then it narrows again. The request has to come from one specific organization, spelled out as a long random identifier.
Two companies. Two identifiers. Two policies.
Neither one can speak for the other.
Send it again. The signature matches the name on the envelope, the receiving end checks it, and the message lands in an inbox like it was never in question.
Nothing about the quarantine rule changed. It was never wrong.
The mail just finally qualifies.
Everything Working Correctly
Welcome back.
Before the break I told you a test message left the company address and never arrived, and I gave you the short version of why: the sending service had only ever been introduced to a machine-generated name, and the real company names were never registered with it.
That's true enough to put in a teaser. It's not precise, and the imprecision hides the actual mechanism, which is the interesting part.
So let's do it properly. Today's work is sixty-odd lines and it touches one file, and it is one of the cleanest examples I've seen of a failure that is caused entirely by things working correctly.
The Symptom
Start with the symptom, because the symptom is the hardest part.
A message is sent from a real person, at a real company address, to a real recipient. It does not arrive. It also does not bounce.
Those two facts together are what make this expensive. A bounce is a gift. A bounce is a machine-readable explanation, delivered to your inbox, usually with the exact reason and often with a link. You can search for it. You can forward it to someone.
Quarantine produces none of that. The receiving server accepted the message, evaluated it, decided it was probably a forgery, and filed it in a junk folder that the recipient will check approximately never.
From the sender's side, that is indistinguishable from the message having evaporated. There's no error, because from every machine's point of view, nothing went wrong.
The Company's Own Rule
And the rule that put it there is the company's own.
On the very first day of this project, a policy record went into both domains. Version one, policy quarantine, one hundred percent, report failures.
In plain terms: to every mail server on the internet — if a message says it's from us and can't prove it, don't deliver it to the inbox. Every message, no sampling.
That rule is functioning exactly as written. It's just that the first thing it caught was us.
Two Different Products
So why couldn't our own mail prove it was ours? For that, you need to know that sending mail here involves two different products that most people assume are one.
There's the mailbox service. That's the part staff experience — the thing they log into, the place their mail lives, the calendar, the address book. It's also where inbound mail lands, which is what the delivery record in each domain points at.
And then there's the bulk sending service. Different product, different name, different set of concepts.
When somebody hits send in the mailbox service, that message doesn't go out from the mailbox service. It gets handed to the sending service, and the sending service is the one that talks to the rest of the internet — and, critically, the one that applies the cryptographic signature.
Two services. One does mailboxes. The other does signatures. The mail passes from one to the other, and the entire failure lives in that handoff.
An Identity
Now, the sending service has a central concept it calls an identity.
An identity is a name you've proven you control. You declare it, the service gives you a verification token, you publish that token as a record in your domain, the service reads it back, and from then on the service is willing to sign and send as that name.
Here's the part that took me a while to see clearly. The mailbox service, when it's set up, quietly creates an identity for its own internal address — a long machine-generated hostname on the provider's own domain, derived from a short alias you picked during setup. Nobody would ever print it on a business card. It exists so the service has something to sign as before you've told it anything.
And that internal name was set up on day one, complete with its own signing keys.
The Signature Didn't Say the Right Name
So the signature on the vanished message was not missing. It was not broken. It was cryptographically valid, and any receiving server that checked it would have confirmed it.
It just didn't say the right name.
And this is the mechanism the short version hides, so I want to be careful with it.
A signature carries the domain that signed it. The visible from-address carries the domain the reader thinks it's from. The quarantine rule doesn't merely ask "is there a valid signature?" It asks whether the signing name and the visible name match.
That matching requirement is the entire reason the rule is worth anything. Without it, a forger signs their message with a domain they own, presents a technically perfect signature, and puts anybody's name in the from field.
A Notarized Letter
The nearest analogy I've got is a notarized letter.
The letterhead says the consultancy. The notary stamp at the bottom is genuine, unforged, verifiable — and it's a stamp belonging to somebody else entirely.
Nothing about it is fake. Everything about it is wrong. And the correct response to receiving it is deep suspicion, which is precisely what the receiving servers had.
Two Doors, Both Shut
Now. There is a second way a message can satisfy that rule, and this is where a decision from earlier in the week comes back around.
The rule accepts two independent proofs. Either the signature aligns with the visible name — which we've just established it didn't — or the return path aligns with it. The return path being the invisible envelope address, the one bounces come back to.
A few days ago, the dedicated return paths for both companies were removed. I flagged it at the time as a change to the outbound mail path made quietly on a day about something else, and said I didn't fully understand it yet.
Here's what it did. Without a custom return path, the envelope address reverts to one owned by the provider. A provider-owned envelope does not match the company name in the from field.
So that proof was unavailable too.
Two doors, and both of them shut — one because the signature carried an internal machine name, and one because the return path went back to being the provider's. Either one alone would have been enough to get the mail delivered. That's why the failure was total rather than intermittent.
Declared Again
So today's work has to make the signature carry the real company name. And that turns out to be two separate problems, only one of which is obvious.
The obvious half: both real domains get declared as identities in the sending service, explicitly, by name.
And here's a subtlety worth a minute, because it looks like duplication and isn't quite.
Those domains were already declared as identities elsewhere in this project — over in the module that handles general outbound sending, defined by looping over the same shared variable that holds both companies.
But the permission we're about to write has to attach to a specific identity, and to attach to it you need a direct reference — the full resource address of that exact object. Modules in this tool don't reach into each other. A resource defined in one place is simply not visible from another unless somebody deliberately wires an output through.
So the identity gets declared again, in the file where the permission lives, so the permission has something to point at. Underneath, both declarations describe the same verified name, and the service treats a re-declaration as a no-op.
My read is that this is a module boundary showing through — the cost of having drawn a line between "general sending" and "the mail system," paid in one extra declaration. Reasonable price. Worth knowing it's there, so that the next person who deletes one of them knows which one they're deleting.
Permission
Now the half that takes longer than it looks. Permission.
You own the domain. You own the account. The mailbox service is in that account, the sending service is in that account, both were created by the same person on the same afternoon.
And the mailbox service still cannot sign as your domain, because owning an identity and permitting another service to use it are separate grants.
This is a policy that hangs on the resource rather than on the caller. Instead of "here is what this user may do," it says "here is who may act on this specific name." The name itself carries the guest list.
One Caller, One Region
So each domain gets a policy, and the policy names one caller.
Not a person. Not an access key. A service — the mailbox product itself, identified by its service name, in one specific region.
That regional detail is not decoration. The same product running in a different region is a different principal and would be refused. Which is correct, because the mail infrastructure here lives in one region and nothing in another region has any business signing as these companies.
principals {
identifiers = ["workmail.us-east-1.amazonaws.com"]
type = "Service"
}
This Organization
And then it narrows again, and the second narrowing is the one I'd have missed at twenty-five.
A condition is attached: the request must originate from one specific mail organization, spelled out as a long random identifier.
Here's why that's necessary. When you name a service as the permitted caller, you are not naming your instance of that service. You're naming the service. The same service, running for every other customer of that cloud, arrives wearing the same badge.
Which opens a specific and well-documented shape of attack: somebody else's mail organization asks the shared service to send on their behalf, the service dutifully makes the request, and the request arrives at your identity carrying a principal your policy trusts.
The service isn't compromised. It's doing its job. It's just been pointed at your name by someone who isn't you.
The source condition is what closes that. It says: I trust this service, but only when it is acting for this organization, whose identifier is written here in full.
condition {
test = "ArnEquals"
variable = "aws:SourceArn"
values = [
"arn:aws:workmail:us-east-1:...:organization/m-05d6f26b67014492a73e3748ec2e4b67"
]
}
A Wildcard Pointed at Exactly One Resource
The action being granted, meanwhile, is broad. It's a wildcard across the sending service's operations.
But it's a wildcard pointed at exactly one resource, reachable by exactly one caller, acting for exactly one organization. The breadth is on the verb and the narrowness is on the subject and the object.
actions = ["ses:*"]
resources = [aws_ses_domain_identity.limitless_workmail_domain.arn]
That's a normal shape for a service integration. You generally don't know which internal calls the product will need next release, and pinning the verb list means a future update fails in a way that produces exactly the symptom we spent this episode diagnosing.
Written Twice
And all of it is written twice, once per company. Two identities. Two policy documents. Two organization identifiers, entirely different strings. Two attachments.
data "aws_iam_policy_document" "limitless_workmail_policy" {
statement {
actions = ["ses:*"]
resources = [aws_ses_domain_identity.limitless_workmail_domain.arn]
principals {
identifiers = ["workmail.us-east-1.amazonaws.com"]
type = "Service"
}
condition {
test = "ArnEquals"
variable = "aws:SourceArn"
values = [
"arn:aws:workmail:us-east-1:...:organization/m-05d6f26b67014492a73e3748ec2e4b67"
]
}
}
}
data "aws_iam_policy_document" "glass_workmail_policy" {
statement {
actions = ["ses:*"]
resources = [aws_ses_domain_identity.glass_workmail_domain.arn]
principals {
identifiers = ["workmail.us-east-1.amazonaws.com"]
type = "Service"
}
condition {
test = "ArnEquals"
variable = "aws:SourceArn"
values = [
"arn:aws:workmail:us-east-1:...:organization/m-55ebf45a16cf4122a8b0e644d7d76651"
]
}
}
}
resource "aws_ses_identity_policy" "limitless_ses_policy" {
identity = aws_ses_domain_identity.limitless_workmail_domain.arn
name = "WorkMail"
policy = data.aws_iam_policy_document.limitless_workmail_policy.json
}
resource "aws_ses_identity_policy" "glass_ses_policy" {
identity = aws_ses_domain_identity.glass_workmail_domain.arn
name = "WorkMail"
policy = data.aws_iam_policy_document.glass_workmail_policy.json
}
No loop, no shared variable, no clever abstraction over the pair — which is a departure from how the rest of this project is written, and I think it's deliberate. The organization identifiers can't be derived from anything. They were generated when the mail organizations were created by hand, which was the one part of this system the tooling could never manage.
So the values are opaque, they were copied off a screen, and writing them out twice means neither company's policy can ever accidentally reference the other's.
The consultancy cannot sign as the second brand. The second brand cannot sign as the consultancy. Not by convention — by the absence of any grant that would allow it.
The Proof Was Already in Place
And then the part that costs nothing today because of work done on the first day.
A new identity normally means a wait. You declare the name, the service issues a token, you publish it, and then you sit there refreshing while the naming system propagates.
But the ownership records for both of these domains were published on day one, along with three signing keys each. They've been sitting in those zones the whole time, verified, doing nothing in particular.
So today's declarations verify essentially on arrival. The proof of ownership was already in place. The only missing piece was ever the permission.
That's the quiet payoff of having done the naming thoroughly at the start. The fix that would have taken a day of waiting takes one apply.
Send the Test Again
Send the test again.
The mailbox service hands the message to the sending service. The sending service now has an identity for the real company domain, and a policy permitting that exact organization to use it. So it signs with the real domain's keys.
The receiving server pulls the signature, fetches the public half from the records that have been sitting in that zone since the first day, checks the maths, and then checks the name on the signature against the name in the from field.
They match.
The rule is satisfied, the quarantine instruction never fires, and the message lands in an inbox like it was never in question.
Nothing Was Broken
What I want you to take from today is that nothing was broken.
The quarantine rule was correct. The signature was valid. The mailbox service behaved exactly as designed. The sending service refused a request it had never been permitted to accept, which is the entire reason you'd trust it with your domain in the first place.
Every component was right. The failure was in the space between two of them — a permission nobody had written, because there was no obvious moment at which to write it.
That's most production incidents, honestly. Not a broken part. A pair of correct parts with nothing connecting them, discovered by a message that should have arrived.
The First Entity That Rule Caught
And there's a smaller thing underneath it that I keep turning over.
This company published a strict, absolute, no-exceptions rule about who is allowed to speak in its name, on the first day, before the mail even worked.
And the first entity that rule caught, held, and refused to deliver was the company itself.
That's not an embarrassment. That's the only real test a rule like that ever gets. A policy you've never been caught by is a policy you haven't confirmed is switched on.
Nothing about the quarantine rule changed today. It was never wrong.
The mail just finally qualifies.