authentication
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
Hey there! In my new role as Director of Deliverability for AWeber, I’m going to dive right in! I’m putting together a new webinar AS WE SPEAK, that covers everybody’s favorite topic — DKIM, DMARC, YAHOO, GMAIL & YOU! Also known as: what you need to do to comply with Yahoo and Google’s new sender requirements. Because this is focused on AWeber customers, I’ll cover everything from where and how to buy a domain name for your email messages (and why you have to), how to link that up to your AWeber account to correctly authenticate your email sends, how to configure and implement a DMARC record, and more! And I’ll take your questions, too! I hope you’ll join me alongside Jesse Kennedy to learn more about these very important bits for email sending success! The fun happens Wednesday, January 17th at 12:00 eastern. Click here to register.
As you well know, Gmail and Yahoo Mail are now requiring that all senders start to publish a DMARC record, if they weren’t publishing one already. Hopefully you watched the webinar with LB Blair and myself (I’ll link to the recording here as soon as it is available) where we talk at length about DMARC and what you need to know to start to be able to “speak DMARC” as needed. But if you didn’t watch that? And don’t have the time to dive into making yourself a DMARC export? What’s the five minute version of all of this, how do you get up and running quickly without having to stop and worry about RFCs and options. “Just tell me what I need to know to get it done.” Okay, I got you. Here we go. Before you proceed with this, you need to ensure that you’ve implemented DKIM authentication for
On January 9th at 6pm GMT, 1pm EST and 9am PST I’ll be speaking with Nout Boctor-Smith of Nine Lives Digital about the new Yahoo and Google technical requirements. In this webinar you’ll: Learn more about what these new email sender guidelines entail and how they differ from the status quo Understand why you’re being asked to do things that were previously handled by your ESP (email service provider) Discover what adjustments you can make now to ensure your emails reach their intended inboxes in 2024 We know folks have a lot of questions about these changes and how to comply with them, so we’ve made sure to leave time for them. I’m so looking forward to this opportunity and I hope you can join us! Reserve Your Space!
Since I wrote about it last month the requirements for bulk senders to Yahoo and Google have changed a little. The big change is that bulk senders need to authenticate with both SPF and DKIM, rather than SPF or DKIM. Only one of those has to align with the 822 From: header.
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
On Tuesday, October 3, Google and Yahoo announced updated sender requirements for those who wish to send mail to Gmail or Yahoo Mail successfully and in volume. Marcel Becker from Yahoo and Neil Kumaran from Google explain in detail what senders will have to do if they don’t want to find their mail blocked at either mailbox provider. They warn that failure to comply will result in rejected mail in early 2024.Any changes here really are evolutionary more than revolutionary. These have been solid “best practice” recommendations for a good long while; so I think of this as both “documenting what everybody knows” and laying the groundwork for reasoned, documented policy-based blocking of non-conforming mail. Those requirements boil down to this:Authenticate email. We were moving to a point where you basically already had to authenticate your email messages if you wanted inbox placement success; now it’s fair to say that it
Google are circulating a new set of requirements for bulk senders on their blog. So are Yahoo. It’s almost like postmasters talk to each other or something. If you dig through the links in the Gmail blog post you can find this summary of what they’ll be requiring from bulk senders by February: Set up SPF or DKIM email authentication for your domain. Ensure that sending domains or IPs have valid forward and reverse DNS records, also referred to as PTR records. Learn more Keep spam rates reported in Postmaster Tools below 0.3%. Learn more Format messages according to the Internet Message Format standard (RFC 5322). 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. If you regularly forward email, including using mailing lists or inbound gateways, add ARC headers to outgoing email. ARC headers indicate the message was forwarded and identify