SPF
I wrote last year about using “stunt” nameservers for customer subdomain authentication – i.e. dynamically generating all the authentication records needed in DNS for each customer as needed. For example, if you’re an ESP that has customers who can’t or won’t use their own domains and you still need to give them unique subdomains you can generate CNAME records to support white label DKIM authentication: selector ._domainkey. customerid .espcustomer.com CNAME selector .dkim.esp.com or generate white label DMARC with useful rua= reporting: _dmarc. customerid .espcustomer.com TXT “v=DMARC1 p=none rua=rua+ customerid @esp.com” Once you’ve set up these DNS records once they’ll work for all your customers, you just need to put the right domains in your DKIM signature and return path. I shared some demo code to explain the concept last year, but since then we’ve developed a robust, production-ready application to dynamically serve DNS in this way. It’s called
In February 2024, Google and Yahoo started implementing a series of gradual enforcements for organisations that send over 5000 emails daily, also defined as bulk email senders. These enforcements are especially relevant to Domain-based Message Authentication, Reporting & Conformance (DMARC). With this initiative, Google and Yahoo intend to reduce the overall amount of spam and spoofed content sent across the internet, especially focusing on the authentication of an organisation’s email infrastructure. This move, aimed at combating spam and improving email security, involves using Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and DMARC standards. This article covers the Google and Yahoo requirement specifications and focuses on the potential impacts on European businesses. In particular, it addresses the complications of implementing DMARC across the European email ecosystem and the necessary steps to comply with the enforcement. Impact on European Email Senders: A Closer Look Popular Email Providers in Europe Challenges of
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
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
When you query DNS for something you ask your local DNS recursive resolver for all answers it has about a hostname of a certain type. If you’re going to a website your browser asks your resolver for all records for “google.com” of type “A”1 and it will either return all the A records for google.com it has cached, or it will do the complex process of looking up the results from the authoritative servers, cache them for as long as the TTL field for the reply says it should, then return them to you. There are dozens of different types of records, AAAA for IPv6 IP addresses, MX for mailservers, TXT for arbitrary text, mostly used for various sorts of authentication (including SPF, DKIM and DMARC). And then there’s CNAME. CNAME stands for “Canonical Name” and means “Go and ask this different question instead”. If you have a DNS record
Looks like Microsoft has run into email authentication issues today. Specifically, the domain hotmail.com appears to have a broken SPF record wherein messages sent by Hotmail/Outlook.com/Microsoft OLC using a hotmail.com from address aren’t passing SPF authentication. Here’s a link to a KBXSCORE report I’ve run, showing the failure.While hotmail.com is affected, the outlook.com domain doesn’t appear troubled — my test sends from an outlook.com from address seem to pass SPF. (Microsoft has many other domains; I’ve only checked these two.)Looking at the SPF records for hotmail.com, here’s what I see:hotmail.com descriptive text “v=spf1 include:spf-a.outlook.com include:spf-b.outlook.com ip4:157.55.9.128/25 include:spf-a.hotmail.com include:_spf-ssg-b.microsoft.com include:_spf-ssg-c.microsoft.com -all”outlook.com descriptive text “v=spf1 include:spf-a.outlook.com include:spf-b.outlook.com ip4:157.55.9.128/25 include:spf-a.hotmail.com include:_spf-ssg-b.microsoft.com include:_spf-ssg-c.microsoft.com include:spf.protection.outlook.com ~all”The hotmail.com SPF record is missing “include:spf.protection.outlook.com” — which is present in the outlook.com SPF record. And I see it present in a cached copy of Hotmail’s SPF record that I collected last month. So, I suspect that to be