BT Internet

I’ve been seeing reports for the last few weeks that a lot of folks are having problems getting mail into BT Internet. Many people are reporting the response

smtp;554 Message rejected for policy reasons (3.2.2.1) – Please report any problems to BT via the postmaster btinternet.com mailbox and include your sending ip address with an example header of your email

Unfortunately, the postmaster account appears to not be as responsive as it used to be. This may be a consequence of the move from Yahoo to Critical Path and then CP being bought by Openwave.
One thing people are suggesting is that valid and correct SPF records are crucial for delivery to BT Internet. I don’t know if this is really the fix, and  many of the companies reporting the problem have valid SPF records. But it’s always a good idea to check your SPF with our authentication checking tool.
 

Related Posts

Your purchased list … is spam.

This morning I got spam from someone selling email addresses. The mail starts:

Read More

My panels from #EEC16

I had the privilege to be a part of two panels at EEC16, with some of the best folks in the business.
The first panel was “Everything You Ever Wanted to Know About Deliverability, but Were Afraid to Ask.”  eec_deliv_slide
We had a lot of great audience questions.
The first question, which was awesome (and I don’t think planted) was: “What is the most important thing we can do to improve our deliverability?”
All of us had really similar answers: pay attention to your data and your acquisition. Deliverability starts with your data: good data = good deliverability, poor data = poor deliverability. How you acquire addresses is vital to any email program.
I’ve had dozens of sales calls with potential clients over the years. Most of them tell me lots of stuff about their marketing program. I hear details of engagement, data hygiene, response rates, CTRs, bounce handling. But very, very few people spontaneously tell me how they’re acquiring addresses. That’s so backwards. Start with acquiring addresses the right way. Deliverability is all in the acquisition step. Of course, you need to nurture and care for those subscribers, sent the right message at the right time and all the good things we talk about. None of that matters if you don’t start with good data.
Another question was about spamtraps. The panel had me take this one. I’ve written extensively about spamtraps and what they do and what they mean. The important thing to remember, though, is that a spamtrap is a signal. If you have spamtraps on your list, then there is a problem with your data acquisition. Somehow, people are getting addresses that do not belong to them on the list.
Spamtraps are a problem, but not for the reasons many people think they are problems. Folks get upset when their mail is blocked because of spamtraps. Blocking isn’t the only damage, though. For every spamtrap on a list that is one less responsive addresses. It’s one customer who you are not reaching. If there are spamtraps on a list, it’s likely there are deliverable addresses that don’t belong to your customers, too. These recipients are going to view that mail as spam. They didn’t sign up, they didn’t ask for it, they don’t want it. They’re going to complain, hurting your reputation. Too many of these recipients and delivery will suffer.
Spamtraps are a warning that something is wrong. That something is usually your data acquisition process.
Questions went on through the session and ranged from things like how to get mail to B2B inboxes and is there value in certification. We also had some insightful questions about authentication.
The second panel I was on was the closing keynote panel: “ISP Postmasters & Blacklist Operators: Defending Consumer Inboxes.” This was where I got to show my incoming mail chops, a bit. I was a last minute fill in for the panel and I am honored that Dennis and Len thought I could represent the incoming mail folks. It’s not like I’m out there writing filters, but I do pay attention to what the filter operators are saying and doing.
I think it is important for marketers to get a feel for what’s really going on at the ISPs. They aren’t trying to stop real mail, they’re trying to stop malicious mail. Matt from Comcast talked a lot about how marketers and ISPs share customers and the ISPs are trying to keep those customers safe and happy. Jaren discussed some of the decision making processes his company goes through deciding whether to err on the side of letting spam through or filtering good mail. Tom discussed how his blocklist works with some brands to help stop phishing attacks against those brands.
Overall, I think the session was a great success. The conference was great and I am looking forward to going back next year.
Were you at either panel? What did you think?
+eddc

Read More

Who can you trust?

I’ve been recently dealing with a client who is looking at implementing authentication on their domains. He’s done a lot of background research into the schemes and has a relatively firm grasp on the issue. At this point we’re working out what policies he wants to set and how to correctly implement those policies.
His questions were well informed for the most part. A few of them were completely out of left field, so I asked him for some of his references. One of those references was the EEC Email Authentication Whitepaper.
My client was doing the best he could to inform himself and relies on industry groups like the EEC to provide him with accurate information. In this case, their information was incomplete and incorrect.
We all have our perspectives and biases (yes, even me!) but there are objective facts that can be independently verified. For instance, the EEC Authentication whitepaper claimed that Yahoo requires DKIM signing for access to their whitelist program. This is incorrect, a sender does not have to sign with DKIM in order to apply for the Yahoo whitelist program. A bulk sender does have to sign with DKIM for a Y! FBL, but ISPs are given access to an IP based FBL by Yahoo. I am shocked that none of the experts that contributed to the document caught that error.
Independent verification is one reason I publish the Delivery Wiki. It’s a resource for everyone and a way to share my knowledge and thought processes. But other experts can “check my work” as it were and provide corrections if my information is outdated or faulty. All too often, senders end up blaming delivery problems on evil spirits, or using “dear” in the subject line or using too much pink in the design.
Delivery isn’t that esoteric or difficult if you have a clear understanding of the policy and technical decisions at a range of ESPs and ISPs, the history and reasoning behind those decisions, and enough experience to predict the implications when they collide.
Many senders do face delivery challenges and there is considerable demand for delivery experts to provide delivery facts. That niche has been filled by a mix of people, of all levels of experience, expertise and technical knowledge, leading to the difficult task of working out which of those “experts” are experts, and which of those “facts” are facts.

Read More