Email Authentication and DMARC: Cause of Deliverability Issues When Missing or Misconfigured
Since at least February 2024, many email senders have experienced an increase in deliverability problems. The cause is that major email providers including Google and Yahoo began to enforce policies requiring adoption of sender Authentication and DMARC. The objective is to make their email platforms more strict about which emails they mark as suspicious, spam, or outright refuse to deliver to recipients on their systems. The February change date was announced by Google in October 2023 as official notification that email senders must prepare for the enforcement of the accompanying guidelines by making adjustments to their email domain settings.
The Recent Changes Are Causing Deliverability Issues
Unfortunately, many organizations did not heed the warning and were surprised by the consequences. Many senders had email messages wholly rejected very early, despite the rejection phase for non-compliant traffic scheduled to begin in April. Part of the cause was likely due to new domains, whose enforcement actions were on an accelerated timeline. There are many reasons that email can fail normal delivery, some of which became unacceptable since the change, for example – using an email “from” address which does not match the actual sending domain, and others. Most affected by that change are Website owners or webdesigners who had set up site SMTP with an @gmail as the “from” address.
Email Delivery Failure
If you are experiencing email delivery problems, you may have been told by customers and suppliers that they haven’t been receiving your emails. Some receive them labeled with a warning that they are “suspicious” or “unauthenticated” email messages. Website owners aren’t getting contact form messages, or transactional messages from the website.
What is Authentication and DMARC?
Sender Authentication
Email Authentication means proving that email which appears to be sent by a domain is actually being sent with permission of the domain owners, rather than by imposters. The minimum standard of providing authentication includes sending from an address on the same domain, and adding either an SPF or DKIM record to the domain’s DNS containing information correlating to the domain.
DMARC
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is a security protocol designed to combat email spoofing to reduce phishing, spamming, and scamming. Specifically, there is a “DMARC” DNS record which states a policy of none, quarantine, or reject among other details.
Used in combination with email authentication (SPF, DomainKeys, “from” email address domain), the the presence of the DMARC policy record instructs receiving servers to cross-check alignments of the visible “from” domain with the domains and ip addresses in the SPF record; that the DKIM key signature in email headers matches the public key in the DKIM record; most importantly it includes the policy, which are instructions on strictness, how to handle sent emails which do not pass, and where to send reports.
Significance
If Authentication and DMARC are absent or aren’t properly configured, organizations sending from email addresses on their company domains can be affected with email deliverability errors. Marketing emails and transactional emails (including website contact form submissions) are also negatively affected.
Implementation
The implementation of Authentication and DMARC requires configuration of specific settings on the domains which send email. The settings are made within the DNS records to comprise a system of checks determining whether the email is being sent with authentication and alignment of permitted senders on the domain. The term “DMARC” is often used to refer to the whole system of the domain records settings required to implement it, or just the DMARC policy record. DNS records are referenced at the end.
Images: Two images have been combined. Image 1 is from Gmail, and has been colorized. Image 2 is Google’s Email Sender Guidelines, at https://support.google.com/a/answer/81126#zippy=%2Crequirements-for-all-senders
The top (image 1) is the warning message a recipient sees if Gmail flags an email as suspicious.
The warning appears if an email sender is not who they purport to be, or if it seems suspicious due to not complying with the sending requirements.
Below that is image 2 – Google’s Email Sender Guidelines.
Email Sender Guidelines
Gmail’s Email Sender Guidelines which are now being enforced, state that everyone (including GoogleWorkspace users) sending email to personal Gmail users must comply with a set of sending requirements in order for their emails to be delivered to intended recipients’ inboxes as normal. The guidelines require implementation of sender authentication methods including: SPF or DKIM, that the sender email shown be an email address on the same domain, use of TLS, having valid PTR records, and have a low rating of being marked as spam (.3%). They highly recommend both SPF, DKIM, and also implementing DMARC, all of which are required for bulk email senders (who send 5,000 or more per day).
There has been some misunderstanding about these guidelines by professionals. Many have mistaken the list of requirements as applying only to bulk email senders, but that is not the case. Instead, the list applies to all senders as the heading states in the image from Google. The bold “important” note about senders of more than 5,000 emails refers the drop-down tab section below it where additional requirements are listed. Those requirements include all of SPF, DKIM, and DMARC among other things.
We agree with Google, everyone should do all of those! Why do the bare minimum? Be safer and be ready for the next time they increase the requirements! 🤷🏻♀️ Just do it or hire it out, thereby securing your clients’ reputation, deliverability and protecting others from harm.
Make Email Safe Again 🧢
Without DMARC set up and monitored, scammers could be using your domain to send email to thousands of people around the world. They find domains and subdomains which haven’t been secured with a DMARC policy, then use those which haven’t yet been blacklisted. They use them to conceal their identity when sending emails of ill intent, often with the added benefit of appearing to be the trusted entity displayed on the email address.
The enforcement rollout by major email providers is a serious effort to reduce scams and cybersecurity threats, which are often initiated when bad actors send email disguised as the sender indicated. Until legitimate email senders implement Authentication and DMARC correctly, their emails will sometimes be mistaken as spoofed or unauthorized and may fail to be delivered.
Sender Reputation
Email abuse causes problems for the domain owner – businesses like yours who suddenly can’t send email. The abused domains often become “blacklisted”, and websites can also be blocked on search engines if the blacklist triggering behavior is extreme. Sender reputation can be correlated to the domain and the IP address.
If these are some of the problems you have been experiencing, the most likely cause is that you or whomever is managing your domain have not taken steps to comply with Authentication and DMARC.
If you think your domain or IP address has been blacklisted, you can check at the end of this article and then work towards restoring your domain’s reputation.
Realtime Blackhole Lists (RBLs)
“Blacklists” of email domains and IP addresses are collected and shared among email servers automatically. Having your domain end up in these lists means that your sender reputation is poor and you will encounter severe email deliverability problems. There are many reasons that email senders land on the blacklists. The most common are:
- Bad actors sent spam or scam emails from your domain which was then reported. This happened because the authentication and DMARC settings discussed in this article were not implemented or were too weak, allowing them to take advantage of the unprotected domain.
- Legitimate emails your organization sent looked forged due to the missing signs of secure authentication because the settings were not implemented.
- Your organization sends marketing emails and had numerous reports by recipients that it was spam. This could be because a) you did not obtain explicit consent to send them marketing emails or b) you sent emails to your list of your subscribers after a pause during which they changed their mind or forgot they had subscribed.
- Email sent by your organization was marked as spam by anti-spam software due to detection of spammy language and/or the types and amount of links you included.
My Thoughts
As a website developer who works with servers, email and domains, email deliverability and security are issues I take seriously. I stay up to date on news about exploits and have fixed many problems in this realm. I see sending reports which reveal thousands of attempts by imposters to send email from others’ domains. This is why it worries me to observe that many domain owners, marketers, and web designers are not taking steps to prevent this.
What I see is that it is quite common for domains to have the DMARC policy of “p=none” which is like having no policy whatsoever. In fact, I have read that the Whitehouse (.gov) domain also has this non-policy setting. Do a search for “dmarc whitehouse gov”. The stricter options are “quarantine” or “reject”, but there seems to be a lack of awareness surrounding them.
There have been warnings by the NSA and FBI about hostile nations taking advantage of this no policy weakness. They are also exploiting an even more common mistake, that domain owners have no settings on their subdomains – no SPF and Domainkey records, and a DMARC policy of p=none.
Recommendations
Setup guides for email hosts, email marketing platforms, and other services often recommend “p=none” as the default DMARC policy. However, this should come with a clear recommendation of adopting a stricter policy once deliverability is stable.
Technical experts emphasize that “p=none” should only be used initially while monitoring. Email security managers have standard procedures for monitoring email send failures and spoof attempts. The stage of monitoring send reports and resolving issues is necessary prior to making a successful transition to stricter policy settings. Given the rise in email misuse, it is important to schedule the move out of the “p=none” stage.
Get Help
When clients use any of my email setup or improvement services, I properly implement, monitor and transition DMARC for protection and deliverability. This is necessary for the following: domain email accounts, SMTP sending for website forms and other notifications, and custom domains used on email marketing platforms.
See the email services I provide to other web professionals as well as direct to consumers.
Email DNS Records
These are the records which most commonly must be added or changed for email services when using an outside email host such as Google Workspace, email marketing, and SMTP for website notifications:
- MX – “Mail Exchange” record lists email server domains or IPs provided by your Email Service Provider.
- DKIM – “Domain Key Identified Message” record is a text record containing a public decryption key which is provided by the Email Service Provider. Receiving email servers will use this key and try to match it to the private key which signed the email headers and reside on the sending email server. Matching the DKIM is one part of determining whether the email is authentic.
- SPF – “Sender Policy Framework” record is a text record containing which server domains or IP addresses are authorized to send mail from this domain and how strictly to judge this information for alignment.
- DMARC – As noted in the beginning of the article, the DMARC record contains the policy for how to handle email that does not align to authentication standards. Here, we can instruct recipient email servers whether to reject, quarantine, or do nothing (p=none) when all or some of the authentication measures to do not align or pass. Report info should also be included here.
Blacklist Lookup and Removal Tools
Spamhaus
Spamhaus.org – Look up your sending domain at Spamhaus, a reputable non-profit blacklist provider. If you are found on the list, a note about issues and solutions may be provided on the page.
Microsoft Blacklist Removal
Microsoft manages its own blacklists. If your email domain has been blacklisted by Microsoft, you will receive a message similar to this Non Delivery Report (NDR):
550 5.7.606-649 Access denied, banned sending IP [IP address] (ex. 5.7.511 Access denied)
- Microsoft Office365 – If you have fixed the issues which were causing your emails to be banned, you can forward the NDR email to the Microsoft email address listed in the notice. Another method is to submit your sending domain and its IP address. For more information, watch this instruction video.
- Microsoft Outlook Blacklist Removal – If you have been blacklisted from Outlook.com, you can use: Outlook list removal tool here (requires Microsoft account login).
More information
- Email Sender Guidelines from Gmail
- Guidelines Enforcement Answers ” “
FBI
Cloudflare
- Cloudflare – DNS records
Sendgrid
- Email Sender Reputation – This article by Sendgrid explains the domain and IP addresses as factors of email sender reputation, which impacts deliverability. TL;DR: both IP and Domain are considered. Even if you send from different IP addresses, the Domain accrues a reputation “score”.
Table of Contents
Contact us if you need email troubleshooting or authentication and dmarc services.
