How do I unspam myself?
June 4, 2023 12:02 PM Subscribe
Following up on this one. How do I make my emails not end up in people's spam folders?
The sender is [my store email address] via ecbiz219.inmotionhosting.com (my website host). I use POP3 to check and send from that address through my gmail account.
I've checked with a bunch of people, and as many as a third of my emails are going into spam folders. When I check the authentication record, I get SPF results but not DKIM or DMARC. (In this, [server] is the name of my website, which is hosted by inmotion.)
Authentication-Results: mx.google.com;
spf=pass (google.com: found no external ips, assuming domain of [server]@ecbiz219.inmotionhosting.com as permitted sender) smtp.mailfrom=[server]@ecbiz219.inmotionhosting.com
Received-SPF: pass (google.com: found no external ips, assuming domain of [server]@ecbiz219.inmotionhosting.com as permitted sender)
Is the lack of DKIM and DMARC causing an issue? How do I fix this? On the host side, I have both SPF and DKIM enabled.
The sender is [my store email address] via ecbiz219.inmotionhosting.com (my website host). I use POP3 to check and send from that address through my gmail account.
I've checked with a bunch of people, and as many as a third of my emails are going into spam folders. When I check the authentication record, I get SPF results but not DKIM or DMARC. (In this, [server] is the name of my website, which is hosted by inmotion.)
Authentication-Results: mx.google.com;
spf=pass (google.com: found no external ips, assuming domain of [server]@ecbiz219.inmotionhosting.com as permitted sender) smtp.mailfrom=[server]@ecbiz219.inmotionhosting.com
Received-SPF: pass (google.com: found no external ips, assuming domain of [server]@ecbiz219.inmotionhosting.com as permitted sender)
Is the lack of DKIM and DMARC causing an issue? How do I fix this? On the host side, I have both SPF and DKIM enabled.
Hey GoatDog. I'm a consulting CTO for SaaS businesses and often troubleshoot email delivery and spam filtering issues at scale.
Because there are so many related-but-separate systems involved in email, getting this all working is rarely as straight forward as flipping the switch in your host's control panel.
One of the reasons email is so successful is that it is technically very simple to get a message to anyone else's decentralized inbox. To send an email, your outgoing email server performs a domain name service (DNS) lookup to ask "what network IP address should I contact to communicate email for this human-friendly domain name?". Then Your mail sender can then just open a connection directly to that address and say "EHLO! I have a message for an account named GoatDog at YourShop.com. Here's the text."
Because email is most useful when anyone can send you a message, receiving email servers need to accept any message that says it is destined for GoatDog@YourShop.com. Then people started taking advantage of this for unsolicited direct marketing, colloquially known as "spam" messages. (Search YouTube for Monty Python's spam skit to understand why.)
To combat this problem, several schemes have been built over the years to try and validate that the source of a email is the claimed sender, so that bad actors can at least be tracked and blocked. Otherwise they can just put on a fake name tag and lie about who an email message is from ("spoofing").
SPF ("Sender Policy Framework") is an out-of-band system designed to help receiving mail servers confirm that the sending email server is authorized to be passing messages from the email sender's InterestedParty.com domain. Setting up SPF involves creating a specially formatted DNS TXT record that says "servers at these IP addresses can be trusted to be sending email messages that are from InterestedPary.com. Any servers not on this list are fake spammers trying to steal our good name."
[Note: Your SPF result headers above seem to imply that there is no SPF information available at all, so all messages that claim they are sent from YourShop.com are "soft passing" this check. SPF is not yet correctly set up with DNS records on YourShop.com. ]
With many emails being sent through large popular services like Google Gmail or Microsoft Outlook.com, an SPF record indicating that anybody using a Google IP address could be the real YourShop.com is not specific enough.
DKIM ("DomainKeys Identified Mail") is a method of electronically signing each email message confirming that it really came from the desk of YourShop.com. This system makes use of public/private key cryptography. A key pair is created so that your domain's private key is used to generate a content signature value for the chunk of text being given to the receiving server. The receiving mail server can look up the public key and use that to confirm that the content signature is valid. This is accomplished by publishing the public key value in a DNS TXT record so that it's easy for any mail server to find. Typically your email host will generate the public/private keypair on their server, keep the private key for signing outgoing messages, and tell you the public key to set up the DKIM public key DNS record.
DMARC (“Domain-based Message Authentication, Reporting & Conformance”) does not strictly help a receiving email server determine if an incoming email message is from a legitimate source. It is more of a handling policy that tells receiving mail services that YourShop.com is a good neighbor and has done their part in setting up the SPF and DKIM sender authentication systems, so if emails don't pass those checks they can just throw them out instead of giving unwanted spam messages to their mail clients. Without that confirmation, the receiving email server needs to try and guess if you're a legitimate sender that hasn't set up those other checks or if you're an unsolicited imposter.
DMARC also provides receiving mail server with a "complaints hotline" to report when they receive a message that claims to be from YourShop.com but failed the identity checks. This is helpful for identifying when those systems are working successfully or if something has accidentally broken and all of your legitimate outbound emails are using the wrong signature key.
Setting up a DMARC handling policy is also creating a specially formatted DNS TXT record for YourShop.com. Getting the error messages back requires subscribing to a DMARC message handling service that acts as your complaints call center.
Feel free to MeMail me if you'd like some help getting everything set up on your domain. It's one of these things that's pretty straightforward when you know the knobs to turn, but can be hard to wrap your head around from scratch.
posted by QuixoticGambit at 2:45 PM on June 4, 2023 [6 favorites]
Because there are so many related-but-separate systems involved in email, getting this all working is rarely as straight forward as flipping the switch in your host's control panel.
One of the reasons email is so successful is that it is technically very simple to get a message to anyone else's decentralized inbox. To send an email, your outgoing email server performs a domain name service (DNS) lookup to ask "what network IP address should I contact to communicate email for this human-friendly domain name?". Then Your mail sender can then just open a connection directly to that address and say "EHLO! I have a message for an account named GoatDog at YourShop.com. Here's the text."
Because email is most useful when anyone can send you a message, receiving email servers need to accept any message that says it is destined for GoatDog@YourShop.com. Then people started taking advantage of this for unsolicited direct marketing, colloquially known as "spam" messages. (Search YouTube for Monty Python's spam skit to understand why.)
To combat this problem, several schemes have been built over the years to try and validate that the source of a email is the claimed sender, so that bad actors can at least be tracked and blocked. Otherwise they can just put on a fake name tag and lie about who an email message is from ("spoofing").
SPF ("Sender Policy Framework") is an out-of-band system designed to help receiving mail servers confirm that the sending email server is authorized to be passing messages from the email sender's InterestedParty.com domain. Setting up SPF involves creating a specially formatted DNS TXT record that says "servers at these IP addresses can be trusted to be sending email messages that are from InterestedPary.com. Any servers not on this list are fake spammers trying to steal our good name."
[Note: Your SPF result headers above seem to imply that there is no SPF information available at all, so all messages that claim they are sent from YourShop.com are "soft passing" this check. SPF is not yet correctly set up with DNS records on YourShop.com. ]
With many emails being sent through large popular services like Google Gmail or Microsoft Outlook.com, an SPF record indicating that anybody using a Google IP address could be the real YourShop.com is not specific enough.
DKIM ("DomainKeys Identified Mail") is a method of electronically signing each email message confirming that it really came from the desk of YourShop.com. This system makes use of public/private key cryptography. A key pair is created so that your domain's private key is used to generate a content signature value for the chunk of text being given to the receiving server. The receiving mail server can look up the public key and use that to confirm that the content signature is valid. This is accomplished by publishing the public key value in a DNS TXT record so that it's easy for any mail server to find. Typically your email host will generate the public/private keypair on their server, keep the private key for signing outgoing messages, and tell you the public key to set up the DKIM public key DNS record.
DMARC (“Domain-based Message Authentication, Reporting & Conformance”) does not strictly help a receiving email server determine if an incoming email message is from a legitimate source. It is more of a handling policy that tells receiving mail services that YourShop.com is a good neighbor and has done their part in setting up the SPF and DKIM sender authentication systems, so if emails don't pass those checks they can just throw them out instead of giving unwanted spam messages to their mail clients. Without that confirmation, the receiving email server needs to try and guess if you're a legitimate sender that hasn't set up those other checks or if you're an unsolicited imposter.
DMARC also provides receiving mail server with a "complaints hotline" to report when they receive a message that claims to be from YourShop.com but failed the identity checks. This is helpful for identifying when those systems are working successfully or if something has accidentally broken and all of your legitimate outbound emails are using the wrong signature key.
Setting up a DMARC handling policy is also creating a specially formatted DNS TXT record for YourShop.com. Getting the error messages back requires subscribing to a DMARC message handling service that acts as your complaints call center.
Feel free to MeMail me if you'd like some help getting everything set up on your domain. It's one of these things that's pretty straightforward when you know the knobs to turn, but can be hard to wrap your head around from scratch.
posted by QuixoticGambit at 2:45 PM on June 4, 2023 [6 favorites]
You should absolutely set up all three (SPF, DKIM and DMARC) as they all contribute different things to email validation. I recently set them up for my own domain (gible.net) and found https://mxtoolbox.com/ to be very useful for identifying issues and understanding what I needed to do to fix them. The InMotion support docs that eschatfische linked to would have been insufficient for me; I mostly got it sorted with a combination of Google's and Cloudflare's support docs. YMMV as I'm using those platforms.
posted by gible at 6:08 PM on June 4, 2023 [2 favorites]
posted by gible at 6:08 PM on June 4, 2023 [2 favorites]
Response by poster: I guess I'll have to talk to Inmotion's customer support, because in both cases it says "DKIM is properly configured for this domain," followed by a "current DKIM TXT record" and some gibberish. Same for SPF. There aren't any other steps I can take from that point.
posted by goatdog at 7:23 PM on June 4, 2023
posted by goatdog at 7:23 PM on June 4, 2023
I have had some success with inmotion's tech support helping me with email deliverability issues, so definitely worth trying a chat. They've sometimes had to adjust the SPF and DKIM settings for me, as I'm not savvy enough to do it myself.
posted by jindc at 10:41 AM on June 5, 2023 [1 favorite]
posted by jindc at 10:41 AM on June 5, 2023 [1 favorite]
« Older Best way to prevent leakage when two pipes are... | Followup after watching last episode of Succession Newer »
This thread is closed to new comments.
These are Inmotion's support docs for enabling SPF and DKIM. Perhaps you just need to go in per the instructions and select "Install the Suggested Record" for DKIM and SPF for this domain? If that doesn't work, and this still isn't clear, this is certainly something Inmotion's support could help you with easily.
posted by eschatfische at 2:15 PM on June 4, 2023 [1 favorite]