DMARC

The Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA), Federal Bureau of Investigation (FBI), and Multi-State Information Sharing and Analysis Center (MS-ISAC) have released Phishing Guidance—Stopping the Attack Cycle at Phase One to provide guidance in the ever-waging battle against phishing exploits. The guidance is relevant to all organizations, though it may pose challenges for those with limited resources. To address this, the guide incorporates a section with customized suggestions tailored for small- and medium-sized businesses that may lack the resources for a dedicated IT staff to consistently combat phishing threats. For software manufacturers, the emphasis is on adopting secure-by-design and default strategies. The guidance encourages software companies to create and deliver software that is resistant to common phishing threats, ultimately enhancing the cybersecurity resilience of their customers. In the phishing mitigation guidance for all organizations, CISA, NSA, FBI, and MS-ISAC recommend organizations implement DMARC and other controls

I’ve got just a tiny slice of data for you today. I took the top 100 (US) mailbox provider domains, as measured by mail sent to them, and looked for DMARC records. Do they have a DMARC record? And if so, what is the DMARC policy? Things look good from this angle. Seventy of those top 100 domains do indeed have some sort of DMARC policy in place. Of those that have a DMARC policy in place, just over 60% of those domains have a restrictive (p=quarantine or p=reject policy). This is particularly timely given that Gmail’s upcoming requirements say you should not impersonate (send as) gmail.com in your from address. Based on how internet service providers (ISPs) and mailbox providers (MBPs) are moving to respect DMARC policy, that restriction also applies to a good two-thirds of the top MBP domains. Remember: Your from address should only contain a domain

Starting February, 2024, long established email authentication best practices will become a requirement. It’s as simple as that, folks. This news may be alarming to you for a variety of reasons; you may have previously interpreted these guidelines as being optional or didn’t understand the related technical complexities. Or maybe you trusted that your email service provider, or IT Department was taking care of this for you. Whichever camp you may be in, the responsibility is yours to ensure you are compliant and have the proper visibility to maintain that favorable status from that point forward. As abuse continues to mature, so must the controls that have been implemented to secure the email channel. We applaud Google and Yahoo for ushering this new reality in much of the same way that dmarcian has always taken a standards and best practices approach. Our mission has been to spread DMARC across the

As 2024 approaches, major players in the email industry, such as Gmail and Yahoo, are ushering in a pivotal shift that carries significant implications for email marketers and senders alike.  Gmail’s New Email Requirements Gmail’s new email requirements are designed to bring a higher degree of security, transparency, and user-friendliness to the inbox. These requirements are specifically tailored for bulk senders — those who dispatch more than 5,000 messages to Gmail addresses daily. While this threshold may seem imposing, the impact of these changes is poised to benefit email marketers, recipients, and the email ecosystem as a whole. Concurrently, Yahoo is unveiling a parallel set of prerequisites. This collaborative initiative involving prominent industry leaders underscores a shared dedication to enhancing email communication, prioritizing security, user-friendliness, and freedom from spam. Significance for Email Marketers The significance of these changes cannot be understated. They signify a critical step towards a safer, more

If you’re an ESP with small customers you may have looked at the recent Google / Yahoo requirements around DMARC-style alignment for authentication and panicked a bit. Don’t impersonate Gmail From: headers. Gmail will begin using a DMARC quarantine enforcement policy, and impersonating Gmail From: headers might impact your email delivery.…For direct mail, the domain in the sender’s From: header must be aligned with either the SPF domain or the DKIM domain. This is required to pass DMARC alignment. So everyone who’s using their gmail address to send bulk mail is going to have to stop doing that within the next few months if they still want their mail to be delivered. For any ESP customer that already has, or can be convinced to buy, a domain for their web presence maybe they can be persuaded to switch to using that – though even if they can, onboarding 100,000 technically naive users

If you dig into the newly published upcoming sender requirements from Google, you’ll unearth three points that relate to DMARC. These are important enough that I wanted to highlight them specifically.First, note that Gmail is moving to a “p=quarantine” policy for gmail.com. That means it is no longer safe to send mail as (anything)@gmail.com except when doing so via Gmail’s infrastructure. This new policy update is Google telling the world to spam filter mail that says it’s from a gmail.com email address, but doesn’t pass email authentication tests. This is a big deal. Gmail, Yahoo, and many other mailbox providers are going to filter unauthenticated messages much more harshly as a result.My memory’s a little fuzzy, but I remember a freemium SMB-focused ESP that had a free “newsletter service” that I think they’ve long since shut down. The platform let you send as yourself, so they served up an awful

Australian telecommunications provider Telstra has very recently implemented a “p=reject” DMARC policy for their primary email domains (telstra.com, telstra.com.au, bigpond.com and bigpond.com.au). What this means for senders is that it is no longer safe to use these domains in your from address when sending from anything other than Telstra’s email platform. No using Telstra email addresses to send mail from your ESP, CRM or newsletter platform — these domains are now configured so that ISPs are encouraged to reject mail from these domains when not authenticated properly.Remember that in this day in age it’s always best to send your emails from a third party platform using only your own specific domain or subdomain, owned by you and configured to authenticate properly from every email sending platform you’re using.My cached DMARC checks for the top 10 million domains show Telstra domains previously had a DMARC policy of “none” back in June

Email forwarding can sometimes throw a wrench in DMARC authentication results, and we often get questions about how to manage forwarded emails, especially with mailing lists. Emails are forwarded automatically all the time, more so than most people expect. Forwarding happens automatically when you send an email to myfriend@example.com and that person has set up their email to be forwarded to a separate inbox, like myfriend@dmarcian.com. Another common instance of automatic forwarding is a mailing list, like Google Groups. From the perspective of the email receiver—the one that is generating DMARC XML reports—your email appears to be coming from an infrastructure that has nothing to do with you. In Google Groups, DMARC data that displays forwarding will show your domain as a sender, a Google IP as the sender, and a variety of receivers who send the DMARC report as part of their DMARC check. This number can increase quite

Though Cisco email security appliances (ESA) can be configured to send DMARC aggregate (RUA) reports, they have a limited number of daily DMARC reports they provide. This limit can be easily reached by organizations sending large volumes of email, especially if multiple subdomains are seen in the From header of messages received. The number of subdomains seen is an issue because of a deficiency in how the Cisco IronPort system generates DMARC reports. Instead of creating a single XML report containing data for the top-level domain and any subdomains (e.g. example.com along with www.example.com, server.example.com, etc), each server instance generates a completely separate report for each—this causes the limit to be reached rapidly. Increasing the daily limit will ensure that you have the proper visibility and are helping other organizations with their DMARC projects. The daily DMARC report default setting is 1000, which can be increased only through the command-line

Here’s some long-time-coming news from Microsoft, one of the world’s largest mailbox providers: they have started rolling out changes to honor DMARC policies as published in a domain’s DNS. Microsoft will now be treating the p=reject policy as intended; email failing DMARC authentication will not be delivered. Microsoft had been treating the DMARC policies of p=quarantine and p=reject the same way; email failing DMARC with a p=reject policy was delivered to the spam folder. Microsoft said they had operated this way “because some legitimate email may fail DMARC. For example, a message might fail DMARC if it’s sent to a mailing list that then relays the message to all list participants. If Microsoft 365 rejected these messages, people could lose legitimate email and have no way to retrieve it. Instead, these messages will still fail DMARC but they’ll be marked as spam and not rejected.” Microsoft signaled the change to