What about AOL?

If you're wondering if AOL still exists as a separate entity, the answer is no. AOL as a standalone ISP is no more.

What was AOL is now part of Verizon Media Group, which for a time was called Oath.

AOL, Yahoo and Verizon are all one mailbox provider, from a sender's perspective. The Yahoo CFL (Complaint Feedback Loop) aka FBL covers all of the legacy ISP domains that made up these separate providers. That includes aol.com, yahoo.com, verizon.net, and various other domains. You can find my best guess at a list of all Verizon Media (Oath) domains here.

If you're having problems delivering mail to AOL, you should look for guidance on how to resolve delivery problems to Yahoo Mail. Yahoo Mail's infrastructure is now hosting mail for all of the Verizon Media domains. If you have issues sending to aol.com, then you are also having problems delivering to yahoo.com, and the Yahoo Mail filters apply.

The Verizon/AOL/Yahoo Postmaster (sender information) website can be found here.

SPF and DKIM Alignment: What are they and why do they matter?

If you have implemented DMARC for your email sending domain, the spec requires that your messages either pass "SPF alignment" or "DKIM alignment." Here's what those are and why they are important (and why you should always do both).

SPF alignment is where the mail you send has a return-path domain (aka the sender domain or bounce domain) that matches your from address domain. A DMARC record uses the "aspf" setting to govern how tightly this is checked. If you do not include the "aspf" setting (and you don't need to), then the default "relaxed" setting will be applied.

If the domains match, then you've successfully passed the SPF alignment check. If the domains do not match, then you've failed the SPF alignment check.

What counts as a match? Here's both relaxed and strict examples:

This is a successful relaxed SPF-aligned set of headers:
Return-Path: bounce-12345@bounce.spamresource.com
From: newsletter@spamresource.com
This matches because both the return-path (bounce) domain and from domain are part of the same domain (spamresource.com). Because it is the relaxed (default) setting, a subdomain match is close enough (bounce.spamresource.com matching spamresource.com).

If your DMARC record includes "aspf=s" (strict) then the domains have to match exactly. The above example would fail SPF alignment because "bounce.spamresource.com" does not exactly match "spamresource.com."

This is a successful strict SPF-aligned set of headers:
Return-Path: newsletter@spamresource.com
From: newsletter@spamresource.com
This matches because both the return-path (bounce) domain and from domain are the exact same domain (spamresource.com).

This would fail the "SPF alignment" test:
Return-Path: bounce-12345@bounce.spamresource.com
From: newsletter@wombatmail.com
This would fail either a strict and/or relaxed (default) SPF alignment check, because "spamresource.com" and "wombatmail.com" are different domains.

That's SPF alignment. Now, let's review DKIM alignment.

DKIM alignment is a bit simpler. Successful DKIM alignment means that your DKIM "d=" domain (the domain you're signing for with a DKIM signature) exactly matches the domain used in your from address. Here's an example of a header snippet that shows that the DKIM "d=" domain is xnnd.com and the domain in the from address is also xnnd.com. This message passes the DKIM alignment check.

Authentication-Results: happydance.xnnd.com; dkim=pass
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=xnnd.com; s=x; t=1567713062; bh=Zw/RlvF6ULJHFKg+HQrAUB5/DtCqJwS50FJKVwCDlhQ=; h=Date:Reply-to:List-Unsubscribe:List-Id:From:Subject:To:From; b=VluvorKp...(etc.)
From: newsletter@xnnd.com

The DKIM and SPF alignment checks don't show up in Gmail (or other ISP's) authentication results directly, but you can infer them by looking for DMARC failures and manually reviewing the header settings to see if either DKIM or SPF fail to align.

To pass DMARC, only one of these have to pass. So even if your return-path domain doesn't match your from domain -- meaning you fail the SPF alignment check -- if your DKIM signature aligns, you'd pass DMARC.

Still, in my opinion, it's very much best practice to ensure messages comply with both SPF and DKIM alignment requirements. If you don't, I think you'll see an elevated number of bounces due to DMARC failures. 

There are a couple of reasons why. First, various email filters clobber or don't always check DKIM signatures. A clobbered DKIM signature -- most likely seen as a "body hash did not verify" authentication error, means some intermediate or receiving mail server changed something in the email message, and whatever they changed was a field or content area protected (signed) by the DKIM signature. If you change the message, the DKIM signature is no longer valid. That's the point of DKIM -- providing proof that a message was not modified after the sender initiated it. Or in this case, providing proof that it was modified and thus, the signature can no longer be trusted.

If you don't have SPF alignment in place, but do have DKIM alignment in place, if something happens to invalidate that DKIM signature, then all you have left is the SPF alignment check. Your message won't pass it, and the message will fail DMARC, and may be rejected.

If you do have SPF alignment in place, but don't have DKIM alignment properly configured (or don't have DKIM in place at all), this is almost better than the reverse. These messages will pass SPF, and have proper SPF alignment in place, and they'll pass DMARC. Except in the case of email forwarding. Email forwarding is incompatible with SPF; SPF is based on checking the IP address of the "last hop" (most recent) mail server, and if mail is forwarded, it adds additional hops, and now the receiving mail server is no longer checking the correct IP address. Those messages will fail SPF, and the lack of DKIM alignment and/or lack of a DKIM signature will make the messages fail DMARC. These messages are also likely to be rejected.

Mail forwarding isn't easy in a world with DMARC. Thankfully, most folks have figured that out and don't blindly forward messages in ways that are incompatible with DMARC. But there are still a lot of legacy systems out there-- not everybody is up to date or considers DMARC compatibility to be a top priority. So you will see occasional issues due to this.
DMARC can be complex, but don't be afraid. My point here being that I do think you should implement DMARC to help protect your domain from unauthorized use. I just think you should do it ONLY if you can also ensure that the mail you send will pass both SPF alignment and DKIM alignment, to protect against these potential failure points.

Is email spam a solved problem?

Engadget asks, "Did AI kill off spam and we just didn’t notice?"

I'm not sure about THAT, but this article is still a very interesting read, and a good overview of how CAN-SPAM isn't considered a great law, how e-postage went nowhere (in spite of Bill Gates' help), and what TensorFlow is and why it matters.

Also: Wow! In this article, Neil Kumaran, Product Manager for Gmail, points out that "Gmail blocks about 10 million spam emails a minute." I guess the barbarians are still at the gate.

BIMI: Current Status? Should we bother?

Since lots of folks are reaching out to me, asking for help with BIMI records and/or wondering if it's something they should take the time to implement, I figured I would take a few minutes to explain the current state-of-the-state with regard to BIMI, and help to answer the question of whether or not you should move forward with it.

BIMI stands for "Brand Indicators for Message Identification," and if you want the really short version of what it is, it's this: a way to publish a logo and have that logo displayed on or near your email messages in whatever email platforms support it. Find out more about BIMI here, courtesy of Litmus.

I think that some folks are (perhaps over-) selling BIMI functionality as a trust feature for end subscribers. I'm not sure I buy that just yet. Platforms like Yahoo Mail and Gmail have already had a little logo display feature for a while now. Some smart folks have implemented that old style of logo, but I haven't seen much in the way of documented success of how you could demonstrate that it improved consumer confidence. But I do still think there's value -- it's a good branding measure, and I think you should do it. And if I'm wrong, and there is "trust value" to be found, then you'll benefit from that, as well.

From an ISP's perspective, BIMI is a tool to help drive adoption of DMARC. To implement BIMI, you need to implement DMARC, with a restrictive (p=reject or p=quarantine) policy. Meaning you have to lock your sending domain down to help prevent forged use of the domain. ISPs want this because it helps make it easier for them to tell good mail apart from bad mail. It's far from the only measure of goodness or badness, but it's still a useful thing.

So my guidance is, you should implement DMARC, and you should implement a BIMI record. Just be eyes-wide-open about what it does and what it likely doesn't do.

But don't immediately expect it to drive a significant increase in open and click rates or otherwise cause your email to significantly change how subscribers see it. It's good to add the little logo, but do keep in mind that is not the only thing governing whether or not your mail will get to the inbox and whether or not recipients are going to read and interact with your email messages.

Creating the BIMI record is easy. Your logo should be an SVG file, recommended to be on a white background, best if it can render well in a square or circle, and hosted on a website with SSL (https). When you've created and hosted that logo, you're ready to create your BIMI DNS record. After creating the BIMI DNS record (or if you need help and guidance on how to create it), pop on over to Mailkit's excellent BIMI tool.

ISP support for BIMI is limited today. Yahoo and Google have announced support for Yahoo Mail and Gmail, respectively. Yahoo Mail currently has support for BIMI in beta, and it's unclear when Gmail support will launch. Microsoft hasn't announced any support for BIMI as of yet, but I expect that they may jump on the BIMI bandwagon at some point in the future.

Also, right now, BIMI is essentially a simple thing. Implement and configure DMARC, then publish your BIMI record. But the standard hints at having some sort of trusted party or vetting service review and approve BIMI records at some point.

One example of this hit the news recently. Somebody called Entrust Datacard has announced a "Verified Mark Certificate" process and noted a leading bank as one of its first "verified" entities. How this ties into the current or near-future use of BIMI is unclear to me, and I can't really answer the question of whether or not this is something sender should pursue. It's possible that this or some other form of vetting or registration may be necessary in the future. I'll be keeping an eye out to see how this develops over time.

ARS Technica: How to read email headers

Here's a not totally bad guide from ARS Technica on how to read email headers. It's worth reading (and bookmarking for future reference.)

BIMI Moves Forward as Google Commits to Pilot Program

It looks like Gmail will have support for BIMI! As announced by Agari, Google will be running a BIMI pilot program soon. Read all about it here.

If you didn't already know, BIMI is meant to be a simple method for a brand or domain owner to publish a logo that is meant to be displayed adjacent to their email messages in an email client or webmail platform. Yahoo has beta-level support for it today.

Google previously would show a logo defined by the Google Plus profile associated with that email address, but future support for that was thrown in doubt when Google announced the shutdown of end user access to the Google Plus platform. Existing logos in place still seem to work. It's unclear what will happen in the future with regard to currently published logos or brand avatars.

Google and Yahoo seem to be the only mail platforms with announced support for BIMI at this time. Still, that's a significant chunk of a marketer's B2C subscriber list, covering Gmail, AOL, Yahoo and Verizon email domains.

Now Hiring: Amazon

Check out this job posting from Amazon for a Senior Product Manager in the AWS Digital User Engagement team. I am led to believe that this job likely will have an Amazon SES email focus, and that an email technology background and/or strong deliverability experience would be a huge plus. Happy hunting!

Now hiring: Sailthru / Campaign Monitor, Salesforce and more...

Looking for an email marketing-related job?

Sailthru / Campaign Monitor's "now hiring" site is a good place to start. They've even got a deliverability role posted.

Salesforce has a number of positions listed as well, including this Marketing Cloud consultant role, and you can work remote!

Also: Email Marketing Agency Trendline Interactive is looking to hire a Deliverability Strategist.

The American Bar Association is looking for an Email Marketing Director.

Iterable is looking for a an Email Deliverability Consultant.

Mailchimp is looking for a Deliverability-focused Software Engineer.

Got more job opportunities you'd like to share? Drop me a line. I'm always eager to help good people find employment.

Google Postmaster Tools doesn’t like us. How can I fix it?

Are you struggling with how to improve your sending reputation in Google Postmaster Tools? 250ok's LoriBeth Blair just published a very insightful blog post on this very topic.

Mailkit's BIMI Inspector Tool

Trying to publish a BIMI record? Wondering if you've done it correctly? Mailkit has this cool new tool in beta that will help you check and validate your BIMI record. Check it out!

AOL & Yahoo Mailbox Merger: It’s Done!

Verizon Media (aka Oath, aka Yahoo & AOL) folks report that the merger of the AOL user base into the Yahoo Mail infrastructure is complete! Congrats! I'm sure it was a long, hard road.

The bad way to do this would have been to keep the AOL accounts alive on some old, deprecated server cluster that people will eventually forget about, and some day it would crash and data would be lost. So while it was harder up front to immediately consolidate everyone onto one single platform, I'm definitely sure that in the long term, it's for the best.

When Gmail Was First Announced, People Thought It Was an April Fools' Joke

Gmail just turned 15 years old! Hard to believe that when it was announced on April 1, 2004, some people actually thought it was an April Fools' joke.

And now? Gmail's pretty much in charge of email. Don't count out Microsoft and Verizon (Yahoo), but most B2C senders will tell you that Gmail houses the largest single pool of subscribers that they send messages to.

And here's Google looking forward: Hitting send on the next 15 years of Gmail.

AMP: The next big thing?

AMP (short for “Accelerated Mobile Pages") is a method to place dynamic content in email messages, announced by Google, now supported in Gmail, and with Verizon (AOL/Yahoo) now announcing support for it. What is it? Should you care? Want to learn more about it? Lifehacker has posted a pretty good overview of it, albeit from a user's perspective. It's worth a read.

How Do I Avoid the Spam Filter?

Savvy deliverability expert Karen Balle answers a common but important question: How do I avoid the spam filter? And follows it up with a spot-on 6-Step Plan to Escape the Spam Folder.

Hello, Verizon Media Postmaster!

Verizon Media (previously known as OATH, previously known as Yahoo, previously known as AOL) has just launched their new Postmaster Site. Check it out!

As announced on their Postmaster Blog by Lead Postmaster Lili Crowley.

I think it's fair to assume that the legacy AOL Postmaster site is likely to shut down at some point in the near future. It brings a tear to my eye, as that site goes back quite a long time. Here it is in 2003, courtesy of the Internet Archive.

How to Make Sure Important Emails Stay Out of Your Spam Folder

Today, Gizmodo explains how to train Gmail, Outlook/Windows Mail, and Apple Mail on what shouldn't be considered spam.

They left out filter rules in Gmail -- it's pretty easy to create a filter rule in Gmail where the action is "never send to spam" -- this comes in very handy for me, as a lot of the mailing lists I'm on talk about spam and sometimes include samples. Though they might legitimately be spam, if they go to my Gmail spam folder, it makes it hard to see them.

GPT Downtime

Over on the Mailop list (ignore the SSL warning, that is a long-standing issue), people are noting that Google Postmaster Tools has been missing data and/or been glitchy and/or disallowing new domain registrations over the past days. If you had trouble before, you might want to try again now -- a few folks are saying that things seem to be getting better as of today (Wednesday), though it is unclear as to whether or not all missing historical data will be populated.

For more on Google Postmaster Tools, start here.

DMARC Policies Up 250% In 2018

Look at the explosive growth of DMARC implementations! This is great to see.

Read more about it over on dmarc.org.

Gmail SPF Status of Best Guess: What does it mean?

If, like me, you use Gmail to test and check email authentication results, then you're used to seeing SPF results that say pass or fail. But what does it mean when it says "best guess"?

Here's an example of a Gmail SPF results header that mentions "best guess":

Received-SPF: pass (google.com: best guess record for domain of bounce31@b.email.example.com designates as permitted sender)

What this means is that Google's "faking it" -- they are synthesizing a potential SPF record based on what information they can figure out about the domain. The exact rules that go into the synthesized SPF record are unclear. It could be past email history. It could be that reverse DNS between the sending IP address and sending domain match. Or it could be other things. That's not the important bit. The important bit is this: When Gmail tells you "best guess," it means it can't find your SPF record in DNS. That's a problem, and one you should investigate immediately.

In the example above, Gmail is saying that it can't find an SPF record for "b.email.example.com." Google's systems are smart enough to deal with it, so your deliverability to Gmail subscribers is unaffected. But other ISPs do not all have similar "fake an SPF record" functionality. That means that some other ISPs probably will block this same mail due to DNS failures or lack of DNS entries. If you review all your bounces, you'll probably see that this is the case.

And it can be a difficult issue to troubleshoot, if you see those bounces, then test with Gmail, and Gmail says that SPF passes. There's little to indicate that something is wrong, except for that magic phrase "best guess." Keep an eye out for it and know that it's a strong indicator of a potential DNS issue with your sending domain.

Gmail: Improving spam filtering with TensorFlow

Google just announced today how they've improved spam filtering using TensorFlow.

What's TensorFlow, you might ask? "An open-source machine learning (ML) framework developed at Google. These new protections complement existing ML and rules-based protections, and they’ve successfully improved our detection capabilities. With TensorFlow, we are now blocking around 100 million additional spam messages every day."

That's a lot of newly blocked email messages. Does it affect you, dear sender? Hopefully not, because Google says that they're "now blocking spam categories that used to be very hard to detect," including "image-based messages, emails with hidden embedded content, and messages from newly created domains that try to hide a low volume of spammy messages within legitimate traffic."

This doesn't mean suddenly it is unsafe to send image-heavy emails to your Gmail subscriber base. Google's not about to intentionally start blocking legitimate mail that people actually signed up for. But it does highlight that the closer you get to the edge of best practices -- if you have any practice failings in different areas, you could end up overlapping with one or more of these categories. If so, your messages might actually merit blocking. I'm guessing the chances that it affects a "legitimate" sender are pretty slim, though. But, just a reminder -- "Don't be like Goofus," as the old Goofus and Gallant stores in Highlights for Children used to tell us.

Spammers often do things like rotate through newly purchased domains, embed content in unique ways to try to evade filters, and use images to hide messaging from machine filter review. Don't do these things, and I think you'll probably be just fine.

2018: Did I get it right?

Just over a year ago I predicted that 2018 would be a year full of mailbox provider consolidation, many folks implementing DMARC, and ISP filtering getting more tougher than ever. Was I right? It sure sounds a lot like what I worked on much of the time last year.

Is it too glib to say 2019: More of the same? Because that's my first thought. Provider filters continue to get tighter, DMARC is bigger than ever, and AOL and Yahoo are not quite done merging. I suspect BIMI will grow in 2019, but I feel like we're two or three years out before somebody can declare that 20xx is the "year of BIMI."

I know I'll be focusing more on international (non-US) deliverability this year, but it's hard to say if that's just me, that might not be an "industry" thing.

What do you foresee for challenges and likely focus areas for email and deliverability in 2019?

Fun while it lasted...

Remember back in September when I blogged about how to create a Google+ account to make your brand icon display next to your emails when sending to Gmail users?

Well, looks like that won't work after a certain point, as Google is shutting down Google+ and will be deleting Google+ accounts and content.

I got a notice this morning that says my various Google+ accounts (used for logo display for various email sender tests I've set up) will be shut down on April 2, 2019.

It was fun while it lasted.

I wonder if this means Google will get on board with the BIMI logo display standard? Or there will be some other way to do this? We shall see.

Stop using NJABL! Now!

I just replied to an email from a guy who thinks I'm blocking his mail. I'm not, because I don't run a blacklist or a spam filter, and haven't done so for years. I would have loved to have helped guide him in the right direction, but my reply to him bounced because his mail server is misconfigured to use the NJABL blacklist.

The NJABL blacklist has been dead for almost five years.

If you still have it in your email server configuration, you're now going to block a lot of wanted mail. Because the domain's name servers just changed and they have a wildcard entry that now has the effect of "blacklisting the world."

You were warned...almost five years ago.

Characters in the local part of an email address

Need a "common sense" breakdown showing you what characters should be allowed in the username part (local part) of an email address? This handy guide from Jochen Topf covers exactly that.

It doesn't EXACTLY align with RFCs, but when you look at it from a common sense perspective, I agree with his categorization of each character. This would be a good thing to reference if you were building your own email capture form. (I'd probably also reject the "maybes" for an email capture form, but not reject them in an MTA configuration. Some of the "maybes" show up in bounce addresses somewhat regularly, but are almost never found in legitimate end user email addresses.)