Can I send mail “from” a domain name I don't host with you?
Customers occasionally ask if it’s okay to send outgoing email through our servers using an email address that isn’t hosted with us.
For example, we’ve been asked if it’s okay to send email from a “harvard.edu” address through our servers, because Harvard University doesn’t provide their alumni with an outgoing email server.
Unfortunately, you can’t do that. While that sort of thing was commonly allowed before spam became a problem, it’s neither secure nor reliable on today’s Internet.
On this page:
E-mail forgery is a big problem. When you get a message falsely claiming to be from Citibank, Harvard, or another institution, that happened because another email company incorrectly allowed one of their users to send mail claiming to be from citibank.com, harvard.edu, and so on.
If every mail company prevented their users from sending mail from unrelated domain names, most email forgery would stop immediately.
For that reason, the Internet Engineering Task Force has published “Best Practice” recommendations that say that email servers “MUST perform authentication on the identity asserted during all mail transactions”.
In other words, if you’re sending mail claiming to be from “email@example.com”, then our mail server needs to make sure that you’re authorized to do that — if we don’t, you could be forging a stranger’s Harvard address. But of course, only Harvard can check that (they could make sure you’re using the password they’ve assigned you). We have no way of checking it. Allowing it would allow any of our customers to send malicious forged mail.
So the bad news is that you can’t send mail claiming to be from other domain names we don’t handle mail for. The good news is that since we don’t allow hackers and spammers to open accounts with us and do that, our servers are almost never blacklisted because they’ve sent forged email messages. Your outgoing email delivery is much more reliable as a result.
Even if we allowed this, it wouldn’t work reliably anyway.
E-mail forgery is such a problem nowadays that many receiving mail servers try to detect mail that was sent from an unauthorized server for a given domain name, then filter such messages as “spam”.
There’s a system called SPF that allows organizations to “publish” information about what IP addresses they legitimately send mail from, and it’s becoming more and more widely used.
And there’s another system called DKIM that allows outgoing servers to “digitally sign” mail to indicate that it's not a forgery, and to publish information saying that unsigned mail shouldn’t be trusted.
If you sent mail claiming to be “from” harvard.edu through our servers, and Harvard added SPF or DKIM information saying that mail from unspecified servers or unsigned mail is forged (which is increasingly likely), you’ll have big problems. The mail you send will be rejected, filtered, or even just deleted by receiving mail servers.
In short, sending mail like this doesn’t work well. If an organization gives you an email address that’s supposed to work for outgoing mail, they should also give you a properly configured outgoing mail server to use that handles SPF and DKIM. If they refuse to give you that, that means they don’t want you sending mail using that address. That unfortunately isn’t a problem we can solve (it’s a policy issue between you and them, not a technical problem).
What is DMARC?
A system called DMARC allows receiving mail servers to easily check the SPF and DKIM details mentioned above. If you receive a “bounce” mentioning “DMARC”, or saying that a message was “not accepted for policy reasons”, it often means that a script on your site is sending messages claiming to be “From” an address you don’t really own.
This is particularly common with feedback form scripts, “tell-a-friend” scripts, and so on. These sometimes try to send messages claiming to be “From” the address of the person filling out the form, which is always wrong.
For example, if your site has a “Contact Us” form, and a visitor fills it out using their own “firstname.lastname@example.org” AOL address, your script should not send a message to your Gmail address like this:
From: Visitor <email@example.com> To: example.com Webmaster <firstname.lastname@example.org> Subject: Feedback form
This won't work. Gmail will notice that your site is sending messages from an aol.com address, but they know you aren’t really aol.com, so they reject it as a “forgery”. (While it may be the case that your visitor really owns the address “email@example.com”, you don’t know if that’s actually true, and you can’t just take someone’s word for it on today’s Internet. And Gmail has no idea at all where you got the address from or why example.com is trying to send mail that claims it’s from AOL.)
Instead, make your script send email only from addresses ending with your own domain name, as in this example:
From: firstname.lastname@example.org Reply-To: Visitor <email@example.com> To: example.com Webmaster <firstname.lastname@example.org> Subject: Feedback form from Visitor (email@example.com)
Gmail will accept this because you’re explicitly sending it from an address @example.com, even if it mentions “firstname.lastname@example.org” in the “Reply-To” and “Subject” fields.
(Most people asking us about this turn out to be using a WordPress plugin called “Contact Form 7” that seems to send the wrong way by default; we have a page explaining how to modify Contact Form 7 to work with DMARC. And we have another page explaining how to fix this for the Gravity Forms plugin.)