Damn Punctuation

Today on "Things I learned", I get reacquainted with punctuation and how it, when it wants to, will 'eff up your deliverability.

🎵 Dun dun 🎵 (my version of the Law & Order transition sound)

The consult started super simple. 

<!--Heavily paraphrased conversation.-->

CLIENT: "My emails are going to spam and I heard I have to make changes for Yahoo and Google, but I don't know what to do."

ME: "Sweet! I can surely help with that. Would you like a technical review, strategic review, the works, or just a couple hours to provide you guidance?"

CLIENT: "Let's start with a couple hours because I don't really know what I need, but I know I have to do something with a DKIM and an SPF."

ME: "You got it! We'll start by meeting for an hour when you have availability and will go through it one step at a time. Then we can meet again if there is more to do or we can talk about any other issues or concerns you may have."

<!--End heavily paraphrased conversation.-->

Oh boy, I love these types of consults; not just because they are relatively easy, but I get to chat about the DNS and authentication. 

NERD ALERT! 

To be honest, I find it (selfishly) very satisfying to leave a consult knowing you haven't just completed the job, but you also armed the client with more information and know-how than they had before you met.

We meet the next week and we go through all the different ways they can send mail:

• Google Workspace
• Filemaker Pro (database) application, which is tied into NameCheap's Private Email offering
• Apple Mail application
  

All three ways to send mail can send mail using one of their two domains. For client privacy, I will be protecting their identity with super cool made up client domains: supercoolmadeupclientdomain.com and supercoolmadeupclientdomaininc.com.

So we are looking at six tests (one test for each domain from each system.) Before I have them send all six, I have them send a test from each domain out of Workspace so I can see what authentication is in place and what is missing.

Results:

• supercoolmadeupclientdomain.com
• Spam folder
• No passing SPF (neutral) on supercoolmadeupclientdomain.com
• Passing DKIM using Google's DKIM domain, supercoolmadeupclientdomain-com.20230601.gappssmtp.com.

• To keep client information private, I removed a bunch of information; however, you can see there is no SPF passing (otherwise it would say "mailed-by" above the "signed-by.")
• There is a passing DKIM signature as Google displays "signed-by." And look at that! Signed with gappsmtp.com! If you don't know, gappsmtp.com is Google's shared DKIM domain. It is assigned by default until you set up your own DKIM in Google Workspace.

•  supercoolmadeupclientdomaininc.com
• Inbox
• Passing SPF with supercoolmadeupclientdomaininc.com
• Passing DKIM with on supercoolmadeupclientdomaininc.com

Ok even EASIER, only one domain to set up, supercoolmadeupclientdomain.com.

So we:

1. Open up Workspace
2. Create a DKIM key in Workspace
3. Add generated DKIM key to the DNS
4. Add a TXT record (since none existed so far) for SPF using Google's SPF record, v=spf1 include:_spf.google.com ~all.
5. Send a test message
6. IT WORKS! AND it goes to my INBOX!

OMG I'm getting excited. This consult is IN THE BAG and we still have time to spare!

The rest should be easy peasy because authentication is passing on the other domain.

Before we do anything else, we set up an account at Valimail for their free DMARC monitoring, add both domains to the UI, copy the DMARC value, and add a DMARC record for both domains starting with p=none. We'll let that sit and review the results in a week or two.

Ok, now that we know authentication exists and is working, let's just make sure both domains work from all three ways to send email. 

A part of me wanted to say, "Okie dokie, we're all done!" But one thing I've learned in my prior life as a content specialist is to test multiple systems because sometimes weird things happen."

We already confirmed Google Workspace, but we send another test to make sure and to also see if DMARC is picked up in the headers. Looks good! Now we just need to test Apple Mail and Filemaker Pro.

• Google Workspace ✅
• Filemaker Pro (database) application
• Apple Mail application

We moved on to Apple Mail. Tests were sent for both domains and both tests looked beautiful, passing authentication and going to my inbox. BOOM, another one checked off!

• Google Workspace ✅
• Filemaker Pro (database) application
• Apple Mail application ✅

And finally, the coup de grâce (yes a little hyperbolic, but I like to be playful and use words that are probably not fitting, but add flare!) Tests were sent for both domains and both...wait...only one of them looks good.

• Google Workspace ✅
• Filemaker Pro (database) application ⛔
• Apple Mail application ✅

Something be foul in these parts...

SPF is clearly there and passing, but where the heck did the DKIM go? It's IN the DNS. It's going through the same mail servers as before, just through a different application.

Ok let's check out these headers to see if anything looks funky. 

GASP!

Why, yes, something DOES look funky.

It was odd that the company name in the From Name had no spaces, but it's not the first time that I came across that so I didn't linger. But looking closer at the headers, the From: header is only showing the visible From and there is no 5322.from address (visible from address). Where did it go? Why isn't it included?

<!-- Incoming side story -->

The client had previously asked me if it matters what they send as (meaning which account, personal or company) and, because I was focusing on authentication, I said, "No, because no matter the address, it's the domain we are focusing on right now." To be honest, up until this point, I hadn't spent much time focusing on the visible From Name (heck I deleted it from the majority of my screen grabs above.) The goal was authentication. And nothing really made me pause until we got to the last two tests.

The tests sent from Workspace used my client's first and last name or they displayed the company name with spaces, commas, and periods. Only one of the tests showed the 5322.from address, but using the drop down in the UI to see the send details, the From Name was there and it was also in the headers. This too didn't surprise me as I've seen it before where Google only shows the 5322.from address if there might be a concern about reputation.

The Apple tests also looked good so it was another check in the "nothing to see here" box, so again I didn't think about it and moved on.

But the tests from the database both displayed the From Name differently than what was received previously from the other applications. Again, I was so focused on the missing DKIM signature, I didn't think deeply around what was being displayed and why (assuming it was just something missing from the application.)

In retrospect, this a miss on my part. There's no reason NOT to look into of all the settings that are displayed clearly in front of me, especially those things that create that split-second pause and aren't consistent. This is a great reminder to note the pauses because they very well could matter.

<!-- End side story -->

The client begins to look at their SMTP setup in Filemaker Pro to try to figure out if they set up their address correctly. But, we have hit the top of the hour so we either need to extend the meeting or meet up later. OR, the client said, "Let me go back and look at these settings first to make sure I have everything put in correctly. Let's schedule time next week to touch base if I can't find the issue and review DMARC reports."

I get a meeting scheduled, but we are so close I hate departing without a firm closure and solution. Alas, we're out of time for today and I don't have access to their system, nor can I see what they are looking at. I must relinquish control and wait to hear back or speak next week.

2 hours go by and I get such a lovely email from the client with such confidence I couldn't help but smile. 

"I am sending this email from my database using the supercoolmadeupclientdomaininc.com domain, and I am confident you will get it because we found the problem.

We had “Super Cool Made Up Client, Inc.” as the FROM name. We discovered that the comma and period were the problem. 

Google rejected the name and simply put the outgoing email address as the FROM name. Namecheap deleted everything from the comma on and ran the words together and did not include the outgoing email, which resulted in an invalid FROM address.
  

I changed the FROM name to “Super Cool Made Up Client Inc” and tested both outgoing servers. In both cases the FROM name now appears, and the email address is included."

AND DKIM was BACK!

So, there you have it!

• Google Workspace ✅
• Filemaker Pro (database) application ✅
• Apple Mail application ✅

A simple comma and a little ol' period was tearing $%^& up on the way out the door. This wasn't a clear issue up front as Workspace and Apple Mail was showing everything correctly. However, when those applications sent the mail, they put quotes (" ") around the visible From Name, the Filemaker Pro integration did not.

I don't know exactly why or where things broke (I can speculate) nor why the database application didn't include or trigger the use of quotes (they are needed if you are going to add periods, etc. into the visible From Name.) Somewhere in that flow things went sideways to the point where not only did the  From Name not display correctly, but the From Address didn't even get written into the From: header in the email payload.

Moral of the story, anything can break email. Check the little things, even the periods and commas.

🎵 Dun dun 🎵

DAMN PUNCTUATION