Can't Send Email to Addresses at My Own Domain

can't send email to addresses at my own domain

I've had this problem myself, when I was redesigning a site recently.

There was an issue with the way our system was set up, so that the system thought that because the email was coming from the same domain it was a spam email and as such blocked it.

Check with your system administrator that you are allowed to be sending the emails etc.

Either that, or you'll have to modify the headers to have look like it's being sent from an external address. Hope you get it sorted.

Why can I send emails from domains I don't own?

Yes, you are correct that there's isn't anything technically preventing you from sending e-mail as another user. This is defined as part of the Simple Mail Transfer Protocol (SMTP). However, there are authentication processes out there to try and identify mail sent like this on the receiving end:

1. DKIM (Domain Keys Identified Mail) https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail
2. SPF (Sender Policy Framework) https://en.wikipedia.org/wiki/Sender_Policy_Framework

It is likely that it's actually the failure of these authentication processes that is directing your mail to your junk folder, instead of/as well as the message content. This, combined with other elements in the UI of your e-mail client (such as "fraud detection" in Thunderbird) is, as a user, what would call out to you that the e-mail might not be trustworthy.

DKIM

DKIM works via an asymmetric key. Only the true owner of a domain knows the private half which is used to digitally sign emails, and they publish the public half as a TXT record in their DNS zone.

When someone receives an e-mail claiming to be from example.com, their email client will check a DKIM-Signature header on the message, using the published public half of the key to verify that the message has been signed correctly. As the signature also includes a hash of the message contents, this also ensures that the contents have not been changed in transit as well as ensuring the sender is legitimate.

SPF

The true owner of a domain publishes a list of hosts allowed to send e-mail on it's behalf, again as a TXT record in their DNS zone.

When someone receives an e-mail claiming to be from example.com, their e-mail client will check that the host that sent the e-mail has been authorized to by the domain's owner.

Can't send emails to custom domains (non-gmail/hotmail emails) using Mailgun

It seems that for some email services, it requires a valid "receive" MX record for your domain/subdomain (for Mailgun it was mg.mydomain.com) to verify the identity of the sender. I added the MX records

10 mxa.mailgun.org
10 mxb.mailgun.org

for mg.mydomain.com and it seemed to have worked.

Allow customers to send from their own domain in a SAAS application

First, for the record, my SaaS platform does this (vía option 2b). It’s an e-commerce marketplace and I need the receipts to be sent from the email address of the product seller, not from me (the marketplace)

You have two(ish) options

1. Send email through your client’s mail servers (instead of mailjet)

2. Verify the client’s domain on your Mailjet (or similar email) service

option 1

With option 1, you’ll need to ask your client’s IT team to setup a username and password for you to access their SMTP server. This is essentially just like them creating an email account for you to use. This may seem like the easiest path available for you, but there are potential pitfalls and disadvantages:

Doing this, you will lose the mail open/click/bounce tracking functionality you get with mailjet; because you’ll be using the company’s SMTP server instead.

If you’re sending out as a fairly common email address (eg info@your-client.com) the client may already have that account active on their mail servers. That would allow them to receive replies into the existing infrastructure but make them wary of the security issues with sharing a password to their mail server with you.

You might find that they don’t even have the ability to give you a username and password. Modern mail services don’t allow for SMTP access (which is what your web app will need); and security conscious companies require 2 factor authentication on mail accounts (which your web app can’t answer)

Option 2

For this, you will need to ask their IT team to configure some DNS records to prove to mailjet, and to the email recipient, that you’re allowed to send on behalf of your client.

You did this for your own domain when you first setup mailjet. See https://app.mailjet.com/support/how-to-add-a-sender-address,96.htm for what this involves, but it’s a case of asking the client to configure a DNS record.

That tells mailjet that you’re allowed to send on behalf of that domain; but you’ll also want the client to adjust their SPF and DKIM records so as the recipient of the emails knows to trust Mailjet’s servers with emails sent from your client’s domain name. Normally, recipients only trust email sent from your client’s mail server (which you have as option 1) and distrust email sent from SAAS providers.

You will (or should) have done this on mailjet for your own domain already as well. https://app.mailjet.com/docs/spf-dkim-guide

So for this, you’ll need your client to setup 3 DNS records.

If you go this way, you could setup a separate Mailjet account which they and you have access to. That way they ca see their dashboard directly and feel a sense of ownership and security around it. But you won’t be able to markup the price of it /p>

Conclusion

How important is the tracking? If you can’t lose that you need to go with option 2.

How technically savvy is the client? Are they going to be able to have those DNS records changed? Are they going to be (rightly) security conscious around giving you an account on their main mail sever.

Option 2 would be my preference. You might need to hold their hand through the DNS setup so get it configured on Mailjet (And ask about SPF in here to make sure you get it right) so you can provide them with clear instructions of the specific 3 DNS records to create/update.

Whatever approach you take make sure you’re talking to the right people at your clients side soon. Their marketing team may be keen to do this with you, but if their IT feels left out of the conversation they will be difficult to get on board when you need them to make the changes. Us IT folk can be grumpy and obstinate /p>

your web app

This is going to need some adjustment. You probably already store your Mailjet credentials in a file or environment variables; these might need to move these to a dB table so you can relate credentials with specific accounts. But we’d need more info on the web app to be able to speak more to that side of the challenge.

option 2b

just as a note instead of a real suggestion. Be aware that some email service provers allow the sending verification part to be done by sending an email to someone on that domain (eg admin@yourclient.com) and then allowing sending vía the API if the recipient clicks on the approve link on that email. But, even with that setup you still need the client to configure SPF and DKIM on their DNS, so the extra one record isn’t a big ask. AWS’s SES allows for this. This works for me; but I have different requirements around deliver ability, and a large number of non-tech users (as opposed to your one or two big clients)

Send or receive email if server get downtime

If you are hosting your own e-mail server, use a local e-mail client and POP3/IMAP with your server. If a message is unable to be sent due to your server being down, it will be held in the program's outbox until the server is back up and running. Unfortunately this is the downside of hosting your own e-mail. There is no way of sending/receiving e-mail without a working server, just as it is impossible to send/receive phone calls if your phone line was cut.

---

Related Topics