Email Integration Services: SendGrid & Mailgun

Email integration connects your application to a service that can deliver mail at volume, with authentication, templates and a record of what happened to each message. Password resets, order confirmations, invoices and login alerts are part of the product. When they land in spam, arrive late or never leave the server, customers assume the business is broken.

CodeWiz sets up transactional email for web applications, online stores and SaaS products. We connect SendGrid, Mailgun or another provider, authenticate the domain, separate real product mail from newsletters, and make failures visible instead of silent. The application keeps the business event; the provider handles delivery.

This is for teams sending mail from a plugin, a shared host or one SMTP login nobody wants to touch. It is also for stores where a timeout at checkout can mean a paid order and no confirmation.

Email Integration with SendGrid

SendGrid is a strong default when you want a maintained API, dynamic templates and clear webhooks for bounces and complaints. We treat the account as production infrastructure: its own subuser or API key per application, no key in the frontend, and a sending domain that is not the same hostname customers use to log in.

What a production setup includes

• Domain authentication, so receivers can check that mail claiming to be from you was sent with your permission. The steps are documented in SendGrid’s domain authentication guide.
• A dedicated API key with only the mail-send permission, stored as a secret, rotated when staff who could see it leave.
• Dynamic templates for the messages that change often, with a plain-text part as well as HTML.
• Event webhooks for delivered, deferred, bounced and spam-reported, pointed at an endpoint we control.
• A suppression list the application actually reads, so we do not keep retrying an address that hard-bounced.

The DNS records come from the dashboard, not from a blog post. A typical shape, with placeholders, looks like this:

We publish the records, wait for the provider to verify them, and send a seed message to a Gmail and an Outlook inbox before any customer traffic uses the domain. An SPF record that already exists gets merged. Adding a second v=spf1 does not give you two policies; it gives you none that receivers will trust.

Mailgun Email Integration and Inbound Routes

Mailgun fits teams that want a developer-facing HTTP API, regional sending (including the EU) and inbound mail: replies, support addresses and “email this document in” flows. The integration work is the same shape as SendGrid, with routing as the extra piece.

• A verified sending domain, with SPF, DKIM and a tracked hostname for clicks and opens only where you actually need them. Mailgun’s domain verification is the checklist we follow.
• Separate domains or subdomains for transactional and bulk mail, so a newsletter complaint does not punish password resets.
• Inbound routes that verify Mailgun’s signature before the application parses the body. An open inbound URL is an open way to inject content.
• Stored API keys and webhook signing keys outside the repository.
• Log retention matched to how long support needs to answer “where is my receipt?”.

We choose Mailgun or SendGrid based on inbound needs, data residency and what is already on the account, not on which logo is more familiar. Both can send a password reset. They are not interchangeable once templates, webhooks and domains are in production, so the first choice should be a deliberate one.

Transactional Emails for Orders, Accounts and Payments

Email integration, in practice, is the mail a user triggered or must receive: welcome, verify address, reset password, order confirmed, receipt, shipping update, invoice, security alert. It is not a newsletter with the logo removed. These messages have to be fast, specific and recoverable.

We do not send them inside the web request that created the order. The request records the event and returns. A worker renders the message and hands it to the provider, with retries and a backoff when the provider returns a 429 or a 5xx. If the worker is down, the event is still in the queue or the database, not lost because PHP timed out. That lines up with how we treat orders in e-commerce without lost orders, and with receipts from a payment gateway integration.

Messages we usually wire up first

• Account: verify email, reset password, new-device or new-login notice, with a short lifetime on every link.
• Orders: confirmed, paid, shipped, refunded. Each one names the order id, the amount and what happens next. The wider store flow is covered in our e-commerce optimization blueprint.
• Payments: receipt and failed-payment notice. The notice tells the customer what to do; it does not include a full card number.
• Operations: a low-stock or failed-job mail to staff, on a different stream from customer mail so an internal flood cannot block a reset password.

Email Templates Editors Can Change Without a Deploy

Email templates are where most teams either hard-code HTML in a controller or hand a marketer a file they are afraid to edit. We split fixed layout from the words and the data. Layout stays in version control. Copy that changes with a campaign or a legal line lives in the provider’s template tool or in your CMS, with a preview.

• One layout, many messages: header, footer, and a content block. Button styles live in one place.
• Variables are named and documented (order_id, customer_name, action_url). Missing data fails the render in staging, not in a customer’s inbox.
• HTML and plain text stay in sync. Some clients, and some accessibility tools, only show the text part.
• Links in account mail are absolute, HTTPS, and do not pass through an open redirect.
• A preview is sent to a seed list before a template change reaches production. We keep the previous version so a bad edit can be rolled back without a deploy.

Templates are also a deliverability choice. A single giant image, a hidden unsubscribe on a password reset, or a subject line that looks like a promotion will train filters to distrust the domain you use for receipts.

Choosing a Provider

The right provider is the one whose operational model matches the mail you send. Price per message matters at high volume; it is rarely the reason order mail fails.

We recommend the account you already pay for when it fits, and we say so when a self-hosted SMTP server is a false economy. Moving later means new DNS, new templates and a parallel sending period.

Deliverability: SPF, DKIM, DMARC and Bounces

Deliverability is the receiver deciding to trust you. Authentication is the part you can actually implement. SPF names the servers allowed to send for the domain. DKIM signs the message. DMARC tells receivers what to do when those checks fail, and sends you reports. Google’s email sender guidelines are the practical bar for anyone sending meaningful volume to Gmail: authentication, alignment, and a working complaint path.

How we bring a domain up

• Start DMARC at p=none and read the reports, so a forgotten server (a newsletter tool, an old scanner, a support desk) shows up before you quarantine it.
• Move to quarantine or reject once the legitimate sources are aligned. A strict policy on day one blocks mail you forgot about.
• Align the visible From domain with the DKIM domain. A signature for em.sendgrid.net does not, by itself, authenticate you@yourdomain.com.
• Process bounces. A hard bounce suppresses the address. A soft bounce retries a limited number of times. A complaint is a stop, not a retry.
• Keep a seed inbox on the major providers and look at it after DNS or template changes. Spam placement is a signal, not a vanity metric.

We also keep the sending volume honest. A brand-new domain that suddenly emits tens of thousands of messages looks like a compromised account. Warm-up, for a domain that will send a lot, means starting with the mail people asked for and growing from there.

Transactional Mail and Marketing on Separate Streams

Marketing mail and product mail have different rules and different failure modes. A campaign needs consent, a list and an unsubscribe that works in one click. A password reset needs none of that, and it must not be delayed because a campaign is in progress. Mixing them on one domain, one API key and one template folder is how a promotion damages the inbox placement of receipts.

• Separate subdomains, for example mail.example.com for product mail and news.example.com for campaigns.
• Separate API keys and suppression lists. An unsubscribe from a newsletter must not block a shipping update, and a hard bounce on a reset address must not be ignored.
• Consent and an identifiable sender on anything promotional. Transactional mail stays limited to the event that caused it.
• Staff alerts on a third path when they are noisy, so monitoring mail cannot fill the same quota as customer mail.

Common Delivery Mistakes We Fix

The failures we are asked to repair are rarely “the provider is down”. They are setup decisions that were fine on a staging inbox:

• Sending from the web request, so a slow provider turns into a failed checkout and a missing confirmation.
• Two SPF records, or a record that still lists a server you left years ago.
• No webhook, so bounces exist only in a dashboard nobody opens.
• The same domain for a purchased list and for password resets.
• Secrets in the theme, the mobile app or a public repository.
• Links in account mail that expire without the template saying so, or that point at staging.
• No plain-text part, and a layout that is one image with no text for the filter to read.

What Drives the Cost

We estimate after seeing which messages you send, from where, and what happens when one fails. The work scales with a few facts:

• How many message types, languages and templates, and whether copy is already written.
• Whether the domain already has clean SPF, DKIM and DMARC, or whether old senders have to be found first.
• Inbound mail, multiple brands and a move off an existing provider, which means a parallel run.
• Webhooks, suppression and a queue in the application, versus “call the API and hope”.
• Ongoing watch of DMARC reports and bounces, if you want that after launch rather than a one-off setup.

Connecting one provider and five transactional templates on a domain you control is a small project. Several brands, inbound routes and a migration with no gap in order mail is a larger one. We tell you which before we start.

How We Work

1. Discovery: we list every message the product sends, which system sends it today, and which failures customers already notice.
2. Plan: we choose the provider, the domains, the split between product mail and marketing, and what “failed” must do for an order or a password reset.
3. Build: we authenticate the domain, store secrets, add templates, and send through a worker with retries and event webhooks.
4. Test: seed inboxes, a forced bounce, a complaint, a provider timeout and a template with missing data. Staging must not email real customers.
5. Launch: we cut over one message type at a time, starting with the one that hurts most when it fails, and we watch placement and bounce rate.
6. Support: a short runbook for rotating keys, reading a bounce and rolling back a template, plus optional watching of DMARC and the queue.

Why CodeWiz

• The application and the mail path together: we build the Laravel, Node.js, WordPress and store code, so the message is queued where the order or the login actually happens.
• Open-source first, providers where they earn their place: your app stays portable. SendGrid or Mailgun is a delivery service, not a place we hide business logic.
• Tailored, not a default plugin: a WooCommerce shop, a SaaS billing mailer and a support inbox do not get the same setup.
• Fair pricing: premium development without premium prices, from Banja Luka, working remotely with clients locally and internationally.
• The rest of the product in the same hands: payments, performance and the storefront sit with the same team. More about the studio is on the about CodeWiz page.

Frequently Asked Questions

How long does an email integration take?

A single provider, a verified domain and a handful of transactional templates is often done within days, including seed tests. A migration off an old sender, with inbound routes and several brands, takes longer because DNS and the parallel run have to overlap.

How much does the setup cost?

It depends on the number of templates, the state of your DNS and whether mail is already sent from the web request. Provider fees are yours, billed by that provider. We quote the implementation after a look at the messages, not as a flat package.

Will my mail stop going to spam?

Authentication, a clean list and separate streams remove the usual reasons receivers distrust a domain. No one can promise a specific inbox placement at Gmail or Outlook. We can show you the authentication result, the bounce rate and a seed inbox after launch.

Can you move us off an old SMTP plugin without losing order mail?

Yes. We run the new path in parallel, compare a sample of messages, then switch one type at a time. Orders stay recorded in your database even while a single send is retried, which is the point of taking the send out of the checkout request.

Do you handle newsletters as well as receipts?

We set up the separation, the domain and the consent basics so a campaign cannot damage transactional placement. The campaign calendar and the copy are yours. We would rather wire the unsubscribe correctly than send a list you are not allowed to mail.

Ready for Mail That Arrives?

Tell us which messages customers miss today and which system sends them. We will propose a setup that authenticates the domain and keeps order and account mail moving when the provider hiccups. Contact us to talk it through, or see our email integration services.