Get the next one in your inbox.
One email when we publish something worth reading. No spam — appropriately enough, we'd know.
"Send from your own domain" sounds simple but touches SMTP credentials and DNS records most people never think about. Here's what's actually happening.
Get an instant summary, key takeaways, action items, and answers to your questions about this article.
Sending email from your own domain means the mail is routed through an SMTP server tied to your domain's identity, and your domain's DNS has authentication records telling other mail providers the sending source is legitimate. Without this, email sent 'on your behalf' by a third party can look unverified to spam filters, hurting deliverability.
"Send from your own domain" sounds like a checkbox — either your emails come from you, or they don't. Under the hood, it's really two separate things lining up at once: where the message is actually sent from, and what your domain's DNS says about who's allowed to send on its behalf.
Every email is sent through an SMTP server — a piece of mail infrastructure somewhere that has credentials (a username and password, usually) tied to a specific sending account. If a form backend sends your notification emails through its own shared servers, the message technically comes from them, even if the From address is set to look like it's from you. Connecting your own SMTP server — your own email provider's outgoing server, with your own username and password — means the message is actually routed through infrastructure tied to your identity, not a shared one.
This is what FormBridge's Custom SMTP setting does: under Account → SMTP Configurations, you add your provider's host, port, encryption type, username, and password, and assign that connection to a form. From then on, that form's notifications and autoresponders go out through your server instead of FormBridge's default sender.
The SMTP server is only half the story. Every domain also has DNS records — public settings anyone can look up — that other mail servers check to decide whether a message claiming to be from your domain is legitimate. Without the right records in place, a receiving mail server has no way to confirm that the server sending the message was actually authorized by your domain to do so. That uncertainty is exactly the kind of signal spam filters weigh heavily, regardless of how well-written the email itself is.
These DNS records live with your domain's DNS host or registrar — not with whichever tool is sending the mail — so setting them up is a one-time step you or your provider handles at the domain level, separate from any SMTP configuration.
The payoff for getting both pieces right isn't cosmetic. It's fewer messages landing in spam, more trust signals for receiving mail providers, and a sender identity that's actually verifiable rather than borrowed. If you're already connecting a custom SMTP server to send under your own name, it's worth confirming your domain's authentication records are in place too — the SMTP connection and the DNS records are two different requirements that both need to be satisfied for the full deliverability benefit.
Technically, it means two things line up: the SMTP server actually sending the message is configured with credentials tied to your domain (so the From address matches who's really sending it), and your domain's DNS has records that let receiving mail servers verify that sending source is authorized to send mail as you.
Mail providers use domain authentication as a major signal when deciding where to deliver a message. If a receiving server can't verify that your domain actually authorized the sending source, it treats the message with more suspicion, which increases the odds it lands in spam rather than the inbox regardless of how well-written the content is.
One email when we publish something worth reading. No spam — appropriately enough, we'd know.