You know, sometimes it's the silliest, most boneheaded things which trip us up. This is true for your email too. See if you can spot the mistakes in this email (this is a genuine, unretouched email, other than our changing the name of the service to "Geegaw" in order to protect the hapless).
Here's why you should never send email "from" an email address that doesn't exist, and why an email address from which you send email needs to be real. Once upon a time somebody - somewhere - somehow decided that it would be good idea to send email to their mailing lists using an email address in their "From:" field that didn't really exist. But sending email "from" an email address that doesn't really exist is a spectacularly bad idea. In fact, it may even qualify as the Epic Fail of "from" email address ideas.
Just mention the term 'DNS', and many email senders' eyes glaze over; say "reverse DNS" or "rDNS" and a look of panic may replace the glaze. Yet, not only are these not complicated concepts, but having reverse DNS set up is crucial to having consistent, good email delivery and deliverability. So it's important to have a good understanding of what DNS and reverse DNS are, and do.
Yesterday we talked about why you should give each of your customers their own IP address. But for various reasons, not everybody can do that - at least not right away - and so, as promised, today we are going to talk about segregating your outbound mail across different IP addresses based on opt-in quality.
Of the current email authentication mechanisms, SPF, DKIM, and DMARC, DKIM seems to be the most confusing for people (this is why we offer a human-powered DKIM checker, contact us for a free DKIM check). What is a DKIM selector? What are the DKIM tags? How does one create a DKIM record? Is there a good DKIM record generator? Here is a plain English explanation of DKIM, and a breakdown of the anatomy of a DKIM record.
Hopefully by now you have read our article about what the big Yahoo DMARC p=reject rejection means for you and your email. And you may or may not be aware that yesterday AOL did the exact same thing, also publishing a DMARC policy of p=reject, which means, essentially, "reject any email coming from a yahoo.com or aol.com address if it was not sent through a Yahoo or AOL mail server."
If you are a business or commercial email sender, you can't help but have heard about the big issue with Yahoo that unfolded over this past week, having to do with Yahoo, DMARC, "p=reject", and Yahoo's rejection and bouncing of billions of pieces of email. But what does it mean for you, the commercial email sender?
Do you know what your DMARC policy is, or if you even have a DMARC record? Of the authentication mechanisms (DMARC, SPF, DKIM) SPF and DKIM are important resources to authenticate different aspects of your email flow, but it's important to have a DMARC record stating your DMARC policy as well. This is because your DMARC policy (contained in your DMARC record which is a text record within your DNS records) tells email receivers what they should do with email that claims to be from you but that fails SPF and/or DKIM.
One of the first things that a responsible ESP must deal with, before starting to mail on behalf of their customers, is Reverse DNS (rDNS from now on). This is true for businesses that send out their own email, as well. This is our tutorial on how to set up rDNS.
