DKIM

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

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

On Tuesday I wrote about using DNS wildcards to implement customer-specific subdomains for email authentication. As I said then, that approach isn’t perfect. You’d much prefer to have per-customer domain authentication, where each customer has their own DKIM d= and ideally their own SPF records, rather than having all customers sharing those records and relying on loose DMARC alignment to have them to work with a per-customer subdomain in the 5322 From: header. But doing that with DNS wildcards would have some odd side effects, such as TXT records appearing where they weren’t expected, in ways that could trigger bugs in rarely tested code paths at mailbox providers and potentially even open up security problems. I mentioned using a “stunt” DNS server would be one option to do that, and then quite a few people asked me what I meant by that. A stunt DNS server is one that doesn’t

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

Gmail has long pushed for adoption of email authentication best practices from email senders, effectively making it tough to get to the inbox without proper email authentication in place. They also, for years now, have been very cautious about what mail they accept over IPv6, declining to accept mail over IPv6 that fails authentication checks. Well, now those same checks now apply to all mail sent to Gmail — over IPv4 or IPv6. Meaning, if you want to send mail to Gmail, you need to authenticate that mail with Domain Keys Identified Mail (DKIM) or Sender Policy Framework (SPF).If you’re trying to send mail to Gmail subscribers, and the mail doesn’t authenticate properly, it’ll be rejected with this error message:550-5.7.26 This mail is unauthenticated, which poses a security risk to the sender and Gmail users, and has been blocked. The sender must authenticate with at least one of SPF or

If you’re seeing intermittent DKIM authentication failures at Microsoft domains (outlook.com, hotmail.com, etc.) — meaning you’re seeing “dkim=fail (body hash did not verify)” instead of “dkim=pass (signature was verified)” in your “Authentication Results” email headers — then what likely has happened is that Microsoft has modified one or more characters in your email message.See, there’s multiple ways to encode email messages for sending them via the Internet — the oldest, default way of just plain text (7-bit ASCII text) doesn’t allow for emojis, accented characters, special character sets, Kanji, anything beyond just the simple characters used to write English-language text. And to allow email to be transmitted in this simplistic character set, but allow for additional, extended characters and alternative character sets, methods of encoding were created that allowed email platforms to do things like specify complicated multi-byte characters by “encoding” them into Quoted-Printable or Base64, to allow them to

Or, how to scare your potential new customers by doing a whole bunch of things wrong all at once, leading to the big warning box of doom. Cold leads, not sending using a full name, and not authenticating properly. Trying to be friendly and sending mail as “Bob” can backfire, especially if your employer has four other people already named Bob, Gmail can’t tell which is which, and Gmail is concerned because your DKIM configuration is busted and you didn’t configure SPF properly. Good job, Bob.This brings me back to the common question, are SPF and/or DKIM required for inbox placement? Well, the lack of them in this case sure didn’t help Bob. Don’t be like Bob. Make it easy for Gmail to identify you and authenticate your mail.

It looks like Microsoft are getting pickier about email address syntax, rejecting mail that uses illegal address formats. That might be what’s causing that “550 5.6.0 CAT.InvalidContent.Exception: DataSourceOperationException, proxyAddress: prefix not supported – ; cannot handle content of message” rejection. Why do we care? It’s good to send syntactically valid email in a warm fuzzies sort of way – it shows we know what we’re doing, and aren’t dodgy spamware – but it’s increasingly important to delivery as mailbox providers are tightening up on their syntax checks. But why are mailbox providers doing that? One reason is that authentication tech like DKIM and DMARC is built around them only being applied to email. Not to messages that kinda look like email. There are ways to bypass DKIM protections by sending invalid messages. As one example, if you send multiple copies of the From: header with different values a DKIM checker