How to Validate Your Email Authentication Is Set Up Correctly for DKIM, DMARC, SPF & BIMI

If you’re sending any significant volumes of marketing emails, chances are your email is not making its way to the inbox if you’ve not configured your email authentication. We work with many companies assisting them with their email migration, IP warming, and deliverability issues. Most companies don’t even realize they have a problem; they think subscribers simply aren’t engaging with their emails.

Phishing

At issue is the growing issue of malicious and fraudulent emails, especially phishing emails. Phishing is a cyber-attack where individuals or organizations try to trick people into revealing sensitive information, such as passwords or credit card details, by disguising themselves as trustworthy entities. This is primarily done via email. The attacker will send an email that appears to be from a legitimate source, then bring you to a landing page that you believe is a login or other authentication page where the victim inadvertently enters their personal information.

The Invisible Problems of Deliverability

There are three invisible problems with email deliverability that businesses are unaware of:

1. Permission – Email service providers (ESPs) manage the opt-in permissions… but the internet service provider (ISP) manages the gateway for the destination email address. It’s an inherently flawed system that has skyrocketed fraudulent schemes like phishing. 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. The ISPs assume you’re a spammer or sending malicious emails… unless you prove otherwise.
2. Inbox Placement – ESPs consistently promote high deliverability rates that are nonsense. An email routed directly to the junk folder and never seen by your email subscriber is technically delivered. To truly monitor your inbox placement, you must use a seed list and look at each ISP to identify whether your email landed in the inbox or the junk folder. My company can provider this testing for you as well.
3. Reputation – ISPs and third-party services also maintain reputation scores for the sending IP address for your email. There are blacklists that ISPs may use to block all of your emails altogether, or you may have a poor reputation that would get you routed to the junk folder. You can use many services to monitor your IP reputation, but I’d be a bit pessimistic since many don’t have insight into each ISP’s algorithm.

Email Authentication

The best practice for mitigating any inbox placement issues is to ensure you have set up email authentication records that ISPs can use to look up and validate 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 few standards:

• Sender Policy Framework (SPF) – the oldest standard, is where you register a TXT record on your domain registration (DNS) that states what domains or IP addresses you are sending emails from for your company. For example, I send emails for Martech Zone from Google Workspace.

v=spf1 include:_spf.google.com ~all

• Domain-based Message Authentication, Reporting and Conformance (DMARC) – this newer standard has an encrypted key that can validate 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 and 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:dmarc@martech.zone; aspf=s; fo=s;

• Brand Indicators for Message Identification (BIMI) – the newest addition, BIMI provides a means for ISPs and their email applications to display the brand’s logo within the email client. There’s both an open standard and an encrypted standard for Gmail, where you also need an encrypted verified mark certificate (VMC). The certificates are expensive, so I’m not doing that yet. VMCs are being issued by two accepted Mark Verifying Authorities: Entrust and DigiCert. More information can be found at the BIMI group.

v=BIMI1; l=https://martech.zone/logo.svg;a=self;

How To Validate Your Email Authentication

All the source, relay, and validation information associated with every email are found within the message headers. Interpreting these is pretty easy if you’re a deliverability expert, 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 my DKIM rules, whether DMARC passes (it doesn’t) and SPF passes… but that’s a lot of work. There’s a much better workaround, though, to use DKIMValidator. DKIMValidator provides you with 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 = info@martech.zone
From IP      = 74.207.235.122
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 'info@martech.zone' in 'mfrom' identity (mechanism 'include:circupressmail.com' matched)
spf_header = Received-SPF: pass (martech.zone: Sender is authorized to use 'info@martech.zone' in 'mfrom' identity (mechanism 'include:circupressmail.com' matched)) receiver=ip-172-31-60-105.ec2.internal; identity=mailfrom; envelope-from="info@martech.zone"; helo=us1.circupressmail.com; client-ip=74.207.235.122

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
                            [74.207.235.122 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 set up!

Best Practices in Implementing DMARC

Implementing DMARC correctly is crucial for email security and sender reputation. The policy you choose depends on your goals for email authentication and your readiness to handle potential issues. Here’s a breakdown of the three policies:

1. None (p=none): This policy is typically used for monitoring and collecting data without affecting the delivery of your emails. It allows domain owners to see who is sending mail on behalf of their domain. It’s a good starting point to understand how your email is being processed and to identify potential authentication issues without risking legitimate email delivery. While it may seem like ignoring the policy, it’s a valuable diagnostic tool to ensure everything is correctly set up before moving to more restrictive policies.
2. Quarantine (p=quarantine): This policy suggests to receiving mail servers that emails failing DMARC checks should be treated with suspicion. Usually, this means placing them in the spam folder rather than outright rejecting them. It’s a middle ground that reduces the risk of legitimate emails being rejected while still offering protection against fraudulent emails. It’s a good next step after none once you’ve confirmed that your legitimate emails pass DMARC checks.
3. Reject (p=reject): This is the most secure policy, indicating to receiving servers that emails failing the DMARC checks should be rejected. This policy effectively prevents phishing attacks and ensures that only authenticated emails reach recipients. However, it should be implemented carefully after thorough testing with “none” and possibly “quarantine” policies to avoid rejecting legitimate emails.

Best Practices:

• Start with p=none to collect data and ensure that your legitimate emails are properly authenticated.
• Move to p=quarantine to start protecting your domain while minimizing the risk of legitimate emails being rejected.
• Finally, shift to p=reject once you are confident that your email sending practices are fully compliant with DMARC, to maximize protection against email fraud.

Each step should involve analyzing DMARC reports and adjusting your email sending practices as necessary to ensure that legitimate emails are authenticated correctly.

SPF Record Builder SPF and DKIM Validator BIMI Inspector