DreamHost – Gmail Conflict: Emails With Attachments Blocked By Gmail When Using Spoofed Address

This one is a bit esoteric, but it had been befuddling me for months:

When using a WordPress blog hosted on DreamHost, unless your blog is using an email address set up on DreamHost, some emails sent by WordPress will be rejected outright by Gmail (and other email services) — namely, any message that has an attachment won’t be accepted.

The fix: You need to either create a real email address, on DreamHost, that uses your blog’s domain; or you need to use a third-party email service; or use a plugin to force WordPress to use SMTP for sending emails, and then configure your SMTP server to properly handle messages.

Gmail: No Attachments On Spoofed Emails

I host this website on DreamHost, which is hands-down the best shared Web hosting I’ve ever run across, in terms of the price I pay for the features I get.

At the same time, Gmail handles almost all my email needs. So, when I set up this WordPress blog, I used dougvanderweide@gmail.com as the default email address to be used by WordPress.

For most email that my WordPress install needs to send me, that’s not a problem. The messages were sent and received without incident for years.

Some time ago, I installed what was formerly known as Better WP Security, now iThemes Security. One of its features is the ability to have database backups emailed to me on a schedule.

The problem I ran into is that while Better WP Security reliably generated the backups, and even saved them to my non-standard WP uploads directory path, and even managed to send those emails, I never got them at my Gmail address.

Sent ... but never received.
Sent … but never received.

Basically, any email that had an attachment, sent via WordPress, was blocked by Gmail. Not sent to spam; bounced outright.

The fix was straightforward: I had to create a new email address, on the dougv.com domain, to enable the delivery of messages with attachments. Then, I changed the default email address for this blog under Settings > General, as well as the email addresses in the iThemes Security area, to be my dougv.com address.

Email address changed to be one on dougv.com
Email address changed to be one on dougv.com

In the Dreamhost control panel, I also set up that new email address to forward all messages it receives to dougvanderweide@gmail.com — mostly so I don’t have to bother checking that new dougv.com email. (I could also set up Gmail to check that account via POP, or use an IMAP client to check both accounts; I’m slightly inconvenienced no matter what, and forwarding is, to me, the least of admittedly mild inconveniences).

Added Gmail as a forwarding address for my dougv.com email address.
Added Gmail as a forwarding address for my dougv.com email address.

Interestingly, by adding Gmail as a forwarding address, I can now receive those database attachments I wasn’t getting before.

I believe this is related to spoofing: That is, using an email address that isn’t associated with a specific email server as the from address for an email. Google isn’t fond of spoofed emails, but accepts them when they don’t have attachments; but any attachment from a spoofed address is cause for outright rejection of the message.

That’s fair enough from a security standpoint, so I can’t fault them.

Quick Fixes When You Must Spoof

Let’s suppose you can’t use your website’s domain to send email messages, or your email is hosted someplace else and therefore, when WordPress creates the message, it will effectively be spoofing your address. How can you fix that?

The best fix is to use a plugin, theme function or the like to override wp_mail() — the code WordPress uses to send email — to use SMTP, rather than the default mail() function built into PHP.

This, in combination with SPF records (more on those in a moment) — and with DomainKeys, a method for digitally signing emails — will almost certainly overcome your spoofed mail delivery problems.

For example, suppose your website is at myblog.com, but you need to send email messages from email.com. If you set your blog up to use the email address me@email.com, and configure WordPress to use the SMTP servers at email.com, your email will actually originate on email.com.

In other words, you won’t be spoofing; your messages will be sent from email.com, even though it’s myblog.com that wants to send them.

The next best option is to use a third-party email service, such as Google Apps For Business, in conjunction with an SPF record on your blog’s domain, indicating that you use that third-party service to create email, and the appropriate MX record entries at myblog.com to use that third-party email service.

This doesn’t remove the spoof; but it signals that you are intentionally using another service to send email, and are willing to take responsibility for the spoofed message.

A weak option, which probably won’t work, is to create an SPF record, for your website domain, that includes the domain from which your emails are originating.

Again, assuming a blog at myblog.com and an email address at email.com, that SPF record on myblog.com would look like:

v=spf1 include:email.com ~all

This isn’t going to directly fix your problem, either, and it might not be enough to get Gmail or other email services to stop rejecting your spoofed emails outright. But like using a third-party vendor, it is going to signal email providers that you are willing to take responsibility for messages sent from email.com but that bear a myblog.com address.

All links in this post on delicious: https://delicious.com/dougvdotcom/dreamhost-gmail-conflict-emails-with-attachments-blocked-by-gmail-when-using-spoofed-address

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  • Check out the Commenting Guidelines before commenting, please!
  • Want to share code? Please put it into a GitHub Gist, CodePen or pastebin and link to that in your comment.
  • Just have a line or two of markup? Wrap them in an appropriate SyntaxHighlighter Evolved shortcode for your programming language, please!