SMTP vs Email API vs Self-Hosting: Which Should You Use for Transactional Email?

Use an email provider API if transactional email is part of your product, and speak SMTP to that provider rather than to a raw server. Run your own mail server only when you have a reason that is not cost, and even then self-host inbound and relay outbound. The visible difference between these three options is the code you write. The difference that decides whether the mail lands is who owns IP reputation, rDNS, the complaint list and the DNS records for your sending domain.

One thing is identical across all three routes, and it is where most of the real work sits. Your sending domain needs SPF, DKIM and DMARC published and aligned, and somebody has to read the aggregate reports that come back. That work does not go away because a provider handles the transport, and it is not optional either. It is also the layer that is cheapest to get wrong and cheapest to get right: the free SPF, DKIM and DMARC checkers at DMARCFlow will tell you what is broken on a domain before a campaign does.

The short answer

Default: an email provider API, for transactional mail that matters. It gives you structured errors, idempotency, event webhooks and metadata, which is the difference between "the send failed" and "the send failed because the address is gone".

Use SMTP when portability matters more than observability. Every language and framework speaks it, and switching providers is a credentials change rather than a rewrite.

Self-host only for a specific reason, and separate inbound from outbound. Receiving mail is a weekend project. Delivering it is a mail operations job.

What actually differs between the three routes

Who owns this	SMTP to a relay	Provider API	Your own server
Sending IP reputation	Provider	Provider	You
rDNS / PTR record	Provider	Provider	You
Port 25 access	Provider	Provider	You, and often not available
Bounce and complaint handling	Provider, partly	Provider, usually via webhooks	You
Blocklist monitoring	Provider	Provider	You
IP warm-up	Provider	Provider	You
SPF, DKIM and DMARC records	You	You	You
Reading DMARC aggregate reports	You	You	You

Read that last two rows again. The DNS records for your sending domain and the reports coming back from it stay with you in every column. Switching to a provider does not hand those over.

Option 1: SMTP to a relay

SMTP is the standard protocol for handing a message to a mail server, and it has been since the early internet. Your application opens a connection, authenticates, and passes the message over.

The advantage is portability. Every language and framework has an SMTP client, and most frameworks ship one. When you outgrow your provider, the change is new credentials and a new hostname, not a new integration. That matters more than teams expect, because email providers get replaced more often than the code around them.

In practice a relay connection is plain SMTP over port 587 with STARTTLS, or port 465 with TLS from the first byte. Port 25 is the other thing, and it is the one that stays between you and the internet when you try to be a mail server yourself.

The cost is visibility. SMTP gives you a queue of results, not a stream of events. Error handling, per-message metadata, delivery receipts and retry logic all have to be built, usually badly, on top of a protocol that was designed for a different era. If you need to know which of 4,000 password resets bounced, you will end up either polling the provider or parsing their bounce queue yourself.

SMTP to a relay is a good default when the mail is low volume and low stakes, or when your framework already has a solid mail library.

Option 2: A provider API

Instead of speaking SMTP, the application makes an HTTP request and gets a JSON response back. The provider handles the SMTP layer underneath. What you get on top is what the API is for:

• Structured errors. A rejected address tells you why, in a field you can branch on, instead of a log line to grep.
• Idempotency. A retry with the same key sends one message, not two. This is the feature that matters most for transactional mail and the hardest to build on top of SMTP.
• Event webhooks. Bounces, deliveries, opens, clicks and complaints arrive as POSTs to an endpoint you control, so suppression lists update in seconds.
• Metadata. Attach your order ID, user ID or tenant to a message and read it back on every event.
• Observability. Logs that join up with the rest of your system, without writing an SMTP-to-queue bridge.

The cost is lock-in. Every provider has a different API, a different error shape and a different event format. Migration is a project, not a credentials change. For a product that will outlive its first email provider, that is worth pricing in rather than discovering later.

The other thing to understand about the API route: the provider owns the sending identity. It signs your DKIM, it publishes the SPF include, it holds the reputation of the IP. Your domain stays on the From address and in the DNS, but the sending path belongs to them.

Option 3: Running it yourself

This is the option people pick because it looks free and turns out to be a different job.

Receiving is the easy half. Postfix plus Dovecot, an MX record pointing at your box, a certificate from Let's Encrypt and you have a working inbox in an afternoon.

Delivering is the other half, and it is where the list lives:

• Port 25. The port for server-to-server mail is blocked by most residential ISPs and by a good share of cloud providers. If your server sits on a home connection or a budget VPS, outbound mail may simply not leave.
• IP reputation. A residential address is pre-blocklisted by default. A freshly provisioned cloud IP can carry the previous tenant's sending history, and you inherit their blocklist entries and their complaint history.
• rDNS. Mail servers need forward and reverse DNS that agree. This is separate from SPF and DKIM, and DMARCFlow does not check it.
• SPF, DKIM and DMARC. You publish these yourself, you keep the keys yourself, and you rotate them yourself. A selector that outlives its key means every message fails verification.
• Blocklist monitoring. Somebody has to check the lists daily and act on the listings.
• DMARC reports. You need a collector and a way to read the output. See the next section, because this is the part that cannot be done entirely on your own domain.
• IP warm-up. New IPs send low volume first and ramp slowly. Getting this wrong burns the address permanently.
• Abuse handling. Complaints have to be processed, and someone has to decide whether to suppress an address.

A hybrid is a sensible landing point, and it is where a lot of teams end up: self-host inbound and storage so you own your mail and your data, then relay outbound through a provider or smarthost. You keep ownership of the receiving side and hand over the reputation-heavy sending side.

The part nobody mentions: you cannot collect your own DMARC reports

This one surprises people, and it changes how the self-hosting option looks.

A DMARC record points at a report collector with the rua tag. If the collector sits on the same domain as the record, the reports are not sent. RFC 7489, section 7.1, says it directly: when the organisational domain where the DMARC record was found is not identical to the organisational domain of the host in the rua or ruf URI, the receiver runs a verification procedure.

The reason is spelled out in the same section:

It is possible to specify destinations for the different reports that are outside the authority of the Domain Owner making the request. This allows domains that do not operate mail servers to request reports and have them go someplace that is able to receive and process them.

That procedure builds a DNS name by prepending _report._dmarc and your policy domain, then looks for a TXT record there. If nothing valid comes back, the receiver ignores the URI and generates no report. One service can accept reports for any domain by publishing a wildcard at *._report._dmarc.example.com.

The practical consequence: the reporting layer is always somebody else's, or a second service you now run and monitor. Self-hosting everything is not actually a complete option. Even the most self-reliant setup ends up depending on an external receiver for DMARC feedback, and someone still has to read the reports and act on the failures.

That is also why deciding to run everything in-house is not a cost answer. The transport is the part you can own. The authentication and the reporting are the parts that carry ongoing work no matter what.

What every route still needs: SPF, DKIM and DMARC

Whichever transport you pick, the sending domain needs the same three records, and they have to line up.

SPF lists the hosts allowed to send for the domain. It is easy to break with a plain DNS mistake: RFC 7208, section 4.6.4, allows ten mechanisms that cause DNS lookups, and exceeding the limit produces a permerror, which means the record stops working entirely. Every extra ESP you add to the include list eats into that budget.

DKIM signs the message body and headers with a private key, and publishes the public key in DNS under a selector. With a provider, the provider usually hands you a CNAME to publish and handles the signing. Self-hosting, you generate the key and manage rotation. Two details matter either way: 2048-bit RSA is the size the large providers expect, and one selector per mail stream keeps each stream's reputation separable.

DMARC ties the two together and tells receivers what to do when they disagree. For bulk senders the minimum policy at Gmail, Yahoo and Microsoft is p=none, and alignment is judged against the organisational domain, which is why a subdomain record that assumes it controls its own policy causes surprises. The rua tag points at your report collector, which is the section above.

Above roughly 5,000 messages a day, the three large providers add requirements on top: one-click unsubscribe, a spam rate ceiling of 0.3%, valid forward and reverse DNS, and TLS. Those apply to whichever route you chose. Transport does not exempt you from them.

Where DMARCFlow fits

The verification and monitoring layer is the piece that does not change between the routes, so it is worth getting right first.

DMARCFlow's free checkers verify a domain's DMARC record, its SPF configuration and its DKIM setup, and point at the specific mistake rather than a pass or fail. The DMARC checker at https://dmarcflow.com/en/dmarc-checker reads the published policy and the alignment status. The DKIM checker at https://dmarcflow.com/en/dkim-checker reads the selector, the key length and the TXT record. The email header analyzer at https://dmarcflow.com/en/email-header-analyzer reads the Authentication-Results header on a real message so you can see what a provider actually decided rather than what you assumed.

The paid side is where the ongoing work lands. The dashboard receives and interprets DMARC aggregate reports, tracks failures over time, and flags when something you do not recognise starts sending as your domain. Subdomain discovery finds sending identities you forgot you had. Multi-domain management is the practical part for teams with more than one sending domain. Pricing is not the obstacle: EUR 1.00 per month excluding VAT covers a single domain with the free checks and record generation, EUR 34.99 per month excluding VAT covers up to five domains with full monitoring and cross-domain management, and Enterprise is a custom quote with unlimited domains and users. Cancel anytime.

Two audiences get the most out of it. Teams juggling several sending domains, where a per-domain checklist stops scaling and the dashboard does. And self-hosters, who hit the reporting constraint in the previous section head on and would otherwise be running a collector by hand.

What DMARCFlow does not do is worth stating plainly. It does not send your mail, so it is not an alternative to any of the three routes above. It does not warm up IP addresses. It does not manage list hygiene or process complaint abuse. It does not check PTR or rDNS records. It does not judge message content. It verifies email authentication and makes sense of the reports that describe it, and that is the part that nobody can opt out of.

How to decide in five minutes

1. Is transactional mail part of the product, or a side feature? If it is part of the product, use a provider API. The idempotency and the event webhooks pay for themselves the first time a retry would have sent a duplicate invoice.
2. Do you need to change providers later? If yes, or if you are not sure, speak SMTP to the provider. The abstraction is one line of configuration.
3. Is there a reason to own the sending path that is not the invoice? Compliance, a data residency requirement, unusual infrastructure. If there is no such reason, self-hosting is buying operational load, not saving money.
4. Do you have, or plan to have, more than one sending domain? If yes, set up the monitoring before you need it. The free checkers cost nothing and the paid dashboard starts at EUR 1.00 a month.
5. Regardless of the route, check the records today. Run the DMARC checker at https://dmarcflow.com/en/dmarc-checker against your organisational domain and against every subdomain you send from. A subdomain that inherits the organisational domain's policy is the most common surprise in this whole area.

Frequently asked questions

Which is better for transactional email, SMTP or an API?

An API, if the mail matters. It gives you idempotency, structured errors and event webhooks, which stop you building a queue and a retry layer on top of SMTP. SMTP wins when portability is the priority, because switching providers is a credentials change rather than a rewrite.

Is it worth running your own mail server for transactional email?

Rarely, and never as a cost decision. Port 25 blocking, inherited IP reputation, rDNS, key rotation, blocklist monitoring, warm-up and abuse handling all land on you. It is worth it when you have a specific requirement, not when you want to avoid a monthly bill.

Do you need DMARC if you use an email provider?

Yes. The provider signs and sends, but your domain is what appears in the From address, and the DMARC record is published on your domain's DNS. The provider cannot publish it for you. Above roughly 5,000 messages a day, Gmail, Yahoo and Microsoft all require a DMARC policy of at least p=none, plus SPF and DKIM passing. The free checker at https://dmarcflow.com/en/dmarc-checker shows which record is in force on a domain in a few seconds, and it is the quickest way to confirm that a subdomain is inheriting the organisational domain policy rather than running its own.

What is the hardest part of self-hosting email?

Delivering, not receiving. Receiving mail is a configuration job. Delivering is reputation work: getting port 25 open, earning a sending history, keeping the blocklists clean, and staying on the right side of the complaint thresholds.

Can you collect DMARC reports on your own domain?

Not on the same organisational domain as the DMARC record. RFC 7489 section 7.1 requires the report destination to be on a different organisational domain, and the receiver verifies it with a _report._dmarc TXT lookup before sending anything. A service that accepts reports for any domain publishes a wildcard record for that.

Should you use the same provider for transactional and marketing mail?

No. The three large providers say so directly for bulk senders, and the reason is that reputation follows the sending path, not the domain. A campaign that generates complaints will drag down the path your password resets travel through. Separate sending infrastructure, or at minimum separate IPs, and the two streams stop sharing a verdict.

The bottom line

Pick the route by what you are willing to own, not by what looks flexible in the code. An API for the product, SMTP for portability, self-hosting for a specific reason, and in every case the DNS records and the reports stay yours. DMARCFlow checks those records for free and reads the reports when there is more than one domain, so the part that never goes away is at least covered. Verify them before you need them, because the first report that tells you something is wrong tends to arrive at the worst possible moment.