Don’t Know Your Company’s SMTP Server? Use mx.text.email Instead (With a Few Caveats)

A lot of devices and systems can send email alerts… but only if you give them SMTP settings.

Think: industrial equipment, UPS units, security panels, environmental sensors, website monitoring tools, network appliances, and “smart” everything. Many of these products were designed for IT departments and assume you know your company’s outbound mail server details.

If you don’t know your company’s SMTP server information (and you can’t easily get it), there’s a simple fallback: you can send directly to text.email’s SMTP server.

The Quick Option: Connect Directly to mx.text.email

If your device asks for an SMTP server, you can enter:

• SMTP server / host: mx.text.email

You can typically connect on any of these ports (depending on what your device supports):

• 25
• 587
• 465
• 2525

Then configure the “To” address as your text.email address, for example:

• your-number@text.email
• your-number@your-subdomain.text.email

When text.email receives the email, it converts it into an SMS message (and handles the rest of the delivery flow).

No username/password needed

Many SMTP setups require authentication (a username + password). That’s common when you’re sending email out to the broader internet.

This direct-to-text.email approach is different because:

• You’re sending to a local address at @text.email or @subdomain.text.email
• The message is being handed directly to the receiving server for the text.email domain

So in typical device UIs, you can leave these blank:

• Username: (blank)
• Password: (blank)

If the device forces you to enter something anyway, try entering a placeholder value (some devices won’t allow empty fields), but text.email does not require SMTP AUTH for mail destined to text.email.

A Note About SPF / DKIM / DMARC (Important)

Email authentication is normally validated using three common mechanisms:

• SPF (was this message sent from an allowed server for the sender’s domain?)
• DKIM (is there a valid cryptographic signature from the sender’s domain?)
• DMARC (does the sender’s domain publish a policy requiring SPF/DKIM alignment, and did the message pass?)

What text.email does today

Right now, mx.text.email is not strictly validating inbound mail against SPF, DKIM, and DMARC.

That’s intentional: lots of alerting devices send email in “weird” ways, and we’d rather deliver your SMS than block a critical notification because a device can’t do modern email auth correctly.

What may change later

Over time, we’ll likely tighten this up and start enforcing SPF/DKIM/DMARC checks more strictly (because stronger validation helps prevent abuse, spoofing, and spam).

Why direct device-to-mx.text.email can fail these checks

If your device is relaying directly to mx.text.email, it’s very common for one or more of SPF/DKIM/DMARC to fail, for reasons like:

• The device uses a “From” address like alerts@yourcompany.com, but it’s not actually sending from an approved outbound server for yourcompany.com → SPF fails
• The device doesn’t support DKIM signing at all → DKIM fails
• Your domain has a DMARC policy requiring alignment, and the device’s sending behavior doesn’t align → DMARC fails

So even though it works today, direct relay is best treated as a fallback—and it’s another reason to prefer your company’s official SMTP relay whenever possible.

When Should You Use Direct Relay?

Use this approach when:

• You don’t know your organization’s SMTP relay settings
• You don’t have permission to use the corporate mail system
• You’re working with a device where the vendor documentation is vague (or wrong)
• You want to “just make it send alerts” without involving IT

If you do have access to your company’s SMTP server information, it’s usually better to use that.

Downsides and Tradeoffs to Consider

Direct-to-mx.text.email is convenient, but it’s not always the best long-term solution.

1) Some networks block outbound SMTP (especially port 25)

Many corporate networks and ISPs block outbound SMTP to reduce spam. If your device sends mail on port 25, the connection might fail entirely.

Workarounds:

• Try 587, 465, or 2525
• Use your corporate SMTP relay (often permitted internally)

2) No authentication means fewer identity guarantees

Without SMTP AUTH, the receiving side has fewer ways to confirm the sender is “allowed” to send. That can make spoofing easier and auditing harder.

3) Future SPF/DKIM/DMARC enforcement may break direct relay setups

As described above, this is the big one: direct relay is the most likely path to failing SPF/DKIM/DMARC in the future.

4) Some devices have outdated SMTP/TLS support

Old devices can be finicky about STARTTLS, TLS versions, or SMTP behaviors. A corporate relay may be more forgiving.

5) Debugging is sometimes harder without IT visibility

If you route through your corporate SMTP relay, IT can often look up logs. Direct device-to-mx.text.email setups can be trickier to diagnose if the device doesn’t provide good error details.

6) Compliance and security considerations

Some organizations require alerts to flow through approved systems, especially if messages contain sensitive data.

Recommendations and Quick Setup Checklist

Ready to get started?

Recommended best practice

• Best: Use your organization’s approved SMTP relay (if available)
• Fallback: Use mx.text.email when you don’t know the SMTP details or can’t get them
• Always: Send to your text.email address (@text.email or @subdomain.text.email) so it routes correctly and generates SMS

Setup checklist

When a device asks for SMTP settings:

• ✅ SMTP server/host: mx.text.email
• ✅ Port: 25, 587, 465, or 2525
• ✅ SMTP authentication: None / disabled
• ✅ “To” address: your text.email address
• ✅ Send a test message

If the test fails, the two most common causes are:

1. outbound SMTP blocked on the network (try a different port)
2. the device’s TLS/SMTP implementation is outdated