Mail you send from Ascensie leaves from your own address, not from one of ours. That takes some work up front: you have to prove the domain is yours. Here is what happens, why those steps exist, and what we do with the signals that come back afterwards.
Why the domain matters
Someone who sees name@yourcompany.com knows who they are dealing with. Someone who sees an unfamiliar address belonging to a middleman does not, and neither does their mail server.
Mail servers decide largely on reputation, and reputation attaches to the domain that signs the mail. Mail from your own verified domain builds a history you benefit from. Mail from a shared address shares that history with everyone else using it, including whoever mailed a purchased list last week.
Verifying the domain
You register your domain in the settings and get back a set of DNS records to add at your registrar. Three things have to check out before you may send.
DKIM. Three CNAME records pointing at keys generated for your domain. Every message that goes out then carries a signature the recipient can verify. If it verifies, the message provably came from this domain and was not altered in transit.
A custom return path. A subdomain with its own MX record and its own SPF entry, where notifications about undeliverable mail are sent. This is a second verification, independent of DKIM, and the two can sit at different states for days. Both have to be green.
A verification record of ours. One TXT record with a value generated per registration. It is needed because Amazon keeps a single identity per domain: without that extra record, the answer "this domain is verified" would also come back for someone who merely typed the domain in. A domain can therefore be active for only one account at a time here, and that is enforced by the database rather than by a form.
SPF, DKIM and DMARC in plain language
All three answer a different question about the same message.
SPF says which servers are allowed to send mail on behalf of this domain. It is a list of senders, published in DNS.
DKIM says this message was signed with a key belonging to this domain, and the content was not changed on the way.
DMARC says what to do when it does not check out. It ties SPF and DKIM to the domain the recipient actually sees in the From line, and tells the receiving server whether to reject such a message, file it as junk, or only report it.
DKIM and the return path are handled during verification. DMARC you publish yourself, and it is worth doing: without a DMARC policy, anyone can mail in your name with nothing standing in their way. Start with a policy that only reports, read the reports, then tighten it.
Bounces and complaints are not noise
The moment you start sending, signals come back, and they are the most valuable data you will get about your mail. We receive them from Amazon as they happen.
A hard bounce means the address does not exist. A soft bounce means it did not work today: full mailbox, server briefly away. A complaint means somebody pressed the spam button.
Those three say very different things, and treating them as one thing goes wrong in two directions. Keep mailing addresses that do not exist and every receiving party reads that as the behaviour of someone who does not maintain a list, which costs you delivery within weeks. Treat a full mailbox as a dead address instead, and real customers quietly disappear from your list.
What we do with them
A hard bounce suppresses the address. Nothing is sent there again until you undo it.
A soft bounce does not. It is recorded, so you can find an address that consistently fails, but it does not prune your list.
A complaint always suppresses. Someone who presses the spam button has said they want nothing more, and that ends the discussion.
That suppression list belongs to your account alone, and you can look at it. Every address shows why it is there. Seeing it matters: a list that grows silently never explains why a campaign reached fewer people than you expected.
The filtering happens in one place in the send path, immediately before sending. One place can be proven; two places is one place someone can forget.
Every mailing also carries an unsubscribe link, and an unsubscribe lands on the same list as a complaint. Waiting for someone to reach for the spam button is the most expensive way to learn they wanted out.
Every customer has its own reputation
Outbound mail runs through Amazon SES in the Frankfurt region. Each account gets its own separated space there, with its own suppression list.
That is precisely why we set it up this way. Delivery, bounce and complaint figures are measured per customer. If something goes wrong at one customer it is visible at that customer and can be stopped there, without anyone else being affected. Alongside our own figures we also fetch Amazon's recommendations, such as a missing DMARC record or a bounce rate creeping up. We show the two separately rather than as one blended number, because they do not measure the same thing.
And mail coming in
Receiving works on the same idea. You point a subdomain of your own domain at us with an MX record. Mail sent there arrives in your shared inbox, attached to the contact it belongs to. Which account a message belongs to is decided by the address it was actually delivered to, not by what the headers say, because blind-copied mail names its recipient in no header at all.
There is no Gmail or Outlook connection, and there will not be one. An MX record works with any provider and stays yours.