August 16, 2022 Email Deliverability
If you’re not doing all you can to stay out of email spam boxes, you’re wasting all your outbound effort. In this article, we’ll show you how DMARC, SPF and DKIM records are essential to every fintech company doing email prospecting. And the free tools you can use to check if you’re compliant.
PS: This is going to be a for-dummies kind of article.
Jerry has invented a debit card that can be controlled with thoughts. His invention is growing popular and everyone wants to hear from Jerry (presidents will open Jerry’s emails).
A hacker reads the news and tries to send phishing emails designed to look like they come from Jerry.
A DMARC (Domain-based Message Authentication, Reporting, and Conformance) record is there to protect Jerry from people sending emails pretending to be him.
When Jerry sends you an email, your email server will do authentication checks (SPF and DKIM—more on that ahead). But when your email server can’t authenticate whether that email came from Jerry, his DMARC records should contain instructions on what you should do to that unauthenticated email.
Jerry’s DMARC records can have one of three answers: reject that email is not from me, quarantine that email, I’m not so sure about it, and accept that email (do nothing).
If DMARC records are to prevent malicious emails purporting to be from your domain, why are they important to every cold emailer’s arsenal?
Well…when you’re sending cold emails, your recipient’s email service provider has to decide where to place the email (hello spam box).
As they do authentication checks to see if your email really came from you they will apply the actions stipulated in your DMARC records (accept, reject, do nothing).
But without these instructions, there is a chance your recipient’s email provider will place your emails wrongly (hello spam box… is…is it me you’re looking for).
At the heart of it, DMARC records are like sirens that show you something has gone wrong with how the emails you send are authenticated–which is handled by your SPF and DKIM records.
According to Google support documents, when you’re first setting up your DMARC records you need to gradually transition from none (do nothing when you can’t authenticate my emails) to reject (don’t accept any email from me that can’t be authenticated).
Your recipient’s mail servers will be sending you deliverability reports that you can read.
While your DMARC records are set to none, your emails are still delivered to your recipients even when authentication fails. At this stage, you should regularly read your DMARC records to learn how receiving email service providers authenticate your emails and why your messages have not been authenticated.
If too many of your emails are going to spam, you will fix that by checking your SPF and DKIM records. Once you learn this, you can transition your DMARC records to quarantine, then reject.
According to Google Support, you should set up your SPF and DKIM records 48 hours before turning on your DMARC. And wait at least 7 days before changing your records from none to quarantine, depending on your organisation’s volume of emails.
PS: Watch out for valid messages from you that end up in spam and bounce/error notices.
What is this and why is it important?
Imagine yourself an emperor of a secret kingdom and you decide to send a message to a sister kingdom. To verify to the recipient that the secret message came from you, you’ll have to sign it.
On seeing the signature, the recipient will need to have access to a reference they can check the letter’s signature against to verify that it’s genuine.
DKIM records serve the same purpose as the king’s signature. Every email you send is signed in the ‘From’ section of your email header. To authenticate that the email really came from you, the recipient’s email server will have to check that header signature against a public record that you need to publish (DKIM records)
How to do this varies, depending on what you’re using to send your emails. If using Google Workspace, here’s the guide, and one for Zoho email: Some website hosts set it up automatically for you (mine did).
SPF records allow you to designate a third party to send emails on your behalf without getting thrown into the spam bin and the key melted.
If you’re using services like Mailchimp, SendInBlue, Sendgrid, etc. Through your SPF records, you can designate the IP addresses and domains you allow to send emails on your behalf.
For instance, when you send a cold email from a third party, your email recipient’s server will check your public SPF records to see if they’ve been allowed to do so, if not… hello spam box.
Here are the SPF setup guides for those using Google Workspace, and Zoho Email to send cold emails. Some website hosts set this up automatically, so you don’t have to worry about this.
To check if your DKIM, DMARC and SPF records are up and running, my favourite tools for this include, MXTOOLBOX, Mail-tester, and MailGenius.
The reason we need to set all this up (even though it may seem like we don’t need it all) is to reduce the chances of our cold emails getting stuck in spam boxes for technical reasons we can control.
Additionally, for salespeople in financial services and fintech—where email security needs to be tighter—it’s a way to protect you and your recipient from email phishing attacks.
PS: We advocate running cold email campaigns on alternative domains–that redirect to your website–rather than your primary company domain… this will often need you to set up DKIM, SPF and DMARC records for all of them.