This is another paragraph.

This is even more.

Značky: #Network, #testing, #administrative

Značky: #gmail, #downtime, #gpt, #google, #Network

Check it out: "The Deliverability role provides support and professional services to marketing and communication teams, helping them to reach their customers and achieve success.

"Bringing together an understanding of technical deliverability, data and analytics, marketing strategy and industry compliance, the Deliverability Consultant has a broad range of skills used to provide support, education and guidance.

"The Deliverability Consultant's day-to-day role is one of internal and client communication on a regional and global level; answering ticket-based customer support escalations; problem solving and investigation, providing analytical insight and strategic marketing solutions to clients; and the technical setup and management relating to email and digital messaging."

Click here for more information or to apply .

You may recall that SAP acquired Emarsys back in late 2020, after ex-Salesforce Marketing Cloud CEO Bob Stutz left Salesforce for SAP, leading to another Salesforce alum, Joanna Milliken, becoming CEO of Emarsys.

Značky: #Network

What is it? It's a way for you to ask Google to reconsider their Gmail filtering decisions for your emails, to give them more information and contact information, hopefully allowing them to improve their spam filtering and perhaps allowing them to reconsider putting your mail in the spam folder or blocking it.

Why should you do it? Because every little bit helps. In almost all cases, it will not garner a response, but Google says that they do review all submissions. In some cases, this will cause them to help improve your ability to get mail to the inbox -- my understanding being that this submission does create an internal ticket in their system that will be reviewed by the right people.

There are caveats to keep in mind here:

• This is not a fast process. Not only does Google specifically say that they will not respond, they warn that it could take a couple of weeks to see any improvement -- if Google agrees that improvement or adjustment is warranted. And no, there is no escalation or bypass process available to senders to speed things up.
• There's no status update or followup process to confirm if this process helped to improve things. All you can do is measure your inbox placement and deliverability rates both before and after. Keep an eye out to see if things improve after two weeks.
• This process is not a substitute for sending email correctly. Broken authentication, failing DKIM or DMARC, sending unwanted mail or mail with very low engagement, these are all things that will impede your ability to get messages delivered to the inbox. Asking Google for help is not going to help, if you have a clear "best practice" sending problem. Your mail has to be technically correct and entirely desired -- there's no way around that.

Even keeping those limitations in mind, I have seen this process help improve delivery and inbox placement at Gmail for some senders. So, I do suggest that you (or your deliverability consultant) should submit a sample message to Google via this process, whenever you're working on troubleshooting a Gmail deliverability issue.

(And if you are troubleshooting a Gmail deliverability issue, why not check out the Spam Resource Deliverability Guide to Gmail ? You might find it useful.)

Značky: #google, #isp, #gmail, #Network

Značky: #Network, #2021

Lots of job openings feels to me like that's a good sign for our industry. People need our help and expertise, now more than ever!

Don't be afraid to reach out to me if you'd like me to post a deliverability-related job opening to Spam Resource. I don't charge for this service, but I do reserve the right to not post all openings.

Značky: #Network

SPF aka Sender Policy Framework is a form of email authentication. It's basically just a DNS record that you configure for your domain, and that DNS record usually just contains a list of the IP addresses of your mail servers (or somebody else's mail servers that are allowed to send mail on behalf of your domain). Wikipedia's the place to start if you want to dive into what SPF is in great detail. If you're reading on past this point, I'm going to assume that you know what an SPF record looks like .

When you create an SPF record, the last bit of it ends in the "all" mechanism, with one of three "modifiers:" ~all, -all or ?all. Here's what each one does.

• Using ?all means "neutral/no" policy defined. This is sort of useless. You might see an ISP do this to say, "I'm not sure what all of my IP addresses are, but here, at least you have these ones, you can perhaps choose to whitelist my mail based on these." Cranky nerd jerks who want to fight about whether or not SPF should even exist will sometimes use this, as well. (If you find a "+all" mechanism, then you've definitely found one of those.)
• Using ~all means you're setting a "soft fail" policy. You see this most often. The sender is saying "I am pretty sure I've listed all of my IPs in my SPF record, but I'm hedging my bets slightly."
• Using -all means you're setting a "hard fail" policy. The sender is saying "I've for sure gotten my SPF record right, this is all of my IPs." It implies that ISPs should treat mail harshly if it references that domain but fails SPF.

For most senders, I recommend -all. Some folks recommend ~all, and that's okay, too, but historically there was an implied modest deliverability boost for using -all, so that's why I initially went that route, and why I still recommend it. For a lot of ESP send platforms, their use of a domain or subdomain is often pretty regimented and templated and the chances of sending mail through some other "weird way" that you didn't initially contemplate is very low. Meaning -all is generally going to be safe to use in that scenario.

This can also go hand-in-hand with DMARC. DMARC (and a DMARC reporting tool) can help you monitor for mail that fails SPF, helping you to catch when you might have accidentally gotten your SPF record wrong (perhaps not including all IP addresses).

For another point of view, EasyDMARC covers this on their site here . They recommend ~all instead of -all, but sometimes smart people can come up with different guidance, and I think that's okay.

Značky: #Network, #spf

They say: "Sitecore is growing and so our Email Deliverability Department!  Email Deliverability is our number one priority for our clients and our new Sitecore Send product. As a deliverability specialist, you will have to proceed on technical investigations into clients' email systems, review messages sent by our users, and make recommendations based on analyzing messages, client's methods, statistics, and strategies."

The role is posted as being in Ottawa and I'm unclear on whether or not remote is an option. I'm going to assume yes, since it is 2021.

You should apply! Click here for more info .

Značky: #Network, #sitecore

Over on the Kickbox blog , my colleague Jennifer Nespola Lantz talks about sending domains and what you need to think about if you want to share domains between multiple email provider platforms. It's a common thing, right? You are probably using more than one service provider, CRM or automation platform. You've probably also got a corporate email system in the mix. Can you send from more than one platform using the same domain? And if so, should you? What are the limitations and concerns around using the same domain to send from multiple systems? Jen walks us through it .

Značky: #authentication, #Network, #kickbox, #domains