If you’re sending email at any type of volume, it’s an industry where you’re assumed guilty and have to prove your innocence. We work with a lot of companies assisting them with their email migration, IP warming, and deliverability issues. Most companies don’t even realize that they have a problem at all.
The Invisible Problems of Deliverability
There are three invisible problems with email deliverability that businesses are unaware of:
- Permission – Email service providers (ESP) manage the opt-in permissions… but the internet service provider (ISP) manages the gateway for the destination email address. It’s really a terrible system. You can do everything right as a business to acquire permission and email addresses, and the ISP has no idea and may block you anyway.
- Inbox Placement – ESPs promote high deliverability rates that are basically nonsense. An email that is routed directly to the junk folder and never seen by your email subscriber is technically delivered. In order to truly monitor your inbox placement, you have to use a seed list and go look at each ISP. There are services that do this.
- Reputation – ISPs and third-party services also maintain reputation scores for the sending IP address for your email. There are blacklists which ISPs may use to block all of your email altogether, or you may have a poor reputation which would get you routed to the junk folder. There are a number of services you can use to monitor your IP reputation… but I’d be a bit pessimistic since many don’t actually have insight into each ISPs algorithms.
The best practices for mitigating any inbox placement issues is to ensure you have set up a number of DNS records that ISPs can use to look up and ensure that the emails you are sending are truly sent by you and not by someone pretending to be your company. This is done through a number of standards:
- Sender Policy Framework (SPF) – the oldest standard around, this is where you register a TXT record on your domain registration (DNS) that states what domains or IP addresses that you are sending email from for your company. For example, I send email for Martech Zone from Google Workspace and from CircuPress (my own ESP currently in beta). I have an SMTP plugin on my website to also send via Google, otherwise I would have an IP address included on this as well.
v=spf1 include:circupressmail.com include:_spf.google.com ~all
- Domain-based Message Authentication, Reporting and Conformance (DMARC) – this newer standard has an encrypted key in it that can validates both my domain and the sender. Each key is produced by my sender, ensuring that emails sent by a spammer can’t get spoofed. If you are using Google Workspace, here’s how to set up DMARC.
- DomainKeys Identified Mail (DKIM) – Working alongside the DMARC record, this record informs ISPs how to treat my DMARC and SPF rules as well as where to send any deliverability reports. I want ISPs to reject any messages that don’t pass DKIM or SPF, and I want them to send reports to that email address.
v=DMARC1; p=reject; rua=mailto:firstname.lastname@example.org; adkim=r; aspf=s;
- Brand Indicators for Message Identification (BIMI) – the newest addition, BIMI provides a means for ISPs and their email applications to display the logo of the brand within the email client. There’s both an open standard as well as an encrypted standard for Gmail where you also need an encrypted certificate. The certificates are pretty expensive so I’m not doing that just yet.
NOTE: If you need assistance on setting up any of your email authentication, don’t hesitate to reach out to my firm Highbridge. We have a team of email marketing and deliverability experts that can assist.
How To Validate Your Email Authentication
All of the source information, relay information, and validation information associated with every email is found within the message headers. If you’re a deliverability expert, interpreting these is pretty easy… but if you’re a novice, they’re incredibly difficult. Here’s what the message header looks like for our newsletter, I’ve grayed out some of the autoresponse emails and campaign information:
If you read through, you can see what my DKIM rules are, whether DMARC passes (it doesn’t) and that SPF passes… but that’s a lot of work. There’s a much better workaround, though, and that’s to use DKIMValidator. DKIMValidator provides you an email address that you can add to your newsletter list or send via your office email… and they translate the header information into a nice report:
First, it validates my DMARC encryption and DKIM signature to see whether or not it passes (it doesn’t).
DKIM Information: DKIM Signature Message contains this DKIM Signature: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=circupressmail.com; s=cpmail; t=1643110423; bh=PTOH6xOB3+wFZnnY1pLaJgtpK9n/IkEAtaO/Xc4ruZs=; h=Date:To:From:Reply-to:Subject:List-Unsubscribe; b=HKytLVgsIfXxSHVIVurLQ9taKgs6hAf/s4+H3AjqE/SJpo+tamzS9AQVv3YOq1Nt/ o1mMOkAJN4HTt8JXDxobe6rJCia9bU1o7ygGEBY+dIIzAyURLBLo5RzyM+hI/X1BGc jeA93dVXA+clBjIuHAM9t9LGxSri7B5ka/vNG3n8= Signature Information: v= Version: 1 a= Algorithm: rsa-sha256 c= Method: relaxed/relaxed d= Domain: circupressmail.com s= Selector: cpmail q= Protocol: bh= PTOH6xOB3+wFZnnY1pLaJgtpK9n/IkEAtaO/Xc4ruZs= h= Signed Headers: Date:To:From:Reply-to:Subject:List-Unsubscribe b= Data: HKytLVgsIfXxSHVIVurLQ9taKgs6hAf/s4+H3AjqE/SJpo+tamzS9AQVv3YOq1Nt/ o1mMOkAJN4HTt8JXDxobe6rJCia9bU1o7ygGEBY+dIIzAyURLBLo5RzyM+hI/X1BGc jeA93dVXA+clBjIuHAM9t9LGxSri7B5ka/vNG3n8= Public Key DNS Lookup Building DNS Query for cpmail._domainkey.circupressmail.com Retrieved this publickey from DNS: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+D53OskK3EM/9R9TrX0l67Us4wBiErHungTAEu7DEQCz7YlWSDA+zrMGumErsBac70ObfdsCaMspmSco82MZmoXEf9kPmlNiqw99Q6tknblJnY3mpUBxFkEX6l0O8/+1qZSM2d/VJ8nQvCDUNEs/hJEGyta/ps5655ElohkbiawIDAQAB Validating Signature result = fail Details: body has been altered
Then, it looks up my SPF record to see if it passes (it does):
SPF Information: Using this information that I obtained from the headers Helo Address = us1.circupressmail.com From Address = email@example.com From IP = 220.127.116.11 SPF Record Lookup Looking up TXT SPF record for martech.zone Found the following namesevers for martech.zone: ns57.domaincontrol.com ns58.domaincontrol.com Retrieved this SPF Record: zone updated 20210630 (TTL = 600) using authoritative server (ns57.domaincontrol.com) directly for SPF Check Result: pass (Mechanism 'include:circupressmail.com' matched) Result code: pass Local Explanation: martech.zone: Sender is authorized to use 'firstname.lastname@example.org' in 'mfrom' identity (mechanism 'include:circupressmail.com' matched) spf_header = Received-SPF: pass (martech.zone: Sender is authorized to use 'email@example.com' in 'mfrom' identity (mechanism 'include:circupressmail.com' matched)) receiver=ip-172-31-60-105.ec2.internal; identity=mailfrom; envelope-from="firstname.lastname@example.org"; helo=us1.circupressmail.com; client-ip=18.104.22.168
And lastly, it provides me insight on the message itself and whether the content may flag some SPAM detection tools, checks to see if I’m on blacklists, and tells me whether or not it’s recommended to be sent to the junk folder:
SpamAssassin Score: -4.787 Message is NOT marked as spam Points breakdown: -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at https://www.dnswl.org/, high trust [22.214.171.124 listed in list.dnswl.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 HTML_FONT_LOW_CONTRAST BODY: HTML font color similar or identical to background 0.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid 0.0 T_KAM_HTML_FONT_INVALID Test for Invalidly Named or Formatted Colors in HTML 0.1 DKIM_INVALID DKIM or DK signature exists, but is not valid
Be sure to test every ESP or third-party messaging service that your company is sending email from to ensure your Email Authentication is properly setup!
Disclosure: I’m using my affiliate link for Google Workspace in this article.